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

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

Уявіть: CI-пайплайн падає через перевищення ліміту пуллу з GCR, а в кластері Kubernetes образи не оновлюються, тому що посилання ведуть на старий реєстр. Розробники втрачають годину-дві на налагодження, а терміновий фікс іде в прод із затримкою. Google Container Registry (GCR) офіційно застарів і не рекомендований для нових проєктів. Artifact Registry — його наступник, який не тільки зберігає Docker-образи, а й підтримує Helm-чарти, npm-пакети, Maven-артефакти та Python-модулі. Перехід на новий реєстр дає гнучкий IAM, вбудоване сканування вразливостей та автоматичне очищення старих артефактів. Наші сертифіковані інженери Google Cloud з 5+ роками досвіду та 20+ виконаними проектами з міграції гарантують якісне налаштування без простоїв. Вартість міграції — від $1500, економія на зберіганні — $300-500 на місяць.

Переваги Artifact Registry перед GCR

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

Як налаштувати IAM для 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:

Крок 1: Налаштування репозиторію і доступу

Створюємо репозиторій у потрібному регіоні та налаштовуємо Docker credential helper. Обираємо europe-west1 для низької затримки:

1. Створення репозиторію:

gcloud artifacts repositories create my-app \
    --repository-format=docker \
    --location=europe-west1 \
    --description="Production Docker images" \
    --project=my-gcp-project

2. Налаштування docker credential helper:

gcloud auth configure-docker europe-west1-docker.pkg.dev 

3. 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

Крок 2: Cleanup-політики — скорочення витрат на зберігання в 3 рази

Без cleanup-політик за рік накопичується до 500 ГБ сміття — особливо якщо CI генерує білди на кожен коміт. Cleanup-політики скорочують витрати на зберігання в 2-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 годин (від $500). Якщо потрібна міграція з GCR та оновлення всіх посилань — 1–2 дні (від $1500). Вартість розраховується індивідуально після аудиту інфраструктури, але середня економія на зберіганні після міграції становить 35% ($300-500 на місяць для типових проєктів). Наші інженери мають сертифікацію Google Cloud та досвід міграції 20+ проєктів. Наша компанія працює з GCP понад 5 років і реалізувала 20+ успішних міграцій. Інвестиції в налаштування окупаються за 2-3 місяці за рахунок зниження витрат на зберігання та прискорення пайплайнів. Замовте аудит інфраструктури GCP — ми оцінимо поточну конфігурацію та запропонуємо план міграції. Отримайте консультацію сертифікованого інженера Google Cloud.

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