Політика базових образів: що ламається без неї
Поки єдиного правила немає, кожна команда бере базовий образ звідти, звідки зручно, і оновлює його коли згадає.
Уночі в батьківському образі змінюється патч-версія — уранці одна зі служб піднімається з новою бібліотекою і падає на несумісному виклику, а причина не видна: той самий код, та сама гілка, інший батько.
Політика базових образів відсутня, і збірка починає залежати від того, що хтось виклав у спільний реєстр.
Далі починається розбіжність середовищ. Стенд зібраний на минулому батькові, прод — на поточному, у розробника локально взагалі образ із кешу, і баг відтворюється на одному контурі з трьох.
Паралельно накопичуються застарілі залежності: оновлювати батька страшно, бо ніхто не перевіряв, що приїде разом із ним, — версія живе в проді до першого інциденту.
Тіньові збірки закривають цей біль по-своєму: частина образів збирається повз конвеєр, руками, з локальних машин, і потрапляє в реєстр без сканування та без метаданих про склад.
Так виходить невідтворювана збірка — з одного коміту виходять різні артефакти, і відкат на попередній образ перестає бути відкатом.
Ціна проявляється в найневдаліший момент — під час планового оновлення батька або термінового закриття вразливості. Спочатку доводиться розбирати, що взагалі зібрано і на чому, і лише потім щось змінювати.
Розбираємо, як це закривається: єдиний батьківський образ, фіксовані теги, вікно оновлення та перевірка на стенді до проду.
Вимірюваний ефект: час збірки та стабільність середовищ
Політика базових образів вимірюється не числом документів, а чотирма величинами: строк випуску релізу, частка успішних оновлень, кількість ручних правок конфігурації на реліз і відтворюваність стендів.
Ми знімаємо ці показники до впровадження — за історією збірок у реєстрі та журналами розгортання, — інакше ефект нема чим підтвердити.
Основний зсув — у строці випуску. Коли всі сервіси збираються від одного зафіксованого базового образу, а оновлення безпеки надходять централізовано, команді не потрібно на кожному релізі узгоджувати версії бібліотек і перезбирати шари вручну.
Підготовка релізу скорочується в рази, а сама збірка вкладається в передбачуваний час замість «як пощастить із кешем».
Частка успішних оновлень зростає завдяки зникненню цілого класу відмов — розбіжності оточень. Тестове, передпродуктивне та продуктивне середовище перестають відрізнятися набором системних пакетів, тому розбіжність конфігурації зникає як категорія інциденту. Залишаються помилки в коді та логіці — те, що справді потребує інженера, а не перезбирання.
Ручні правки конфігурації зникають із процесу: зміна базового шару робиться в одному репозиторії та проходить ті самі перевірки, що й код. Під час налаштування еталонного образу ми спираємося на CIS Benchmarks — вимоги безпеки перевіряються автоматично, а не очима чергового.
Передбачуваність стендів стає вимірюваною: той самий дайджест образу дає однакову поведінку на будь-якому вузлі, а відкат зводиться до перемикання на попередній тег.
Режими оновлення та контроль версій образів
Політика базових образів відповідає на одне питання: хто і коли вирішує, що основа сервісу змінилася. Збій проявляється не в момент зміни — несумісність бібліотек або непропатчена вразливість випливають через кілька релізів, коли причина вже загублена в історії збірок.
Ключове розгалуження — жорстке закріплення версії проти плаваючих міток. Закріплення за незмінним хешем дає повторюваність: та сама основа, той самий результат. Плаваюча мітка приносить свіжі виправлення без правок у коді, але робить оновлення некерованою подією.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жорстке закріплення версії за хешем | Регульовані сервіси, відтворювані збірки, аудит | Патчі не надходять самі — потрібен регламент оновлення |
| Плаваючі мітки | Внутрішні сервіси, тестові стенди | Збірка ламається у випадковий момент, відкат неочевидний |
| Повне перестворення збірки | Планове оновлення, підготовка до великого релізу | Тривалий прогін перевірок, потрібен паралельний стенд |
| Шари надбудови | Свої патчі поверх готової основи | Зростає число шарів, складніше відстежити походження |
Далі — сумісність версій. Ведемо матрицю «версія основи × залежності сервісу» і проганяємо по ній збірку: якщо бібліотека вимагає старішу гілку, конкретний сервіс залишається на ній, інші йдуть уперед.
Шари надбудови збираємо лише з внутрішнього репозиторію — оновлення основи не тягне за собою неперевірений код, а перестворення збірки запускається за розкладом, а не за фактом збою.
Етапи впровадження: від аудиту реєстру до регламенту
Порядок кроків тут не формальність: правила, написані до інвентаризації, ламають збірки команд, чиїх залежностей ви ще не бачили. Тому йдемо від фактів до регламенту — кожен етап дає вхід для наступного.
- Аудит реєстру. Вивантажуємо образи та теги, позначаємо, що працює в продакшені, а що тягнеться як батьківський шар. На виході — список із датами збірки та власниками сервісів.
- Схема залежностей. Будуємо граф: сервіс → базовий образ → спільні шари. Видно, скільки команд зачепить зміна образу і які збірки переводити першими.
- Налаштування правил збірки. Фіксуємо дозволені базові образи та їхнє джерело, політику тегів, перевірку підпису. Збірка з неперевіреного джерела блокується автоматично, а не умовляннями в чаті.
- Перевірка на стенді. Проганяємо один-два сервіси на нових правилах: системні бібліотеки, сертифікати, права доступу. Конфлікт дешевше зловити тут, ніж на релізі.
- Відкат та винятки. Переконуємося, що попередні образи доступні та відкат займає хвилини, а для старого сервісу є тимчасовий виняток із датою перегляду.
- Передача регламенту. Віддаємо документ і навчаємо команду: як додати новий базовий образ, хто погоджує, що робити при відхиленій збірці.
Після цього правило живе в процесі збірки, а не в інструкції: порушення видно відразу, а не на розборі інциденту.
Регламенти оновлення, схеми та карта залежностей
Регламент — не документ заради документа, а набір артефактів, за якими ваша команда працює без нас.
Кожен пункт прив'язаний до дії: хто має право змінювати базовий образ, у якому порядку збірка потрапляє в робочий контур, що робити вночі, якщо в базовому шарі знайшли критичну вразливість. Нижче — комплект, який залишається у вас після впровадження політики базових образів.
- Регламент оновлення — періодичність перезбирання, строк життя тегу та відповідальний за випуск.
- Карта залежностей — який сервіс на якому базовому образі зібраний, хто власник і які шари він успадковує; оновлюється при кожній збірці.
- Політики доступу — хто публікує образ у реєстр, хто лише читає, хто затверджує винятки; права розведені за ролями.
- Порядок винятків — форма тимчасового відступу: обґрунтування, строк, власник, дата перегляду; жоден не губиться і потрапляє у звіт.
- Схема оточень — які теги дозволені в тестовому контурі, які в робочому, як збірка просувається між ними.
- Інструкція чергової зміни — покроковий порядок при критичній вразливості: оцінка охоплення, перезбирання, відкат.
- Звітність — частка сервісів на актуальному образі, відкриті винятки, час від виходу виправлення до розгортання.
Кейс: як усунули розбіжність середовищ і прискорили випуск
До впровадження політики базових образів дев'ять команд збирали базовий шар кожна по-своєму: залежності підтягувалися в момент збірки, і той самий сервіс на шести стендах отримував різні системні бібліотеки.
Розбіжність середовищ коштувала дорожче, ніж виглядало у звітах. Приблизно кожен четвертий викат падав на старті через незбіг версій бібліотек, а розбір причин займав більше часу, ніж сама збірка.
Повний цикл збірки займав близько 11 хвилин, шість із них ішли на встановлення залежностей із зовнішніх джерел.
Зафіксували один батьківський образ з описаним складом пакетів і звели збірку та зберігання артефактів у Harbor.
Дочірні образи збираються лише від перевіреного батька, оновлення йде перезбиранням за розкладом і при появі вразливостей у базових пакетах, а не правками в кожному репозиторії.
Після переходу стенди перестали різнитися — частка відмінних пакетів упала з третини до нуля. Збірка скоротилася до трьох хвилин завдяки спільному батькові та кешуванню шарів, розмір образів зменшився втричі після видалення зайвих утиліт.
Клас відмов «на стенді працювало, у продуктивному середовищі ні» зник, при цьому відкат на попередній тег залишився доступним: старі образи зберігаються в реєстрі та підписані.
Чим відрізняється жорстке закріплення від рекомендаційного режиму?
Різниця проявляється в момент, коли перевірку не пройдено. Жорстке правило блокує збірку: базовий образ не з довіреного реєстру або не пройшов перевірку на вразливості — артефакт не випускається. Рекомендаційний режим фіксує те саме порушення, але пропускає збірку: відхилення потрапляє у звіт.
Жорсткі правила окупаються там, де потік збірок великий і команд багато. У м'якому режимі попередження накопичуються, а старі базові шари живуть місяцями — одного разу вразливість знаходиться одразу у двадцяти сервісах. Блокування вирівнює всіх: оновлення базового шару перестає бути доброю волею окремої команди.
Зворотний бік — термінове виправлення. Коли критичну вразливість треба закрити зараз, а потрібний образ ще не пройшов повний цикл перевірки, жорстка політика стає поперек: патч готовий, випустити не можна.
Інженери йдуть в обхід — правлять політику вручну або тягнуть невраховану гілку, і керованість збірки від цього падає.
Компроміс режимів виглядає як два маршрути всередині однієї політики. Загальний потік іде за жорсткими правилами, а для аварійного виправлення залишається окремий шлях: рекомендаційний режим з обов'язковою реєстрацією винятку — хто випустив, на який строк, чим обґрунтував. Виняток живе обмежений час і потім автоматично повертає збірку в жорсткий режим.
Політика версіонується разом із кодом, кожна збірка знає, під яку його ревізію пройшла, а число чинних винятків — вимірювана величина. Зростаючий список винятків сам підказує, де правила надто суворі, а де базові образи оновлюються рідше, ніж потрібно командам.
Технічні сумніви: сканування, підписи, сумісність
Походження перевіряється двічі: базовий шар фіксується за дайджестом, а не за плаваючим тегом, і на виході образ отримує підпис та атестацію. Перед викатом контроль допуску в кластер звіряє підпис із ключем довіри — підмінений образ просто не доходить до розгортання.
Цілісність збірки перестає залежати від дисципліни, а готові інструменти підпису на кшталт Sigstore закривають цю частину без самописних скриптів.
Перехід на політику робимо поетапно, інакше перший же реліз упирається в чужу збірку. Спочатку вона працює в режимі аудиту, потім блокує прод-простори імен, і лише потім — усі інші. Збірка, яка поки тягне легасі-образ, отримує тимчасовий виняток із власником і датою перегляду.
Сумісність із поточними збірками не зламається?
Ламається лише те, що тягне образи без супроводу. Для нестандартних баз — свої середовища виконання, нативні модулі — збираємо мінімальний шар і вносимо його до списку дозволених. Застосунок збирається як раніше, змінюється батьківський шар.
Сканування вразливостей не загальмує конвеєр?
Скануємо дельту та кешуємо звіт за дайджестом: той самий шар повторно не перевіряється. На кожен коміт — критичні рівні, повний звіт — за розкладом.
Як відкотитися, якщо нова база ламає реліз?
Старий образ залишається в реєстрі: правило зберігання тримає останні збірки на тег, тому повернення — зміна дайджесту в маніфесті, а не перезбирання. Виняток із політики описаний як код і відкочується разом із ним.
Обговоримо задачу: аудит реєстру та план впровадження
Аудит реєстру починається не зі звіту, а з доступу до фактів: без інвентаризації образів і розуміння, хто і як їх збирає, будь-яка політика базових образів залишиться декларацією.
Тому порядок старту такий — ви надсилаєте ввідні, ми розбираємо реєстр і конвеєри збірки, потім повертаємося з планом впровадження та оцінкою робіт за етапами.
Для оцінки достатньо додати:
- перелік базових образів і тегів у реєстрі із зазначенням власників сервісів;
- кілька прикладів файлів збірки з різних команд — від давніх сервісів до свіжих;
- налаштування конвеєрів збірки та правила сканування образів на вразливості;
- схему доступу до реєстру: хто публікує, хто лише читає, де лежать ключі;
- вимоги щодо безпеки та ізоляції середовищ, які політика має закрити;
- список сервісів, які не можна зупиняти, і зручне вікно для змін.
Далі ми звіряємо факти з практикою: дивимося дублі базових образів, дрейф тегів, строк життя шарів і скільки збірок обходить перевірки.
На виході — план впровадження за етапами: від заморозки списку допущених базових образів до автоматичної перевірки в конвеєрі та відкату на попередній образ, якщо правило блокує реліз.
Обговоримо задачу — опишіть її у вільній формі, і ми повернемося з оцінкою робіт, строками та порядком старту.
