aio350 Dec 15 2021 at 13:28

Docker: заметки веб-разработчика. Итерация первая

23 min

48K

Timeweb Cloud corporate blogJavaScript*DevOps*

Привет, друзья!

Хочу поделиться с вами заметками о Docker.

Заметки состоят из 4 частей: 2 теоретических и 2 практических.

Если быть более конкретным:

эта часть посвящена самому Docker, Docker CLI и Dockerfile;
в второй части рассказывается о Docker Compose;
в третьей части мы разработаем приложение, состоящее из 3 сервисов (клиента, админки и API) и базы данных (PostgreSQL);
в четвертой части мы это приложение "контейнеризуем".

Если вам это интересно, прошу под кат.

Что такое `Docker`?

Начало работы с Docker на английском.

Перевод на русский от Microsoft.

Docker — это открытая платформа для разработки, доставки и запуска приложений. Он позволяет отделить приложения от инфраструктуры и управлять инфраструктурой по аналогии с тем, как мы управляем приложениями.

Docker предоставляет возможность упаковывать и запускать приложение в слабо изолированной среде — контейнере. Изоляция и безопасность позволяют одновременно запускать несколько контейнеров на одном хосте (хостом может быть наша локальная машина, дата центр, облачный провайдер или их микс). Контейнеры являются легковесными и содержат все необходимое для запуска приложения, что избавляет нас от необходимости полагаться на то, что установлено на хосте.

Для чего Docker может использоваться?

Быстрая и согласованная доставка приложений

Docker рационализирует жизненный цикл разработки, позволяя разработчикам работать в стандартизированной среде через локальные контейнеры, предоставляющие приложения и сервисы. Контейнеры отлично подходят для рабочих процессов непрерывной интеграции и непрерывной доставки (continuous integration/continuous delivery, CI/CD).

Отзывчивая разработка и масштабирование

Платформа, основанная на контейнерах, позволяет легко портировать приложения. Контейнеры могут запускаться на локальной машине разработчика, в физических или виртуальных дата-центрах, облачных провайдерах или смешанных средах.

Запуск большего количества приложений на одной машине

Docker является легковесным и быстрым. Он предоставляет работоспособную и экономичную альтернативу виртуальным машинам на основе гипервизора, что позволяет использовать больше вычислительных мощностей для решения аналогичных задач.

Архитектура `Docker`

Docker использует клиент-серверную архитектуру. Клиент (Docker client) обращается к демону (Docker daemon), который поднимает (собирает), запускает и распределяет контейнеры. Клиент и демон могут быть запущены в одной системе или клиент может быть подключен к удаленному демону. Клиент и демон общаются через REST API поверх UNIX-сокетов или сетевого интерфейса. Другим клиентом является Docker Compose, позволяющий работать с приложениями, состоящими из нескольких контейнеров.

Демон

Демон (dockerd) регистрирует (слушает) запросы, поступающие от Docker API, и управляет такими объектами как образы, контейнеры, сети и тома. Демон может общаться с другими демонами для управления сервисами.

Клиент

Клиент (docker) — основной способ коммуникации с Docker. При выполнении такой команды, как docker run, клиент отправляет эту команду демону, который, собственно, эту команду и выполняет. Команда docker использует Docker API. Клиент может общаться с несколькими демонами.

Docker Desktop

Docker Desktop — это десктопное приложение для Mac и Windows, позволяющее создавать и распределять контейнерные приложения и микросервисы. Docker Desktop включает в себя демона, клиента, Docker Compose, Docker Content Trust, Kubernetes и Credential Helper.

Реестр

В реестре (registry) хранятся образы контейнеров. Docker Hub — это публичный реестр, который (по умолчанию) используется Docker для получения образов. Имеется возможность создания частных (закрытых) реестров.

При выполнении таких команд, как docker pull или docker run, необходимые образы загружаются из настроенного реестра. А при выполнении команды docker push образ загружается в реестр.

