Learning on the go with python container builds - part 2

Chapter 2: let's get bigger with our python footprint and containers:

Got some new experiences some time back but did not get a chance to post them as I have been extremely busy lately. Happy Friday to everyone and here we go:

Let’s take as an example an application for which we separate its functionality into three-tiers following a microservice architecture. This is a pretty common architecture for multi-service applications. Our example application consists of:

• a UI tier – running on an nginx service
• a logic tier – the Python component we focus on
• a data tier – we use a mysql database to store some data we need in the logic tier

To make things simple we should create our directory structure as follows from the best practices:

Project

├─── web

└─── app

└─── db

We have already covered how to containerize a Python component in the first part of this blog post series. 

To manage networking and attach containers is very tedious and that's, where docker-compose, comes into use.

Docker Compose file:

We define a list of services - DB uses base image directly and no other configuration, app, and web will have their own dockerfiles

We need to mention where the service image is - the build field requires a path with a dockerfile inside.

Sample docker compose file:

Let’s see how to deploy the project with Docker Compose. 

All we need to do now is to place the docker-compose.yaml at the root directory of the project and then issue the command for deployment with docker-compose.

All this is triggered with only one command.

Check the running containers:

Best practices to write docker-compose files:

1. Network Separation? - If we do not set any network then all our containers will end in the same network.This may not be a good thing if we want to isolate our containers in different networks. For example - 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.
2. Docker Secrets - 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>.

1. 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:

Another example of dockerization for NGINX proxy and Postgres DB