Содержимое образа

Разрешённое содержимое

Dockerfile в Fedora не должны содержать принципиально новый код. Это означает, что программное обеспечение должно быть правильно упаковано в виде RPM и размещено в репозиториях Fedora; Dockerfile являются лишь механизмом доставки предопределённых «готовых к запуску» конфигураций. Любое содержимое, сопровождающее Dockerfile, должно быть либо файлами конфигурации, либо скриптами запуска/оркестрации. Цель этого — следовать ключевым положениям философии Release Engineering Fedora.

Размещение файлов

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

Какова бы ни была выбранная структура, рекомендуется использовать схожие пути для похожих образов контейнеров. Например, если образ контейнера PostgreSQL использует определённую структуру каталогов, MariaDB должна использовать аналогичную структуру, поскольку именно этого будут ожидать пользователи.

Рекомендуемое расположение и схема именования приведены ниже (в качестве примера взят MySQL):

Table 1. Расположение вспомогательных файлов

Расположение

Описание

/usr/bin/run-mysqld

Основные исполняемые файлы, которые обычно используют пользователи; один из них обычно устанавливается как CMD по умолчанию

/usr/libexec/container-setup

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

/etc/my.cnf

Основной файл конфигурации для демона; расположение файла конфигурации должно совпадать с RPM, поскольку этого ожидают пользователи

/usr/share/container-scripts/mysql/my-tuning.cnf.template

Шаблон для другого файла конфигурации; его содержимое может быть обработано с помощью утилиты envsubst, чтобы конкретные значения устанавливались в соответствии с переменными среды, переданными в качестве аргумента команде docker run

/var/lib/mysql/data

Путь к данным, который часто является томом Docker; часть data важна, чтобы монтируемый каталог не имел родительского каталога, принадлежащего root

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

Добавление всех файлов в Dockerfile затем может быть настолько простым:

``` COPY root / ```

Исходные файлы могут храниться на FTP или другом носителе, который не сохраняет атрибуты файлов UNIX, поэтому Dockerfile или скрипт `container-setup` должны убедиться, что файлы имеют правильные атрибуты, например, что файлы в `/usr/bin/*` являются исполняемыми и т. д.


=== Многоконтейнерные сервисы

Каждый образ контейнера должен предоставлять только один «сервис», а многоконтейнерные сервисы должны управляться внешним инструментом оркестрации на усмотрение пользователя, таким как [https://www.openshift.org/ OpenShift Origin], [http://kubernetes.io/ kubernetes], [http://deis.io/ deis], [https://docs.docker.com/swarm/ Docker Swarm], [https://docs.docker.com/compose/ Docker Compose], [https://dcos.io/ DC/OS], [https://www.cloudfoundry.org/ Cloud Foundry], [https://mesos.apache.org/ Apache Mesos] и т. д.

Такие многоконтейнерные сервисы должны быть документированы таким образом, чтобы пользователи могли адаптировать их под свои нужды. Одним из примеров является использование спецификации [https://github.com/projectatomic/nulecule nulecule] от [https://projectatomic.io Project Atomic].

Want to help? Learn how to contribute to Fedora Docs ›