Объекты

При использовании Docker мы создаем и используем образы, контейнеры, сети, тома, плагины и другие объекты. Рассмотрим некоторые из них.

Образы (Images)

Образ — это доступный только для чтения шаблон с инструкциями по созданию контейнера. Часто образ представляет собой модификацию другого образа.

Можно создавать свои образы или использовать образы, созданные другими и опубликованные в реестре. Для создания образа используется Dockerfile, содержащий инструкции по созданию образа и его запуску (см. ниже). Ряд инструкций в Dockerfile приводит к созданию в образе нового слоя (раньше новый слой создавался для каждой инструкции). При изменении Dockerfile и повторной сборке образа пересобираются только модифицированные слои. Это делает образы легковесными, маленькими и быстрыми.

Контейнеры (Containers)

Контейнер — это запускаемый экземпляр образа. Мы создаем, запускаем, перемещаем и удаляем контейнеры с помощью Docker API или CLI (command line interface, интерфейс командной строки). Мы можем подключать контейнеры к сетям, добавлять в них хранилища данных и даже создавать новые образы на основе текущего состояния.

По умолчанию контейнеры хорошо изолированы от других контейнеров и хоста. Однако мы можем управлять тем, насколько изолированы сеть, хранилище данных или другая подсистема контейнера.

Контейнер определяется образом и настройками, указанными при его создании и запуске. При удалении контейнера его состояние также удаляется. Этого можно избежать с помощью хранилища данных.

Пример команды docker run

Следующая команда запускает контейнер ubuntu, интерактивно подключается к локальному сеансу командной строки и выполняет в ней команду /bin/bash:

docker run -i -t ubuntu /bin/bash

При выполнении этой команды происходит следующее:

Поскольку на нашей машине нет образа ubuntu, Docker загружает его из реестра (то же самое делает команда docker pull ubuntu).
Docker создает новый контейнер (то же самое делает команда docker container create).
В качестве последнего слоя Docker выделяет контейнеру файловую систему для чтения и записи. Это позволяет запущенному контейнеру создавать и модифицировать файлы и директории в его локальной файловой системе.
Поскольку мы не указали сетевых настроек, Docker создает сетевой интерфейс для подключения контейнера к дефолтной сети. Это включает в себя присвоение контейнеру IP-адреса. Контейнеры могут подключаться к внешним сетям через сетевое соединение хоста.
Docker запускает контейнер и выполняет /bin/bash. Поскольку контейнер запущен в интерактивном режиме и подключен к терминалу (благодаря флагам -i и -t), мы можем вводить команды и получать результаты в терминале.
Выполнение команды exit приводит к прекращению выполнения /bin/bash. Контейнер останавливается, но не удаляется. Мы можем запустить его снова или удалить.

Команды и флаги

docker run

Команда docker run используется для запуска контейнера. Это основная и потому наиболее часто используемая команда.

# сигнатура
docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
# основные настройки (флаги)
-d - запуск контейнера в качестве отдельного процесса
-p - публикация открытого порта в интерфейсе хоста (HOST:CONTAINER)
# например
-p 3000:3000
-t - выделение псевдотерминала
-i - оставить STDIN открытым без присоединения к терминалу
--name - название контейнера
--rm - очистка системы при остановке/удалении контейнера
--restart - политика перезапуска - no (default) | on-failure[:max-retries] | always | unless-stopped
-e - установка переменной среды окружения
-v - привязка распределенной файловой системы (name:/path/to/file)
# например
-v mydb:/etc/mydb
-w - установка рабочей директории

Следующая команда запускает контейнер postgres:

# \ используется для разделения длинных команд на несколько строк
docker run --rm \
 # название контейнера
 --name postgres \
 # пользователь
 -e POSTGRES_USER=postgres \
 # пароль
 -e POSTGRES_PASSWORD=postgres \
 # название базы данных
 -e POSTGRES_DB=mydb \
 # автономный режим и порт
 -dp 5432:5432 \
 # том для хранения данных
 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data \
 # образ
 postgres

