Практический пошаговый гайд по созданию и использованию Yandex Container Registry (YCR) в 2026 году: от создания реестра до интеграции с Kubernetes и проверки уязвимостей. Примерное время выполнения — 60–90 минут для базовой настройки и интеграции.
0
Статья была полезной?
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…
Что вы изучите
Как создать реестр в Yandex Cloud через CLI yc (версия yc 0.96.0, релиз 2026) и через веб-консоль.
Как аутентифицироваться и запушить Docker-образ в YCR: команды docker 24.0 (2025) и пример тегирования.
Интеграция образов из YCR с Kubernetes 1.28 (2025) — создание imagePullSecret и манифесты deploy.
Проверка уязвимостей с помощью Trivy 0.47 (2025) и обзор встроенных возможностей сканирования Yandex Cloud.
Сравнение с альтернативами (ECR, GCR, GitHub Packages) и расчёт затрат на хранение/трафик (оценка 2026).
Требования
Аккаунт Yandex Cloud с включённой биллинг-учётной записью и правами администратора для папки/проекта.
CLI: yc 0.96.0 (2026). Установка занимает ~1–2 минуты.
Docker: docker 24.0 (2025) или совместимый runtime (достаточно 2 CPU / 4 GiB RAM для локальной сборки образов).
Kubectl: kubectl 1.28 (2025) для деплоя в кластер Kubernetes 1.28 (минимум 2 vCPU и 4 GiB RAM в рабочем узле для тестового окружения).
Trivy: trivy 0.47 (2025) для оффлайнового сканирования образов (RAM 1–2 GiB, время сканирования для 150 MB образа ~20–40 с).
Порты: Docker push/pull использует HTTPS 443. Kubernetes API — 6443 (если подключаетесь к удалённому кластеру).
Почему YCR?
Yandex Container Registry (далее YCR) — реестр образов, интегрированный с Yandex Cloud IAM и объектным хранилищем. Ключевые преимущества: нативная авторизация через yc, управление правами на уровне папок/сервисных аккаунтов, и интеграция с локальной экосистемой Yandex Cloud (VPC, KMS, Monitoring).
За 2025–2026 годы YCR получил улучшенную поддержку сканирования уязвимостей и ускорение pull-запросов по региональным CDN. Типичный размер образа: nginx:1.26-alpine ≈ 6 MB (сжатый), полнофункциональный Python-образ на базе python:3.12-slim ≈ 120–200 MB. При планировании учтите: хранение 100 GB образов и слоёв занимает 100 GB дискового пространства и влияет на стоимость хранения и исходящий трафик.
Скриншот консоли Yandex Cloud: создание реестра YCR 2026
Шаг 1: создание реестра
Цель шага — создать контейнерный реестр в выбранной папке Yandex Cloud и получить URL реестра для тегирования образов. В качестве инструмента используйте yc 0.96.0 (2026).
Команда:
# создайте реестр в указанной папке
yc container registry create --name my-ycr --folder-id FOLDER_ID
# получить список реестров в папке
yc container registry list --folder-id FOLDER_ID
Пояснение: опция --folder-id указывает папку Yandex Cloud. В веб-консоли создаётся тот же реестр с метаданными и ID. Выполнение команды занимает ~1–3 секунды на API-запрос; инициализация реестра занимает несколько секунд в фоне.
Ошибка: "Permission denied: iam.grant" — означает, что у пользователя нет прав на создание ресурсов в папке. Фикс: назначьте роль roles/editor для пользователя или используйте сервисный аккаунт с нужными правами в папке.
Шаг 2: push образов
Цель — аутентифицироваться в реестре и отправить Docker-образ. Мы используем OAuth-токен, который генерирует yc iam create-token. Регистри URL в примерах: cr.cloud.yandex.net. Команды работают с Docker 24.0 (2025).
Команды (пример):
# Получаем OAuth-токен (действителен 1 час)
yc iam create-token --duration=3600 > yandex-token.txt
# Логин в реестр (используйте 'oauth' как username)
cat yandex-token.txt | docker login --username oauth --password-stdin cr.cloud.yandex.net
# Тегирование и push
docker build -t myapp:1.0 .
docker tag myapp:1.0 cr.cloud.yandex.net/cr-abcdefgh12345678/myapp:1.0
docker push cr.cloud.yandex.net/cr-abcdefgh12345678/myapp:1.0
Пояснение: токен, выданный yc iam create-token, используется как пароль с именем пользователя oauth. Тег должен содержать URL реестра и ID реестра (в примере cr-abcdefgh12345678), иначе push пойдёт в публичный Docker Hub.
Ожидаемый вывод (успешный push):
Login Succeeded
The push refers to repository [cr.cloud.yandex.net/cr-abcdefgh12345678/myapp]
1.0: digest: sha256:... size: 237 MB
Потенциальная ошибка и решение:
ERROR: denied: requested access to the resource is denied
Фикс: проверьте токен (возможно, просрочен) и права сервисного аккаунта. Если ошибка повторяется, выполните:
Другой типичный сбой: TLS/Network — если push зависает (время >120 s) или прерывается, проверьте правила VPC/Firewall и исходящий HTTPS-порт 443. Для медленных сетей рекомендуем включать параллельную загрузку слоёв в Docker (в Docker 24.0 это стандартно).
Скриншот: успешный docker push в YCR
Шаг 3: интеграция с K8s
Цель шага — настроить Kubernetes (kubectl 1.28) так, чтобы поды могли вытягивать образы из YCR. Способ: создать секрет типа docker-registry и использовать его в Deployment или ServiceAccount.
Пояснение: секрет ycr-secret хранит учётные данные Docker и используется через imagePullSecrets. Вместо явного включения секрета в каждый deployment можно прикрепить секрет к ServiceAccount и использовать ServiceAccount в spec.template.
Ожидаемый вывод (успех):
secret/ycr-secret created
deployment.apps/myapp created
kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-xxxxxx-abcde 1/1 Running 0 12s
Фикс: убедитесь, что секрет существует в том же namespace, где разворачивается Pod, и что токен действителен. Если кластер использует Частный сетевой маршрут, проверьте доступ по HTTPS к cr.cloud.yandex.net из узлов кластера. Для автоматизации лучше использовать сервисный аккаунт Yandex Cloud с назначенной ролью container.registry.* и привязать его к Kubernetes через OIDC/Workload Identity.
Шаг 4: vulnerability scan
Цель — проверить образы на известные уязвимости. Два подхода: встроенный сканер Yandex Cloud (если включён) и офлайн-сканирование с помощью Trivy 0.47 (2025). Trivy даёт быстрые отчёты и поддерживает формат JSON для CI.
2026-02-10T15:10:00.123Z INFO Detected OS: debian
NAME INSTALLED FIXED-IN SEVERITY
libssl1.1 1.1.1d-... 1.1.1l-... HIGH
openssl 1.1.1d-... 1.1.1l-... CRITICAL
Типичный сбой и решение:
Error: failed to download image: failed to resolve reference "cr.cloud.yandex.net/...": unauthorized: authentication required
Фикс: перед запуском Trivy выполните локальный docker login с OAuth-токеном (как в шаге 2) — trivy использует локальные Docker credentials. Для CI передавайте переменную окружения TRIVY_USERNAME=oauth и TRIVY_PASSWORD=$(yc iam create-token).
Встроенное сканирование YCR: начиная с версий 2025–2026 Yandex Cloud предложил интеграцию сканера уязвимостей на стороне сервиса. Включение и просмотр результатов — через консоль Yandex Cloud в разделе Container Registry → Security. Встроенный сканер может автоматически запускаться по push и выдаёт CVE-репорты вида: COUNT(critical)=2, COUNT(high)=5. Встроенный отчёт содержит CVE-ID, описание, уязвимый пакет и рекомендации по обновлению слоя.
Какие альтернативы?
Короткий разбор конкурентов и когда их стоит выбирать:
Amazon ECR — хорош, если инфраструктура уже в AWS; качественная интеграция с IAM и скорости по регионам AWS.
Google Artifact Registry (GCR) — если основной стек в GCP и требуется tight интеграция с Artifact Registry и GKE.
GitHub Container Registry (GHCR) — удобна для CI/CD на GitHub Actions; есть бесплатные приватные репозитории для Open Source проектов.
GitLab Container Registry — выбор для тех, кто держит репозитории и CI в GitLab, умеет автоматизировать build→push внутри пайплайна.
Docker Hub — удобен для публичных образов, но приватные лимиты и политика rate-limiting в 2025–2026 требуют внимания при частых pull.
Совет по выбору: если основная инфраструктура размещена в Yandex Cloud и важна интеграция с IAM и локальными сервисами (KMS, Monitoring), YCR даёт меньше операций по настройке безопасности и сетей, чем перенос образов между публичными провайдерами.
Ценообразование YCR в 2026 году состоит из трёх основных компонентов: стоимость хранения (GB/месяц), исходящий трафик (GB) и операции (API-запросы/PUT). Приведённые цифры — ориентиры и требуют проверки в вашем аккаунте перед продакшеном.
Оценка (пример, 2026):
Хранение: ≈ 0.02–0.05 USD за GB/месяц (в зависимости от региона и типа хранения). Для 100 GB это 2–5 USD/месяц.
Исходящий трафик (egress): ≈ 0.05–0.12 USD за GB (зависит от региона и направления трафика). Для CI, где ежедневно скачивается ~50 GB, это ≈ 75–180 USD/месяц.
Операции/API: стандартные запросы на чтение/запись образов включены в тариф, дополнительные платные операции — редкость, обычно счёт формируется на стороне объектного хранилища.
Пример расчёта: вы храните 200 GB образов и генерируете 1 TB исходящего трафика в месяц:
200 GB × 0.03 USD = 6 USD/месяц за хранение.
1024 GB × 0.08 USD = 81.92 USD/месяц за egress.
Итого ≈ 88 USD/месяц плюс возможные дополнительные расходы на KMS/Monitoring.
Практическая рекомендация: включите Lifecycle-политику на стороне CI/CD, чтобы автоматически удалять старые теги (удалять метки старше 30–90 дней) и минимизировать хранение больших неизменяемых слоёв. Регулярно агрегируйте статистику pull-ов, чтобы оптимизировать CDN/регион.
Частые вопросы
Как аутентифицироваться в YCR из CI (GitHub Actions)?
Для автоматизации в GitHub Actions используйте секреты репозитория: сохраните сервисный ключ Yandex Cloud (json) в секрете YC_SERVICE_ACCOUNT_KEY. В workflow выполните установку yc CLI, затем импортируйте ключ: yc init --service-account-key-file=${{ secrets.YC_SERVICE_ACCOUNT_KEY }}. После этого выполните yc iam create-token и используйте результат как пароль для docker login --username oauth --password-stdin cr.cloud.yandex.net. Такой подход обеспечивает краткоживущий токен в runtime CI и исключает хранение постоянных паролей.
Что делать, если при pull из кластера узлы не могут получить доступ к cr.cloud.yandex.net?
Проверьте сетевую доступность: подключитесь к узлу и выполните curl -v https://cr.cloud.yandex.net. Если соединение не устанавливается, проверьте VPC маршруты и firewall rules (исходящие правила по порту 443). Если используется приватный кластер с egress через NAT Gateway, убедитесь, что NAT настроен и имеет доступ в интернет. Альтернативно можно использовать локальный кэш proxy-registry (например, registry:2) внутри VPC.
Почему push занимает слишком много времени и как ускорить?
Медленный push обычно связан с: медленным интернет-каналом, большим числом слоёв и отсутствием параллельной загрузки. Оптимизации: уменьшите количество слоёв (объедините RUN команды в Dockerfile), используйте сжатые базовые образы (alpine), и запускайте push в среде с хорошим сетевым каналом (CI runner в том же регионе Yandex Cloud). Также проверьте настройки MTU и возможные прокси в пути трафика.
Какие роли IAM нужны для сервисного аккаунта, который пушит образы?
Минимальный набор ролей для сервисного аккаунта: containerregistry.registryAdmin или набор ролей, дающих права на загрузку и управление образами в конкретной папке/реестре. В продакшене рекомендуется использовать принцип наименьших привилегий: назначать права на уровне конкретного реестра (или папки) вместо прав на уровне организации.
Сколько времени занимает сканирование образа Trivy и встроенным сканером?
Trivy 0.47 сканирует типичный текстовый/интерпретируемый образ (~150 MB) за 20–40 секунд на машине с 2 vCPU и 2 GiB RAM. Встроенный сканер Yandex Cloud для той же картинки даёт первичный отчёт за ~1–2 минуты (включая очередь на сервере и анализ слоёв), но время зависит от загрузки сервиса и числа слоёв.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…