Docker — DevOps: Автоматизация локального окружения

Приложение в контейнере
Работа с образами
Управление контейнерами
Взаимодействие с другими частями системы
Подготовка собственного образа

Докер — универсальный способ доставки приложений на машины (локальный компьютер или удаленные сервера) и их запуска в изолированном окружении.

Вспомните, когда вам приходилось собирать программы из исходников. Этот процесс включает в себя следующие шаги:

Установить все необходимые зависимости под вашу операционную систему (их список ещё надо найти)
Скачать архив, распаковать
Запустить конфигурирование make configure
Запустить компиляцию make compile
Установить make install

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

Докер позволяет упростить эту процедуру до запуска одной команды причем с почти 100% гарантией успеха.

Чтобы начать пользоваться Докером, необходимо установить движок — Docker Engine. На странице https://docs.docker.com/engine/install/ доступны ссылки для скачивания под все популярные платформы. Выберите вашу и установите Докер.

Посмотрим на вымышленный пример, в котором происходит установка программы Tunnel на локальный компьютер в директорию /usr/local/bin используя образ tunnel:

docker run -v /usr/local/bin:/out tunnel

Запуск этой команды приводит к тому, что в основной системе в директории /usr/local/bin оказывается исполняемый файл программы, находящейся внутри образа tunnel. Команда docker run запускает контейнер из образа tunnel, внутри происходит компиляция программы и, в конечном итоге, она оказывается в директории /usr/local/bin основной файловой системы. Теперь можно стартовать программу, просто набрав tunnel в терминале.

А что если программа, которую мы устанавливаем таким способом, имеет зависимости? Весь фокус в том, что образ, из которого был запущен контейнер, полностью укомплектован. Внутри него установлены все необходимые зависимости, и его запуск практически гарантирует 100% работоспособность, независимо от состояния основной ОС.

Часто даже необязательно копировать программу из контейнера на вашу основную систему. Достаточно запускать сам контейнер, когда в этом возникнет необходимость. Предположим, что мы решили разработать статический сайт на основе Jekyll. Jekyll — популярный генератор статических сайтов, написанный на Ruby. Например, сайт с гайдами Хекслета сгенерирован с его помощью. И при генерации использовался Докер (об этом можно прочитать в гайде: как делать блог на Jekyll).

Старый способ использования Jekyll требовал установки на вашу основную систему как минимум Ruby и самого Jekyll в виде гема (gem — название пакетов в Ruby). Причем, как и всегда в подобных вещах, Jekyll работает только с определенными версиями Ruby, что вносит свои проблемы при настройке.

С Докером запуск Jekyll сводится к одной команде, выполняемой в директории с блогом (подробнее можно посмотреть в репозитории наших гайдов):

docker run --rm --volume="$PWD:/srv/jekyll" -it jekyll/jekyll jekyll server

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

Приложение в контейнере

Теперь поговорим о том, как приложение отображается на контейнеры. Возможны два подхода:

Всё приложение — один контейнер, внутри которого поднимается дерево процессов: приложение, веб сервер, база данных и всё в этом духе.
Каждый запущенный контейнер — атомарный сервис. Другими словами каждый контейнер представляет собой ровно одну программу, будь то веб-сервер или приложение.

На практике все преимущества Docker достигаются только со вторым подходом. Во-первых, сервисы, как правило, разнесены по разным машинам и нередко перемещаются по ним (например, в случае выхода из строя сервера), во-вторых, обновление одного сервиса не должно приводить к остановке остальных.

Первый подход крайне редко, но бывает нужен. Например, Хекслет работает в двух режимах. Сам сайт с его сервисами использует вторую модель, когда каждый сервис отдельно, но вот практика, выполняемая в браузере, стартует по принципу "один пользователь — один контейнер". Внутри контейнера может оказаться всё что угодно в зависимости от практики. Как минимум, там всегда стартует сама среда Хекслет IDE, а она в свою очередь порождает терминалы (процессы). В курсе по базам данных в этом же контейнере стартует и база данных, в курсе, связанном с вебом, стартует веб-сервер. Такой подход позволяет создать иллюзию работы на настоящей машине и резко снижает сложность в поддержке упражнений. Повторюсь, что такой вариант использования очень специфичен и вам вряд ли понадобится.

Другой важный аспект при работе с контейнерами касается состояния. Например, если база запускается в контейнере, то её данные ни в коем случае не должны храниться там же, внутри контейнера. Контейнер как процесс операционной системы, может быть легко уничтожен, его наличие всегда временно. Docker содержит механизмы для хранения и использования данных, лежащих в основной файловой системе. О них будет позже.

