Работа с реестром контейнеров

Вы можете хранить образы Docker и OCI и управлять ими в Container registry.

В этой статье

Примечание.

Container registry в настоящее время находится в public preview для GitHub Enterprise Server и подлежит изменению.

Для использования Container registry необходимо включить GitHub Packages и изоляцию поддоменов. Дополнительные сведения см. в разделе Работа с реестром контейнеров.

Сведения о Container registry

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

Чтобы использовать Container registry на GitHub Enterprise Server, администратор сайта должен сначала настроить GitHub Packages для экземпляра и включить изоляцию поддомена. Дополнительные сведения см. в разделе [AUTOTITLE и Начало работы с пакетами GitHub для вашего предприятия](/admin/configuration/configuring-network-settings/enabling-subdomain-isolation).

Сведения о поддержке Container registry

В настоящее время Container registry поддерживает следующие форматы образов контейнеров:

При установке или публикации образа Docker Container registry поддерживает внешние слои, такие как образы Windows.

Проверка подлинности Container registry

Примечание.

GitHub Packages поддерживает проверку подлинности только с помощью personal access token (classic). Дополнительные сведения см. в разделе Управление личными маркерами доступа.

Для публикации, установки и удаления частных, внутренних и общедоступных пакетов требуется маркер доступа.

Можно использовать personal access token (classic) для проверки подлинности в API GitHub Packages или API GitHub . При создании personal access token (classic)можно назначить маркер различным областям в зависимости от ваших потребностей. Дополнительные сведения о областях, связанных с пакетами, для personal access token (classic), см. в разделе Сведения о разрешениях для пакетов GitHub.

