Как тегировал образы Docker

Стратегия тегирования Docker-образов

Тегирование Docker-образов — это критически важный аспект DevOps-практик, который напрямую влияет на воспроизводимость, безопасность и эффективность CI/CD пайплайнов. За 10+ лет работы я выработал многоуровневый подход к тегированию, который эволюционировал от простых версий до сложных систем, интегрированных с инфраструктурой как код и политиками безопасности.

Основные принципы тегирования

Я придерживаюсь следующих ключевых правил:

• Иммутабельность тегов: Тег, однажды присвоенный образу, никогда не должен перезаписываться. Это основа воспроизводимости сборок.
• Семантическая информативность: Тег должен нести максимум информации о содержимом образа.
• Автоматизация: Весь процесс тегирования должен быть частью CI/CD-пайплайна, без ручного вмешательства.

Структура тегов в CI/CD пайплайне

В современном пайплайне я использую комбинацию из нескольких тегов на один собранный образ.

# Пример команд для тегирования в скрипте сборки
# 1. Тег с хэшем коммита (уникальный и неизменный идентификатор)
docker build -t myapp:${COMMIT_SHA} .

# 2. Тег с номером сборки из CI (например, Jenkins BUILD_NUMBER или GitLab CI PIPELINE_ID)
docker tag myapp:${COMMIT_SHA} myapp:build-${CI_PIPELINE_ID}

# 3. "Плавающий" тег для ветки (например, 'latest' для main, 'staging' для develop)
docker tag myapp:${COMMIT_SHA} myapp:latest

# 4. Семантический тег версии (если сборка соответствует релизу)
docker tag myapp:${COMMIT_SHA} myapp:${SEMANTIC_VERSION}

Детализация стратегий

1. Уникальный идентификатор (основной тег):

    *   **`<имя-образа>:<sha-коммита>`** (например, `api-service:a1b2c3d`). Это основа. Git SHA обеспечивает прямую трассируемость от образа обратно к исходному коду. Этот тег никогда не меняется для данной сборки.

1. Теги, указывающие на окружение или ветку (подвижные теги):

    *   **`latest`** — классический, но опасный в production. Я использую его только для образов из `main`/`master` ветки в регистри разработки.
    *   **`staging`**, **`qa`** — указывают на последний успешный образ, промоутированный в соответствующее окружение. Удобны для деплоя.
    *   **`<имя-ветки>`** (например, `feature-login-refactor`) — для автоматических сборок с feature-веток. Позволяет легко протестировать конкретный образ.

1. Семантическое версионирование (SemVer):

    *   **`<мажорная>.<минорная>.<патч>`** (например, `1.5.2`). Присваивается автоматически на основе тега Git (`git tag`) или анализа `CHANGELOG.md`. Это основа для production-релизов.
    *   **Дополнительные метаданные:** Иногда добавляю `-rc1` (release candidate) или `-beta` для пре-релизов.

1. Мета-теги для интроспекции:

    *   **Теги с датой сборки:** `2024-05-27-1030` — помогает в задачах анализа и отката.
    *   **Тег `git-<короткий-sha>`:** Дублирует информацию, но удобен для чтения.

Продвинутые практики и интеграции

• Multi-arch теги: С появлением ARM-серверов (Graviton, Apple Silicon) используется манифест docker buildx. Образ тегируется одинаково, но содержит манифест для linux/amd64 и linux/arm64.

  docker buildx build --platform linux/amd64,linux/arm64 -t myapp:1.0.0 --push .
  

• SBOM и сигнатуры: В современных регистрах (Harbor, Azure ACR, AWS ECR) к тегам автоматически прикрепляются Software Bill of Materials (SBOM) в формате SPDX и косвенные теги, указывающие на отсканированный образ без уязвимостей (<тег>-scan-clean).
• Политики хранения (Retention Policies): Настройка правил в регистре для автоматической очистки. Например:

    *   Хранить все теги с хэшами коммитов за последние 90 дней.
    *   Хранить все семантические версии (`1.x.x`, `2.x.x`).
    *   Удалять все `feature-*` теги старше 7 дней.

• Использование docker inspect и лейблов: Помимо тегов, каждый образ снабжается Docker-лейблами (LABEL) с метаданными внутри.

  LABEL org.opencontainers.image.version="1.5.2"
  LABEL org.opencontainers.image.revision="${COMMIT_SHA}"
  LABEL com.mycompany.ci.pipeline.url="${CI_PIPELINE_URL}"
  

Рабочий пример в GitLab CI

# .gitlab-ci.yml (фрагмент)
variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  IMAGE_TAG_LATEST: $CI_REGISTRY_IMAGE:latest
  IMAGE_TAG_BRANCH: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build:
  stage: build
  script:
    - docker build --label "commit=$CI_COMMIT_SHA" -t $IMAGE_TAG .
    - docker tag $IMAGE_TAG $IMAGE_TAG_BRANCH
    # Тегируем latest только для main ветки
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        docker tag $IMAGE_TAG $IMAGE_TAG_LATEST
      fi
    - docker push $IMAGE_TAG
    - docker push $IMAGE_TAG_BRANCH
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        docker push $IMAGE_TAG_LATEST
      fi

Итог: Правильное тегирование — это не просто соглашение, а инфраструктурный слой, который обеспечивает надежность деплоя, мгновенный откат к известному хорошему образу и полную аудиторию от production-инцидента до строки кода. Моя стратегия — это баланс между уникальностью (хэш коммита) для точности и удобства (подвижные теги) для операционной работы.