docker build

Команда docker build используется для создания образа на основе файла Dockerfile и контекста. Контекст — это набор файлов, находящихся в локации, определенной с помощью PATH или URL. PATH — это директория в нашей локальной системе, а URL — это удаленный репозиторий. Контекст сборки обрабатывается рекурсивно, поэтому PATH включает как директорию, там и все ее поддиректории, а URL — как репозиторий, так и все его субмодули. Для исключения файлов из сборки образа используется .dockerignore (синтаксис этого файла похож на .gitignore).

# сигнатура
docker build [OPTIONS] PATH | URL | -

Создание образа:

# в качестве контекста сборки используется текущая директория
docker build .

Использование репозитория в качестве контекста (предполагается, что Dockerfile находится в корневой директории репозитория):

docker build github.com/creack/docker-firefox

docker build -f ctx/Dockerfile http://server/ctx.tar.gz

В данном случае http://server/ctx.tar.gz отправляется демону, которые загружает и извлекает файлы. Параметр -f ctx/Dockerfile определяет путь к Dockerfile внутри ctx.tar.gz.

Чтение Dockerfile из STDIN без контекста:

docker build - < Dockerfile

Добавление тега к образу:

docker build -t myname/my-image:latest .

Определение Dockerfile:

docker build -f Dockerfile.debug .

Экспорт файлов сборки в директорию out:

docker build -o out .

Экспорт файлов сборки в файл out.tar:

docker build -o - . > out.tar

docker exec

Команда docker exec используется для выполнения команды в запущенном контейнере.

# сигнатура
docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
# основные флаги
-d - выполнение команды в фоновом режиме
-e - установка переменной среды окружения
-i - оставить `STDIN` открытым
-t - выделение псевдотерминала
-w - определение рабочей директории внутри контейнера

Пример:

# -U - это пользователь, которым по умолчанию является root
docker exec -it postgres psql -U postgres

В данном случае в контейнере postgres будет запущен интерактивный терминал psql. Выполним парочку команд:

# получаем список баз данных
\l
# подключаемся к базе данных mydb
-d mydb
# получаем список таблиц, точнее, сообщение об отсутствии отношений (relations)
\dt
# выходим
\q

docker ps

Команда docker ps используется для получения списка (по умолчанию только запущенных) контейнеров.

# сигнатура
docker ps [OPTIONS]
# основные флаги
-a - показать все контейнеры (как запущенные, так и остановленные)
-f - фильтрация вывода на основе условия (`id`, `name`, `status` и т.д.)
-n - показать n последних созданных контейнеров
-l - показать последний созданный контейнер
# пример получения списка приостановленных контейнеров
docker ps -f 'status=paused'

Для получения списка образов используется команда docker images.

Команды управления

# запуск остановленного контейнера
docker start CONTAINER

# приостановление всех процессов, запущенных в контейнере
docker pause CONTAINER

# остановка контейнера
docker stop CONTAINER

# "убийство" контейнера
docker kill CONTAINER

# перезапуск контейнера
docker restart CONTAINER

# удаление остановленного контейнера
docker rm [OPTIONS] CONTAINER
# основные флаги
-f - принудительное удаление (остановка и удаление) запущенного контейнера
-v - удаление анонимных томов, связанных с контейнером
# пример удаления всех остановленных контейнеров
docker rm $(docker ps --filter status=exited -q)

# удаление образа
docker rmi IMAGE

###

# управление образами
docker image COMMAND

# управление контейнерами
docker container COMMAND

# управление томами
docker volume COMMAND

# управление сетями
docker network COMMAND

# управление docker
docker system COMMAND

Другие команды

Для получения логов запущенного контейнера используется команда docker logs:

