Ответ
Это стандартная практика для тегирования образов. Я делаю это, указывая несколько тегов при выполнении команды 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).