Публикация образов Docker

В этом уроке вы узнаете, как публиковать образы Docker в реестр, такой как Docker Hub или GitHub Packages, как часть вашего рабочего процесса непрерывной интеграции (CI).

В этой статье

Введение

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

Примечание.

Если вы хотите отправить в другой сторонний реестр Docker, пример из раздела «Публикация изображений» GitHub Packages может послужить хорошим шаблоном.

Необходимые компоненты

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

Кроме того, могут быть полезны базовые знания в следующих областях:

  •         [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)

  •         [AUTOTITLE](/actions/security-guides/automatic-token-authentication)

  •         [AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry)

Сведения о конфигурации образа

Это руководство предполагает, что у вас есть полное определение образа Docker, хранящегося в GitHub репозитории. Например, репозиторий должен содержать Dockerfile и все остальные файлы, необходимые для выполнения сборки Docker и создания образа.

          Вы можете использовать предварительно определенные ключи заметки для добавления метаданных, включая описание, лицензию и исходный репозиторий в образ контейнера. Для получения дополнительной информации см. [AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images).

В этом руководстве мы будем использовать действие build-push-action Docker для сборки образа Docker и отправки его в один или несколько реестров Docker. Дополнительные сведения см. в статье build-push-action.

Публикация изображений в Docker Hub

Примечание.

Docker Hub обычно накладывает ограничения скорости для операций отправки и извлечения, которые повлияют на задания на локальных запусках. Однако GitHub, размещенные в runner, не подлежат этим ограничениям на основе соглашения между переменными данных.product.github %} и Docker.

Каждый раз, когда вы создаёте новый релиз на GitHub, вы можете запускать рабочий процесс для публикации вашего изображения. Рабочий процесс в приведенном ниже примере выполняется при активации события release с типом действия published.

В примере рабочего процесса ниже мы используем действия Docker login-action и build-push-action для создания образа Docker и, если сборка успешна, отправляем созданный образ в Docker Hub.

Чтобы перейти в Docker Hub, вам нужно иметь аккаунт Docker Hub и создать репозиторий Docker Hub. Для получения дополнительной информации см. Pushing a container image of Docker to Docker Hub в документации Docker.

Для Docker Hub требуются варианты login-action: * username и password: Это ваше Docker Hub логин и пароль. Мы рекомендуем хранить имя пользователя и пароль Docker Hub как секреты, чтобы они не были раскрыты в файле рабочего процесса. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.

Для Docker Hub требуется metadata-action вариант: * images: Пространство имён и имя для образа Docker, которое вы собираете/отправляете в Docker Hub.

Для Docker Hub требуются варианты build-push-action: * tags: тег нового образа в формате DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY:VERSION. Можно задать один тег, как показано ниже, или указать несколько тегов в виде списка. * push: если задано значение true, образ будет отправлен в реестр в случае успешной сборки.

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

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

name: Publish Docker image

on:
  release:
    types: [published]

jobs:
  push_to_registry:
    name: Push Docker image to Docker Hub
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
      attestations: write
      id-token: write
    steps:
      - name: Check out the repo
        uses: actions/checkout@v5

      - name: Log in to Docker Hub
        uses: docker/login-action@f4ef78c080cd8ba55a85445d5b36e214a81df20a
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: my-docker-hub-namespace/my-docker-hub-repository

      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-name: index.docker.io/my-docker-hub-namespace/my-docker-hub-repository
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Вышеуказанный рабочий процесс проверяет репозиторий GitHub, использует login-action для входа в реестр, а затем использует действие build-push-action, чтобы: создать образ Docker на основе Dockerfile вашего репозитория; Отправьте изображение в Docker Hub и примените к образу тег.

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

Публикация изображений для GitHub Packages

Каждый раз, когда вы создаёте новый релиз на GitHub, вы можете запускать рабочий процесс для публикации вашего изображения. Рабочий процесс в приведенном ниже примере выполняется при отправке изменения в release ветвь.

В приведённом ниже примере рабочего процесса мы используем Docker login-action, metadata-action, и build-push-action действия для создания образа Docker, и если сборка успешна, отправляем созданный образ в GitHub Packages.

Требуемые login-action варианты следующие GitHub Packages : * registry: Должно быть установлено на ghcr.io``ghcr.io. * username: Вы можете использовать ${{ github.actor }} контекст, чтобы автоматически использовать имя пользователя, запустившего запуск рабочего процесса. Дополнительные сведения см. в разделе Справочник по контекстам. * password: для пароля можно использовать автоматически созданный секрет GITHUB_TOKEN. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Требуемый metadata-action вариант для GitHub Packages следующего: * images: пространство имен и имя образа Docker, который вы собираете.

Требуемые build-push-action варианты следующие GitHub Packages :

  •         `context`: Определяет контекст сборки как набор файлов, расположенных в указанном пути.

  •         `push`: Если установлено на `true`, изображение будет отправлено в реестр, если оно успешно собрано.

  •         `tags` и `labels`: Они заполняются выходами из `metadata-action`.

Примечание.

  • Этот рабочий процесс использует действия, которые не сертифицированы GitHub. Они предоставляются сторонними лицами и управляются отдельными условиями обслуживания, политикой конфиденциальности и документацией по поддержке.
  • GitHub рекомендует закреплять действия с фиксацией SHA. Чтобы получить более новую версию, потребуется обновить SHA. Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