docker logs [OPTIONS] CONTAINER
# основные флаги
-f - следование за выводом
-n - n последних строк

Для удаления всех неиспользуемых данных (контейнеры, сети, образы и, опционально, тома) используется команда docker system prune. Основные флаги:

-a - удаление всех неиспользуемых образов, а не только обособленных (dangling)
--volumes - удаление томов

Предостережение: применять эту команду следует с крайней осторожностью, поскольку удаленные данные не подлежат восстановлению.

Полный список команд и флагов.

Dockerfile

Dockerfile — это документ (без расширения), содержащий инструкции, которые используются для создания образа при выполнении команды docker build.

Предостережение: не используйте / в качестве PATH для контекста сборки. Это приведет к передаче демону всего содержимого жесткого диска вашей машины.

Инструкции выполняются по одной. Результаты наиболее важных инструкций фиксируются в виде отдельных слоев образа. Обратите внимание: каждая инструкция выполняется независимо от других. Это означает, что выполнение RUN cd /tmp не будет иметь никакого эффекта для последующих инструкций.

Dockerfile может содержать следующие инструкции:

# Комментарий
ИНСТРУКЦИЯ аргументы

# Основные
# FROM - родительский образ
FROM <image>[:<tag>] [AS <name>]
# пример
FROM node:12-alpine AS build

# WORKDIR - установка рабочей директории для инструкций RUN, CMD, ENTRYPOINT, COPY и ADD
WORKDIR /path/to/dir
# пример
WORKDIR /app

# COPY - копирование новых файлов или директорий из <src>
# и их добавление в файловую систему образа по адресу, указанному в <dest>
COPY <src> <dest>
COPY ["<src>", "<dest>"]
# пример
COPY package.* yarn.lock ./
# или
COPY . .
# ADD, в отличие от COPY, позволяет копировать удаленные файлы,
# а также автоматически распаковывает сжатые (identity, gzip, bzip2 или xz) локальные файлы

# ADD - копирование новых файлов, директорий или удаленного (!) файла из <src>
# и их добавление в файловую систему образа по адресу, указанному в <dest>
ADD <src> <dest>
ADD ["<src>", "<dest>"]
# пример
ADD some.txt some_dir/ # <WORKING_DIR>/some_dir/

# RUN - выполнение команды в новом слое на основе текущего образа и фиксация результата
RUN <command>
# или
RUN ["executable", "arg1", "arg2"] # Кавычки должны быть двойными
# пример
RUN npm install

# CMD - предоставление дефолтных значений исполняемому контейнеру
CMD ["executable", "arg1", "arg2"]
# или если данной инструкции предшествует инструкция ENTRYPOINT
CMD ["arg1", "arg2"]
# или
CMD command arg1 arg2
# пример
CMD [ "node", "/app/src/index.js" ]
# RUN выполняет команду и фиксирует результат,
# CMD ничего не выполняет во время сборки, а определяет команду для образа
# (!) выполняется только одна (последняя) инструкция CMD

# ENTRYPOINT - настройка исполняемого контейнера
ENTRYPOINT ["executable", "arg1", "arg2"]
ENTRYPOINT command arg1 arg2
# пример
ENTRYPOINT ["top", "-b"]
CMD ["-c"]
# docker run -it --rm --name test top -H
# top -b -H
# разница между ENTRYPOINT и CMD:
# https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
# https://stackoverflow.com/questions/21553353/what-is-the-difference-between-cmd-and-entrypoint-in-a-dockerfile

# переменные
# ${var} или $var
# пример
FROM busybox
ENV FOO=/bar
WORKDIR ${FOO}    # WORKDIR /bar
ADD . $FOO        # ADD . /bar
COPY \$FOO /qux   # COPY $FOO /qux

# Другие
# LABEL - добавление метаданных к образу
LABEL <key>=<value>
# пример
LABEL version="1.0"

