Docker-compose tutorial installation and quick start

The tutorial is based on the latest compose version 3 under Ubuntu
Reference: https://docs.docker.com/compose/overview/

1. Introduction to Compose

Docker Compose is a Docker tool for defining and running complex applications. An application using a Docker container usually consists of multiple containers. With Docker Compose, you no longer need to use shell scripts to start containers.

Compose manages multiple Docker containers through a configuration file. In the configuration file, all containers are defined through services, and then the docker-compose script is used to start, stop, and restart the application, the services in the application, and the containers of all dependent services. It is very suitable for scenarios where multiple containers are combined for development.

2. Compose and Docker compatibility

Docker version changes:

Starting from version 1.13.x, Docker is divided into Enterprise Edition EE and Community Edition CE. The version numbers are also changed to be released according to the timeline, for example, 17.03 is March 2017.

The software repository of Docker's Linux distribution has changed from the previous https://apt.dockerproject.org and https://yum.dockerproject.org to the current https://download.docker.com, and the package names have been changed to docker-ce and docker-ee.

3. Install Docker

The Docker Community Edition is called docker-ce. The old version of the Docker package is called docker or docker-engine. If you have installed the old version of docker, you must uninstall it first and then install the new version of docker. Docker is developing very rapidly, and updates to apt repositories often lag behind. Therefore, the installation method recommended by the Docker official website is to download the Docker installation script.
Uninstall the old version (if it has not been installed, you can skip this step):

$ sudo apt-get remove docker docker-engine docker.io

Install the latest Docker:

$ curl -fsSL get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

The shell will prompt you to enter the sudo password and then start executing the latest docker process or

$ curl -sSL https://get.docker.com/ | sh 

Confirm that Docker is successful and the latest Docker:

$ sudo docker run hello-world

4. Install docker-compose

Two latest Docker installation methods

1. Download the docker-compose binary file from github and install it

Download the latest version of the docker-compose file

sudo curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

If github access is too slow, you can use daocloud to download

sudo curl -L https://get.daocloud.io/docker/compose/releases/download/1.25.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

Add executable permissions

sudo chmod +x /usr/local/bin/docker-compose

Test installation results

$ docker-compose --version
docker-compose version 1.16.1, build 1719ceb

2.pip installation

sudo pip install docker-compose

5. Docker-compose file structure and examples

Docker-compose file structure

docker-compose.yml:

version: "3"
services:
 
 redis:
  image: redis:alpine
  ports:
   - "6379"
  networks:
   -frontend
  deploy:
   replicas: 2
   update_config:
    parallelism: 2
    delay: 10s
   restart_policy:
    condition: on-failure
 
 db:
  image: postgres:9.4
  volumes:
   -db-data:/var/lib/postgresql/data
  networks:
   - backend
  deploy:
   placement:
    constraints: [node.role == manager]
 
 vote:
  image: dockersamples/examplevotingapp_vote:before
  ports:
   - 5000:80
  networks:
   -frontend
  depends_on:
   - redis
  deploy:
   replicas: 2
   update_config:
    parallelism: 2
   restart_policy:
    condition: on-failure
 
 result:
  image: dockersamples/examplevotingapp_result:before
  ports:
   - 5001:80
  networks:
   - backend
  depends_on:
   -db
  deploy:
   replicas: 1
   update_config:
    parallelism: 2
    delay: 10s
   restart_policy:
    condition: on-failure
 
 worker:
  image: dockersamples/examplevotingapp_worker
  networks:
   -frontend
   - backend
  deploy:
   mode: replicated
   replicas: 1
   labels: [APP=VOTING]
   restart_policy:
    condition: on-failure
    delay: 10s
    max_attempts: 3
    window: 120s
   placement:
    constraints: [node.role == manager]
 
 visualizer:
  image: dockersamples/visualizer:stable
  ports:
   - "8080:8080"
  stop_grace_period: 1m30s
  volumes:
   - "/var/run/docker.sock:/var/run/docker.sock"
  deploy:
   placement:
    constraints: [node.role == manager]
 