YAML
name: Create and publish a Docker image
on:
  push:
    branches: ['release']

Configures this workflow to run every time a change is pushed to the branch called release.

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

Defines two custom environment variables for the workflow. These are used for the Container registry domain, and a name for the Docker image that this workflow builds.

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest

There is a single job in this workflow. It's configured to run on the latest available version of Ubuntu.

    permissions:
      contents: read
      packages: write
      attestations: write
      id-token: write

Sets the permissions granted to the GITHUB_TOKEN for the actions in this job.

    steps:
      - name: Checkout repository
        uses: actions/checkout@v5
      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

Uses the docker/login-action action to log in to the Container registry registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

This step uses docker/metadata-action to extract tags and labels that will be applied to the specified image. The id "meta" allows the output of this step to be referenced in a subsequent step. The images value provides the base name for the tags and labels.

      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

This step uses the docker/build-push-action action to build the image, based on your repository's Dockerfile. If the build succeeds, it pushes the image to GitHub Packages. It uses the context parameter to define the build's context as the set of files located in the specified path. For more information, see Usage in the README of the docker/build-push-action repository. It uses the tags and labels parameters to tag and label the image with the output from the "meta" step.

      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME}}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see Using artifact attestations to establish provenance for builds.

#
name: Create and publish a Docker image

# Configures this workflow to run every time a change is pushed to the branch called `release`.
on:
  push:
    branches: ['release']

# Defines two custom environment variables for the workflow. These are used for the Container registry domain, and a name for the Docker image that this workflow builds.
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

# There is a single job in this workflow. It's configured to run on the latest available version of Ubuntu.
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
    permissions:
      contents: read
      packages: write
      attestations: write
      id-token: write
      #
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5
      # Uses the `docker/login-action` action to log in to the Container registry registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      # This step uses [docker/metadata-action](https://github.com/docker/metadata-action#about) to extract tags and labels that will be applied to the specified image. The `id` "meta" allows the output of this step to be referenced in a subsequent step. The `images` value provides the base name for the tags and labels.
      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
      # This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
      # It uses the `context` parameter to define the build's context as the set of files located in the specified path. For more information, see [Usage](https://github.com/docker/build-push-action#usage) in the README of the `docker/build-push-action` repository.
      # It uses the `tags` and `labels` parameters to tag and label the image with the output from the "meta" step.
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
      
      # This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see [Using artifact attestations to establish provenance for builds](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds).
      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME}}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Приведенный выше рабочий процесс активируется отправкой в ветвь «выпуска». Он проверяет репозиторий GitHub и использует login-action для входа в Container registry. Затем он извлекает метки и теги для образа Docker. Наконец, он использует build-push-action действие для создания изображения и публикации его на Container registry.

Публикация изображений для Docker Hub и GitHub Packages

В одном рабочем процессе образ Docker можно опубликовать в нескольких реестрах с помощью действий login-action и build-push-action для каждого реестра.

Следующий пример рабочего процесса использует шаги из предыдущих разделов (Публикация образов в Docker Hub и Публикация изображений в GitHub Packages) для создания единого рабочего процесса, который отправляется в оба реестра.

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

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

name: Publish Docker image

on:
  release:
    types: [published]

jobs:
  push_to_registries:
    name: Push Docker image to multiple registries
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
    steps:
      - name: Check out the repo
        uses: actions/checkout@v5

      - name: Log in to Docker Hub
        uses: docker/login-action@f4ef78c080cd8ba55a85445d5b36e214a81df20a
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: |
            my-docker-hub-namespace/my-docker-hub-repository
            ghcr.io/${{ github.repository }}

      - name: Build and push Docker images
        id: push
        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

Вышеуказанный рабочий процесс проверяет репозиторий GitHub , использует login-action twice для входа в оба реестра и генерирует теги и метки с помощью действия metadata-action . Затем действие build-push-action строит изображение Docker в Docker Hub и Container registry.

Примечание.

При переводе в несколько реестров:

  • Дайджесты изображений могут различаться в зависимости от реестра, что затрудняет проверку заверок.
  • Чтобы поддерживать единый дайджест и позволить одной аттестации проверять все копии, сначала отправьте в один реестр и используйте инструмент, например crane copy , для повторения изображения в другом месте.
  • Если вы решите создавать и отправлять данные в каждый реестр отдельно, вам нужно создать отдельное подтверждение для каждого, чтобы ваши артефакты оставались проверяемыми.

Отработка практических навыков

Практикуйте публикацию изображений Docker с помощью упражнения Publishing Docker imagesGitHub Skills .

В этом упражнении вы узнаете, как:

  • Аутентифицировать с GitHub Packages использованием GITHUB_TOKEN.
  • Создайте и опубликуйте изображения контейнеров в Container registry (ghcr.io).
  • Используйте официальные действия Docker, такие docker/login-actionкак , docker/build-push-actionи docker/setup-buildx-action.
  • Генерируйте теги автоматически на docker/metadata-action основе ветвей, пулл-запросов и релизов.
  • Создавайте функции, pull-запросы и релизы с правильным версионированием контейнеров.