# EXPOSE - информация о сетевом порте, прослушиваемом контейнером во время выполнения
EXPOSE <port> | <port>/<protocol>
# пример
EXPOSE 3000

# ENV - установка переменных среды окружения
ENV <key>=<value>
# пример
ENV MY_NAME="No Name"

# VOLUME - создание точки монтирования
VOLUME ["/var/log"]
VOLUME /var/log

# USER - установка пользователя для использования при запуске контейнера
# в любых инструкциях RUN, CMD и ENTRYPOINT
USER <user>[:<group>]
USER <UID>[:<GID>]

# ARG - определение переменной, которая может быть передана через командную строку при
# выполнении команды `docker build` с помощью флага `--build-arg <name>=<value>`
ARG <name>[=<default value>]

# ONBUILD - добавление в образ триггера, запускаемого при использовании
# данного образа в качестве основы для другой сборки
ONBUILD <INSTRUCTION>

Справка по Dockerfile.

Управление данными

По умолчанию файлы, создаваемые в контейнере сохраняются в слое, доступном для записи (writable layer). Это означает следующее:

данные существуют только на протяжении жизненного цикла контейнера, и их сложно извлекать из контейнера, когда в них нуждается другой процесс
слой контейнера, доступный для записи, тесно связан с хостом, на котором запущен контейнер. Данные нельзя просто взять и переместить в другое место
запись в такой слой требует наличия драйвера хранилища (storage driver) для управления файловой системой. Эта дополнительная абстракция снижает производительность по сравнению с томами данных (data volumes), которые пишут напрямую в файловую систему

Docker предоставляет 2 возможности для постоянного хранения данных на хосте: тома (volumes) и bind mount. Для пользователей Linux также доступен tmpfs mount, а для пользователей Windows — named pipe.

Выбор правильного типа монтирования

Независимо от выбранного типа монтирования, для контейнера данные выглядят одинаково. Они представляют собой директорию или файл в файловой системе контейнера.

Разница между томами, bind mount и tmpfs mount заключается в том, где хранятся данные на хосте.

тома хранятся в части файловой системы хоста, управляемой Docker (/var/lib/docker/volumes/ на Linux). Процессы, не относящиеся к Docker, не должны модифицировать эту часть. Тома — лучший способ хранения данных в Docker
bind mount может храниться в любом месте системы хоста. Это могут быть даже важные системные файлы и директории. Модифицировать их могут любые процессы
tmpfs mount хранится в памяти и не записывается в файловую систему

Управление данными в Docker.

Тома (Volumes)

Тома — предпочтительный способ хранения данных, генерируемых и используемых контейнерами. Они полностью управляются Docker, в отличие от bind mount, которые зависят от структуры директории и операционной системы хоста. Преимущества томов состоят в следующем:

тома легче восстанавливать и мигрировать
томами можно управлять с помощью Docker CLI и Docker API
тома работают как в Linux, так и в Windows контейнерах
тома могут более безопасно распределяться между контейнерами
движки томов (volume drivers) позволяют хранить тома на удаленных хостах и облачных провайдерах, шифровать содержимое томов или добавлять в них новый функционал
содержимое новых томов может заполняться (population) контейнером
тома имеют более высокую производительность

Тома также являются более предпочтительными перед хранением данных в слое контейнера, доступном для записи, поскольку тома не увеличивают размер контейнера. Содержимое контейнера существует за пределами жизненного цикла контейнера.

Флаги -v и --mount

--mount является более явным и многословным. Основное отличие состоит в том, что при использовании -v все настройки комбинируются вместе, а при использовании --mount они указываются раздельно.

Движок тома может быть определен только с помощью --mount.

