Практический пошаговый гайд по созданию и использованию Yandex Container Registry (YCR) в 2026 году: от создания реестра до интеграции с Kubernetes и проверки уязвимостей. Примерное время выполнения — 60–90 минут для базовой настройки и интеграции.
Статья была полезной?
yc 0.96.0 (2026). Установка занимает ~1–2 минуты.docker 24.0 (2025) или совместимый runtime (достаточно 2 CPU / 4 GiB RAM для локальной сборки образов).kubectl 1.28 (2025) для деплоя в кластер Kubernetes 1.28 (минимум 2 vCPU и 4 GiB RAM в рабочем узле для тестового окружения).trivy 0.47 (2025) для оффлайнового сканирования образов (RAM 1–2 GiB, время сканирования для 150 MB образа ~20–40 с).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
Цель шага — создать контейнерный реестр в выбранной папке 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-запрос; инициализация реестра занимает несколько секунд в фоне.
Ожидаемый вывод (успех):
created_at: "2026-02-10T14:32:10Z"
name: "my-ycr"
registry_id: "cr-abcdefgh12345678"Типичная ошибка и фикс:
Ошибка: "Permission denied: iam.grant" — означает, что у пользователя нет прав на создание ресурсов в папке. Фикс: назначьте роль roles/editor для пользователя или используйте сервисный аккаунт с нужными правами в папке.Цель — аутентифицироваться в реестре и отправить 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Фикс: проверьте токен (возможно, просрочен) и права сервисного аккаунта. Если ошибка повторяется, выполните:
yc iam create-token --duration=3600 > yandex-token.txt
cat yandex-token.txt | docker login --username oauth --password-stdin cr.cloud.yandex.netДругой типичный сбой: TLS/Network — если push зависает (время >120 s) или прерывается, проверьте правила VPC/Firewall и исходящий HTTPS-порт 443. Для медленных сетей рекомендуем включать параллельную загрузку слоёв в Docker (в Docker 24.0 это стандартно).
Скриншот: успешный docker push в YCR
Цель шага — настроить Kubernetes (kubectl 1.28) так, чтобы поды могли вытягивать образы из YCR. Способ: создать секрет типа docker-registry и использовать его в Deployment или ServiceAccount.
Команды (вариант через командную строку):
# Создаём секрет на основе токена yc (подставьте namespace)
kubectl create secret docker-registry ycr-secret \
--docker-server=cr.cloud.yandex.net \
--docker-username=oauth \
--docker-password="$(yc iam create-token)" \
--docker-email=you@example.com -n default
# Пример Deployment, использующий секрет
cat <deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 2
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: cr.cloud.yandex.net/cr-abcdefgh12345678/myapp:1.0
ports:
- containerPort: 8080
imagePullSecrets:
- name: ycr-secret
EOF
kubectl apply -f deployment.yamlПояснение: секрет 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Типичная ошибка и исправление:
ImagePullBackOff
Events:
Warning Failed 1s (x3 over 12s) kubelet Failed to pull image "cr.cloud.yandex.net/.../myapp:1.0": rpc error: code = Unknown desc = access forbiddenФикс: убедитесь, что секрет существует в том же namespace, где разворачивается Pod, и что токен действителен. Если кластер использует Частный сетевой маршрут, проверьте доступ по HTTPS к cr.cloud.yandex.net из узлов кластера. Для автоматизации лучше использовать сервисный аккаунт Yandex Cloud с назначенной ролью container.registry.* и привязать его к Kubernetes через OIDC/Workload Identity.
Цель — проверить образы на известные уязвимости. Два подхода: встроенный сканер Yandex Cloud (если включён) и офлайн-сканирование с помощью Trivy 0.47 (2025). Trivy даёт быстрые отчёты и поддерживает формат JSON для CI.
Trivy (локальное сканирование):
# Установите trivy 0.47 (пример для Linux)
# curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sudo sh -s -- -b /usr/local/bin v0.47.0
# Сканирование образа в реестре (авторизация нужна, используйте токен yc)
export TRIVY_NON_SSL=false
trivy image --severity CRITICAL,HIGH --format table cr.cloud.yandex.net/cr-abcdefgh12345678/myapp:1.0Ожидаемый вывод (успех):
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, описание, уязвимый пакет и рекомендации по обновлению слоя.
Короткий разбор конкурентов и когда их стоит выбирать:
Совет по выбору: если основная инфраструктура размещена в Yandex Cloud и важна интеграция с IAM и локальными сервисами (KMS, Monitoring), YCR даёт меньше операций по настройке безопасности и сетей, чем перенос образов между публичными провайдерами.
Ценообразование YCR в 2026 году состоит из трёх основных компонентов: стоимость хранения (GB/месяц), исходящий трафик (GB) и операции (API-запросы/PUT). Приведённые цифры — ориентиры и требуют проверки в вашем аккаунте перед продакшеном.
Оценка (пример, 2026):
Пример расчёта: вы храните 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/регион.
Для автоматизации в 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 и исключает хранение постоянных паролей.
Проверьте сетевую доступность: подключитесь к узлу и выполните curl -v https://cr.cloud.yandex.net. Если соединение не устанавливается, проверьте VPC маршруты и firewall rules (исходящие правила по порту 443). Если используется приватный кластер с egress через NAT Gateway, убедитесь, что NAT настроен и имеет доступ в интернет. Альтернативно можно использовать локальный кэш proxy-registry (например, registry:2) внутри VPC.
Медленный push обычно связан с: медленным интернет-каналом, большим числом слоёв и отсутствием параллельной загрузки. Оптимизации: уменьшите количество слоёв (объедините RUN команды в Dockerfile), используйте сжатые базовые образы (alpine), и запускайте push в среде с хорошим сетевым каналом (CI runner в том же регионе Yandex Cloud). Также проверьте настройки MTU и возможные прокси в пути трафика.
Минимальный набор ролей для сервисного аккаунта: containerregistry.registryAdmin или набор ролей, дающих права на загрузку и управление образами в конкретной папке/реестре. В продакшене рекомендуется использовать принцип наименьших привилегий: назначать права на уровне конкретного реестра (или папки) вместо прав на уровне организации.
Trivy 0.47 сканирует типичный текстовый/интерпретируемый образ (~150 MB) за 20–40 секунд на машине с 2 vCPU и 2 GiB RAM. Встроенный сканер Yandex Cloud для той же картинки даёт первичный отчёт за ~1–2 минуты (включая очередь на сервере и анализ слоёв), но время зависит от загрузки сервиса и числа слоёв.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…