Для проверки подлинности в реестре GitHub Packages в рабочем процессе GitHub Actions можно использовать следующее:

  • GITHUB_TOKEN для публикации пакетов, связанных с репозиторием рабочих процессов.
  • personal access token (classic) с по крайней мере read:packages областью действия для установки пакетов, связанных с другими частными репозиториями (GITHUB_TOKEN можно использовать, если репозиторий предоставлен доступ на чтение к пакету. См . раздел AUTOTITLE.

Проверка подлинности в рабочем процессе GitHub Actions

Этот реестр поддерживает детализированные разрешения. Для реестров, поддерживающих детализированные разрешения, если рабочий процесс GitHub Actions использует personal access token для проверки подлинности в реестре, настоятельно рекомендуется обновить рабочий процесс для использования GITHUB_TOKEN. Инструкции по обновлению рабочих процессов, прошедших проверку подлинности в реестре с помощью personal access token, см. в разделе Публикация и установка пакета с помощью GitHub Actions.

Примечание.

Возможность удаления и восстановления пакетов с помощью REST API GitHub Actions в настоящее время находится в public preview и подлежит изменению.

Вы можете использовать GITHUB_TOKEN рабочий процесс GitHub Actions для удаления или восстановления пакета с помощью REST API, если маркер имеет admin разрешение на пакет. Репозитории, публикующие пакеты с помощью рабочего процесса и репозиториев, которые явно подключены к пакетам, автоматически предоставляются admin разрешения на пакеты в репозитории.

Дополнительные сведения см. в GITHUB_TOKENразделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах. Дополнительные сведения о рекомендациях при использовании реестра в действиях см. в разделе Справочник по безопасному использованию.

Вы также можете предоставить доступ к пакетам независимо для GitHub Actions. Дополнительные сведения см. в разделе [AUTOTITLE и Настройка управления доступом и видимости пакета](/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package).

Проверка подлинности с помощью personal access token (classic)

Убедитесь, что вы замените HOSTNAME экземпляр GitHub Enterprise Server имя узла или IP-адрес в приведенных ниже примерах.

Примечание.

GitHub Packages поддерживает проверку подлинности только с помощью personal access token (classic). Дополнительные сведения см. в разделе Управление личными маркерами доступа.

  1. Создайте personal access token (classic) с соответствующими областями для задач, которые необходимо выполнить. Если для вашей организации требуется единый вход, необходимо включить его для нового маркера.

    Примечание.

    По умолчанию при выборе write:packages области для personal access token (classic) в пользовательском интерфейсе repo также будет выбрана область. Область repo предлагает ненужный и широкий доступ, который мы рекомендуем избежать использования для рабочих процессов GitHub Actions в частности. Дополнительные сведения см. в разделе Справочник по безопасному использованию. В качестве обходного решения можно выбрать только write:packages область для personal access token (classic) в пользовательском интерфейсе с помощью этого URL-адреса: https://HOSTNAME/settings/tokens/new?scopes=write:packages

    • Выберите область read:packages для скачивания образов контейнеров и считывания их метаданных.
    • Выберите область write:packages для скачивания и отправки образов контейнеров, а также для считывания и записи их метаданных.
    • Выберите область delete:packages для удаления образов контейнеров.

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

  2. Сохраните данные personal access token (classic). Рекомендуется сохранить маркер в качестве переменной среды.

    export CR_PAT=YOUR_TOKEN

  3. С помощью интерфейса командной строки для типа контейнера войдите в службу Container registry по адресу containers. HOSTNAME.

    $ echo $CR_PAT | docker login containers. HOSTNAME -u USERNAME --password-stdin
> Login Succeeded

Отправка образов контейнеров

В этом примере отправляется последняя версия IMAGE_NAME.

docker push containers. HOSTNAME/NAMESPACE/IMAGE_NAME:latest

Замените NAMESPACE именем личная учетная запись или организации, для которой требуется область действия изображения.

В этом примере отправляется версия 2.5 образа.

docker push containers. HOSTNAME/NAMESPACE/IMAGE_NAME:2.5

При первой публикации пакета для параметра видимости по умолчанию выбирается закрытый доступ. Чтобы изменить видимость или задать разрешения доступа, см. раздел Настройка управления доступом и видимости пакета. Вы можете связать опубликованный пакет с репозиторием с помощью пользовательского интерфейса или командной строки. Дополнительные сведения см. в разделе Подключение репозитория к пакету.

При отправке образа контейнера из командной строки образ не связан с репозиторием по умолчанию. Это даже если вы пометите изображение с пространством имен, которое соответствует имени репозитория, например containers.github.companyname.com/octocat/my-repo:latest.

Самый простой способ подключить репозиторий к пакету контейнера — опубликовать пакет из рабочего процесса с помощью ${{secrets.GITHUB_TOKEN}}репозитория, содержащего рабочий процесс, автоматически связан. Обратите внимание, что GITHUB_TOKEN у вас нет разрешения на отправку пакета, если вы ранее принудили пакет к тому же пространству имен, но не подключили пакет к репозиторию.

Чтобы подключить репозиторий при публикации образа из командной строки и убедиться, что у вас GITHUB_TOKEN есть соответствующие разрешения при использовании рабочего процесса GitHub Actions, рекомендуется добавить метку org.opencontainers.image.source в вашу Dockerfile. Дополнительные сведения см. в разделе "Образы контейнеров метки" в этой статье иПубликация и установка пакета с помощью GitHub Actions.

Вытягивание образов контейнеров

Вытягивание по хэшу

Чтобы всегда использовать один и тот же образ, можно указать точную версию образа контейнера для вытягивания, задав значение SHA digest.

  1. Чтобы найти значение хэша SHA, используйте docker inspect или docker pull, а затем скопируйте значение SHA после Digest:

    docker inspect containers. HOSTNAME/NAMESPACE/IMAGE_NAME

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

  2. При необходимости удалите образ локально.

    docker rmi containers. HOSTNAME/NAMESPACE/IMAGE_NAME:latest

  3. Вытяните образ контейнера с @YOUR_SHA_VALUE после имени образа.

    docker pull containers. HOSTNAME/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs

Вытягивание по имени

docker pull containers. HOSTNAME/NAMESPACE/IMAGE_NAME

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

Вытягивание по имени и версии

Пример интерфейса командной строки Docker с образом, извлеченным по имени и тегу версии 1.14.1:

$ docker pull containers. HOSTNAME/NAMESPACE/IMAGE_NAME:1.14.1
> 5e35bd43cf78: Pull complete
> 0c48c2209aab: Pull complete
> fd45dd1aad5a: Pull complete
> db6eb50c2d36: Pull complete
> Digest: sha256:ae3b135f133155b3824d8b1f62959ff8a72e9cf9e884d88db7895d8544010d8e
> Status: Downloaded newer image for containers. HOSTNAME/NAMESPACE/IMAGE_NAME/release:1.14.1
> containers. HOSTNAME/NAMESPACE/IMAGE_NAME/release:1.14.1

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

Вытягивание по имени и последней версии

$ docker pull containers. HOSTNAME/NAMESPACE/IMAGE_NAME:latest
> latest: Pulling from NAMESPACE/IMAGE_NAME
> Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344
> Status: Downloaded newer image for containers. HOSTNAME/NAMESPACE/IMAGE_NAME:latest
> containers. HOSTNAME/NAMESPACE/IMAGE_NAME:latest

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

Сборка образов контейнеров

В этом примере собирается образ hello_docker:

docker build -t hello_docker .

Добавление тегов в образы контейнеров

  1. Найдите идентификатор образа Docker, к которому вы хотите добавить тег.

    $ docker images
> REPOSITORY                                            TAG                 IMAGE ID            CREATED             SIZE
> containers. HOSTNAME/my-org/hello_docker         latest            38f737a91f39        47 hours ago        91.7MB
> hello-world                                           latest              fce289e99eb9        16 months ago       1.84kB

  2. Добавьте тег к образу Docker, указав идентификатор образа, желаемое имя образа и место размещения.

    docker tag 38f737a91f39 containers. HOSTNAME/NAMESPACE/NEW_IMAGE_NAME:latest

Замените NAMESPACE именем личная учетная запись или организации, для которой требуется область действия изображения.

Образы контейнеров маркировки

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

Для большинства изображений можно использовать метки Docker для добавления ключей заметок в изображение. Дополнительные сведения см. в официальной документации Docker и предварительно определенных ключах заметок в репозиторииopencontainers/image-spec.

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

Следующие ключи заметок поддерживаются в Container registry.

Ключ.Description
org.opencontainers.image.sourceURL-адрес репозитория, связанного с пакетом. Дополнительные сведения см. в разделе Подключение репозитория к пакету.
org.opencontainers.image.descriptionТекстовое описание ограничено 512 символами. Это описание появится на странице пакета под именем пакета.
org.opencontainers.image.licensesИдентификатор лицензии SPDX, например MIT, ограничен 256 символами. Лицензия появится на странице пакета на боковой панели "Сведения". Дополнительные сведения см. в списке лицензий SPDX.

Чтобы добавить ключ в качестве метки Docker, мы рекомендуем использовать инструкцию в вашей команде LABEL Dockerfile. Например, если вы являетесь пользователем octocat и являетесь владельцем my-repo, и ваш образ распространяется по условиям лицензии MIT, вы добавите следующие строки в вашу Dockerfile:

LABEL org.opencontainers.image.source=https://HOSTNAME/octocat/my-repo
LABEL org.opencontainers.image.description="My container image"
LABEL org.opencontainers.image.licenses=MIT

Кроме того, можно добавить метки в образ во время сборки с помощью docker build команды.

$ docker build \
 --label "org.opencontainers.image.source=https://HOSTNAME/octocat/my-repo" \
 --label "org.opencontainers.image.description=My container image" \
 --label "org.opencontainers.image.licenses=MIT"

Добавление описания в многоархивовые изображения

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

Описание, которое отображается на странице пакета для изображения с несколькими арками, получается из annotations поля в манифесте изображения. Как и метки Docker, заметки предоставляют способ связывания метаданных с изображением и поддержки предварительно определенных ключей заметки. Дополнительные сведения см. в разделе "Заметки " в репозитории opencontainers/image-spec .

Чтобы указать описание многоархового изображения, задайте значение для org.opencontainers.image.description ключа в annotations поле манифеста, как показано ниже.

"annotations": {
  "org.opencontainers.image.description": "My multi-arch image"
}

Например, следующий шаг рабочего процесса GitHub Actions создает и отправляет многоархивовый образ. Параметр outputs задает описание изображения.

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

- name: Build and push Docker image
  uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
  with:
    context: .
    file: ./Dockerfile
    platforms: ${{ matrix.platforms }}
    push: true
    outputs: type=image,name=target,annotation-index.org.opencontainers.image.description=My multi-arch image

Устранение неполадок

  • Container registry имеет ограничение на 10 ГБ для каждого слоя.
  • Для отправки данных Container registry установлено ограничение времени ожидания в 10 минут.