Как вы тегируете Docker-образы?

Я придерживаюсь строгой стратегии тегирования, которая обеспечивает однозначную идентификацию образа, его происхождение и назначение. Это критически важно для CI/CD и развертывания.

Основные команды и практики:

1. Тегирование при сборке (docker build -t):

   # Базовый вариант: имя образа и тег
   docker build -t mycompany/myapp:1.5.0 .
   
   # Часто в CI я добавляю тег, указывающий на коммит
   docker build -t mycompany/myapp:1.5.0-$(git rev-parse --short HEAD) .

2. Тегирование существующего образа (docker tag):

   # Создаю дополнительный тег для пуша в другой реестр или как альтернативное имя
   docker tag mycompany/myapp:1.5.0 registry.prod.com/team/myapp:release-2024-05-27

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

• Избегаю тега latest в продакшене. Он неоднозначен. Использую его только для образа по умолчанию в тестовых целях.
• Семантическое версионирование (SemVer): :major.minor.patch (например, :2.1.15). Это основной тег для релизов.
• Теги, привязанные к коду:
  • :git-<short-sha> — для сборок с конкретного коммита.
  • :branch-<name> — для nightly-сборок с feature-ветки (например, :branch-feature-auth).
• Среда назначения: Иногда добавляю суффикс, например :1.5.0-staging для образа, специально подготовленного для стейджинга.

Пример рабочего процесса в CI/CD (GitHub Actions):

- name: Build and tag Docker image
  run: |
    docker build -t ${{ secrets.REGISTRY }}/app:${{ github.sha }} .
    # Дополнительный тег с версией из package.json, если это релиз
    docker tag ${{ secrets.REGISTRY }}/app:${{ github.sha }} ${{ secrets.REGISTRY }}/app:${{ steps.version.outputs.current-version }}

Итог: Чёткая система тегов — это основа для эффективного управления образами, отката изменений и понимания того, что именно запущено в данный момент.