$ docker-compose up -d Creating network "project_default" with the default driver Pulling db (mysql:8.0.19)… … Status: Downloaded newer image for mysql:8.0.19 Building app Step 1/6 : FROM python:3.8 ---> 7f5b6ccd03e9 Step 2/6 : WORKDIR /code ---> Using cache ---> c347603a917d Step 3/6 : COPY requirements.txt . ---> fa9a504e43ac Step 4/6 : RUN pip install -r requirements.txt ---> Running in f0e93a88adb1 Collecting Flask==1.1.1 … Successfully tagged project_app:latest WARNING: Image for service app was built because it did not already exist. To rebuild this image you must use docker-compose build or docker-compose up --build. Building web Step 1/3 : FROM nginx:1.13-alpine 1.13-alpine: Pulling from library/nginx … Status: Downloaded newer image for nginx:1.13-alpine ---> ebe2c7c61055 Step 2/3 : COPY nginx.conf /etc/nginx/nginx.conf ---> a3b2a7c8853c Step 3/3 : COPY index.html /usr/share/nginx/html/index.html ---> 9a0713a65fd6 Successfully built 9a0713a65fd6 Successfully tagged project_web:latest
To rebuild images we can run a build and then an up command to update the state of the project containers:
$ docker-compose build $ docker-compose up -d
As we can see, it is quite easy to manage the lifecycle of the project containers with docker-compose.
Best practices for writing Compose files
Let us analyse the Compose file and see how we can optimise it by following best practices for writing Compose files.
Network separation
When we have several containers we need to control how to wire them together. We need to keep in mind that, as we do not set any network in the compose file, all our containers will end in the same default network.
This may not be a good thing if we want only our Python service to be able to reach the database. To address this issue, in the compose file we can actually define separate networks for each pair of components. In this case the web component won’t be able to access the DB.
Docker Volumes
Every time we take down our containers, we remove them and therefore lose the data we stored in previous sessions. To avoid that and persist DB data between different containers, we can exploit named volumes. For this, we simply define a named volume in the Compose file and specify a mount point for it in the db service as shown below:
We can explicitly remove the named volumes on docker-compose down if we want.
Docker Secrets
As we can observe in the Compose file, we set the dbpassword in plain text. To avoid this, we can exploit docker secrets to have the password stored and share it securely with the services that need it. We can define secrets and reference them in services as below. The password is being stored locally in the project/db/password.txt file and mounted in the containers under /run/secrets/<secret-name>.
We have now a well defined Compose file for our project that follows best practices. An example application exercising all the aspects we discussed can be found here.
What’s next?
This blog post showed how to set up a container-based multi-service project where a Python service is wired to other services and how to deploy it locally with Docker Compose.
In the next and final part of this series, we show how to update and debug the containerized Python component.
フィードバック
「コンテナ化されたPython開発–パート0」に関する2つの考え