Почему приватный Docker Registry ломается при росте команды
Пока образы тянутся из публичного источника, выкладка зависит от чужого сервиса. Лимиты на скачивание образов срабатывают в самый неудачный момент — когда параллельно собираются несколько веток и агенты разом запрашивают базовые слои. Сборка не падает сразу: она замедляется, часть шагов падает по таймауту, и конвейер приходится перезапускать вручную.
Второй сбой тише и поэтому дороже. Теги перезаписываются, и под одним именем на разных стендах оказываются разные байты: тестировщик проверяет не то, что соберёт релиз. Рассинхрон образов между стендами не видно в логах, он видно в инцидентах — «на тесте работало, в продакшене нет». Воспроизводимость сборки теряется, потому что никто не знает, что именно лежит в образе.
Дальше ломается откат релиза по образу. Пока нужные слои лежат в локальном кеше агента, всё держится; при переезде агента или перезаписи тега предыдущей версии просто нет. Остаётся пересобирать прошлый коммит по памяти и надеяться, что зависимости подтянутся в тех же версиях.
Цена — часы простоя на команду и потерянные релизные окна. Лечится это не дисциплиной, а сменой точки хранения: свой реестр образов с неизменяемыми тегами, разграничением прав и проверкой образов до выкладки. Разбираем, как это закрывается.
Что даёт управляемый реестр образов
Единая точка выдачи образов убирает главную причину расхождений между стендами. Приватный Docker Registry собирает артефакты в одном месте: приложение собирается один раз, а дальше все среды — разработка, тестирование, продуктив — получают один и тот же неизменяемый слой. Спор «у меня работает» заканчивается, потому что сравнивать нечего: идентификатор артефакта одинаков на всех контурах, а не пересобирается заново на каждой машине.
Кеш слоёв рядом с вычислительными ресурсами сокращает время выкладки релиза. Базовые слои скачиваются один раз, при обновлении приложения передаётся только изменённая часть, и развёртывание перестаёт зависеть от доступности публичных хранилищ. Типичный эффект — выкладка укладывается в единицы минут вместо десятков, а команды перестают дублировать трафик при параллельных сборках.
Контроль версий держится на политике тегов: релиз получает неизменяемую метку, а подвижные метки закрываются для записи, чтобы под одним именем не оказался другой артефакт. Из этого вырастает воспроизводимый откат — возврат на предыдущий релиз делается переключением метки и занимает минуты, без пересборки и без поиска нужной сборки в чьём-то каталоге.
Сканирование при загрузке и по расписанию меняет картину с уязвимостями: политика не пропускает в продуктив образ с критичными находками, поэтому доля артефактов с известными уязвимостями падает, а не растёт вместе с числом сервисов. Ролевая модель доступа добавляет порядок: команда видит и выкладывает только свои проекты, действия попадают в журнал, а доступы отзываются вместе с уходом сотрудника.
Варианты хранения образов: сравнение режимов
Выбор режима хранения образов определяет две вещи: как быстро команда откатывается на предыдущий релиз и насколько предсказуемо растёт сам реестр. Отличия между вариантами — не в железе, а в том, кто отвечает за доступность, обновления, права доступа и очистку старых тегов.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Локальный реестр на своём железе | Данные не должны покидать ваш контур; есть свои машины и инженеры, готовые сопровождать сервис | Обновления, резервные копии и место на дисках — на вашей стороне; отказ узла останавливает сборки, пока не поднят второй экземпляр |
| Облачный управляемый реестр | Команда распределена, держать инфраструктуру не хочется; нужен быстрый старт и доступ из разных сетей | Настройка прав и сканирование ограничены возможностями провайдера; объём реестра и число обращений требуют дисциплины по очистке |
| Гибридная схема с репликацией | Сборка идёт внутри сети, а раздача — внешним площадкам; нужны и скорость, и доступность | Две точки хранения: рассинхрон тегов при сбое репликации, сложнее разбирать инциденты, нужна политика «кто источник» |
Ограничения у всех трёх режимов проявляются одинаково: кончилось место или лёг узел — сборки встали, а откатываться некуда. Поэтому рядом с реестром сразу настраивают роли и области видимости, а не выдают команде общий доступ на запись.
Дальше разбираем, как это закрывается в Harbor: разграничение прав по проектам, автоматическое сканирование образов при загрузке и правила очистки по тегам.
Этапы внедрения: от аудита до передачи
Работы идём в порядке, при котором реестр включается без остановки текущих выкладок: сначала фиксируем, что уже есть, затем проектируем хранение и права, и только потом переносим образы.
- Аудит сборочных конвейеров и инвентаризация образов. Какие сервисы собираются, откуда берутся базовые слои, кто и как пушит, сколько тегов живёт в старом хранилище. Результат — список репозиториев и единое правило именования.
- Схема реестра. Проекты и квоты, политики жизненного цикла (сколько тегов держим, когда чистим), размещение хранилища и репликация. Схему согласуем до развёртывания, иначе данные придётся переносить повторно.
- Развёртывание и подключение. Поднимаем Harbor в отказоустойчивой конфигурации, настраиваем TLS, интеграцию с корпоративным каталогом пользователей и резервное копирование.
- Права доступа. Роли по проектам, отдельные служебные учётные записи для конвейеров, разделение чтения и записи, анонимный доступ закрыт.
- Миграция образов. Переносим с сохранением дайджестов и проверкой целостности — пересобирать ничего не нужно, выкладки не прерываются.
- Проверка выкладки. Прогоняем реальные сборки и развёртывания: сканирование уязвимостей, политика блокировки критичных находок, откат на предыдущий тег.
- Передача реестра команде. Регламенты, схема, порядок восстановления и обучение на живом стенде — дальше команда ведёт реестр сама.
Конфигурации Registry, политики доступа и регламенты
После внедрения у команды заказчика остаётся не только работающий реестр, но и полный набор артефактов, по которым его можно развивать и сопровождать без нас. Файлы конфигурации хранятся в git рядом с манифестами развёртывания, поэтому различия между средами задаются значениями, а не правкой шаблонов вручную. Что именно передаём:
- Конфигурации реестра: параметры хранилища, внешние подключения, лимиты на размер загрузки, включённые проверки уязвимостей и сроки хранения слоёв.
- Политики доступа: правила на уровне проектов и репозиториев, требования к подписанным образам, запрет перезаписи неизменяемых тегов.
- Роли и права команд: матрица «команда — проект — действие», привязка к корпоративному каталогу, отдельные учётные записи для сборочных агентов.
- Регламент обновления образов: периодичность пересборки базовых слоёв, порядок выпуска исправлений безопасности, ответственные за подтверждение.
- Правила очистки и хранения: сколько последних образов на тег остаётся, что уходит из реестра автоматически, как сохранить возможность отката.
- Схема резервного копирования: какие метаданные и артефакты копируются, с какой периодичностью, как проверяется восстановление на отдельном контуре.
- Инструкции для команд: как получить доступ, как опубликовать образ, куда обращаться при инциденте и как читать отчёт сканирования.
Каждый документ привязан к конкретному файлу и версии, а не описывает желаемое состояние. Передача сопровождается прогоном: разворачиваем реестр с нуля по этим материалам и сверяем результат с рабочим контуром.
Кейс: как сократили время выкладки и число инцидентов
Команда сопровождала около сорока сервисов: сборка шла в конвейере непрерывной интеграции, а образы складывались в публичный реестр без политик доступа. Выкладка на тестовый стенд занимала в среднем 35–40 минут, и половина времени уходила на ручную подстановку тегов и повторные сборки после невнятных ошибок.
На стендах расходились версии: разработчик отправлял latest, тестировщик поднимал не тот образ, дежурный не мог быстро понять, что именно работает сейчас. Расхождения между окружениями всплывали три-четыре раза в неделю, а разбор инцидента с образом — откат не той версии, несовместимая библиотека — занимал два-три часа.
Мы развернули приватный реестр на Harbor: проекты по командам и окружениям, роли в RBAC, отдельные служебные учётные записи для конвейера, неизменяемые теги и правило хранения, которое чистит старые слои, но оставляет последние сборки для отката. Сканирование уязвимостей идёт при отправке образа, сборка с критичными находками блокируется до исправления, исключение оформляется явно и на ограниченный срок.
Через три месяца: выкладка на стенд — около шести минут вместо сорока, потому что стенд тянет образ по неизменяемому тегу. Расхождения версий между окружениями сократились до нуля. Доля образов с известными критичными уязвимостями упала с 22% до 0,4% — остались единичные случаи, где обновление зависит от внешнего поставщика. Инцидентов, связанных с образами, за два квартала не зафиксировано.
Откат при этом остаётся управляемым: нужные сборки хранятся, журнал реестра показывает, кто и когда отправил образ, поэтому разбор занимает минуты, а не часы.
Что делать, если реестр образов уже развёрнут вручную
Работающий самодельный реестр не нужно пересобирать с нуля — его переносят на управляемую платформу, сохранив прежние адреса выдачи образов. Начинаем с инвентаризации: без неё перенос превращается в перебор тегов наугад. Дальше — поэтапное переключение, при котором выкладки не останавливаются.
Инвентаризация образов идёт от факта, а не от списка в голове инженера: реестр отдаёт перечень репозиториев и тегов, и его сверяют с журналами обращений, ссылками в конфигурациях кластеров и шагами сборки. На выходе видно, какие образы тянут боевые и тестовые контуры, какие дублируют друг друга по слоям, а какие не запрашивались ни разу. Обычно заметная часть тегов оказывается балластом — и это сразу задаёт реальный объём работ.
Перенос существующего реестра делаем с периодом двойной работы: Harbor поднимается рядом, настраивается проксирование к старому адресу, и он остаётся источником, пока не переключится последний потребитель. Сборки переводят на служебные учётные записи, ограниченные своим проектом, а общие ключи отзываются по мере миграции — бесшовный переход без окна простоя.
Права и хранилище приводим в порядок сразу: проекты по командам, роли от «только чтение» до администратора реестра, синхронизация с каталогом пользователей, квоты и правило хранения — последние десять тегов на репозиторий, релизные теги неизменяемы. Легаси-теги не удаляем вслепую: их гасят по метрике обращений, а освободившиеся слои собирает сборщик мусора.
Частые технические сомнения при переходе на свой реестр
Главное сомнение при уходе от внешнего реестра — не «как настроить», а «что будет, когда он перестанет отвечать». Ниже прямые ответы про доступность, переписывание сборочных конвейеров и ответственность после передачи.
Что произойдёт, если реестр станет недоступен?
Развёрнутые контейнеры продолжают работать: образ уже лежит на узле, перезапуск идёт из локального кэша. Реестр держим в двух экземплярах на разных площадках, состояние — в реплицируемом хранилище. Отказ одной машины не останавливает сборки и выкладки, а проверка доступности выводит узел из балансировки сама.
Придётся ли переписывать сборочные конвейеры?
Нет. Адрес реестра и учётные данные вынесены в переменные окружения — меняется строка в настройках агента сборки, логика шагов остаётся прежней. На время перехода старое зеркало работает параллельно, поэтому переключение идёт без остановки выкладок.
Насколько защищён приватный реестр?
Доступ строится на ролях: команда видит только свои проекты, права на чтение и запись разделены. Образы сканируются на уязвимости при загрузке, политика блокирует выкладку сборок с критичными находками, а для автоматики используются короткоживущие учётные данные вместо общего пароля на всех.
Что с поддержкой после передачи?
Передаём конфигурации, схемы размещения, регламенты обновления и восстановления, доступы оформляются на вашу сторону. Инженеры остаются на сопровождении с согласованным временем реакции, но не как единственные, кто умеет обслуживать реестр: после обучения операцию проводит ваша команда.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться с оценкой и планом работ по реестру, нужен минимум вводных: где сейчас лежат образы, сколько команд публикует, какие требования к доступам и хранению. Обычно достаточно разговора с нашим инженером и доступа к текущей конфигурации — разбирать весь контур целиком не требуется.
- Перечень сервисов и команд, которые публикуют и забирают образы — от него зависит схема проектов и изоляция между ними.
- Объёмы и текущее хранение: сколько тегов живёт в реестре и что обязательно сохранить при переносе.
- Требования к ролям: кто только читает, кто публикует, кому нужны права администратора и на какой срок.
- Правила хранения: сколько последних версий держать, что уходит из реестра без возможности отката.
- Политика проверки образов на уязвимости: блокировать публикацию или только фиксировать результат.
- Ответственный со стороны заказчика и окно, в которое допустимы работы на общем контуре.
В ответ приходит план работ по реестру: этапы, изменения в существующих сборках, точки проверки и критерии приёмки, а также оценка внедрения с разбивкой по этапам — без работ «по факту». План согласуется с вашим техлидом, при необходимости — с безопасностью.
После согласования стартуем с тестового контура: поднимаем реестр, переводим пилотную команду, смотрим на скорость сборки и выгрузки образов. Дальше — поэтапный перевод остальных команд, обучение дежурных и передача документации. Опишите задачу в двух словах — вернёмся с оценкой и планом.
