Private container registry: как хранить Docker-образы безопасно и не зависеть от публичных сервисов

Docker-образы давно стали обычной частью разработки: их собирают в CI/CD, передают между командами, выкатывают в Kubernetes и используют как основу для staging, production и тестовых окружений. Но есть один момент, о котором часто вспоминают слишком поздно: где именно эти образы лежат и кто реально контролирует доступ к ним. Публичный registry удобен, пока всё работает гладко. А потом появляется rate limit, недоступность внешнего сервиса, внезапные требования безопасности, приватные зависимости, аудит, внутренняя политика хранения артефактов - и простой вопрос превращается в инфраструктурную задачу. Private container registry решает её аккуратно: Docker-образы остаются под вашим контролем, доступы управляются внутри компании, а процесс доставки становится предсказуемым. Это не про «усложнить ради безопасности». Это про нормальную инженерную гигиену: как закрытая кладовая для инструментов, где понятно, кто что положил, кто что взял и почему старые коробки не занимают половину помещения.

Что такое private container registry и зачем он нужен

Container registry - это хранилище Docker-образов и других OCI-артефактов. Разработчик или CI/CD собирает образ, отправляет его в registry, а сервер, Kubernetes-кластер или другой потребитель забирает нужную версию. Public registry работает как общий склад. Он удобен для open source, публичных базовых образов и быстрых экспериментов. Но для внутренней разработки такой подход не всегда подходит. Private container registry - это тот же склад, только с замком, журналом доступа и правилами уборки. Вы сами решаете: кто может push-ить образы; кто может pull-ить production-теги; какие образы сканировать на уязвимости; какие версии хранить, а какие удалять; где лежат данные; как выполнять бэкапы registry; что делать при аварии или миграции. Представьте команду, которая выпускает backend-сервис несколько раз в день. Каждый merge в main собирает новый Docker-образ. Через пару месяцев в registry лежат сотни тегов: часть нужна, часть давно забыта, часть собрана из старых base image. Пока всё маленькое - терпимо. Но когда production зависит от этих образов, «терпимо» быстро превращается в риск. Private registry помогает сделать процесс взрослым: не просто хранить образы, а управлять ими.

Почему не стоит полностью зависеть от публичных registry

Публичные сервисы вроде Docker Hub, GitHub Container Registry или публичных registry облачных провайдеров удобны. С этим никто не спорит. Проблема начинается там, где удобство путают с контролем.

Внешний сервис может быть недоступен

Даже крупные платформы иногда испытывают сбои. Для обычного проекта это неприятно. Для production-инфраструктуры - уже инцидент. Простой пример: вы поднимаете новый pod в Kubernetes, а кластер не может скачать image. Не потому что код сломан. Не потому что сервер недоступен. Просто внешний registry отвечает медленно, ограничивает запросы или временно недоступен. С точки зрения бизнеса это выглядит странно: приложение ваше, серверы ваши, CI/CD ваш, но выкладка зависит от сервиса, который вы не контролируете.

Rate limits могут сломать автоматизацию

Публичные registry часто используют ограничения на pull-запросы. Для одного разработчика это почти незаметно. Для CI/CD, Kubernetes-кластера и автоскейлинга - вполне реальная проблема. Допустим, у вас десять runners, несколько окружений и регулярные пересборки. В какой-то момент лимит заканчивается, пайплайн падает, а команда начинает искать виноватого. Хотя причина не в коде, а в архитектуре доставки. Собственный Docker registry снижает эту зависимость. Часто его используют как приватное основное хранилище или как pull-through cache для внешних образов.

Приватный код не должен случайно стать публичным

Образы могут содержать не только приложение. Иногда внутри остаются конфиги, внутренние пути, названия сервисов, приватные зависимости, временные артефакты сборки. Хорошая практика - не допускать такого вообще. Но хорошая практика не отменяет реальность. Private container registry добавляет ещё один слой защиты. Даже если образ содержит лишнее, он не оказывается в публичной зоне по ошибке.

Комплаенс и аудит требуют ясности

В некоторых компаниях важно понимать, где хранится артефакт, кто имел доступ и как долго он сохраняется. Это особенно актуально для финтеха, e-commerce, SaaS-продуктов, инфраструктурных сервисов и команд, работающих с клиентскими данными. Вопрос аудитора «где хранятся production-образы?» лучше встречать не паузой, а понятной схемой: вот registry, вот доступы, вот retention policy, вот бэкапы, вот процесс восстановления.

