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.
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 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 258MBIt 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 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 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).
Want to know how to deploy a PHP app to production (or any other remote environment)? In this tutorial, I’ll show you all the steps involved, and provide background information along the way, so you can build on what you’ll learn.
Docker and Docker Compose simplify setting up local development environments for developing PHP apps and for deploying them, whether locally or remotely. But, when your PHP app is running inside a Docker container, how do you run your tests — especially test suites that depend on resources such as database or caching servers? In this tutorial, I’ll show you how to do so.
Building a local development environment which mirrors production hasn’t, historically, been an easy task. But with Docker, it’s become almost trivial. In this tutorial, you’ll learn do so by dockerizing a PHP application and deploy it locally with Docker Compose.
Sometimes, you need to override an image’s command when launching a container with Docker Compose. If you need to do that, in this tutorial I’m going to show you how — without the need to update an image’s Dockerfile or shell scripts.
Please consider buying me a coffee. It really helps me to keep producing new tutorials.
Join the discussion
comments powered by Disqus