Help, Docker Compose Runs Old Containers!
When you build a fresh image and run
docker-compose up, the changes
should take effect, right?
Is it docker-compose or is there an issue with my Dockerfile?
Are You Using :Latest?
The first thing to say, is a warning against using the :latest tag in any context except for local development.
You can read more here, but basically you’re in for a lot of potential gotchas if you try to work with :latest for deployment processes.
Using good tags for your Docker image, and setting them explicitly when deploying a new version of your stack is one of the best thing you can do to save a lot of time in the future.
But what if you’re working locally?
Caching Is Tricky Sometimes
The most probable explanation is, that you are still trying to run an old image. Either your tooling, the way you run your containers or your Dockerfile are playing tricks on you.
Docker compose does not see a need to recreate a container or your build used old cached layers. In any case, the changes made to your Dockerfile do not reflect the state of the image run by docker-compose.
The Quick Workaround
In the case that you just want to get it working right now, here’s a quick fix to get the changes you want to see.
Instead of just building your images, and then trying to up them, consider this:
$ docker-compose down $ docker-compose build $ docker-compose up
Which can be shortened to:
$ docker-compose build $ docker-compose up --force-recreate
This will make sure that even ‘unchanged’ containers are stopped and recreated in any case.
Maybe your issues are happening during the image build. If there’s a caching issue with your Dockerfile, you can rebuild it from scratch every single time, and then recreate all containers with the following two commands:
$ docker-compose build --no-cache $ docker-compose up --force-recreate
This will rebuild all images from scratch. If you want to be more selective, you could use:
$ docker build --no-cache -t imagename .
And recreate the containers with docker-compose afterwards.
All of those are meant to be temporary fixes! You should not have to rely on them in the long term.
The Way Forward
You should dig into your Dockerfile and setup, to find out why you are having these issues! If you don’t your workflows will be unnecessarily slow and otherwise not reliable.
If you are experiencing similar issues with your deployments, you should switch towards more meaningful tags than :latest, and rethink the way you’re pushing out new versions of your applications.
Subscribe below for occasional tips about working with Docker and to learn more about deploying containerized apps!
Join the mailing list!
Subscribe to get notified about future articles and stay in touch via email.
I write about Kubernetes, Docker, automation- and deployment topics, but would also like to keep you up to date about news around the business-side of things.