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