# Работа с реестром контейнеров Вы можете хранить образы Docker и OCI и управлять ими в Container registry. ## Сведения о Container registry Container registry хранит образы контейнеров в вашей организации или личной учетной записи и позволяет связать образ с репозиторием. Можно указать, нужно ли наследовать разрешения из репозитория или задавать детализированные разрешения независимо от репозитория. Кроме того, можно анонимно выполнять доступ к открытым образам контейнеров. ## Сведения о поддержке Container registry В Container registry настоящее время поддерживаются следующие форматы образов контейнеров: * [Манифест версии 2 образа Docker, схема 2](https://docs.docker.com/registry/spec/manifest-v2-2/) * [Спецификации Open Container Initiative (OCI)](https://github.com/opencontainers/image-spec) При установке или публикации образа Container registry Docker поддерживаются внешние слои, такие как Windows образы. ## Проверка подлинности в Container registry > \[!NOTE] > GitHub Packages поддерживает только проверку подлинности с помощью personal access token (classic). Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Для публикации, установки и удаления частных, внутренних и общедоступных пакетов требуется маркер доступа. Можно использовать personal access token (classic) для проверки подлинности в API GitHub Packages или API GitHub . При создании personal access token (classic)можно назначить маркер различным областям в зависимости от ваших потребностей. Дополнительные сведения о областях, связанных с пакетами, для personal access token (classic), см. в разделе [Сведения о разрешениях для пакетов GitHub](/ru/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries). Для проверки подлинности в реестре GitHub Packages в рабочем процессе GitHub Actions можно использовать следующее: * `GITHUB_TOKEN` для публикации пакетов, связанных с репозиторием рабочих процессов. * personal access token (classic) с по крайней мере `read:packages` областью действия для установки пакетов, связанных с другими частными репозиториями (`GITHUB_TOKEN` можно использовать, если репозиторий предоставлен доступ на чтение к пакету. См [. раздел AUTOTITLE](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility). ### Проверка подлинности в GitHub Actions рабочем процессе Этот реестр поддерживает детализированные разрешения. Для реестров, поддерживающих детализированные разрешения, если рабочий GitHub Actions процесс используется personal access token для проверки подлинности в реестре, настоятельно рекомендуется обновить рабочий процесс для использования `GITHUB_TOKEN`. Рекомендации по обновлению рабочих процессов, прошедших проверку подлинности в реестре с помощью personal access token[autoTITLE](/ru/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-personal-access-token). > \[!NOTE] > Возможность удаления и восстановления пакетов с помощью REST API GitHub Actions в настоящее время находится в Публичный предварительный просмотр и подлежит изменению. Вы можете использовать рабочий `GITHUB_TOKEN`GitHub Actions процесс для удаления или восстановления пакета с помощью REST API, если маркер имеет `admin` разрешение на пакет. Репозитории, публикующие пакеты с помощью рабочего процесса и репозиториев, которые явно подключены к пакетам, автоматически предоставляются `admin` разрешения на пакеты в репозитории. Дополнительные сведения см. в `GITHUB_TOKEN`разделе [Использование GITHUB\_TOKEN для проверки подлинности в рабочих процессах](/ru/actions/tutorials/authenticate-with-github_token#using-the-github_token-in-a-workflow). Дополнительные сведения о рекомендациях при использовании реестра в действиях см. в разделе [Скомпрометированные бегуна](/ru/actions/concepts/security/compromised-runners#cross-repository-access). Вы также можете предоставить разрешения на доступ к пакетам независимо друг от другаGitHub CodespacesGitHub Actions. Дополнительные сведения см. в разделе \[AUTOTITLE и [Настройка управления доступом и видимости пакета](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package)]\(/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package). ### Аутентификация с помощью personal access token (classic) > \[!NOTE] > GitHub Packages поддерживает только проверку подлинности с помощью personal access token (classic). Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). 1. Создайте новое personal access token (classic) с соответствующими областями для задач, которые необходимо выполнить. Если для вашей организации требуется единый вход, необходимо включить его для нового маркера. > \[!NOTE] > По умолчанию при выборе `write:packages` области в personal access token (classic) пользовательском интерфейсе `repo` также будет выбрана область. Область `repo` предлагает ненужный и широкий доступ, которые мы рекомендуем избежать использования для GitHub Actions рабочих процессов в частности. Дополнительные сведения см. в разделе [Скомпрометированные бегуна](/ru/actions/concepts/security/compromised-runners#cross-repository-access). В качестве обходного решения можно выбрать только `write:packages` область для personal access token (classic) пользовательского интерфейса с помощью этого URL-адреса: `https://github.com/settings/tokens/new?scopes=write:packages` * Выберите область `read:packages` для скачивания образов контейнеров и считывания их метаданных. * Выберите область `write:packages` для скачивания и отправки образов контейнеров, а также для считывания и записи их метаданных. * Выберите область `delete:packages` для удаления образов контейнеров. Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). 2. Сохраните.personal access token (classic) Рекомендуется сохранить маркер в качестве переменной среды. ```shell export CR_PAT=YOUR_TOKEN ``` 3. С помощью интерфейса командной строки для типа контейнера войдите в Container registry службу по адресу `ghcr.io`. ```shell $ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin > Login Succeeded ``` ## Отправка образов контейнеров В этом примере отправляется последняя версия `IMAGE_NAME`. ```shell docker push ghcr.io/NAMESPACE/IMAGE_NAME:latest ``` Замените `NAMESPACE` именем личная учетная запись или организации, для которой требуется область действия изображения. В этом примере отправляется версия `2.5` образа. ```shell docker push ghcr.io/NAMESPACE/IMAGE_NAME:2.5 ``` При первой публикации пакета для параметра видимости по умолчанию выбирается закрытый доступ. Чтобы изменить видимость или задать разрешения доступа, см. раздел [Настройка управления доступом и видимости пакета](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility). Вы можете связать опубликованный пакет с репозиторием с помощью пользовательского интерфейса или командной строки. Дополнительные сведения см. в разделе [Подключение репозитория к пакету](/ru/packages/learn-github-packages/connecting-a-repository-to-a-package). При отправке образа контейнера из командной строки образ не связан с репозиторием по умолчанию. Это даже если вы пометите изображение с пространством имен, которое соответствует имени репозитория, например `ghcr.io/octocat/my-repo:latest`. Самый простой способ подключить репозиторий к пакету контейнера — опубликовать пакет из рабочего процесса с помощью `${{secrets.GITHUB_TOKEN}}`репозитория, содержащего рабочий процесс, автоматически связан. Обратите внимание, что `GITHUB_TOKEN` у вас нет разрешения на отправку пакета, если вы ранее принудили пакет к тому же пространству имен, но не подключили пакет к репозиторию. Чтобы подключить репозиторий при публикации образа из командной строки и убедиться, что у вас `GITHUB_TOKEN` есть соответствующие разрешения при использовании рабочего процесса GitHub Actions, рекомендуется добавить метку `org.opencontainers.image.source` в вашу `Dockerfile`. Дополнительные сведения см. в разделе "[Образы](#labelling-container-images) контейнеров метки" в этой статье и[Публикация и установка пакета с помощью GitHub Actions](/ru/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions). ## Вытягивание образов контейнеров ### Вытягивание по хэшу Чтобы всегда использовать один и тот же образ, можно указать точную версию образа контейнера для вытягивания, задав значение SHA `digest`. 1. Чтобы найти значение хэша SHA, используйте `docker inspect` или `docker pull`, а затем скопируйте значение SHA после `Digest:` ```shell docker inspect ghcr.io/NAMESPACE/IMAGE_NAME ``` Замените `NAMESPACE` именем личная учетная запись или организации, в которой находится изображение. 2. При необходимости удалите образ локально. ```shell docker rmi ghcr.io/NAMESPACE/IMAGE_NAME:latest ``` 3. Вытяните образ контейнера с `@YOUR_SHA_VALUE` после имени образа. ```shell docker pull ghcr.io/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs ``` ### Вытягивание по имени ```shell docker pull ghcr.io/NAMESPACE/IMAGE_NAME ``` Замените `NAMESPACE` именем личная учетная запись или организации, в которой находится изображение. ### Вытягивание по имени и версии Пример интерфейса командной строки Docker с образом, извлеченным по имени и тегу версии `1.14.1`: ```shell $ docker pull ghcr.io/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 ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1 > ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1 ``` Замените `NAMESPACE` именем личная учетная запись или организации, в которой находится изображение. ### Вытягивание по имени и последней версии ```shell $ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:latest > latest: Pulling from NAMESPACE/IMAGE_NAME > Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344 > Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME:latest > ghcr.io/NAMESPACE/IMAGE_NAME:latest ``` Замените `NAMESPACE` именем личная учетная запись или организации, в которой находится изображение. ## Сборка образов контейнеров В этом примере собирается образ `hello_docker`: ```shell docker build -t hello_docker . ``` ## Добавление тегов в образы контейнеров 1. Найдите идентификатор образа Docker, к которому вы хотите добавить тег. ```shell $ docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > ghcr.io/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB > hello-world latest fce289e99eb9 16 months ago 1.84kB ``` 2. Добавьте тег к образу Docker, указав идентификатор образа, желаемое имя образа и место размещения. ```shell docker tag 38f737a91f39 ghcr.io/NAMESPACE/NEW_IMAGE_NAME:latest ``` Замените `NAMESPACE` именем личная учетная запись или организации, для которой требуется область действия изображения. ## Образы контейнеров маркировки Вы можете использовать предварительно определенные ключи заметки для добавления метаданных, включая описание, лицензию и исходный репозиторий в образ контейнера. Значения поддерживаемых ключей будут отображаться на странице пакета для изображения. Для большинства изображений можно использовать метки Docker для добавления ключей заметок в изображение. Дополнительные сведения см[](https://docs.docker.com/engine/reference/builder/#label). в официальной документации Docker и [предварительно определенных ключах](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys) заметок в репозитории`opencontainers/image-spec`. Для изображений с несколькими арками можно добавить описание к изображению, добавив соответствующий ключ заметки в `annotations` поле в манифесте изображения. Дополнительные сведения см. в разделе ["Добавление описания в многоархивовые изображения](#adding-a-description-to-multi-arch-images)". В Container registryподдерживаются следующие ключи заметок. | Ключ. | Description | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `org.opencontainers.image.source` | URL-адрес репозитория, связанного с пакетом. Дополнительные сведения см. в разделе [Подключение репозитория к пакету](/ru/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line). | | `org.opencontainers.image.description` | Текстовое описание ограничено 512 символами. Это описание появится на странице пакета под именем пакета. | | `org.opencontainers.image.licenses` | Идентификатор лицензии SPDX, например MIT, ограничен 256 символами. Лицензия появится на странице пакета на боковой панели "Сведения". Дополнительные сведения см. в списке [](https://spdx.org/licenses/)лицензий SPDX. | Чтобы добавить ключ в качестве метки Docker, мы рекомендуем использовать инструкцию в вашей команде `LABEL``Dockerfile`. Например, если вы являетесь пользователем `octocat` и являетесь владельцем `my-repo`, и ваш образ распространяется по условиям лицензии MIT, вы добавите следующие строки в вашу `Dockerfile`: ```dockerfile LABEL org.opencontainers.image.source=https://github.com/octocat/my-repo LABEL org.opencontainers.image.description="My container image" LABEL org.opencontainers.image.licenses=MIT ``` > \[!NOTE] > При публикации пакета, связанного с репозиторием, пакет автоматически наследует разрешения доступа связанного репозитория, а рабочие процессы GitHub Actions в связанном репозитории автоматически получают доступ к пакету, если ваша организация не отключила автоматическое наследование разрешений доступа. Дополнительные сведения см. в разделе [Настройка управления доступом и видимости пакета](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#about-inheritance-of-access-permissions). Кроме того, можно добавить метки в образ во время сборки с помощью `docker build` команды. ```shell $ docker build \ --label "org.opencontainers.image.source=https://github.com/octocat/my-repo" \ --label "org.opencontainers.image.description=My container image" \ --label "org.opencontainers.image.licenses=MIT" ``` ### Добавление описания в многоархивовые изображения Многоархивное изображение — это образ, поддерживающий несколько архитектур. Он работает путем ссылки на список изображений, каждый из которых поддерживает другую архитектуру в одном манифесте. Описание, которое отображается на странице пакета для изображения с несколькими арками, получается из `annotations` поля в манифесте изображения. Как и метки Docker, заметки предоставляют способ связывания метаданных с изображением и поддержки предварительно определенных ключей заметки. Дополнительные сведения см. в разделе ["Заметки](https://github.com/opencontainers/image-spec/blob/main/annotations.md) " в репозитории `opencontainers/image-spec` . Чтобы указать описание многоархового изображения, задайте значение для `org.opencontainers.image.description` ключа в `annotations` поле манифеста, как показано ниже. ```json "annotations": { "org.opencontainers.image.description": "My multi-arch image" } ``` Например, следующий GitHub Actions шаг рабочего процесса создает и отправляет многоархвовый образ. Параметр `outputs` задает описание изображения. ```yaml # Этот рабочий процесс использует действия, которые не сертифицированы 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 минут для отправки.