-v или --volume: состоит из 3 полей, разделенных двоеточием (:). Поля должны указываться в правильном порядке. Значение каждого поля не является очевидным
- в случае именованных томов первое поле — это название тома, которое является уникальным в пределах хоста. В случае анонимных томов это поле опускается
- второе поле — это путь файла или директории, монтируемой в контейнере
- третье поле является опциональным и представляет собой разделенный запятыми список настроек, таких как ro
--mount: состоит из нескольких пар ключ/значение, разделенных запятыми. Синтаксис --mount является более многословным, зато порядок ключей не имеет значения, а значения ключей являются более очевидными
- type: тип монтирования, может иметь значение bind, volume или tmpfs
- source: источник монтирования. Для именованных томов — это название тома. Для анонимных может быть опущено. Может определяться как source или src
- destination: путь монтируемого в контейнере файла или директории. Может определяться как destination, dst или target
- readonly: если указана данная настройка, том будет доступен только для чтения. Может определяться как readonly или ro
- volume-opt: данная настройка может определяться несколько раз, принимая пары название настройки/ее значение

-v и --mount принимают одинаковые настройки. При использовании томов с сервисами, доступен только флаг --mount.

Создание и управление томами

В отличие от bind mount, тома могут создаваться и управляться за пределами любого контейнера.

Создание тома

docker volume create my-vol

Список томов

docker volume ls

Анализ тома

docker volume inspect my-vol

Удаление тома

docker volume rm my-vol

Запуск контейнера с томом

При запуске контейнера с несуществующим томом, он создается автоматически. В следующем примере том myvol2 монтируется в директорию app контейнера:

docker run -d \
 --name devtest \
 -v myvol2:/app \
 nginx:latest

# или
docker run -d \
 --name devtest \
 --mount source=myvol2,target=/app \
 nginx:latest
# далее будет использоваться только `-v`

В данном случае том будет доступен как для чтения, так и для записи.

Использование тома с Docker Compose

Единичный сервис (single service) Compose с томом может выглядеть так:

version: "1.0"
services:
 frontend:
   image: node:lts
   volumes:
     - myapp:/home/node/app
volumes:
 myapp:

Том будет создан при первом вызове docker compose up. При последующих вызовах данный том будет использоваться повторно.

Том может быть создан отдельно с помощью docker volume create. В этом случае в docker-compose.yml может быть указана ссылка на внешний (external) том:

version: "1.0"
services:
 frontend:
   image: node:lts
   volumes:
     - myapp:/home/node/app
volumes:
 myapp:
   external: true

Популяция тома с помощью контейнера

При запуске нового контейнера, создающего том, когда контейнер содержит файлы и директории в монтируемой директории, содержимое этой директории копируется в том. После этого контейнер монтирует и использует том. Другие контейнеры, использующие том, будут иметь доступ к его предварительно заполненному (pre-populated) содержимому.

В следующем примере мы создаем контейнер nginxtest и заполняем новый том nginx-vol содержимым из директории /usr/share/nginx/html, в которой хранится дефолтная разметка:

docker run -d \
 --name=nginxtest \
 -v nginx-vol:/usr/share/nginx/html \
 nginx:latest

Пример монтирования тома, доступного только для чтения

# :ro
docker run -d \
 --name=nginxtest \
 -v nginx-vol:/usr/share/nginx/html:ro \
 nginx:latest

Резервное копирование, восстановление и передача данных томов

Для создания контейнера, монтирующего определенный том, используется флаг --volumes-from.

Резервное копирование тома

Создаем контейнер dbstore:

docker run -v /dbdata --name dbstore ubuntu /bin/bash

Следующая команда

запускает новый контейнер и монтирует в него том из контейнера dbstore
монтирует директорию из локального хоста как /backup
передает команду для архивации содержимого тома dbdata в файл backup.tar в директории /backup:

docker run --rm \
 --volumes-from dbstore \
 -v $(pwd):/backup \
 ubuntu tar \
 cvf /backup/backup.tar /dbdata

Восстановление данных тома

Создаем новый контейнер:

docker run -d \
 -v /dbdata \
 --name dbstore2 \
 ubuntu /bin/bash

