Skip to main content
In this article, we’ll explore an enhanced version of a Docker Compose file, showcasing improvements over the original version. This guide details the migration from an older, simpler version of the Compose file to a more advanced version 3 format, enabling better configuration and robust networking features.

Original Docker Compose Configuration

Below is the initial Docker Compose setup:
Previously, we demonstrated a very basic, version 1 Docker Compose file. While the older format is straightforward, it lacks support for advanced features. Therefore, we will upgrade the configuration to version 3.

Upgrading to Docker Compose Version 3

Below is an updated Compose file reflecting the changes to version 3 and a modification to the port for the result service:
For more details on the differences between Docker Compose file versions, consult the Docker Documentation. Although a compatibility matrix is available in the documentation, this article focuses on real-world changes, so no visual diagram is provided.
The image shows a section of the Docker documentation website, displaying a compatibility matrix for Docker Compose versions.

Organizing Configuration with the Services Section

In version 3, migrate all configuration settings under a top-level services section. For example, when using version 3.9, your Docker Compose file might look like this:
With more advanced options, you can specify the build context and Dockerfile explicitly:
If you initially had a simplified build configuration like:
…remember to nest it within the services section along with the version declaration.

Updated Docker Compose File with Services Section

The following updated Docker Compose file demonstrates these changes by specifying the version and nesting all service definitions under the services key. In Visual Studio Code, simply indent your existing service definitions under services:.
With Docker Compose version 3, a default network is automatically created for all services. This allows containers to communicate using service names (e.g., the vote service can reach redis or db simply by their names). Consequently, the explicit links section is no longer necessary.

Deploying the Application

Once you’ve updated your Compose file, deploy your application using the docker-compose up command. If your Docker Compose file resides in a directory named “code”, the directory name is used as the project name:
Below is the final version of our Docker Compose file without the obsolete links:
The Docker Compose process creates objects like networks and containers with names prefixed by the project name (in this case, “code”). For example, the network is named “code_default” and the containers follow a similar nomenclature (e.g., “code_worker_1”).

Handling Database Connection Issues

At deployment, you might encounter errors such as “no such device or address” or “waiting for DB” in the logs. These indicate that the worker and result services are having trouble connecting to the PostgreSQL database. This issue occurs because the PostgreSQL image now requires a default superuser password via the POSTGRES_PASSWORD environment variable. To address this, update the DB service by adding the necessary environment variables. The configuration below sets POSTGRES_USER and POSTGRES_PASSWORD to “postgres” for consistency:
After applying these changes, run the docker-compose up command again. With the corrected configuration, all services should start without issue.

Testing the Application

You can now verify the setup by accessing the voting app at http://localhost:5000 and viewing the results app on port 5001. When you cast a vote for “cats,” the results should immediately update to show 100% for cats. Changing your vote to “dogs” should prompt a similar update, confirming that the configuration is correct and the Docker Compose file is working as intended. That’s it for this lesson. Happy Dockering, and see you in the next article!

Watch Video

Practice Lab