official images
1.0.0
Официальные изображения Docker — это тщательно подобранные изображения, размещенные на Docker Hub. Основными принципами являются:
Сосредоточьтесь на бесплатном программном обеспечении с открытым исходным кодом
Поддержка нескольких архитектур
Приведите примеры лучших практик Dockerfile
Активно перестраиваться для получения обновлений и исправлений безопасности.
Придерживайтесь рекомендаций вышестоящего уровня
Добавьте минимальное качество жизни для контейнерной среды там, где это возможно.
См. документацию Docker для получения хорошего общего обзора программы.
По сути, мы стремимся прислушиваться к рекомендациям разработчиков относительно того, как они планируют использовать свое программное обеспечение. Многие изображения поддерживаются в сотрудничестве с соответствующим исходным проектом, если не поддерживаются непосредственно ими. Кроме того, мы стремимся продемонстрировать лучшие практики использования Dockerfiles, которые могут служить справочной информацией при создании или извлечении из них собственных образов.
(Если вы являетесь представителем апстрима, для которого существует образ, и хотите принять участие, см. раздел «Сопровождение» ниже!)
Некоторые образы были портированы для других архитектур, и многие из них официально поддерживаются (в разной степени).
arm32v6 ): https://hub.docker.com/u/arm32v6/arm32v7 ): https://hub.docker.com/u/arm32v7/arm64v8 ): https://hub.docker.com/u/arm64v8/amd64 ): https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ): https://hub.docker.com/u/arm32v5/ppc64le ): https://hub.docker.com/u/ppc64le/s390x ): https://hub.docker.com/u/s390x/mips64le ): https://hub.docker.com/u/mips64le/riscv64 ): https://hub.docker.com/u/riscv64/i386 ): https://hub.docker.com/u/i386/ По состоянию на 12 сентября 2017 г. эти другие архитектуры включены в образы без префиксов через «списки манифестов» (также известные как «индексы» в спецификации образа OCI), так что, например, docker run hello-world , должен работать как есть на всех поддерживаемых платформах.
Если вам интересно, как они создаются, перейдите по адресу https://doi-janky.infosiftr.net/job/multiarch/, чтобы увидеть структуру сборки.
См. раздел «Мультиархитектуры» ниже, где приведены рекомендации по добавлению дополнительных архитектур в официальный образ.
Да! У нас есть специальный репозиторий часто задаваемых вопросов, где мы стараемся собирать другие распространенные вопросы (как о программе, так и о нашей практике).
Благодарим вас за интерес к проекту официальных изображений Docker! Мы стремимся сделать эти инструкции максимально простыми и понятными, но если вы заблудились, не стесняйтесь обращаться к нам в Libera.Chat IRC на канале #docker-library или создав задачу на GitHub здесь.
Обязательно ознакомьтесь с официальными репозиториями в Docker Hub и рекомендациями по написанию Dockerfiles в документации Docker. Они станут основой процесса проверки, выполняемой официальными сопровождающими изображений. Если вы хотите, чтобы процесс проверки прошел более гладко, перед отправкой запроса на извлечение убедитесь, что ваши Dockerfile соответствуют всем пунктам, упомянутым там, а также ниже.
Кроме того, описания Hub для этих образов в настоящее время хранятся отдельно в репозитории docker-library/docs , чей файл README.md объясняет больше о том, как он структурирован и как в него внести свой вклад. Будьте готовы разместить здесь PR-заявку, пока ваше изображение не будет принято здесь.
Поскольку официальные образы предназначены для использования в качестве инструментов обучения для новичков в Docker, а также в качестве базовых образов для опытных пользователей при создании своих рабочих версий, мы проверяем каждый предлагаемый Dockerfile чтобы убедиться, что он соответствует минимальным стандартам качества и удобства обслуживания. Хотя некоторые из этих стандартов трудно определить (из-за субъективности), здесь определяется как можно больше, при этом придерживаясь «Лучших практик», где это уместно.
Контрольный список, который могут использовать сопровождающие во время проверки, можно найти на сайте NEW-IMAGE-CHECKLIST.md .
Необходимо своевременно устранять изменения в версиях и исправления безопасности.
Если вы не представляете вышестоящую компанию, а вышестоящая сторона заинтересована в поддержании образа, необходимо предпринять шаги, чтобы обеспечить плавный переход от обслуживания образа к вышестоящей стороне.
Для вышестоящих разработчиков, желающих взять на себя сопровождение существующего репозитория, первым шагом является участие в работе существующего репозитория. Комментировать проблемы, предлагать изменения и заявлять о себе в «сообществе изображений» (даже если это «сообщество» является всего лишь текущим сопровождающим) — все это важные моменты, с которых нужно начать, чтобы гарантировать, что переход не станет сюрпризом для существующих участников и пользователей.
Принимая на себя управление существующим репозиторием, убедитесь, что вся история Git исходного репозитория хранится в новом репозитории, обслуживаемом вышестоящим репозиторием, чтобы процесс проверки не приостановился во время перехода. Это проще всего сделать, создав новый репозиторий, но также можно получить коммиты непосредственно из оригинала и отправить их в новый репозиторий (т. е. git fetch https://github.com/jsmith/example.git master . git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). На GitHub альтернативой является передача права собственности на репозиторий git. Это можно сделать, не предоставляя администратору группы доступ к репозиторию другого владельца:
Пересборка одного и того же Dockerfile должна привести к упаковке той же версии образа, даже если вторая сборка произойдет несколькими версиями позже, или сборка должна полностью завершиться неудачно, так что непреднамеренное перестроение файла Dockerfile с тегом 0.1.0 не закончится. вверх, содержащий 0.2.3 . Например, если вы используете apt для установки основной программы для образа, обязательно прикрепите ее к определенной версии (например: ... apt-get install -y my-package=0.1.0 ... ). Для зависимых пакетов, установленных с помощью apt обычно нет необходимости привязывать их к версии.
Никакие официальные изображения не могут быть получены из неофициальных изображений или зависеть от них (допускается scratch не-изображений и намеренно ограниченные исключения, закрепленные в .external-pins — см. также .external-pins/list.sh ).
Все официальные изображения должны обеспечивать единообразный интерфейс. Начинающий пользователь должен иметь возможность docker run official-image bash (или sh ) без необходимости изучения --entrypoint . Опытным пользователям также полезно воспользоваться точкой входа, чтобы они могли docker run official-image --arg1 --arg2 без необходимости указывать двоичный файл для выполнения.
Если процессу запуска не нужны аргументы, просто используйте CMD :
CMD [ "irb" ] Если при запуске необходимо выполнить инициализацию, например создание исходной базы данных, используйте ENTRYPOINT вместе с CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Убедитесь, что docker run official-image bash (или sh ) тоже работает. Самый простой способ — проверить ожидаемую команду и, если это что-то другое, просто exec "$@" (запустить все, что было передано, правильно сохраняя экранированные аргументы).
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ " Если образ содержит только основной исполняемый файл и связанные с ним библиотеки (т. е. без оболочки), то можно использовать исполняемый файл в качестве ENTRYPOINT , поскольку это единственное, что может быть запущено:
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] Наиболее распространенным индикатором того, подходит ли это, является то, что образ Dockerfile начинается с scratch ( FROM scratch ).
Постарайтесь сделать Dockerfile простым для понимания/чтения. Для краткости может возникнуть соблазн поместить сложные детали инициализации в отдельный скрипт и просто добавить команду RUN в Dockerfile . Однако это приводит к тому, что полученный Dockerfile становится слишком непрозрачным, и такие файлы Dockerfile вряд ли пройдут проверку. Вместо этого рекомендуется поместить все команды для инициализации в Dockerfile в виде соответствующих комбинаций команд RUN или ENV . Чтобы найти хорошие примеры, посмотрите текущие официальные изображения.
Некоторые примеры на момент написания:
Следуя рекомендациям Docker, настоятельно рекомендуется, чтобы результирующий образ содержал только одну задачу на контейнер; преимущественно это означает только один процесс на контейнер, поэтому нет необходимости в полной системе инициализации. Есть две ситуации, когда процесс, подобный init, может быть полезен для контейнера. Первый из них — обработка сигналов. Если запущенный процесс не обрабатывает SIGTERM при выходе, он не будет завершен, поскольку в контейнере у него PID 1 (см. «ПРИМЕЧАНИЕ» в конце раздела «Передний план» в документации Docker). Вторая ситуация — это жатва зомби. Если процесс порождает дочерние процессы и не использует их должным образом, это приведет к заполнению таблицы процессов, что может помешать всей системе создавать какие-либо новые процессы. Для обеих этих проблем мы рекомендуем Тини. Он невероятно мал, имеет минимальные внешние зависимости, выполняет каждую из этих ролей и выполняет только необходимые части сбора данных и пересылки сигналов.
Обязательно используйте Tini в CMD или ENTRYPOINT , если это необходимо.
Лучше всего устанавливать Tini из пакета, поставляемого с дистрибутивом (например, apt-get install tini ). Если Tini недоступен в вашем дистрибутиве или слишком стар, вот фрагмент файла Dockerfile который можно добавить в Tini:
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --versionЭто тот случай, когда опыт оказывается важнее документации на пути к просветлению, но следующие советы могут помочь:
По возможности избегайте COPY / ADD , но при необходимости будьте максимально конкретны (т. е. COPY one-file.sh /somewhere/ вместо COPY . /somewhere ).
Причина этого в том, что кеш для инструкций COPY рассматривает изменения mtime файла как сбой в кеше, что иногда может сделать поведение кеша COPY непредсказуемым, особенно когда .git является частью того, что необходимо COPY (например).
Убедитесь, что строки, которые с меньшей вероятностью изменятся, предшествуют строкам, которые с большей вероятностью изменятся (с оговоркой, что каждая строка должна генерировать изображение, которое по-прежнему успешно работает без предположений о последующих строках).
Например, строка, содержащая номер версии программного обеспечения ( ENV MYSOFTWARE_VERSION 4.2 ), должна идти после строки, настраивающей файл .list репозитория APT ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
Dockerfile должен быть написан, чтобы помочь смягчить атаки перехвата во время сборки. Наши требования направлены на три основные цели: проверка источника, проверка автора и проверка контента; это достигается соответственно следующим образом: используя https, где это возможно; импорт ключей PGP с полным отпечатком в Dockerfile для проверки подписей; встраивание контрольных сумм непосредственно в Dockerfile . По возможности следует использовать все три. Если подпись не опубликована, можно использовать только https и встроенную контрольную сумму. В крайнем случае, допустима только встроенная контрольная сумма, если на сайте нет https и нет подписи.
Цель рекомендации использования https для загрузки необходимых артефактов состоит в том, чтобы гарантировать, что загрузка происходит из надежного источника, что также значительно затрудняет перехват.
Цель рекомендации проверки подписи PGP — гарантировать, что только авторизованный пользователь опубликовал данный артефакт. При импорте ключей PGP по возможности используйте keys.openpgp.org (в противном случае отдайте предпочтение keyserver.ubuntu.com ). См. также раздел часто задаваемых вопросов о ключах и проверке.
Цель рекомендации проверки контрольной суммы — убедиться, что артефакт соответствует ожиданиям. Это гарантирует, что при изменении удаленного контента Dockerfile также изменится и обеспечит естественное разрушение кэша docker build . В качестве бонуса это также предотвращает случайную загрузку более новых, чем ожидалось, артефактов в файлы с плохими версиями.
Ниже приведены некоторые примеры:
Предпочтительно : загрузка через https, полный импорт отпечатков пальцев ключа PGP и проверка asc , проверка встроенной контрольной суммы.
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# installАльтернативный вариант : полный отпечаток ключа, импортированный в apt, который будет проверять подписи и контрольные суммы при загрузке и установке пакетов.
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (Кстати, rm -rf /var/lib/apt/lists/* примерно противоположен apt-get update — он гарантирует, что слой не включает лишние ~8 МБ данных списка пакетов APT, и обеспечивает соответствующее использование apt-get update .)
Менее безопасный вариант : встроить контрольную сумму в Dockerfile .
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# installПримечание. Использование SHA1 или MD5 следует рассматривать как «контрольную сумму последней инстанции», поскольку оба они считаются в целом небезопасными:
Недопустимо : загрузить файл через http(s) без проверки.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install По умолчанию контейнеры Docker выполняются с ограниченными привилегиями: возможности Linux внесены в белый список, группы управления и профиль Seccomp по умолчанию (1.10+ с поддержкой хоста). Программному обеспечению, работающему в контейнере, для правильной работы могут потребоваться дополнительные привилегии, и существует ряд параметров командной строки для настройки выполнения контейнера. См. Справочник docker run и Seccomp для Docker для справки.
Официальные репозитории, требующие дополнительных привилегий, должны указывать минимальный набор параметров командной строки для функционирования программного обеспечения, и они все равно могут быть отклонены, если это создает серьезные проблемы с переносимостью или безопасностью. В общем, --privileged не разрешен, но комбинация опций --cap-add и --device может быть приемлемой. Кроме того, --volume может быть непростым, поскольку существует множество мест файловой системы хоста, которые создают проблемы с переносимостью/безопасностью (например, сокет X11).
Для обновлений образов, которые представляют собой исправления безопасности, мы рекомендуем выполнить несколько действий, которые помогут обеспечить объединение, сборку и выпуск обновления как можно быстрее:
[email protected] за несколько (рабочих) дней, чтобы сообщить нам и оценить сроки (чтобы мы могли соответствующим образом запланировать время для входящего обновления).[security] в заголовок вашего запроса на включение (например, [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). В каждом репозитории можно указать несколько архитектур для любых тегов. Если архитектура не указана, образы собираются в Linux на amd64 (он же x86-64). Чтобы указать больше или разные архитектуры, используйте поле Architectures (список, разделенный запятыми, пробелы обрезаны). Допустимые архитектуры можно найти в файле oci-platform.go Bashbrew:
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 Architectures любого данного тега должны быть строгим подмножеством Architectures тега, ОТ которого он FROM .
Образы должны иметь один Dockerfile для каждой записи в файле библиотеки, который можно использовать для нескольких архитектур. Это означает, что каждая поддерживаемая архитектура будет иметь одну и ту же строку FROM (например, FROM debian:bookworm ). См. golang , docker , haproxy и php для примеров библиотечных файлов, использующих один Dockerfile для каждой записи, и просмотрите соответствующие репозитории git, например Dockerfile s.
Если разные части Dockerfile встречаются только в той или иной архитектуре, используйте поток управления (например, if / case ) вместе с dpkg --print-architecture или apk -print-arch для определения архитектуры пользовательского пространства. Используйте uname для определения архитектуры только в том случае, если невозможно установить более точные инструменты. См. golang для примера, когда некоторые архитектуры требуют создания двоичных файлов из исходных пакетов вышестоящего уровня, а некоторые просто загружают двоичную версию.
Для базовых образов, таких как debian потребуется другой Dockerfile и контекст сборки, чтобы ADD двоичные файлы, специфичные для архитектуры, и это является допустимым исключением из вышеизложенного. Поскольку эти изображения используют одни и те же Tags , они должны находиться в одной записи. Используйте поля, специфичные для архитектуры, для GitRepo , GitFetch , GitCommit и Directory , которые представляют собой архитектуру, объединенную дефисом ( - ) и полем (например, arm32v7-GitCommit ). Любая архитектура, не имеющая поля, специфичного для архитектуры, будет использовать поле по умолчанию (например, отсутствие arm32v7-Directory означает, что Directory будет использоваться для arm32v7 ). Примеры см. в файлах debian или ubuntu в библиотеке. Ниже приведен пример hello-world :
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
Дополнительную информацию о формате файла библиотеки см. в разделе «Формат инструкций».
К предложению нового официального имиджа не следует относиться легкомысленно. Мы ожидаем и требуем обязательств по поддержанию вашего имиджа (включая, в частности, своевременные обновления по мере необходимости, как указано выше).
Файлы определения библиотеки представляют собой обычные текстовые файлы, находящиеся в каталоге library/ репозитория official-images . Каждый файл библиотеки управляет текущим «поддерживаемым» набором тегов изображений, которые отображаются в описании Docker Hub. Теги, удаленные из файла библиотеки, не удаляются из Docker Hub, поэтому старые версии могут оставаться доступными для использования, но не поддерживаются вышестоящей версией или сопровождающим официального образа. Теги в файле библиотеки создаются только посредством обновления этого файла библиотеки или в результате обновления его базового образа (т. е. образ FROM debian:bookworm будет пересобран при сборке debian:bookworm ). При обновлении базы будет перестроено только то, что находится в файле библиотеки.
Учитывая эту политику, стоит прояснить несколько случаев: версии с обратным заполнением, кандидаты на выпуск и сборки непрерывной интеграции. Когда предлагается новый репозиторий, обычно в первоначальный запрос на включение включаются некоторые старые неподдерживаемые версии с соглашением об их удалении сразу после принятия. Не путайте это с обширным историческим архивом, что не является целью. Другой распространенный случай, когда термин «поддерживается» немного растягивается, — это кандидаты на выпуск. Релиз-кандидат на самом деле — это просто соглашение об именах для релизов с коротким сроком существования, поэтому они полностью приемлемы и поощряются. В отличие от кандидата на выпуск, сборки непрерывной интеграции с полностью автоматизированным циклом выпуска на основе фиксации кода или регулярного расписания не подходят.
Настоятельно рекомендуется просмотреть некоторое содержимое существующей library/ файла (и историю, чтобы почувствовать, как они меняются с течением времени), прежде чем создавать новую, чтобы ознакомиться с преобладающими соглашениями и дополнительно упростить процесс проверки (чтобы что мы можем сосредоточиться на контенте, а не на эзотерическом форматировании или использовании/именовании тегов).
Имя файла определения будет определять имя репозитория изображений, который он создает в Docker Hub. Например, файл library/ubuntu создаст теги в репозитории ubuntu .
Теги репозитория должны отражать версии или варианты исходного кода. Например, Ubuntu 14.04 также известен как Ubuntu Trusty Tahr, но часто просто Ubuntu Trusty (особенно при использовании), поэтому ubuntu:14.04 (номер версии) и ubuntu:trusty (имя версии) являются подходящими псевдонимами для одного и того же содержимого образа. В Docker тег latest — это особый случай, но его употребление несколько неверно; latest действительно является тегом «по умолчанию». Когда кто-то выполняет docker run xyz , Docker интерпретирует это как docker run xyz:latest . Учитывая это, ни один другой тег никогда не содержит строку latest , поскольку пользователи не ожидают и не поощряют ее ввод (т. е. xyz:latest действительно следует использовать просто как xyz ). Другими словами, псевдоним для «высшей версии XYZ серии 2.2» должен быть xyz:2.2 , а не xyz:2.2-latest . Аналогично, если существует альпийский вариант xyz:latest , он должен иметь псевдоним xyz:alpine , а не xyz:alpine-latest или xyz:latest-alpine .
Настоятельно рекомендуется присваивать тегам номеров версий псевдонимы, позволяющие пользователю легко оставаться на «самой последней» версии конкретной серии. Например, учитывая поддерживаемые в настоящее время версии программного обеспечения XYZ 2.3.7 и 2.2.4, предлагаемыми псевдонимами будут Tags: 2.3.7, 2.3, 2, latest и Tags: 2.2.4, 2.2 соответственно. В этом примере пользователь может использовать xyz:2.2 , чтобы легко использовать самый последний выпуск патчей серии 2.2, или xyz:2 если требуется меньшая степень детализации (Python — хороший пример того, где это наиболее очевидно полезно — python:2 и python:3 очень разные, и их можно рассматривать как latest тег для каждого из основных выпусков Python).
Как описано выше, latest на самом деле является «по умолчанию», поэтому изображение, для которого оно является псевдонимом, должно отражать, какую версию или вариант программного обеспечения следует использовать пользователям, если они не знают или не заботятся о том, какую версию они используют. Используя Ubuntu в качестве примера, ubuntu:latest указывает на самую последнюю версию LTS, учитывая, что именно ее следует использовать большинству пользователей, если они знают, что им нужна Ubuntu, но не знают или не заботятся о том, какая версия (особенно если учесть, что это будет наиболее «стабильный» и хорошо поддерживаемый выпуск на данный момент времени).
Формат файла манифеста официально основан на RFC 2822 и поэтому должен быть знаком людям, которые уже знакомы с «заголовками» многих популярных интернет-протоколов/форматов, таких как HTTP или электронная почта.
Основные дополнения основаны на том, как Debian обычно использует 2822, а именно: строки, начинающиеся с # игнорируются, а «записи» разделяются пустой строкой.
Первая запись — это «глобальные» метаданные изображения. Единственное обязательное поле в глобальной записи — это Maintainers , значение которого разделено запятыми в формате Name <email> (@github) или Name (@github) . Любое поле, указанное в глобальной записи, будет использоваться по умолчанию для остальных записей и может быть переопределено в отдельной записи.
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew будет извлекать код из репозитория Git ( GitRepo ) при указанной фиксации ( GitCommit ). Если указанный коммит недоступен при получении master связанного GitRepo , возникает необходимость указать значение для GitFetch , чтобы сообщить Bashbrew, какую ссылку следует получить, чтобы получить необходимый коммит.
Созданный образ будет помечен как <manifest-filename>:<tag> (т.е. library/golang со значением Tags 1.6, 1, latest создаст теги golang:1.6 , golang:1 и golang:latest ).
При желании, если Directory присутствует, Bashbrew будет искать Dockerfile внутри указанного подкаталога, а не в корне (и Directory будет использоваться в качестве «контекста» для сборки вместо верхнего уровня репозитория). Если File присутствует, вместо Dockerfile будет использоваться указанное имя файла.
Подробную информацию о том, как указать другой GitRepo , GitFetch , GitCommit или Directory для конкретной архитектуры, см. в разделе «Мультиархитектура».
library/ папке. Его именем будет имя вашего репозитория на Хабе. Bashbrew ( bashbrew ) — инструмент для клонирования, создания, тегирования и отправки официальных образов Docker. Дополнительную информацию см. README Bashbrew.