Какие варианты выбрать: registry:2, GitLab Registry или Harbor

У private container registry нет одного идеального варианта для всех. Выбор зависит от зрелости команды, требований безопасности и того, насколько тесно registry должен быть связан с CI/CD.

Чаще всего рассматривают три подхода

• минимальный Docker Distribution registry:2

• GitLab Container Registry

• Harbor.

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

registry:2: минимализм, который требует дисциплины

registry:2 - это базовый open-source registry для хранения и раздачи Docker-образов. Его часто выбирают, когда нужен простой приватный registry без сложной панели управления. Он хорошо подходит для небольших команд, тестовых окружений, внутренних проектов и случаев, когда вы хотите контролировать каждый слой самостоятельно.

Пример типичного сценария

• есть VPS или выделенный сервер

• на нём запускается контейнер registry:2

• перед ним ставится Nginx или другой reverse proxy

• настраиваются TLS-сертификаты

• добавляется basic auth или token-based auth

• хранилище выносится на отдельный диск или объектное хранилище

• удаление старых данных выполняется через garbage collection.

Звучит просто. И в этом сила registry:2. Но здесь же и слабое место. У registry:2 нет полноценной web-панели, RBAC уровня enterprise, встроенного vulnerability scanning, удобных retention policy из коробки и красивого аудита. Всё это придётся строить вокруг него. Это как арендовать пустой склад: помещение есть, ворота есть, свет включается. Но стеллажи, камеры, пропуска и правила уборки вы ставите сами.

Когда registry:2 подходит

registry:2 хорош, если команда понимает инфраструктуру и не хочет лишней сложности. Например, у вас несколько сервисов, один production-контур, понятные правила доступа и нет требований к сложному аудиту. Он также удобен для изолированных сред: лабораторий, staging-кластеров, внутренних сборок или edge-инфраструктуры, где важнее простота и автономность.

Когда registry:2 лучше не выбирать

Если вам нужны сканирование уязвимостей, подписи образов, разные роли для команд, удобное управление retention policy и визуальная работа с проектами, минимальный registry быстро станет тесным. Формально всё можно прикрутить скриптами. Практически это часто превращается в набор самодельных костылей, которые сложно поддерживать.

GitLab Container Registry: удобно, если CI/CD уже в GitLab

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

Сценарий выглядит естественно

• код хранится в GitLab

• GitLab CI собирает Docker-образ

• образ публикуется в registry проекта

• deploy job забирает нужный tag

доступы завязаны на роли, токены и CI/CD variables. Для многих команд это самый короткий путь к private container registry. Особенно если GitLab self-managed уже развёрнут на собственной инфраструктуре.

Почему GitLab Registry удобен

Главный плюс - интеграция. Не нужно отдельно объяснять разработчикам, где искать образ. Он находится рядом с проектом. Не нужно вручную прокидывать доступы каждому сервису: можно использовать GitLab-токены, deploy tokens, project access tokens и CI_JOB_TOKEN. Например, backend-команда собирает образ registry.example.com/team/api:1.8.4, а deploy job автоматически передаёт его в Kubernetes. Всё происходит внутри одного workflow. Это удобно, понятно и хорошо ложится на привычную модель DevOps.

Ограничения GitLab Registry

GitLab Registry силён именно как часть GitLab. Если вам нужен отдельный registry для разных команд, внешних систем, нескольких кластеров, сложной политики безопасности и централизованного управления образами, Harbor часто выглядит богаче. Кроме того, GitLab Registry не заменяет полноценную стратегию безопасности сам по себе. Вам всё равно нужно продумать protected repositories, cleanup policies, сканирование, подписи и бэкапы. Хороший инструмент не освобождает от архитектуры. Он просто делает её удобнее.

Harbor: registry для команд, которым нужен контроль

Harbor часто выбирают, когда registry становится важной частью платформы. Это уже не просто место, куда CI/CD складывает Docker-образы. Это центр управления артефактами. Harbor поддерживает проекты, роли, robot accounts, vulnerability scanning, tag immutability, retention rules, replication, audit logging, работу с OCI-артефактами и подписи образов через инструменты вроде Cosign. Если registry:2 - это склад, то Harbor - склад с охраной, пропусками, сканером на входе, журналом посещений и правилами утилизации старых коробок.