Работа с образами

Docker — больше, чем просто программа. Это целая экосистема со множеством проектов и сервисов. Главный сервис, с которым вам придется иметь дело — Registry. Хранилище образов.

Концептуально оно работает так же, как и репозиторий пакетов любого пакетного менеджера. Посмотреть его содержимое можно на сайте https://hub.docker.com/.

Когда мы выполняем команду run docker run <image name>, то Docker проверяет наличие указанного образа на локальной машине и скачивает его по необходимости. Список образов, уже скачанных на компьютер, можно посмотреть командой docker images:

docker images

REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
workshopdevops_web                   latest              cfd7771b4b3a        2 days ago          817MB
hexletbasics_app                     latest              8e34a5f631ea        2 days ago          1.3GB
mokevnin/rails                       latest              96487c602a9b        2 days ago          743MB
ubuntu                               latest              2a4cca5ac898        3 days ago          111MB
Ruby                                 2.4                 713da53688a6        3 weeks ago         687MB
Ruby                                 2.5                 4c7885e3f2bb        3 weeks ago         881MB
nginx                                latest              3f8a4339aadd        3 weeks ago         108MB
elixir                               latest              93617745963c        4 weeks ago         889MB
postgres                             latest              ec61d13c8566        5 weeks ago         287MB

Разберёмся с тем, как формируется имя образа, и что оно в себя включает.

Вторая колонка в выводе выше называется TAG. Когда мы выполняли команду docker run nginx, то на самом деле выполнялась команда docker run nginx:latest. То есть мы не просто скачиваем образ nginx, а скачиваем его конкретную версию. Latest — тег по умолчанию. Несложно догадаться, что он означает последнюю версию образа.

Важно понимать, что это всего лишь соглашение, а не правило. Конкретный образ вообще может не иметь тега latest, либо иметь, но он не будет содержать последние изменения, просто потому, что никто их не публикует. Впрочем, популярные образы следуют соглашению. Как понятно из контекста, теги в Докере изменяемы. Другими словами, вам никто не гарантирует, что скачав образ с одним и тем же тегом на разных компьютерах в разное время вы получите одно и то же. Такой подход может показаться странным и ненадежным, ведь нет гарантий, но на практике есть определенные соглашения, которым следуют все популярные образы. Тег latest действительно всегда содержит последнюю версию и постоянно обновляется, но кроме этого тега активно используется семантическое версионирование. Рассмотрим https://hub.docker.com/_/nginx

1.13.8, mainline, 1, 1.13, latest
1.13.8-perl, mainline-perl, 1-perl, 1.13-perl, perl
1.13.8-alpine, mainline-alpine, 1-alpine, 1.13-alpine, alpine
1.13.8-alpine-perl, mainline-alpine-perl, 1-alpine-perl, 1.13-alpine-perl, alpine-perl
1.12.2, stable, 1.12
1.12.2-perl, stable-perl, 1.12-perl
1.12.2-alpine, stable-alpine, 1.12-alpine
1.12.2-alpine-perl, stable-alpine-perl, 1.12-alpine-perl

Теги, в которых присутствует полная семантическая версия (x.x.x) всегда неизменяемы, даже если в них встречается что-то еще, например, 1.12.2-alphine. Такую версию смело нужно брать для продакшен-окружения. Теги, подобные такому 1.12, обновляются при изменении patch версии. То есть внутри образа может оказаться и версия 1.12.2 и в будущем 1.12.8. Точно такая же схема и с версиями, в которых указана только мажорная версия, например, 1. Только в данном случае обновление идет не только по патчу, но и по минорной версии.

Как вы помните, команда docker run скачивает образ, если его нет локально, но эта проверка не связана с обновлением содержимого. Другими словами, если nginx:latest обновился, то docker run его не будет скачивать, он использует тот latest, который прямо сейчас уже загружен. Для гарантированного обновления образа существует другая команда: docker pull. Вот она всегда проверяет, обновился ли образ для определенного тега.

Кроме тегов имя образа может содержать префикс, например, etsy/chef. Этот префикс является именем аккаунта на сайте, через который создаются образы, попадающие в Registry. Большинство образов как раз такие, с префиксом. И есть небольшой набор, буквально сотня образов, которые не имеют префикса. Их особенность в том, что эти образы поддерживает сам Docker. Поэтому если вы видите, что в имени образа нет префикса, значит это официальный образ. Список таких образов можно увидеть здесь: https://github.com/docker-library/official-images/tree/master/library