networks:
 frontend:
 backend:
 
volumes:
 db-data:

docker-compose usage examples

Use docker-compose to build a web application based on the python flask framework that runs in docker.

Note: Make sure you have installed Docker Engine and Docker Compose. You do not need to install Python or Redis as both are provided by the Docker image.

Step 1: Define the Python application

1. Create a project directory

$ mkdir compose_test
$ cd compose_test
$ mkdir src # source code folder $ mkdir docker # docker configuration folder

The directory structure is as follows:

└── compose_test
  ├── docker
  │ └── docker-compose.yml
  ├── Dockerfile
  └── src
    ├── app.py
    └── requirements.txt

2. Create a python flask application compose_test/src/app.py file in the compose_test/src/directory.

from flask import Flask
from redis import Redis
 
app = Flask(__name__)
redis = Redis(host='redis', port=6379)
 
@app.route('/')
def hello():
  count = redis.incr('hits')
  return 'Hello World! I have been seen {} times.\n'.format(count)
 
if __name__ == "__main__":
  app.run(host="0.0.0.0", debug=True)

3. Create a python requirements file compose_test/src/requirements.txt

flask
redis

Step 2: Create a Dockerfile for the container

One container, one Dockerfile file. Create the Dockerfile file in the compose_test/directory:

FROM python:3.7
 
COPY src/ /opt/src
WORKDIR /opt/src
 
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

The Dockerfile tells Docker the following information:

Build a container image starting from the Python 3.6 image.

Copy the src directory (i.e. compose_test/src) to the /opt/src directory of the container.

Set the container's working directory to /opt/src (the default directory after entering the container via docker exec -it your_docker_container_id_or_name bash ).
Install Python dependencies.
Set the container’s default command to python app.py.

Step 3: Define the docker-compose script

Create a docker-compose.yml file in the compose_test/docker/ directory and define the service in it. The content is as follows:

version: '3'
services:
 web:
  build: ../
  ports:
   - "5000:5000"
 redis:
  image: "redis:3.0.7"

This compose file defines two services, namely, the web and redis containers.
Web container:
* Build the image using the Dockerfile in the parent directory of the current docker-compose.yml file (compose_test/Dockerfile).
* Map the exposed port 5000 on the container to port 5000 on the host. We use the default port 5000 of the Flask web server.
redis container:
* The redis service uses the official redis image version 3.0.7 pulled from Docker Hub.

Step 4: Build and run your application using Compose

Execute the docker-compose.yml file in the compose_test/docker/ directory:

$ docker-compose up
# If you want to run in the background: $ docker-compose up -d
# If you do not use the default docker-compose.yml file name:
$ docker-compose -f server.yml up -d 

Then enter http://0.0.0.0:5000/ in your browser to view the running application.

Step 5: Edit the compose file to add a file bind mount

The above code is statically copied to the container at build time, that is, the source code in the physical host is copied to the container through the COPY src /opt/src command in the Dockerfile file, so that subsequent changes to the code in the src directory of the physical host will not be reflected in the container.
The function of mounting the physical host directory into the container can be achieved through the volumes keyword (at the same time, the COPY instruction in the Dockerfile is deleted, and the code does not need to be packaged into the image when creating the image. Instead, it is dynamically mounted through volumes, and the container and the physical host share the data volume):

version: '3'
services:
 web:
  build: ../
  ports:
   - "5000:5000"
  volumes:
   - ../src:/opt/src
 redis:
  image: "redis:3.0.7"

Mounting the project directory on the host (compose_test/src) to the /opt/src directory in the container via volumes allows you to modify the code on the fly without rebuilding the image.

Step 6: Rebuild and run the application

Build the application using the updated compose file, and then run it.

$ docker-compose up -d

