If you need to find out which image a Docker Compose service is using, you need the docker compose images command. In this short tutorial, I’ll show you how it works.
:idseparator: -
:idprefix:
:experimental:
:source-highlighter: rouge
:rouge-style: pastie
:imagesdir: /images
Recently, I deployed a minor feature change to a small web-based application that was running with Docker Compose.
On checking the application post-deployment, however, I was surprised to see that the expected change hadn’t been deployed.
Just to be sure, I confirmed that:
. New versions of the relevant Docker images had been built.
. The new images had been pushed to the remote Docker container registry.
. The application had been re-deployed using docker compose down
and docker compose up -d
.
. The browser’s cache had been cleared.
Given that, I was confused as to why the expected change wasn’t deployed.
At this point, I accessed the remote PHP service using docker exec and checked the relevant code.
Sure enough, it hadn’t been updated.
It seemed that, for some reason, the new images hadn’t been deployed.
The question was though, how could I check which image was being used by the application?
I’d not needed to do this before, as deployments had always gone pretty smoothly, so I didn’t know how.
Docker being Docker though, I figured that there had to be a command which would tell me what I needed to know.
So, after some searching, I found the docker compose images
command.
Quoting https://docs.docker.com/compose/reference/images/[the official documentation], this command:
Lists images used by the created containers.
It prints out a list of images used by the currently running containers, along with details, such as the image’s tag, id, and size.
On running it from the directory where the application’s Docker Compose configuration files were located, I saw output similar to the example below.
Container Repository Tag Image Id Size
linkedin-post-scheduler-email-1 mailhog/mailhog v1.0.1 4de68494cd0d 392MB
linkedin-post-scheduler-nginx-1 nginx 1.21.6-alpine 51696c87e77e 23.4MB
linkedin-post-scheduler-php-1 linkedin-post-scheduler_php latest 447fe0e7ab6d 258MB
It was then that I saw in the Tag
column, that the php container was still using the previous version of the image.
After further investigation, it turned out that I had changed https://docs.docker.com/engine/context/working-with-contexts/[the Docker Context], for some reason, between building and pushing the images, from the remote to the local Docker daemon.
After changing it back to the remote Docker daemon, pushing the applicable images, and redeploying the application, the functionality was working as expected.
So, if you need to find out which images Docker Compose containers are using, use https://docs.docker.com/compose/reference/images/[the docker compose images command].
Oh, and check that you’re using the correct Docker Context before redeploying the application.
While it was a frustrating experience, it’s also encouraged me to use a CI/CD tool, regardless of how small an application is (wherever practical).
[.img-nopadding]
image::books-and-courses/deploy-with-docker-compose/promo-banner-small.png[link=“https://deploywithdockercompose.com/?utm_campaign=website&utm_source=matthewsetter.com&utm_medium=tutorial&utm_content=textlink&utm_term=find-which-images-docker-compose-containers-are-using”]
Do you need to get your head around Docker Compose
quickly?
What about needing to dockerize existing applications to make them easier to
deploy, reducing the time required for develwpers to get started on projects, or learning how to debug
an existing Docker Compose-based app? Then this free book is for you!
Join the discussion
comments powered by Disqus