Container Registry — что это, зачем нужен и как использовать готовый реестр контейнеров

Container Registry — это хранилище образов контейнеров с инструментами для управления ими. Иногда можно встретить название Artifact Registry (хранилище артефактов) или хранилище образов. Проще всего представить его складом между сборкой и запуском приложения: CI собирает образ и отправляет его туда, а сервер или кластер Kubernetes забирает нужную версию и поднимает контейнер. CI (continuous integration, непрерывная интеграция) — это автоматизированный конвейер, который после каждого коммита собирает проект, прогоняет тесты и упаковывает результат в образ.

Ниже разберём, что реестр контейнеров даёт на практике, как выбрать между тремя вариантами хранения и что нужно сделать для первого рабочего push.

Как устроен реестр контейнеров и какие задачи он решает

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

Терминология вокруг реестров часто путает, поэтому зафиксируем её сразу:

• реестр (registry) — сервис целиком, точка входа вида registry.example.ru;
• репозиторий — набор версий одного образа, например backend/api;
• тег — читаемая метка версии: 1.4.2, stage, latest;
• дайджест — неизменяемый хеш содержимого (api@sha256:9f2c…), точная ссылка на конкретную сборку.

Пока в проекте один сервис и один разработчик, реестр кажется лишним звеном, ведь можно просто собрать и запустить образ локально на своём компьютере. Вопросы появляются по мере роста команды и сложности продукта. Образы оказываются распределены по разным машинам сборки, никто не помнит, какая версия сейчас в разработке, а откат превращается в пересборку из старого коммита. То есть без централизованного хранения разработка и развитие приложения становятся нетривиальной задачей.

Реестр решает несколько задач сразу:

• Единая точка правды — все образы контейнеров лежат в одном месте и деплой в любое окружение идёт из него.
• Управление версиями — теги и дайджесты дают понятную историю сборок и быстрый откат на предыдущую версию.
• Разграничение доступа — CI получает право на запись, кластер — только на чтение, подрядчик — доступ к одному репозиторию.
• Скорость — кластер тянет образы по внутренней сети, а не через интернет.
• Порядок в хранилище — политики очистки сами удаляют старые сборки, чтобы место не заканчивалось внезапно.

Вариантов ровно три: развернуть реестр самостоятельно, использовать публичный сервис или подключить готовый реестр от облачного провайдера. Выбор влияет на бюджет, скорость деплоя и уровень безопасности контейнеров, поэтому пройдёмся по каждому подходу.

Самостоятельное развёртывание

Команда берёт виртуальную машину или физический сервер и разворачивает open source-решение. Чаще всего выбирают Docker Registry (референсная реализация от Docker), Harbor или GitLab Container Registry. Harbor обычно выигрывает по функциональности: он умеет сканировать образы на уязвимости, подписывать их и реплицировать между инсталляциями.

Плюсы подхода:

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

Минусы:

• реестр становится ещё одним сервисом, который нужно обновлять, бэкапить и мониторить;
• нужен инженер, который разбирается в хранилище, сертификатах и CI/CD-процессах;
• за отказоустойчивость команда отвечает сама: одна виртуальная машина с Harbor — это единая точка отказа;
• менеджмент свободного места в реестре также становится отдельной эксплуатационной задачей. Например, 100 образов по 800 МБ занимают около 80 ГБ. Если CI сохраняет несколько версий образов для каждого сервиса, объём за несколько месяцев легко вырастает до сотен гигабайт или более.

Публичные сервисы

К публичным сервисам относятся Docker Hub, GitHub Container Registry и Quay.io. Условия бесплатного использования, лимиты хранения, число приватных репозиториев и ограничения на скачивание зависят от конкретного сервиса и тарифа.

Например, Docker Hub предоставляет бесплатный тариф Personal с неограниченным числом публичных и одним приватным репозиторием; для анонимных пользователей и тарифа Personal действуют лимиты на скачивание образов. Порог входа обычно невысокий: достаточно создать аккаунт, настроить аутентификацию и загрузить образ.

Не стоит также забывать и об ограничениях, связанных с доступностью указанных сервисов для пользователей из РФ.

Плюсы подхода:

• быстрый старт и бесплатный тариф для открытых проектов;
• огромная база готовых базовых образов и обширная документация;
• привычные всем разработчикам команды и интерфейс.

Минусы:

• публичные образы регулярно содержат уязвимости, а иногда и вредоносный код, поэтому использовать их в production-среде без проверки рискованно;
• лимиты на количество pull-запросов ломают сборки в самый неподходящий момент;
• реестр находится далеко от инфраструктуры приложения — каждый pull идёт через интернет, а это медленнее и нагружает внешний канал;
• доступность зависит от внешнего сервиса и его политики в отношении вашего региона.

Провайдер инфраструктуры

Третий путь — взять Container Registry от провайдера, у которого уже развёрнута ваша инфраструктура, например в облаке, или к которому вы планируете переехать в будущем. Провайдер отвечает за хранилище, отказоустойчивость и обновления, а команда работает через привычный Docker CLI и/или веб-консоль. Такой реестр физически находится в тех же дата-центрах, что и виртуальные машины с кластерами оркестратора контейнеров — Kubernetes, поэтому образы передаются по внутренней сети.

В MWS Cloud Platform эту задачу решает Artifact Registry. Сервис предназначен для хранения и управления Docker-образами, Helm-чартами и другими OCI-совместимыми артефактами. Доступ к реестрам и артефактам настраивается с помощью IAM-ролей и сервисных аккаунтов.

Artifact Registry можно использовать вместе с Managed Kubernetes: для группы узлов кластера назначают сервисный аккаунт с ролью registry.puller, а в манифесте приложения указывают полный адрес образа в реестре. Это позволяет встроить реестр в CI/CD-пайплайн и использовать единый путь от сборки до развёртывания приложения в Kubernetes.