Когда стоит смотреть в сторону Harbor

Harbor особенно полезен, если

• у вас несколько команд и проектов

• нужны разные уровни доступа

• важно сканировать образы на уязвимости

• нужны политики хранения тегов

• требуется запретить перезапись production-тегов

• хочется реплицировать образы между площадками

• нужен audit trail

• нужно хранить не только Docker-образы, но и другие OCI-артефакты.

Например, компания поддерживает несколько Kubernetes-кластеров: development, staging, production и отдельный кластер для клиентов. Harbor позволяет выстроить централизованную модель: образы проходят через scanning, подписываются, получают immutable tag и только потом становятся доступными для production. Это не магия. Это просто порядок.

Harbor не отменяет инженерную ответственность

Harbor даёт много возможностей, но его нужно правильно настроить. Нельзя просто поставить платформу и считать, что безопасность появилась сама. Нужны понятные проекты, роли, правила доступа, политика retention, регулярные бэкапы, мониторинг, обновления и проверка восстановления. Иначе получится дорогой шкаф с открытой дверцей.

Доступы: кто может push, кто может pull и кто может удалить образ

Безопасность registry начинается не со сканера уязвимостей. Она начинается с доступа. Самая частая ошибка - один общий аккаунт для всех. Им пользуются разработчики, CI/CD, staging, production и иногда забытый скрипт на старом сервере. Пароль знают многие, ротации нет, журнал действий бесполезен. Такой подход удобен ровно до первого инцидента.

Разделяйте людей, сервисы и окружения

У человека должен быть личный доступ. У CI/CD - отдельный service account или token. У production-кластера - отдельные pull credentials. У временных окружений - ограниченные права.

Пример

• разработчики могут pull из dev-проектов

• CI/CD может push в project registry

• staging может pull staging-теги

• production может pull только подписанные release-теги

• удаление образов доступно ограниченному числу maintainers

• robot account используется только для автоматизации и имеет минимальные права.

Это принцип least privilege в простом виде: каждый получает ровно столько доступа, сколько нужно для работы.

Push в production должен быть защищён

Production-теги нельзя оставлять без защиты. Если любой developer может перезаписать app:prod или app:latest, это рано или поздно закончится неприятно. Лучше использовать понятную схему: каждая сборка получает уникальный тег: commit SHA, version, build number; release-тег создаётся только из проверенной сборки; production-теги защищены от перезаписи; для важных релизов включается tag immutability; deploy использует digest или immutable tag, а не плавающий latest. latest удобен в локальной разработке. В production он похож на коробку без наклейки: вроде ваша, но что внутри - узнаете только после запуска.

TLS обязателен

Private registry без TLS - плохая идея. Логины, токены и сами образы не должны ходить по сети в открытом виде. Даже если registry находится «только внутри сети», это не повод экономить на HTTPS. Внутренние сети тоже бывают шумными: старые серверы, временные туннели, VPN, подрядчики, тестовые машины. Нормальная схема проста: registry работает за reverse proxy, внешний доступ идёт по HTTPS, сертификаты обновляются автоматически, HTTP либо закрыт, либо редиректит на HTTPS.

Vulnerability scanning: проверять образ до того, как он попадёт в production

Vulnerability scanning - это автоматическая проверка образов на известные уязвимости. Сканер смотрит на пакеты внутри image, сверяет их с базами CVE и показывает, где есть риск. Важно понимать: scanner не делает образ «безопасным». Он показывает, где больно. Лечить всё равно должна команда. Простая аналогия: сканер в аэропорту не делает чемодан безопасным. Он помогает заметить подозрительные предметы до посадки.

Где запускать scanning

Есть два рабочих подхода

Первый - scanning в CI/CD. Образ собирается, затем проверяется инструментом вроде Trivy, Grype или встроенным scanner в платформе. Если найдены critical vulnerabilities, pipeline падает.

Второй - scanning внутри registry. Harbor, например, умеет запускать сканирование для артефактов и хранить результаты рядом с образом. Это удобно для аудита и повторных проверок, потому что база уязвимостей обновляется, а старый образ может стать уязвимым уже после публикации.

На практике часто используют оба варианта: CI/CD ловит проблемы до публикации; registry периодически пересканирует уже загруженные образы; production policy запрещает выкатывать образы с критическими уязвимостями без исключения.

