An inherent problem I've ran into at my day job is the necessity to point to different versions of images. Ideally, these images would be tagged, so we could, say, point to each image of a release, or timestamp, or a build. Currently, they don't do that (priorities of different groups, and all that).
To offset local development needs, another co-worker pointed out in the past his prior teams had used docker override files to accomplish this task. I'm all about automation and offloading tweaks and convenience fixes to configuration files, so this was right up my alley.
My local docker environment was pointing to the
:latest docker images. Some code I relied on lived in the
:develop images. Let's not talk about the path that lead to this discovery, lots of messages and conversations ensued to figure this out.
I read up on extending the docker-compose file. From there, I copied our original
docker-compose.override.yml and adjusted the
docker-container.image to point from
:develop. Most importantly - I knew not every image file needed to be pointing to
:develop, so only those files were changed.
To get up and running, I didn't need to do any configuration changes, no command line arguemnts. It was handled by following the established convention that docker looks for the
override.yml and uses it if present.
I brought the containers up - and my original problem I was trying to solved - was complete! I was back in
NOTE: To start a normal environment run
docker-compose up -f docker-compose.yml - this will skip the
I didn't think it through - I copied the entire file. I was worried it would drop certain properties. This was unnecessary, and creates a maintenance issue - if they change a property in the main
docker-compose.yml mine would override it! So I pruned the
docker-compose.override.yml down to the bare minimums - just the
image: paths pointing to
Through my pairing down, I also discovered that they look at the
version: x.x number in both files - if they don't match, it'll throw an error and fail.
Now, as we've moved forward, there's been talk of additional
docker-compose files being necessary. And no one wants to maintain their local
docker-compose.yml file and change which image it posts to, and not accidentally commit those changes. No matter how rad a developer you are - accidents happen, and we want to minimize the ownership of the group of people who might accidentally break that file.
This gives birth to additional
docker-compose.whatever.yml files! So we can (in the future) point to different environments or snapshots and execute them via:
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up
From the docker docs:
Options: -f, --file FILE Specify an alternate compose file (default: docker-compose.yml)
docker-compose runs with
docker-compose -f says “don’t do that, use this file” or in the case of multiple
-f bombs, “use these files” (take note - each
.yml file has to be preceded by a
-f, a la
-f docker-compose.yml -f docker-compose.release.yml).
If you have a
docker-compose.override.yml and you don't want to deal with removing it/stashing it - you can make it ignored on execution by running
docker-compose -f docker-compose.yml (or whatever
.yml file you want).