Docker compose specifying image vs Dockerfile

Question

I'm new to docker-compose and after reading the docs I still have some unclear things that comes to my mind.

So far when I used docker I kept the builds in the following directory tree:

builds:
    Service A:
        Dockerfile
        ServiceA.jar
    Service B:
        Dockerfile
        ServiceB.jar

So when I want to run all I use some shell script, until I read about docker-compose.

I saw that there are 2 ways of creating and running a service (in manner of copying files)

1. Specifying build: path/to/my/build/directory and linking it with volumes: so it can see live code and refresh the service
2. Specifying image: (for example java:8) and then use the volumes: as above

What I want to understand is what is the best practice using docker-compose before I dive in to it, should I create specify image for each service (and replace with the FROM inside the Dockerfile) or should I specify paths to build folders and volumes to keep live code changes, and how does volumes work and their usages when using image tag

Thanks!

Answer 1

In Docker you can simply run services as containers and you can put the state of each service in a volume. This means for you:

• The service is run as a runtime container which will be started from an image.
• The service's binaries are inside an image, the service itself writes data to volumes.
• The image can be either pulled from a image repository or build on the target environment.
• Images can be build with the command docker build or the docker-compose build section.

In your example this means:

1. Keep the directory structure.
2. Use the docker-compose build section to build your immages according your Dockerfiles.
3. Configure your Dockerfile to put the binaries inside the image.
4. Simply start the whole stack including the build with docker-compose up -d
5. Your binaries changed? Simply replace the whole stack with docker-compose up --build --force-recreate -d. This command will rebuild all images and replace containers.

Why you do not place the binaries inside the volume:

• You lose the advantage of image versioning.
• If you replace the binaries files you cannot simply fallback to an older image version.
• You can retag images before you deploy your new version and fallback if an error occurs.
• You can tag and save running containers for fallback and error investigation.