Что делать с результатами сканирования

Плохой сценарий: включить scanner, увидеть сотни findings и перестать на них смотреть. Хороший сценарий: договориться о правилах.

Например

• critical - блокируют релиз

• high - требуют исправления в ближайшем цикле

• medium - попадают в backlog

• false positive - документируются и получают срок пересмотра

• исключения выдаются не навсегда, а до конкретной даты.

Это важно. Иначе vulnerability scanning превращается в пожарную сигнализацию, которая всё время пищит, но никто уже не реагирует.

Не забывайте про base images

Многие уязвимости приходят не из вашего кода, а из base image. Команда может писать идеальный backend, но собирать его на старом образе с устаревшими системными пакетами. Хорошая практика - регулярно обновлять base images, использовать минимальные образы там, где это уместно, и пересобирать сервисы после обновления базового слоя. Например, вместо тяжёлого универсального образа можно использовать slim-вариант или distroless-подход, если приложение это позволяет. Меньше лишних пакетов - меньше поверхность атаки.

Image signing: как доказать, что образ действительно ваш

Сканирование отвечает на вопрос: «Есть ли в образе известные уязвимости?» Image signing отвечает на другой вопрос: «Можно ли доверять происхождению этого образа?» Это разные вещи. Образ может быть чистым по CVE, но собранным неизвестно кем. И наоборот: образ может быть подписан вашей pipeline, но содержать уязвимую библиотеку. Для production нужны оба контроля.

Что даёт подпись образов

Подпись подтверждает, что конкретный image digest был создан доверенным процессом. Например, вашим CI/CD после прохождения тестов и сканирования. Правильнее подписывать не просто tag, а digest. Тег можно перекинуть на другой образ, а digest указывает на конкретное содержимое. Это как разница между «возьми коробку с надписью release» и «возьми коробку с серийным номером 9f3a…». Инструменты вроде Cosign помогают подписывать контейнерные образы и проверять подписи перед использованием.

Где проверять подписи

Подпись полезна только тогда, когда её кто-то проверяет.

Возможные точки контроля

• CI/CD перед продвижением образа в release

• admission controller в Kubernetes

• deploy script перед обновлением сервиса

• registry policy, если платформа поддерживает нужную интеграцию

ручная проверка при расследовании инцидента. Например, pipeline собирает образ, сканирует его, подписывает через Cosign и публикует в Harbor. Затем production-кластер принимает только образы, у которых есть валидная подпись от доверенного issuer или ключа. Это снижает риск, что кто-то случайно или намеренно подменит image в цепочке доставки.

Подписи не должны быть «ритуалом ради галочки»

Иногда команды подписывают образы, но не проверяют подписи при deploy. Формально процесс есть. Практически защиты нет. Подпись без проверки - как печать на документе, который никто не читает. Лучше начать с малого: подписывать release-образы и проверять их в production. Потом расширить практику на staging, Helm charts, SBOM и другие OCI-артефакты.

Retention policy: registry не должен превращаться в свалку

Docker-образы занимают много места. Особенно если у вас активный CI/CD, много веток и частые сборки. Один сервис может генерировать десятки образов в день. Десять сервисов - уже сотни. Без retention policy registry постепенно превращается в чердак: всё вроде нужно, но никто не помнит зачем.

Какие образы стоит хранить

Универсального правила нет, но хорошая retention policy обычно разделяет образы по типам. Production releases нужно хранить дольше. Они важны для rollback, расследований и восстановления. Staging-образы можно хранить ограниченное время: например, 14-30 дней. Feature branch images часто нужны только пока открыта ветка или merge request. PR/MR builds можно удалять быстро, если они не используются для долгих тестов. Base images и shared images стоит хранить аккуратно, потому что от них могут зависеть многие сервисы. Пример простой политики: хранить все production-теги за последние 12 месяцев; хранить последние 20 successful builds для main; удалять feature-теги старше 14 дней; удалять failed/temporary builds старше 7 дней; не удалять теги, помеченные как protected или immutable; не трогать digest, который используется текущим production. Такая политика не только экономит диск. Она снижает хаос.

Теги должны быть предсказуемыми

Retention policy работает лучше, если теги называются системно.

Плохие теги

• test

• new

• final

• latest2

• fix-prod

ivan-build.

