Как настроить пайплайн для сборки одного Docker-образа с несколькими тегами?

«Как настроить пайплайн для сборки одного Docker-образа с несколькими тегами?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Это стандартная практика для тегирования образов. Я делаю это, указывая несколько тегов при выполнении команды docker build или используя возможности CI-инструмента.

Способ 1: Через Docker CLI (универсальный) В скрипте пайплайна можно передать несколько флагов -t:

docker build 
  -t myregistry.com/app:latest 
  -t myregistry.com/app:$CI_COMMIT_SHA 
  -t myregistry.com/app:v1.2.3 
  .
# Затем отправить все теги одним push
docker push myregistry.com/app --all-tags

Способ 2: Использование специальных Actions (GitHub Actions) Action docker/build-push-action удобно поддерживает множественное тегирование:

- name: Build and push Docker image
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: |
      ghcr.io/${{ github.repository }}:latest
      ghcr.io/${{ github.repository }}:${{ github.sha }}
      ghcr.io/${{ github.repository }}:${{ github.ref_name }}

Способ 3: GitLab CI с переменными окружения В GitLab CI удобно использовать предопределенные переменные:

build_image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:latest
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

Моя типичная стратегия тегирования:

  • latest: Для образа из последнего успешного коммита в основную ветку.
  • Хеш коммита ($CI_COMMIT_SHA): Для уникальной идентификации конкретной сборки. Это идеально для отладки и откатов.
  • Версия семантического версионирования (v1.0.1): Для релизных сборок, связанных с git-тегом.
  • Название ветки: Для сборок из feature-веток (например, feat-new-auth).