Удаляются образы командой docker rmi <imagename>.

docker rmi Ruby:2.4

Untagged: Ruby:2.4
Untagged: Ruby@sha256:d973c59b89f3c5c9bb330e3350ef8c529753ba9004dcd1bfbcaa4e9c0acb0c82

Если в Докере присутствует хоть один контейнер из удаляемого образа, то Докер не даст его удалить по понятным причинам. Если вы всё же хотите удалить и образ и все контейнеры, связанные с ним, используйте флаг -f.

Управление контейнерами

Docker Container LifeCycle

Картинка описывает жизненный цикл (конечный автомат) контейнера. Кружками на нём изображены состояния, жирным выделены консольные команды, а квадратиками показывается то, что в реальности выполняется.

Проследите путь команды docker run. Несмотря на то, что команда одна, с точки зрения работы Докера выполняется два действия: создание контейнера и запуск. Существуют и более сложные варианты исполнения, но в этом разделе мы рассмотрим только базовые команды.

Запустим nginx так, чтобы он работал в фоне. Для этого после слова run добавляется флаг -d:

docker run -d -p 8080:80 nginx

431a3b3fc24bf8440efe2bca5bbb837944d5ae5c3b23b9b33a5575cb3566444e

После выполнения команды Докер выводит идентификатор контейнера и возвращает управление. Убедитесь в том, что nginx работает, открыв в браузере ссылку localhost:8080. В отличие от предыдущего запуска, наш nginx работает в фоне, а значит не видно его вывода (логов). Посмотреть его можно командой docker logs, которой нужно передать идентификатор контейнера:

docker logs 431a3b3fc24bf8440efe2bca5bbb837944d5ae5c3b23b9b33a5575cb3566444e

