[PYTHON] [With image diagram] Nginx + gunicorn + Flask converted to Docker [Part 2]

Summary of this article

• As Step 3 of Web application learning roadmap with Python *, ** Start the Web server and App server created in Step 1 in the Docker container ** I will describe the procedure to set. The article consists of two parts, the first part and the second part. First part: Docker conversion Second part: docker-compose introduction` It will be the description about.

Premise

Part 1 This is a continuation of the article.

Final product

Image diagram

Source code

See the Github repository (https://github.com/mintak21/infra-server-env-build-practice/tree/4_docker-compose).

Brief commentary

In the first part, we created a Dockerfile to start the Web server and App server in each container. In order to reduce the cost of starting these containers (in terms of start command), we will start two containers with one docker-compose command. The main changes are as follows.

--Added docker-compose configuration file --Correct the connection destination of the nginx configuration file

docker-compose.yml file

In this case, it is necessary to specify the following as the relationship between containers and the relationship between container hosts.

--App server --Belongs to the same network as the web server --Web server --Port forwarding of container port to host specific port --Belongs to the same network as the App server --Must be after the App server is started

docker-compose.yml

version: "3.7"  #Specify the version of the compose file
services:       #Add description for each container under this layer
###########App server settings from here###########
    app-server:   　　　　　　　　　　 #Can be a service name or host name
        container_name: app-server  #The name of the container
        build:                      #Blocks required when building with a Dockerfile prepared by yourself
            context: ../../         #Specify the path when docker build, relative path from where the yml file is
            dockerfile: deployment/dockerfiles/app-server/Dockerfile #Dockerfile to use. Specified from the context path
        networks:                   #Settings for the network to which this service belongs
            my_host_network:        #See below my_host_Belong to network
                aliases:
                    - uwsgi-server  # my_host_It will be possible to distinguish by this name on the network
        expose:
            - 9876                  #Put this port in the LISTEN state
        restart: always             #Service restart policy
###########Up to this point App server settings###########
###########Web server settings from here###########
    web-server:
        container_name: web-server
        build:
            context: ../../
            dockerfile: deployment/dockerfiles/web-server/Dockerfile
        networks:
            my_host_network:
                aliases:
                    - nginx-server
        ports:
            - 9090:9123     #Port forwarding 9090 on the host PC to 9123 on the container
        depends_on:         #Specify the dependency. web-app before starting server-Will start the server
            - app-server
        restart: always
###########Web server settings so far###########

###########Network settings from here###########
networks:
    my_host_network:            #Alias name when used in the upper server settings
        name: my-nginx-network  #Network name
        driver: bridge          #Driver type, bridge or overlay

As for the network, bridge is adopted because of the pattern of deploying multiple containers on one host PC. If the host is divided into multiple hosts, use ʻoverlay`.

nginx.conf file

Until now, both servers were running (directly) on the host PC, so I specified localhost as the reverse proxy destination. It is necessary to change the connection destination to the App server container in this step.

nginx.conf

http {
	server {
　　　　　   # 「uwsgi-server "is docker-compose.my set in yml_host_network Alias name of the app server on the network
    		location / {
        		proxy_pass http://uwsgi-server:9876;
        		# before: proxy_pass http://127.0.0.1:9876;
    		}

		location /health {
        		proxy_pass http://uwsgi-server:9876/health;
        		# before: proxy_pass http://127.0.0.1:9876/health;
    		}
    	}
}

Start / Delete Container

• Start-up

Terminal

docker-compose -f deployment/docker-compose/docker-compose.yml up
# -Specify the configuration file with the f option

ʻUpbuilds the image according to the settings in the yml file, and the container is created. Image ofbuild + start. It can also be run in the background by adding the -d` option.

• Stop

Ctrl + C, when running in the foreground If you run it in the background, you can stop the container with docker-compose -f deployment / docker-compose / docker-compose.yml stop.

--Container deletion

Terminal

docker-compose -f deployment/docker-compose/docker-compose.yml down

By adding the --rmi all option, all the original images are also deleted.

About docker-compose

Convenient points

Roughly speaking, two points are as follows.

1. You will be able to start and stop multiple containers with one command.
2. The relationship between containers can be specified in the configuration file.

For 1, suppose you need to start 10 containers. Entering docker run {container} 10 times is a reasonable cost, isn't it? You may forget to start one. It will be completed with one command of docker-compose up, so there will be no omission of startup, and above all it is easy. (If you focus only here, you can write a shell)

Regarding 2, let's take this Step as an example. It was not possible to describe each container in Dockerfile, and in the case of docker run, there were some startup conditions that had to be specified as startup options.

--Web server --Port forwarding of container port to host specific port --Belongs to the same network as the App server --Must be after the App server is started --App server --Belongs to the same network as the web server

By using docker-compose, the above settings can be defined in one yml file, so it is possible to reduce the construction difficulty including the relationship between containers and container hosts. .. In particular, the utility value is high in the following cases.

--I want to share volume between container and host --I want to set the network --I want to set many environment variables

Is docker-compose available in Production?

It's my personal opinion, but I think most of them are not used or used locally. That's because if you can create a container and define the relationships between the containers, it's not the end of production. In order to deploy a service in a production (and staging) environment, in addition to the steps so far, we have to think about katakana terms such as scalability, load balancing, network, runtime, and so on. There are some areas that can be solved by using docker-compose, but it seems tough to do everything. The one used for orchestration would still be kubernetes. However, if deploying a kubernetes cluster in a local environment is strict in terms of specifications, or simply checking the behavior of an application, docker-compose can be used more easily.