6. Compose common service configuration reference

A Compose file is a YAML file that defines services, networks, and volumes. The default file name of the Compose file is docker-compose.yml.

**Tip: You can use either the .yml or .yaml extension for this file. They all work.

As with docker run , by default, options specified in the Dockerfile (e.g., CMD , EXPOSE , VOLUME , ENV ) are respected and you do not need to specify them again in docker-compose.yml .

You can also use environment variables in configuration values ​​using Bash-like ${VARIABLE} syntax, see Variable Substitution for more information.

This section contains all configuration options supported by service definitions in version 3.

build

build can specify a path containing the build context:

version: '2'
services:
 webapp:
  build: ./dir

Or, as an object with the context path and the specified Dockerfile and args values:

version: '2'
services:
 webapp:
  build:
   context: ./dir
   dockerfile: Dockerfile-alternate
   args:
    buildno: 1

The webapp service will build the container image using the Dockerfile-alternate file in the ./dir directory.
If you specify both image and build, compose builds the container image through the directory specified by build, and the built image name is the image name and tag specified in image.

build: ./dir
image: webapp:tag

This will build an image named webapp from ./dir and tagged with tag.

context

The path to the directory containing the Dockerfile, or the URL of a git repository.
When the provided value is a relative path, it is interpreted as relative to the location of the current Compose file. This directory is also the context sent to the Docker daemon when building the image.

Dockerfile

Alternative Docker file. Compose will use the fallback file to build. The build path must also be specified.

args

Add parameters for building the image. Environment variables can only be accessed during the build process.
First, specify the parameters to use in the Dockerfile:

ARG buildno
ARG password
 
RUN echo "Build number: $buildno"
RUN script-requiring-password.sh "$password"

Then specify the arguments under the args key. You can pass a mapping or a list:

build:
 context: .
 args:
  buildno: 1
  password: secret
 
build:
 context: .
 args:
  -buildno=1
  - password=secret

** NOTE: YAML boolean values ​​(true, false, yes, no, on, off) must be enclosed in quotes in order for the parser to interpret them as strings.

image

Specifies the image to start the container, which can be an image repository/tag or an image id (or the first part of the id)

image: redis
image: ubuntu:14.04
image: tutum/influxdb
image: example-registry.com:4000/postgresql
image: a4bc65fd

If the image does not exist, Compose will attempt to pull it from an official image registry if you also specify a build, in which case it will build it using the specified build options and tag it with the name and tag specified by image.

container_name

Specify a custom container name instead of the generated default name.

container_name: my-web-container

Because Docker container names must be unique, you cannot scale your service to multiple containers if you specify a custom name.

volumes

Volume mount path settings. You can set the host path (HOST:CONTAINER) or add the access mode (HOST:CONTAINER:ro). The default permission for mounting a data volume is read-write (rw), which can be specified as read-only by ro.
You can mount a relative path on the host, which will be expanded relative to the directory of the Compose configuration file currently in use. Relative paths should always start with . or ..

volumes:
 # Just specify a path and let the engine create a volume - /var/lib/mysql
 # Specify absolute path mapping - /opt/data:/var/lib/mysql
 
 # Relative path to the current compose file - ./cache:/tmp/cache
 
 #Relative path of user's home directory - ~/configs:/etc/configs/:ro
 
 # Named Volume - datavolume:/var/lib/mysql

However, if you want to reuse mounted volumes across multiple services, name the mounted volumes in the top-level volumes keyword, but this is not mandatory. The following example also has the function of reusing mounted volumes, but it is not recommended.

version: "3"
 
services:
 web1:
  build: ./web/
  volumes:
   - ../code:/opt/web/code
 web2:
  build: ./web/
  volumes:
   - ../code:/opt/web/code

** Note: Defining a mount volume via the top-level volumes and referencing it from each service’s volumes list replaces volumes_from in earlier versions of the Compose file format.

version: "3"
 