172.17.0.1 - - [19/Jan/2018:07:38:55 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36" "-"

Вы также можете подсоединиться к выводу лога в стиле tail -f. Для этого запустите docker logs -f 431a3b3fc24bf8440efe2bca5bbb837944d5ae5c3b23b9b33a5575cb3566444e. Теперь лог будет обновляться каждый раз, когда вы обновляете страницу в браузере. Выйти из этого режима можно набрав Ctrl + C, при этом сам контейнер остановлен не будет.

Теперь выведем информацию о запущенных контейнерах командой docker ps:

CONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS              PORTS                                          NAMES
431a3b3fc24b        nginx                            "nginx -g 'daemon of…"   2 minutes ago       Up 2 minutes        80/tcp                                         wizardly_rosalind

Расшифровка столбиков:

CONTAINER_ID — идентификатор контейнера. Так же, как и в git, используется сокращенная запись хеша.
IMAGE — имя образа, из которого был поднят контейнер. Если не указан тег, то подразумевается latest.
COMMAND — команда, которая выполнилась на самом деле при старте контейнера.
CREATED — время создания контейнера
STATUS — текущее состояние.
PORTS — проброс портов.
NAMES — алиас. Докер позволяет кроме идентификатора иметь имя. Так гораздо проще обращаться с контейнером. Если при создании контейнера имя не указано, то Докер самостоятельно его придумывает. В выводе выше как раз такое имя у nginx.

(Команда docker stats выводит информацию о том, сколько ресурсов потребляют запущенные контейнеры).

Теперь попробуем остановить контейнер. Выполним команду:

# Вместо CONTAINER_ID можно указывать имя
docker kill 431a3b3fc24b # docker kill wizardly_rosalind

431a3b3fc24b

Если попробовать набрать docker ps, то там этого контейнера больше нет. Он удален.

Команда docker ps выводит только запущенные контейнеры. Но кроме них могут быть и остановленные. Причём остановка может происходить как по успешному завершению, так и в случае ошибок. Попробуйте набрать docker run ubuntu ls, а затем docker run ubuntu bash -c "unknown". Эти команды не запускают долгоживущий процесс, они завершаются сразу после выполнения, причем вторая с ошибкой, так как такой команды не существует.

Теперь выведем все контейнеры командой docker ps -a. Первыми тремя строчками вывода окажутся:

CONTAINER ID        IMAGE                            COMMAND                  CREATED                  STATUS                       PORTS                                          NAMES
85fb81250406        ubuntu                           "bash -c unkown"         Less than a second ago   Exited (127) 3 seconds ago                                                  loving_bose
c379040bce42        ubuntu                           "ls"                     Less than a second ago   Exited (0) 9 seconds ago                                                    determined_tereshkova

Здесь как раз два последних наших запуска. Если посмотреть на колонку STATUS, то видно, что оба контейнера находятся в состоянии Exited. То есть запущенная команда внутри них выполнилась, и они остановились. Разница лишь в том, что один завершился успешно (0), а второй с ошибкой (127). После остановки контейнер можно даже перезапустить:

docker start determined_tereshkova # В вашем случае будет другое имя

Только в этот раз вы не увидите вывод. Чтобы его посмотреть, воспользуйтесь командой docker logs determined_tereshkova.

Взаимодействие с другими частями системы

Запускать изолированный контейнер, который живёт весь внутри себя, малополезно. Как правило, контейнеру нужно взаимодействовать с внешним миром, принимать входящие запросы на определенный порт, выполнять запросы на другие сервисы, читать общие файлы и писать в них. Все эти возможности настраиваются при создании контейнера.

Interactive mode

Самый простой вариант использования Докера, как мы уже убедились — поднять контейнер и выполнить внутри него какую-либо команду:

docker run ubuntu ls /usr

bin
games
include
lib
local
sbin
share
src
$

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

docker run ubuntu bash

Дело в том, что bash запускает интерактивную сессию внутри контейнера. Для взаимодействия с ней нужно оставить открытым поток STDIN и запустить TTY (псевдо-терминал). Поэтому для запуска интерактивных сессий нужно не забыть добавить опции -i и -t. Как правило, их добавляют сразу вместе как -it. Поэтому правильный способ запуска баша выглядит так: docker run -it ubuntu bash.

Ports

Если запустить nginx такой командой docker run nginx, то nginx не сможет принять ни один запрос, несмотря на то, что внутри контейнера он слушает 80 порт (напомню, что каждый контейнер по умолчанию живёт в своей собственной сети). Но если запустить его так docker run -p 8080:80 nginx, то nginx начнёт отвечать на порту 8080.

Флаг -p позволяет описывать, как и какой порт выставить наружу. Формат записи 8080:80 расшифровывается так: пробросить порт 8080 снаружи контейнера в контейнер на порт 80. Причём по умолчанию порт 8080 слушается на 0.0.0.0, то есть на всех доступных интерфейсах. Поэтому запущенный таким образом контейнер доступен не только через localhost:8080, но и снаружи машины (если доступ не запрещён как-нибудь ещё). Если нужно выполнить проброс только на loopback, то команда меняется на такую: docker run -p 127.0.0.1:8080:80 nginx.

Docker позволяет пробрасывать столько портов, сколько нужно. Например, в случае nginx часто требуется использовать и 80 порт и 443 для HTTPS. Сделать это можно так: docker run -p 80:80 -p 443:443 nginx Про остальные способы пробрасывать порты можно прочитать в официальной документации.

Volumes

Другая частая задача связана с доступом к основной файловой системе. Например, при старте nginx-контейнера ему можно указать конфигурацию, лежащую на основной фс. Докер прокинет её во внутреннюю фс, и nginx сможет её читать и использовать.

Проброс осуществляется с помощью опции -v. Вот как можно запустить баш сессию из образа Ubuntu, подключив туда историю команд с основной файловой системы: docker run -it -v ~/.bash_history:/root/.bash_history ubuntu bash. Если в открытом баше понажимать стрелку вверх, то отобразится история. Пробрасывать можно как файлы, так и директории. Любые изменения производимые внутри volume меняются как внутри контейнера, так и снаружи, причём по умолчанию доступны любые операции. Как и в случае портов, количество пробрасываемых файлов и директорий может быть любым.

При работе с Volumes есть несколько важных правил, которые надо знать:

Путь до файла во внешней системе должен быть абсолютным.
Если внутренний путь (то, что идёт после :) не существует, то Докер создаст все необходимые директории и файлы. Если существует, то заменит старое тем, что было проброшено.

Кроме пробрасывания части фс снаружи Докер предоставляет ещё несколько вариантов создания и использования Volumes. Подробнее — в официальной документации.

Переменные окружения

Конфигурирование приложения внутри контейнера, как правило, осуществляется с помощью переменных окружения в соответствии с 12factors. Существует два способа их установки:

Флаг -e. Используется он так: docker run -it -e "HOME=/tmp" ubuntu bash
Специальный файл, содержащий определения переменных окружения, который пробрасывается внутрь контейнера опцией --env-file.

Подготовка собственного образа

Создание и публикация собственного образа не сложнее его использования. Весь процесс делится на три шага:

Создается файл Dockerfile в корне проекта. Внутри описывается процесс создания образа.
Выполняется сборка образа командой docker build
Выполняется публикация образа в Registry командой docker push

Рассмотрим процесс создания образа на примере упаковки линтера eslint (не забудьте повторить его самостоятельно). В результате сборки мы получим образ, который можно использовать так:

docker run -it -v /path/to/js/files:/app my_account_name/eslint

/app/index.js
  3:6  error  Parsing error: Unexpected token

  1 | import path from 'path';
  2 |
> 3 | path(;)
    |      ^
  4 |

✖ 1 problem (1 error, 0 warnings)

То есть достаточно запустить контейнер из этого образа, подключив каталог с файлами js для проверки как Volume во внутреннюю директорию /app.

1. Конечная структура директории, на основе файлов которой соберется образ, выглядит так:

eslint-docker/
    Dockerfile
    eslintrc.yml

Файл eslintrc.yml содержит конфигурацию линтера. Он автоматически будет прочитан, если лежит в домашней директории под именем .eslintrc.yml. То есть этот файл должен попасть под таким именем в директорию /root внутрь образа.

2. Создание Dockerfile

# Dockerfile
FROM node:9.3

WORKDIR /usr/src

RUN npm install -g eslint babel-eslint
RUN npm install -g eslint-config-airbnb-base eslint-plugin-import

COPY eslintrc.yml /root/.eslintrc.yml

CMD ["eslint", "/app"]

Dockerfile имеет довольно простой формат. На каждой строчке указывается инструкция (директива) и её описание.

FROM

Инструкция FROM нужна для указания образа, от которого происходит наследование. Здесь необходимо оговориться, что образы строятся на базе друг друга и все вместе образуют большое дерево.

В корне этого дерева находится образ busybox. В прикладных задачах напрямую его не используют, так как Докером предоставляются подготовленные образы под каждую экосистему и стек.

RUN

Основная инструкция в Dockerfile. Фактически здесь указывается sh команда, которая будет выполнена в рамках окружения, указанного во FROM при сборке образа. Так как по умолчанию всё выполняется от пользователя root, то использовать sudo не нужно (и скорее всего его нет в базовом образе). К тому же учтите, что сборка образа — процесс не интерактивный. В тех ситуациях, когда вы используете команду, которая может запросить что-то от пользователя, необходимо подавлять этот вывод. Например, в случае пакетных менеджеров делают так: apt-get install -y curl. Флаг -y как раз говорит о том, что нужно производиться установку без дополнительных вопросов.

Технически образ Докера — это не один файл, а набор так называемых слоев. Каждый вызов RUN формирует новый слой, который можно представить как набор файлов, созданных и измененных (в том числе удаленных) командой, указанной в RUN. Такой подход позволяет значительно улучшить производительность системы, задействовав кеширование слоев, которые не поменялись. С другой стороны, Докер переиспользует слои в разных образах если они идентичны, что сокращает и скорость загрузки и занимаемое пространство на диске. Тема кеширования слоев довольно важная при активном использовании Докера. Для её эффективной работы нужно понимать, как она устроена и как правильно описывать инструкции RUN для максимальной утилизации.

COPY

В соответствии со своим названием команда COPY берёт файл или директорию из основной файловой системы и копирует её внутрь образа. У команды есть ограничение. То, что копируется, должно лежать в той же директории, где и Dockerfile. Именно эту команду используют при разработке когда необходимо упаковать приложение внутрь образа.

WORKDIR

Инструкция, устанавливающая рабочую директорию. Все последующие инструкции будут считать, что они выполняются именно внутри неё. Инструкция WORKDIR действует, как команда cd. Кроме того, когда мы запускаем контейнер, то он также стартует из рабочей директории. Например, запустив bash, вы окажетесь внутри неё.

CMD

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

Docker

3. Сборка

Для сборки образа используется команда docker build. С помощью флага -t передается имя образа, включая имя аккаунта и тег. Как обычно, если не указывать тег, то подставляется latest.

docker build -t my_account_name/eslint .

После выполнения данной команды вы можете увидеть текущий образ в списке docker images. Вы даже можете начать его использовать без необходимости публикации в Registry. Напомню, что команда docker run не пытается искать обновленную версию образа, если локально есть образ с таким именем и тегом.