Хорошие теги

• 1.12.0

• 1.12.0-rc.1

• main-8f42c9a

• mr-243-20260618

• release-2026-06-18

prod-2026-06-18. Когда названия понятны, их можно обрабатывать правилами. Когда названия хаотичны, retention превращается в гадание.

Garbage collection - отдельная часть уборки

Удалить tag не всегда значит сразу освободить место на диске. В registry могут оставаться blob-слои, на которые больше никто не ссылается. Чтобы реально освободить storage, нужен garbage collection. В разных registry это устроено по-разному. Где-то GC запускается отдельно, где-то поддерживается online garbage collection, где-то нужно учитывать режим работы и блокировки. Главное - не запускать очистку вслепую. Перед автоматизацией проверьте документацию выбранного registry, протестируйте процесс на staging и убедитесь, что удаление не ломает активные образы. Registry не любит уборку «метлой по живому». Лучше аккуратный регламент, чем героическое восстановление после случайного удаления.

Бэкапы registry: что именно нужно сохранять

Бэкап private registry - это не просто «скопировать папку с образами». Registry обычно состоит из нескольких важных частей: blob storage с layers и manifests; metadata database, если registry её использует; конфигурация сервиса; TLS-сертификаты; секреты и ключи; настройки пользователей, проектов и ролей; retention rules, scanner settings, replication rules; подписи и связанные OCI-артефакты; логи и audit trail, если они нужны для расследований. Если сохранить только образы, но потерять настройки доступа и ключи, восстановление будет болезненным. Если сохранить конфиги, но не сохранить storage, registry поднимется пустым. Если потерять секреты GitLab или Harbor, можно получить работающий сервер, который не может корректно расшифровать или связать данные.

Репликация - не замена бэкапа

Репликация полезна. Она помогает держать копии образов в другом дата-центре, ускорять pull для удалённых площадок и готовить disaster recovery. Но репликация не защищает от всех ошибок. Если кто-то удалил важный image, удаление может уехать на реплику. Если образ был повреждён, проблема тоже может повториться. Если скомпрометировали доступ, злоумышленник может навредить сразу в нескольких местах. Бэкап должен быть отдельным слоем защиты: желательно с версионированием, ограниченным доступом и периодической проверкой восстановления.

Проверяйте restore, а не только backup

Бэкап, который никто не восстанавливал, - это надежда, а не гарантия.

Минимальный здравый процесс

• регулярно создавать backup

• хранить копии отдельно от основного сервера

• шифровать backup, если в нём есть чувствительные данные

• ограничить доступ к backup storage

• периодически поднимать тестовый registry из backup

• фиксировать RPO и RTO.

RPO отвечает на вопрос: «Сколько данных мы можем потерять?» RTO отвечает на вопрос: «За сколько времени мы должны восстановиться?» Для маленькой команды это может быть «не больше суток данных и восстановление за несколько часов». Для production-платформы требования обычно строже.

Архитектура private registry на VPS или выделенном сервере

Private registry можно развернуть на VPS, выделенном сервере или внутри Kubernetes. Для многих команд отдельный сервер - самый понятный старт: меньше движущихся частей, проще контролировать storage, сетевые правила и бэкапы.

Базовая схема может выглядеть так

• reverse proxy принимает HTTPS

• registry работает во внутренней сети или на localhost

• данные лежат на отдельном volume

• доступ к серверу ограничен firewall

• CI/CD подключается по token

• production-кластеры имеют только pull-доступ

• мониторинг следит за диском, ошибками, latency и статусом сервиса

• backup job регулярно отправляет копию в отдельное хранилище.

Такой вариант подходит, если вы хотите контролировать инфраструктуру и не зависеть от публичных сервисов. Особенно когда registry используется для внутренних проектов, production deploy или клиентских окружений.

Storage лучше планировать заранее

Docker-образы растут незаметно. Сегодня registry занимает 50 GB. Через пару месяцев - 500 GB. Потом кто-то включает сборку на каждую ветку, и диск заканчивается в пятницу вечером. Знакомый сюжет.

Чтобы этого избежать, заранее оцените

• сколько сервисов будет храниться

• как часто собираются образы

• средний размер одного image

• сколько тегов нужно хранить

• будут ли храниться multi-arch images

• как часто запускается cleanup

• какой запас нужен для rollback

• где лежат backup-копии.