Распаковываем архив в том нового контейнера:

docker run --rm \
 --volumes-from dbstore2 \
 -v $(pwd):/backup \
 ubuntu bash -c \
 "cd /dbdata && tar xvf /backup/backup.tar --strip 1"

Удаление томов

Данные томов сохраняются после удаления контейнеров. Существует 2 типа томов:

именованные: имеют определенный источник за пределами контейнера, например, awesome:/foo
анонимные: не имеют определенного источника, поэтому при удалении контейнера демону следует передавать инструкции по их удалению

Для удаления анонимного контейнера можно использовать флаг --rm. Например, здесь мы создаем анонимный том /foo и именованный том awesome:/bar:

docker run --rm -v /foo -v awesome:/bar busybox top

После удаления этого контейнера будет удален только том /foo.

Для удаления всех неиспользуемых томов используется команда docker volume prune.

Более подробную информацию о томах можно получить здесь.

Сети (Networks)

Сети позволяют контейнерам общаться между собой. Сетевой интерфейс Docker не зависит от платформы.

Основная функциональность сетей представлена следующими драйверами:

bridge (мост): дефолтный сетевой драйвер. Такие сети, как правило, используются, когда приложение состоит из нескольких автономных контейнеров, которые должны иметь возможность общаться между собой
host: этот драйвер также предназначен для автономных контейнеров, он позволяет использовать сети хоста напрямую, удаляя изоляцию между контейнером и хостом
overlay (перекрытие): такие сети объединяют нескольких демонов вместе и позволяют групповым сервисам (swarm services) взаимодействовать друг с другом. Эти сети также могут использоваться для обеспечения коммуникации между групповым сервисом и отдельным контейнером или между двумя автономными контейнерами на разных демонах
ipvlan: такая сеть предоставляет пользователю полный контроль над адресацией IPv4 и IPv6
macvlan: этот драйвер позволяет присваивать контейнеру MAC-адрес, в результате чего контейнер появляется в сети как физическое устройство
none: отключает сети для данного контейнера. Обычно, используется в дополнение к кастомному сетевому драйверу
плагины

Резюме

bridge: для обеспечения взаимодействия контейнеров, находящихся на одном хосте
host: когда сетевой стек не должен быть изолирован от хоста
overlay: для обеспечения взаимодействия контейнеров, находящихся на разных хостах, или для приложений, работающих вместе через групповые сервисы

Обзор сетей.

Использование дефолтной сети bridge

Сейчас мы запустим 2 контейнера alpine и посмотрим, как они могут взаимодействовать между собой.

Открываем терминал и выполняем следующую команду:

docker network ls

Получаем список сетей bridge, host и none.

Запускаем 2 контейнера alpine. ash — это дефолтный терминал Alpine (аналог bash). Флаги -dit означают запуск контейнера в фоновом режиме (-d), интерактивно (что дает возможность вводить команды) (-i) и с псевдотерминалом (чтобы видеть ввод и вывод) (-t). Поскольку мы не указываем --network, контейнеры подключаются к дефолтной сети bridge:

# контейнер номер раз
docker run -dit --name alpine1 alpine ash

# и номер два
docker run -dit --name alpine2 alpine ash

Проверяем, что оба контейнера запущены:

docker container ls
# или
docker ps

Анализируем сеть bridge на предмет подключенных к ней контейнеров:

docker network inspect bridge

Видим созданные нами контейнеры в разделе "Containers" вместе с их IP-адресами (172.17.0.2 для alpine1 и 172.17.0.3 для alpine2).

Подключаемся к alpine1:

docker attach alpine1

Видим приглашение #, свидетельствующее о том, что мы являемся пользователем root внутри контейнера. Взглянем на сетевой интерфейс alpine1:

id addr show

Первый интерфейс (lo) нас не интересует. Нас интересует IP-адрес второго интерфейса (172.17.0.2).