services:
 db:
  image: db
  volumes:
   - data-volume:/var/lib/db
 backup:
  image: backup-service
  volumes:
   - data-volume:/var/lib/backup/data
 
volumes:
 data-volume:

command

Override the default command executed when the container is started.

command: bundle exec thin -p 3000

The command can also be a list similar to a Dockerfile:

command: ["bundle", "exec", "thin", "-p", "3000"]

links

Link to a container in another service. Please specify both the service name and the link alias (SERVICE:ALIAS), or just the service name.

web:
 links:
  -db
  -db:database
  - redis

In the current web service container, you can access the database application in the db container through the linked db service alias database. If no alias is specified, you can directly use the service name to access it.

Linking does not require services to be enabled to communicate - by default, any service can reach any other service by that service's name. (Actually, communication between containers is achieved by setting the domain name resolution of /etc/hosts. Therefore, you can use the service alias to link to the services of other containers just like using localhost in the application, provided that multiple service containers can be routed and connected in one network)

Links can also play a similar role to depends_on, that is, defining the dependencies between services and thus determining the order in which services are started.

external_links

Link to containers outside of docker-compose.yml, even containers not managed by Compose. The parameter format is similar to links.

external_links:
 - redis_1
 - project_db_1:mysql
 - project_db_1:postgresql

expose

The port is exposed but not mapped to the host machine and is only accessible to the connected service.
Only internal ports can be specified as parameters

expose:
 - "3000"
 - "8000"

ports

Expose port information.
Commonly used simple formats: using the host: container (HOST:CONTAINER) format or just specifying the container's port (the host will randomly choose the port) are all OK.

** Note: When mapping ports using the HOST:CONTAINER format, you may get incorrect results if the container port you use is less than 60, because YAML will parse the xx:yy number format as sexagesimal. So it is recommended to use string format.

Simple short form:

ports:
 - "3000"
 - "3000-3005"
 - "8000:8000"
 - "9090-9091:8080-8081"
 - "49100:22"
 - "127.0.0.1:8001:8001"
 - "127.0.0.1:5000-5010:5000-5010"
 - "6060:6060/udp"

The long form syntax of ports in v3.2 allows configuration of additional fields that cannot be expressed in the short form.
Long form:

ports:
 - target: 80
  published: 8080
  protocol: tcp
  mode: host

target: the port in the container
published: the port of the physical host
protocol: port protocol (tcp or udp)
mode: host and ingress two general modes, host is used to publish host ports on each node, ingress is used for load balanced swarm mode ports.

restart

No is the default restart policy, which will not restart the container under any circumstances. When always is specified, the container is always restarted. on-failure will restart the container if the exit code indicates a failure error.

restart: "no"
restart: always
restart: on-failure
restart: unless-stopped

environment

Add environment variables. You can use either an array or a dictionary. Any boolean values; true, false, yes, no need to be enclosed in quotes to ensure they are not converted to True or False by the YML parser.
A variable given a name will automatically get its value on the Compose host, which can be used to prevent leaking unnecessary data.

environment:
 RACK_ENV: development
 SHOW: 'true'
 SESSION_SECRET:
 
environment:
 - RACK_ENV=development
 - SHOW=true
 -SESSION_SECRET

** Note: If your service specifies the build option, environment variables defined via environment during the build process will not work. The build args suboption will be used to define build-time environment variables.

pid
Set the PID mode to host PID mode. This opens up a shared PID address space between the container and the host operating system. Containers started with this flag will be able to access and manipulate other containers in the bare metal's namespace, and vice versa. That is, containers with this option turned on can access and operate each other through process ID.

pid: "host"

DNS
Configure the DNS server. Can be a single value or a list.

dns: 8.8.8.8
dns:
 - 8.8.8.8
 - 9.9.9.9

This is the end of this article about the installation and quick start of the docker-compose tutorial. For more information about the installation and use of docker-compose, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!