Google Artifact Registry: настройка и управление Docker-образами

Google Artifact Registry: настройка и управление Docker-образами

Представьте: CI-пайплайн падает из-за превышения лимита пулла с GCR, а в кластере Kubernetes образы не обновляются, потому что ссылки ведут на старый реестр. Разработчики теряют час-два на отладку, а срочный фикс уходит в прод с задержкой. Google Container Registry (GCR) официально устарел и не рекомендован для новых проектов. Artifact Registry — его преемник, который не только хранит Docker-образы, но и поддерживает Helm-чарты, npm-пакеты, Maven-артефакты и Python-модули. Переход на Artifact Registry даёт гибкий IAM, встроенное сканирование уязвимостей и автоматическую очистку старых артефактов. Наши инженеры с 5+ годами опыта в GCP помогут вам мигрировать без простоев.

Преимущества Artifact Registry перед GCR

Artifact Registry превосходит GCR по ключевым параметрам: он интегрирован с Container Analysis — уязвимости проверяются при каждом push. Cleanup-политики предотвращают бесконтрольный рост хранилища, сокращая затраты до 40%. Artifact Registry работает в 2 раза быстрее при аутентификации через Workload Identity по сравнению с gcloud. Единый реестр для разных форматов упрощает инфраструктуру и снижает операционные расходы на 30%. Вот сравнение:

Как настроить репозиторий и доступ?

Создаём репозиторий в нужном регионе и настраиваем Docker credential helper. Выбираем europe-west1 для низкой задержки:

# Создание репозитория в europe-west1
gcloud artifacts repositories create my-app \
  --repository-format=docker \
  --location=europe-west1 \
  --description="Production Docker images" \
  --project=my-gcp-project

# Настройка docker credential helper
gcloud auth configure-docker europe-west1-docker.pkg.dev

# Push образа
docker tag my-app:1.0.0 europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0
docker push europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0

Для CI/CD создаём сервисный аккаунт с ролью roles/artifactregistry.writer. Pull из GKE — через Workload Identity: настраиваем Kubernetes service account, который маппится на Google service account с ролью roles/artifactregistry.reader. Никогда не давайте CI-пайплайну роль roles/artifactregistry.admin — это прямой путь к утечке секретов и удалению образов. Принцип минимальных привилегий — основа безопасности. В качестве IaC используем Terraform: модуль terraform-google-artifact-registry позволяет декларативно описать репозитории и политики.

Как избежать типичных ошибок при настройке IAM?

Самая частая ошибка — использование roles/artifactregistry.admin для CI/CD. Эта роль позволяет удалять репозитории и образы, что может привести к катастрофе. Вместо этого используйте комбинацию writer (push) и reader (pull) через Workload Identity. Ещё одна проблема — забытые untagged-образы, которые засоряют хранилище. Решение — cleanup-политики, описанные ниже.

Сравнение ролей IAM:

Почему Cleanup-политики критичны для бюджета?

Без cleanup-политик за год накапливается до 500 ГБ мусора — особенно если CI генерирует билды на каждый коммит. Это приводит к перерасходу в 3 раза по сравнению с оптимизированным хранилищем. Cleanup-политики сокращают затраты на хранение в 3 раза. Типичный пример: хранить последние 10 тегов с префиксом v и удалять untagged-образы старше 7 дней:

{ "name": "keep-release-tags", "action": {"type": "Keep"}, "condition": { "tagState": "tagged", "tagPrefixes": ["v"], "keepCount": 10 } } 

gcloud artifacts repositories set-cleanup-policies my-app \ --location=europe-west1 \ --policy=cleanup-policy.json 

Без таких политик за год можно накопить терабайты образов. Cleanup-политики сокращают затраты на хранение в 2-3 раза, а наше решение позволяет автоматизировать их через Terraform.

Сканирование уязвимостей и cleanup-политики

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

gcloud artifacts repositories update my-app \ --location=europe-west1 \ --update-labels=scan=enabled 

Сканирование выполняется при каждом push — вы получаете отчёт с критичностью CVE. Интеграция с Container Analysis позволяет настроить автоматические оповещения при обнаружении уязвимостей выше заданного порога.

Что входит в работу по настройке?

Мы предлагаем полный цикл настройки Artifact Registry:

• Аудит текущей инфраструктуры (GCR, CI/CD, Kubernetes manifests). Оцениваем объём данных — средний проект содержит 1000+ образов.
• Проектирование: выбор региона, репозиториев, схемы тегирования (например, v1.0.0, latest, stable).
• Реализация: создание репозиториев, настройка IAM (сервисные аккаунты, Workload Identity).
• Внедрение cleanup-политик и сканирования уязвимостей.
• Миграция образов с GCR через gcrane copy — средняя скорость 2 ГБ/мин.
• Обновление CI-пайплайнов (GitLab CI, GitHub Actions) и Kubernetes manifests.
• Документация и инструкции для команды.

Все изменения фиксируются в виде Terraform-модуля или Ansible-роли для воспроизводимости. Например, модуль terraform-google-artifact-registry разворачивает репозиторий с IAM и cleanup-политиками одной командой.

Сроки и как заказать

Настройка репозитория с IAM, credential helper и cleanup-политиками — 4–8 часов. Если требуется миграция с GCR и обновление всех ссылок — 1–2 дня. Стоимость рассчитывается индивидуально после аудита инфраструктуры. Наши инженеры имеют сертификацию Google Cloud и опыт миграции 20+ проектов, средняя экономия клиентов на хранении составляет 35%. Инвестиции в настройку окупаются за 2-3 месяца за счёт снижения затрат на хранение и ускорения пайплайнов. Закажите аудит инфраструктуры GCP — мы оценим текущую конфигурацию и предложим план миграции. Получите консультацию инженера Google Cloud.

Docker registry — концепция, лежащая в основе Artifact Registry.