Для production registry лучше использовать отдельный диск или объектное хранилище. Так проще расширять объём, делать snapshots и не смешивать registry data с системными файлами.

Сеть и firewall: меньше открытых дверей

Registry не должен торчать наружу шире, чем нужно. Обычно достаточно открыть HTTPS для доверенных сетей, CI/CD runners, VPN или конкретных кластеров. SSH-доступ к серверу должен быть ограничен. Админ-панели Harbor или GitLab стоит защищать MFA и отдельными ролями. Если registry нужен только внутри инфраструктуры, не обязательно публиковать его в интернет. Иногда лучше доступ через VPN, private network или bastion. Безопасность часто выигрывает не от сложных инструментов, а от простого вопроса: «Кому вообще нужен доступ к этому порту?»

Как встроить private registry в CI/CD

Registry должен быть частью pipeline, а не отдельной ручной процедурой.

Хороший flow выглядит так

• разработчик пушит код

• CI/CD собирает образ

• образ получает уникальный tag

• pipeline запускает tests

• scanner проверяет image

• при успехе образ публикуется в private container registry

• release job подписывает образ

• production deploy использует digest или immutable tag

старые временные теги удаляются по retention policy. Такой процесс не обязательно внедрять за один день. Можно идти по шагам.

Сначала - private registry и нормальные доступы

• Потом - scanning.

• Затем - retention.

• После этого - signing и enforcement.

Главное, чтобы каждый шаг снижал риск, а не просто добавлял новую кнопку в pipeline.

Пример тегирования для CI/CD

Для main branch

app:main-<short_sha> Для release: app:1.14.2 Для staging: app:staging-20260618-<short_sha> Для merge request: app:mr-381-<short_sha> Для production лучше использовать digest: registry.example.com/app@sha256:... Такой подход помогает понять, откуда взялся образ, когда он был собран и можно ли его безопасно удалить.

Не храните registry credentials в коде

Токены доступа не должны лежать в Dockerfile, compose-файлах, репозитории или shell-скриптах без защиты. Используйте секреты CI/CD, Kubernetes imagePullSecrets, Vault, SOPS, Sealed Secrets или другой принятый в команде механизм. И обязательно ротируйте токены. Особенно если runner был скомпрометирован, сотрудник ушёл из команды или доступ использовался во временном окружении. Секреты любят тишину. Чем меньше мест, где они записаны, тем спокойнее эксплуатация.

Мониторинг и аудит: registry тоже production-сервис

Private registry часто становится критичным сервисом незаметно. Пока он работает, о нём никто не думает. Когда он падает, внезапно нельзя собрать релиз, поднять pod или восстановить окружение. Поэтому registry нужно мониторить как часть production-инфраструктуры.

Минимум стоит отслеживать

• доступность HTTPS endpoint

• ошибки 4xx и 5xx

• время ответа

• количество push/pull операций

• свободное место на диске

• статус garbage collection

• результаты backup jobs

• статус replication, если она используется

• ошибки scanner

• необычные действия пользователей.

Аудит тоже важен. Кто удалил тег? Кто создал robot account? Кто изменил retention policy? Кто отключил immutability? В спокойные дни эти вопросы кажутся бюрократией. В день инцидента они экономят часы.

Типичные ошибки при запуске private container registry

Ошибка 1. Ставить registry без политики доступа

«Потом разберёмся с ролями» - опасная фраза. Потом обычно уже есть десятки пользователей, несколько токенов в CI/CD и непонятно, кто чем пользуется. Лучше сразу разделить роли: admin, maintainer, developer, read-only, robot accounts.

Ошибка 2. Использовать latest в production

latest выглядит удобно, но плохо подходит для воспроизводимых deploy. Сегодня он указывает на один образ, завтра на другой. Production любит конкретику: version tag, immutable tag или digest.

Ошибка 3. Не включать cleanup

Без cleanup registry растёт бесконечно. В какой-то момент место заканчивается, push падает, CI/CD краснеет, команда срочно удаляет «что-нибудь старое». Лучше автоматическая retention policy, чем ручная уборка в панике.

Ошибка 4. Не проверять restore

Backup job может успешно завершаться месяцами, но это ещё не значит, что восстановление сработает. Периодический restore test - скучная, но очень полезная привычка.

Ошибка 5. Полагаться только на vulnerability scanning

