build interrupts after COPY/ADD command in Dockerfile

[akloeber]

The following Dockerfile succeeds to build an image with docker:

FROM dockerfile/java:oracle-java7
RUN mkdir -p /opt/selenium
COPY selenium-server-standalone-2.44.0.jar /opt/selenium/selenium-server-standalone.jar
RUN echo not executed through decking g
EXPOSE 4444
ENTRYPOINT ["java", "-jar", "/opt/selenium/selenium-server-standalone.jar"]

$ docker build -t img-selenium-base selenium-base
Sending build context to Docker daemon 35.17 MB
Sending build context to Docker daemon 
Step 0 : FROM dockerfile/java:oracle-java7
 ---> 6f2d4b7c53a2
Step 1 : RUN mkdir -p /opt/selenium
 ---> Using cache
 ---> e6f396f6a743
Step 2 : COPY selenium-server-standalone-2.44.0.jar /opt/selenium/selenium-server-standalone.jar
 ---> Using cache
 ---> 699f59fc00e6
Step 3 : RUN echo not executed through decking g
 ---> Using cache
 ---> a022ecbfb59d
Step 4 : EXPOSE 4444
 ---> Using cache
 ---> d01095ca9cd8
Step 5 : ENTRYPOINT java -jar /opt/selenium/selenium-server-standalone.jar
 ---> Running in f5a881a9b582
 ---> ca86c1f2eb8a
Removing intermediate container f5a881a9b582
Successfully built ca86c1f2eb8a

But when used to build with decking the build interrupts after the COPY command:

$ decking build all
Looking up build data for img-selenium-base
Building image img-selenium-base from ./selenium-base/Dockerfile
Uploading compressed context...
Step 0 : FROM dockerfile/java:oracle-java7
 ---> 6f2d4b7c53a2
Step 1 : RUN mkdir -p /opt/selenium
 ---> Using cache
 ---> e6f396f6a743
Step 2 : COPY selenium-server-standalone-2.44.0.jar /opt/selenium/selenium-server-standalone.jar

The corresponding decking.json is:

{
  "images": {
    "img-selenium-base": "./selenium-base"
  },
  "containers": {
    "selenium": {
      "image": "img-selenium-base",
      "port": ["4444:4444"]
    }
  },
  "clusters": {
    "main": ["selenium"]
  }
}

The same applies if the ADD command is used instead or if the syntax COPY ["selenium-server-standalone-2.44.0.jar", "/opt/selenium/selenium-server-standalone.jar"] is used.

Environment: Mac OS X 10.10.2 decking 0.3.0

docker version output: Client version: 1.5.0 Client API version: 1.17 Go version (client): go1.4.1 Git commit (client): a8a31ef OS/Arch (client): darwin/amd64 Server version: 1.5.0 Server API version: 1.17 Go version (server): go1.4.1 Git commit (server): a8a31ef

boot2docker version output: Boot2Docker-cli version: v1.5.0 Git commit: ccd9032

[makeusabrew]

Yup, same as #76 (which I appreciate is closed - my bad!).

This won't exactly be resolved in 0.4.0 (released tomorrow) but it will at least throw the error properly.

It's all due to the last throwaway line in the images section of the docs:

http://decking.io/#format-images

"When building an image the relevant Dockerfile will be copied to the root of your project (i.e. to the same directory as your decking.json file) such that any ADD directives will be relative to your project root."

Which is all because when I built decking to scratch my own itch I wanted to keep various Dockerfiles in subfolders but build different images from the root of the project tree, and was sick of not being able to ADD something outside Docker's "context" (which I'm not sure if they've fixed or changed - I'm out of the loop).

Tomorrow's release will at least re-iterate what decking is doing each time decking build is called, but the copy-to-root behaviour probably at least needs to be opt in or out.

[makeusabrew]

https://github.com/makeusabrew/decking-example should at least shed some light on what I was thinking of when originally building decking (although it is a very contrived example)

[akloeber]

Sure, now I understand what you wanted to achieve.

But do you think it is the right way to separate docker stuff and application stuff on the top-level of the folder hierarchy? The Dockerfile and the corresponding sources belong together (if the application gets refactored it is very likely that the Dockerfile also has to be adjusted, just count the references inside the Dockerfile into the sources). So they should be put together to get a high cohesion when creating different modules.

[makeusabrew]

I'm honestly not sure. On the whole my preference is almost the opposite; I don't want my source and Dockerfiles too tightly coupled in terms of where they physically sit on the filesystem, but Docker's restrictions on 'build context' usually enforce this - you can't ADD or COPY something outside / above the current context (i.e. ADD ../foo.txt doesn't work). This poses a problem when your overall application is comprised of many different services which are organised under the same overarching repository, especially when they share some common library sources. You want to build N different container types from N different docker files, but you want them to all share a common root level context. That's where decking was originally coming from.

Anyway; I've noticed a couple of old PRs I've neglected, one of which specifically addresses this issue and gives the user the choice of which directory to use as context (#49). I'll get this merged any into the 0.4.0 release today.

Lastly: to be honest I think decking's strength is container & cluster management. Image building is really just a small convenience, but perhaps more of a distraction from decking's main focus.

[makeusabrew]

Landed in the above commit and will go out with 0.4.0 - you can now pass a run time --context flag OR specify it as part of decking.json configuration. Default is still to assume wherever decking.json lives is the build context.

[makeusabrew]

Fixed in 0.4.0

[akloeber]

Checked with decking@0.4.0 and now it works as documented when setting "context": ".".

[makeusabrew]

Great :)