Проверяем подключение к Интернету:

ping -c 2 google.com

Флаг -c 2 означает 2 попытки ping.

Обратимся ко второму контейнеру. Сначала по IP-адресу:

ping -c 2 172.17.0.3

Работает. Теперь попробуем обратиться по названию контейнера:

ping -c 2 alpine2

Не работает.

Останавливаем и удаляем контейнеры:

docker container stop alpine1 alpine2
docker container rm alpine1 alpine2

Обратите внимание: дефолтная сеть bridge не рекомендуется для использования в продакшне.

Использование кастомной сети bridge

В следующем примере мы снова создаем 2 контейнера alpine, но подключаем их к кастомной сети alpine-net. Эти контейнеры не подключены к дефолтной сети bridge. Затем мы запускаем третий alpine, подключаемый к bridge, но не к alpine-net, и четвертый alpine, подключаемый к обеим сетям.

Создаем сеть alpine-net. Флаг --driver bridge можно опустить, поскольку bridge является сетью по умолчанию:

docker network create --driver bridge alpine-net

Получаем список сетей:

docker network ls

Анализируем сеть alpine-net:

docker network inspect alpine-net

Получаем IP-адрес сети и пустой список подключенных контейнеров.

Обратите внимание на сетевой шлюз, который отличается от шлюза bridge.

Создаем 4 контейнера. Обратите внимание на флаг --network. При выполнении команды docker run мы можем подключить контейнер только к одной сети, поэтому подключение alpine4 к alpine-net выполняется отдельно:

docker run -dit --name alpine1 --network alpine-net alpine ash

docker run -dit --name alpine2 --network alpine-net alpine ash

docker run -dit --name alpine3 alpine ash

docker run -dit --name alpine4 alpine ash
# !
docker network connect alpine-net alpine4

Получаем список запущенных контейнеров:

docker ps

Анализируем bridge и alpine-net:

docker network inspect bridge

Видим, что к данной сети подключены контейнеры apline3 и alpine4.

docker network inspect alpine-net

А к этой сети подключены контейнеры alpine1, alpine2 и alpine4.

В кастомных сетях контейнеры могут обращаться друг к другу не только по IP-адресам, но также по названиям. Данная возможность называется автоматическим обнаружением сервиса (automatic service discovery). Подключаемся к alpine1:

docker container attach alpine1

ping -c 2 alpine2
# success

ping -c 2 alpine 4
# success

ping -c 2 alpine1
# success

Пробуем обратиться к alpine3:

ping -c 2 alpine3
# failure

Отключаемся от alpine1 и подключаемся к alpine4:

docker container attach alpine4

ping -c 2 alpine1
# success

ping -c 2 alpine2
# success

ping -c 2 alpine3
# failure
# но
ping -c 2 172.17.0.2 # IP-адрес alpine3
# success

ping -c 2 alpine4
# success

Все контейнеры могут подключаться к Интернету:

ping -c 2 google.com
# success

Останавливаем и удаляем контейнеры и сеть alpine-net:

docker container stop alpine1 alpine2 alpine3 alpine4

docker container rm alpine1 alpine2 alpine3 alpine4

docker network rm alpine-net

Это конец первой части.

Благодарю за внимание и happy coding!

Tags:

Hubs:

Docker: заметки веб-разработчика. Итерация первая

Что такое `Docker`?

Архитектура `Docker`

Команды и флаги

Dockerfile

Рекомендации по `Dockerfile`

Рекомендации по инструкциям

Управление данными

Сети (Networks)

Articles

Information

Docker: заметки веб-разработчика. Итерация первая

Что такое Docker?

Архитектура Docker

Команды и флаги

Dockerfile

Рекомендации по Dockerfile

Рекомендации по инструкциям

Управление данными

Сети (Networks)

Что такое `Docker`?

Архитектура `Docker`

Рекомендации по `Dockerfile`