Сканер уязвимостей - важный инструмент, но не единственный. Он не заменяет обновления base images, контроль секретов, подписи, ограничение доступов и нормальный процесс релиза. Безопасность registry похожа на сетку: один слой может порваться, но остальные должны удержать систему.

Ошибка 6. Не обновлять сам registry

Harbor, GitLab, registry:2, scanner, reverse proxy, OS - всё это нужно обновлять. Registry хранит важные артефакты, поэтому он сам должен быть частью patch management. Старый registry с уязвимым proxy - странное место для хранения «безопасных» образов.

Практический чек-лист перед запуском

Перед тем как переводить команду на private container registry, полезно пройтись по короткому списку.

Инфраструктура

• выбран registry: registry:2, GitLab Registry или Harbor

• подготовлен сервер, volume или object storage

• настроен HTTPS

• ограничены сетевые доступы

• включён мониторинг

• описан план обновлений.

Доступы

• нет общих аккаунтов для всех

• CI/CD использует отдельный token

• production имеет только pull-доступ

• удаление образов ограничено

• MFA включена для администраторов

• есть процедура ротации токенов.

Безопасность образов

• включён vulnerability scanning

• определены правила для critical/high findings

• используются предсказуемые base images

• release-образы подписываются

• подписи проверяются перед production deploy

• production-теги защищены или immutable.

Хранение

• описана retention policy

• старые temporary images удаляются автоматически

• garbage collection протестирован

• диск или object storage мониторится

• есть запас свободного места.

Бэкапы

• backup включает storage, metadata, конфиги и секреты

• копии хранятся отдельно

• доступ к backup ограничен

• restore протестирован

• понятны RPO и RTO

• репликация не считается заменой backup.

Этот список не выглядит героически. И в этом его ценность. Хорошая инфраструктура редко строится на героизме. Она строится на понятных повторяемых действиях.

Что выбрать в итоге

Если нужен самый простой старт и команда готова самостоятельно настроить безопасность, можно начать с registry:2. Это лёгкий и понятный вариант, но все дополнительные функции придётся организовывать отдельно. Если разработка уже живёт в GitLab, логично использовать GitLab Container Registry. Он хорошо встраивается в pipeline, упрощает аутентификацию и позволяет хранить образы рядом с кодом. Если registry становится центральной частью платформы, есть несколько команд, нужны vulnerability scanning, retention policy, image signing, replication, audit и гибкая модель доступов - стоит смотреть в сторону Harbor. Главное - не выбирать инструмент только по списку функций. Смотрите на реальный workflow команды. Кто собирает образы? Кто выкатывает? Сколько окружений? Какой уровень контроля нужен? Кто будет поддерживать registry через полгода? Инфраструктура должна подходить не только сегодняшнему проекту, но и завтрашней нагрузке.

Private registry как часть зрелой доставки

Private container registry - это не просто «куда складывать Docker-образы». Это точка контроля в цепочке поставки ПО. Через него проходят сборки, релизы, rollback, security checks и production deploy. Поэтому относиться к registry стоит не как к вспомогательной утилите, а как к важному инфраструктурному сервису. Хороший private registry отвечает на простые, но критичные вопросы: откуда взялся этот образ; кто его собрал; прошёл ли он проверку; подписан ли он доверенным процессом; можно ли его выкатывать; как долго его нужно хранить; можно ли восстановить его после аварии. Когда на эти вопросы есть ясные ответы, команда работает спокойнее. Релизы становятся предсказуемее. А инфраструктура перестаёт зависеть от чужих лимитов, чужих сбоев и чужих правил.

Вывод

Собственный private container registry - это практичный шаг для команды, которая уже использует Docker-образы в разработке и production. Он помогает хранить артефакты под контролем, управлять доступами, проверять уязвимости, подписывать release-образы, очищать старые теги и восстанавливаться после сбоев. Начать можно с малого: поднять registry, включить TLS, разделить доступы и подключить CI/CD. Затем добавить vulnerability scanning, image signing, retention policy и регулярные бэкапы. Не обязательно строить идеальную платформу за один подход. Важно двигаться последовательно и не оставлять критичные вещи «на потом». Docker-образы - это не временные файлы после сборки. Это артефакты, из которых живёт ваш production. Чем аккуратнее вы организуете их хранение сегодня, тем меньше сюрпризов получите завтра.