Плюсы подхода:

• нулевые затраты на администрирование — обновления и резервирование берёт на себя облачный провайдер;
• высокая скорость деплоя за счёт близости хранилища к вычислительным ресурсам;
• реестр образов живёт рядом с вычислительными ресурсами Computer или Managed Kubernetes, поэтому трафик передаётся по внутренней сети облака и не проходит через интернет. Это снижает задержки и минимизирует риски безопасности;
• встроенные механизмы безопасности: шифрование, приватный доступ, ролевая модель;
• политики очистки и мониторинг занятого места из коробки.

Минусы:

• сервис платный, в отличие от бесплатного тарифа публичных реестров;
• набор функций определяет провайдер, глубокая кастомизация недоступна;
• инфраструктуру логично держать у того же провайдера, иначе часть выгод теряется.

Короткое сравнение реестров контейнеров по ключевым параметрам:

Готовый реестр даёт эффект не только в удобстве. Вот что меняется на практике:

• Ускорение деплоя — образы лежат рядом с вычислительными узлами, поэтому pull занимает секунды вместо минут. На кластере из десятков нод разница становится заметной сразу.
• Безопасность контейнеров — частный репозиторий образов закрыт от посторонних, данные шифруются, а доступ выдаётся по ролям — CI пишет, кластер читает, никто не делает лишнего.
• Управление версиями — теги показывают, что происходит с сервисом, а дайджест гарантирует, что в прод в production-среду будет развёрнут ровно тот образ, который прошёл тесты.
• Интеграция с Kubernetes — кластер аутентифицируется через сервисный аккаунт, без ручного создания и ротации секретов в каждом неймпейсе.
• Предсказуемая доступность — обычно провайдеры дают гарантии (SLA) на доступность сервиса.
• Контроль расходов — политики очистки удаляют устаревшие сборки автоматически, а мониторинг показывает, сколько места занимают артефакты.

Готовый реестр контейнеров подходит не всем, поэтому разберём, в каких случаях он оправдан, а в каких нет.

Подходит, если вы:

• строите приложение на микросервисах и выкатываете обновления чаще раза в неделю;
• используете Kubernetes и хотите единый пайплайн от сборки до кластера;
• работаете с персональными данными или попадаете под требования регуляторов;
• не готовы выделять человека на поддержку собственного хранилища;
• упёрлись в лимиты Docker Hub или в скорость загрузки образов извне;
• держите инфраструктуру у облачного провайдера и хотите держать образы рядом с ней.

Не подходит или требует расчёта, если вы:

• не используете контейнеры вообще — тогда реестр решает несуществующую задачу;
• ведёте небольшой пет-проект, где хватает публичного репозитория;
• работаете в изолированном контуре без доступа к облаку;
• уже вложились в Harbor с нестандартной логикой, которую готовое решение не повторит.

Покажем порядок на примере Artifact Registry в MWS Cloud Platform: сервис доступен всем, работает под SLA и тарифицируется по опубликованному прайсу. В других реестрах от других провайдеров шаги могут отличаться в деталях, но логика везде одна.

1. Активируйте сервис. В веб-консоли выберите проект, найдите Artifact Registry в списке сервисов и нажмите «Активировать». Для этого понадобится роль admin.
2. Заведите сервисный аккаунт. Создайте аккаунт с нужной ролью и авторизованный ключ к нему, ключ сохраните в отдельном файле. Ролевая модель гранулярная: registry.puller только скачивает артефакты, registry.pusher ещё и загружает с удалением, registry.editor управляет реестрами, репозиториями и политиками очистки. CI обычно хватает pusher, кластеру — puller.
3. Поставьте MWS CLI и Docker. Инициализируйте профиль CLI по авторизованному ключу сервисного аккаунта. Docker ставится по официальной инструкции, а на Linux добавьте пользователя в группу docker, чтобы не писать sudo перед каждой командой.
4. Настройте аутентификацию. Выполните mws registry configure-docker — команда подключает Docker Credential helper, и учётные данные уходят во внешнее хранилище MWS вместо конфита на локальной машине. Проверьте ${HOME}/.docker/config.json: там должен появиться блок credHelpers с адресом registry.mwsapis.ru. Для CI подойдёт и аутентификация по API-ключу.
5. Создайте реестр и загрузите образ. Поставьте тег вида registry.mwsapis.ru/<проект>/<реестр>/api:1.4.2 и выполните docker push по этому адресу. Репозиторий появится автоматически при первой загрузке, а в ответе вернётся дайджест образа.
6. Проверьте результат. Запустите docker run по полному адресу образа — если контейнер поднимается, цепочка собрана верно. Тем же способом в реестр попадают Helm-чарты и другие OCI‑совместимые артефакты.
7. Подключите кластер и настройте политику очистки и контроль хранения. Managed Kubernetes ходит в реестр через сервисный аккаунт с ролью registry.puller. Дальше задайте политику очистки, чтобы старые сборки удалялись сами, и следите за занятым местом в мониторинге реестра.

Дальше остаётся встроить push в CI/CD-пайплайн, чтобы каждая успешная сборка сама попадала в реестр. С этого момента команда перестаёт держать в голове, где лежит актуальный образ, — ответ всегда один. Платить вы будете за объём хранения и исходящий трафик, а доступность сервиса покрывает SLA на уровне 99,99% — это не больше 4 минут 19 секунд простоя в месяц.

Container Registry не самая заметная часть инфраструктуры: он не выдаёт метрик, которыми хвастаются на конференциях, и вспоминают о нём обычно в момент неудачного деплоя. Но именно он превращает набор разрозненных сборок в управляемый процесс — с версиями, доступами и предсказуемым временем выкатки.