Создание пользовательского контейнерного изображения

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

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

Архитектура изображений

Одним из «исходных кодов» изображения является Dockerfile. Dockerfile написан на языке, специфичном для Docker, и может быть скомпилирован в изображение двоичным файлом docker, используя команду docker build. Он также может быть скомпилирован buildah, используя buildah bud.

Большинство изображений основаны на другом изображении. Базовое изображение указывается в начале Dockerfile с директивой FROM. Если базовое изображение отсутствует в локальной системе, оно загружается из указанного репозитория, или, если не указано, из стандартного репозитория программы сборки. Часто это Docker Hub. Например, мы можем собрать изображение mariadb-rocksdb:10.5, начиная с изображения debian:13. Таким образом, у нас будет всё программное обеспечение, включенное в стандартное изображение Debian, и мы добавим MariaDB и его конфигурацию на это изображение.

Все следующие директивы Dockerfile компилируются в новое изображение Docker, идентифицируемое строкой SHA256. Каждое из этих изображений основано на изображении, скомпилированном из предыдущей директивы. Физическое скомпилированное изображение может служить основой для любого количества изображений. Этот механизм экономит много места на диске, время загрузки и время сборки.

На следующей диаграмме показаны отношения между Dockerfile, изображениями и контейнерами:

Синтаксис Dockerfile

Вот пример простого Dockerfile:

FROM ubuntu:20.04

RUN apt-get update
RUN apt-get install -y mariadb-server

EXPOSE 3306

LABEL version="1.0"
LABEL description="MariaDB Server"

HEALTHCHECK --start-period=5m \
  CMD mariadb -e 'SELECT @@datadir;' || exit 1

CMD ["mariadbd"]

Этот пример не очень хорош для практического применения, но он показывает, как выглядит Dockerfile.

Сначала мы объявляем, что базовое изображение, которое следует использовать, — ubuntu:20.04.

Затем мы выполняем некоторые команды для установки MariaDB из стандартных репозиториев Ubuntu и останавливаем службу MariaDB.

Мы определяем некоторые метаданные об изображении с помощью LABEL. Любая метка допустима.

Мы объявляем, что порт 3306 (стандартный порт MariaDB) должен быть открыт. Однако это не оказывает никакого эффекта, если порт не открыт при создании контейнера.

Мы также определяем healthcheck. Это команда, которая выполняется для проверки работоспособности контейнера. Если возвращаемый код равен 0, healthcheck проходит успешно, если он равен 1 — проваляется. В случае MariaDB мы хотим проверить, что она запущена и может ответить на простой запрос. Это лучше, чем просто проверка того, что процесс MariaDB запущен, потому что MariaDB может быть запущена, но не может ответить, например, из-за того, что max_connections достигнут или данные повреждены. Мы считываем системную переменную, потому что мы не должны предполагать, что любая созданная пользователем таблица существует. Мы также указываем --start-period, чтобы дать некоторое время MariaDB на запуск, учитывая, что перезапуск может занять некоторое время, если какие-то данные повреждены. Обратите внимание, что может быть только один healthcheck: если команда указана несколько раз, будет действовать только последняя.

Наконец, мы запускаем команду контейнера: mariadbd. Эта команда выполняется при запуске контейнера на основе этого изображения. Когда процесс останавливается или завершается аварийно, контейнер немедленно остановится.

Обратите внимание, что в контейнере мы обычно запускаем mariadbd напрямую или в скрипте entrypoint exec mariadbd, а не запускаем mysqld_safe или запускаем MariaDB как службу. Контейнеры могут быть перезапущены службой контейнеров. См. автоматический перезапуск.

См. ссылки на документацию ниже, чтобы узнать о поддерживаемом синтаксисе в Dockerfile.

Использование переменных

В Dockerfile можно использовать переменные. Это позволяет, например, устанавливать разные пакеты, устанавливать разные версии пакета или по-разному настраивать программное обеспечение в зависимости от того, как установлены переменные, без изменения самого Dockerfile.

Для использования переменной можно сделать следующее:

FROM ubuntu:20.04

ARG MARIADB_CONFIG_FILE

...

ENTRYPOINT mariadbd --defaults-file=$MARIADB_CONFIG_FILE

Здесь ARG используется после директивы FROM, поэтому переменная не может быть использована в FROM. Также можно объявить переменную до FROM, чтобы мы могли использовать переменную для выбора базового изображения или его метки, но в этом случае переменная не может быть использована после директивы FROM, если ARG не объявлен заново после FROM. Вот пример:

ARG UBUNTU_VERSION
FROM ubuntu:$UBUNTU_VERSION

# Uncomment for the build error to be avoided
# ARG UBUNTU_VERSION

# But this will cause a build error:
RUN echo 'Ubuntu version: $UBUNTU_VERSION' > /var/build_log

Нам нужно будет присвоить значения переменным при сборке Dockerfile, так:

docker build --build-arg UBUNTU_VERSION=20.04 .

Обратите внимание, что переменные Dockerfile — это просто плейсхолдеры для значений. Dockerfile не поддерживает присваивание, условные операторы или циклы.

Версионирование и развертывание изображений

Dockerfile обычно имеют версию, а также файлы, которые копируются в изображения.

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

Реестры контейнеров

Стандартный реестр контейнеров для изображений OCI — Docker Hub. Он содержит официальные изображения Docker, поддерживаемые командой Docker Library и сообществом. Любой человек или организация может открыть учётную запись и загружать изображения в Docker Hub. Большинство изображений Docker с открытым исходным кодом: Dockerfile и необходимые файлы для сборки изображений обычно находятся на GitHub.

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

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

Выбор имен и меток изображений

Имена изображений, разработанных сообществом, следуют этой схеме:

repository/maintainer/technology

Не имеет значения, является ли разработчик человеком или организацией. Для изображений, доступных в Docker Hub, разработчик — это имя учётной записи Docker Hub.

Официальные изображения, поддерживаемые разработчиками Docker Library, имеют неявное имя library, заполненное инструментом получения контейнера. Например, официальное изображение MariaDB называется mariadb, что является псевдонимом для docker.io/library/mariadb.

Все изображения имеют метку, которая идентифицирует версию или вариант изображения. Например, все доступные версии MariaDB в Docker используются в качестве меток изображения. MariaDB 10.11 называется mariadb:10.11.

По сути, метки образуют иерархию. Например, существует метка 10.1.1, чьё значение не изменится со временем. 10.5 всегда будет обозначать последнюю стабильную версию в ветке 10.5. В течение некоторого времени это было 10.5.1, затем оно стало 10.5.2, и так далее.

Когда мы извлекаем изображение без указания метки (т.е., docker pull mariadb), мы неявно запрашиваем изображение с меткой latest. Это ещё более изменчиво: в разные периоды времени оно указывало на последнюю версию 10.0, на последнюю версию 10.1, и так далее.

В производственной среде всегда лучше точно знать, какую версию мы устанавливаем. Поэтому лучше указать метку, значение которой не будет меняться со временем, например, 10.5.21. Чтобы оставаться на последней LTS версии, можно использовать lts.

Загрузка и извлечение изображений

Для извлечения изображения из Docker Hub или собственного реестра используем команду docker pull. Например:

docker pull mariadb:10.5

Эта команда загружает указанное изображение, если оно ещё не присутствует в системе, или если локальная версия не является актуальной.

После изменения Dockerfile мы можем собрать изображение так:

docker build .

Эта процедура может быть автоматизирована такими службами, как Docker Hub и GitHub. Обратитесь к документации этих служб, чтобы узнать, как работает эта функция.

После создания изображения его можно загрузить в реестр. Сделать это можно так:

docker push <image_name>:<tag>

Надёжность содержимого Docker

Docker имеет функцию Docker Content Trust (DCT). Это система, используемая для цифрового подписи изображений на основе ключей PEM. В средах, где безопасность имеет первостепенное значение, важно подписать изображения перед их загрузкой. Это можно сделать как в Docker Hub, так и в собственных реестрах.

Рекомендации и замечания

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

• Иногда полезно выполнять несколько команд оболочки в одной директиве RUN для избежания создания бесполезных изображений.
• Изменение директивы означает, что все последующие директивы также необходимо перестроить. Когда это возможно, директивы, которые, как ожидается, будут меняться часто, должны следовать за директивами, которые будут меняться редко.
• Директивы, такие как LABEL или EXPOSE, должны располагаться ближе к концу Dockerfile. Таким образом, они будут перестраиваться часто, но эта операция недорогая. С другой стороны, изменение метки не должно вызывать длительный процесс перестройки.
• Переменные следует использовать для избежания разрастания Dockerfile. Но если переменная используется, изменение её значения следует проверять. Поэтому убедитесь, что вы не используете переменные без достаточного основания.
• Вносить логику в Dockerfile невозможно или очень сложно. Используйте скрипты оболочки вместо этого, и записывайте свою логику в них. Например, в скрипте оболочки легко выполнить определённое действие только при условии, что переменная имеет определённое значение.
• Если вам нужны контейнеры MariaDB с различными конфигурациями или различными наборами плагинов, используйте описанный выше метод. Не создавайте несколько Dockerfile с разными метками для каждой желаемой конфигурации или набора плагинов. Это может привести к нежелательному дублированию кода и увеличению затрат на обслуживание.

Ссылки

Дополнительные сведения можно найти в документации Docker:

• Справочник Dockerfile.
• docker build.
• Репозитории.
• Развернуть сервер реестра.
• Доверие к содержимому в Docker.

См. также:

• Privacy-Enhanced Mail в Википедии.

Контент изначально предоставлен Vettabase Ltd.