Налаштування AMI/Image Pipeline для золотих образів

Чому ручне складання ламає золотий образ AMI

Ручне налаштування серверів не відтворюється: інженер заходить на вузол, править конфіги, доставляє пакети, щось доробляє «тимчасово» — і сервер вирушає в прод як є.

Через кілька місяців в одному середовищі живуть десятки унікальних серверів, у кожного своя історія правок, і жоден не можна підняти заново в тому самому вигляді.

Дрейф конфігурації накопичується непомітно: на одному вузлі змінено ліміт з'єднань, на іншому залишилася стара гілка бібліотеки, на третьому відкрито порт «на час відладки».

Тести проходять на одному сервері й падають на іншому — відтворити помилку нічим, бо еталонного стану просто не існує, а документація описує те, що задумувалося, а не те, що працює.

Відновлення після збою перетворюється на археологію: вузол піднімають з пам'яті, з листування та з уривків старих скриптів, які давно ніхто не підтримував.

За галузевими даними Uptime Institute, більшість тяжких аварій починається з людської зміни конфігурації, а не з відмови заліза, — і простій у такому сценарії вимірюється годинами, бо відновлення йде методом спроб.

Резервні копії тут теж не рятують: вони повертають дані, але не стан операційної системи та середовища.

Золотий образ AMI закриває цей клас відмов: складання описано кодом, версіонується і проходить перевірку на стенді до публікації. Новий сервер отримує рівно той стан, який уже було протестовано, — і розбираємо, як це влаштовано.

Що змінюється після переходу на автоматизоване складання

Раніше новий сервер складали руками за інструкцією: набір пакетів, версії бібліотек, правки конфігів — усе залежало від того, хто і в який день цим займався.

Золотий образ AMI, який складається автоматично з версіонованого опису, прибирає цю варіативність: будь-яке складання дає один і той самий стан, а не «приблизно такий самий».

Час складання та введення в експлуатацію

• Новий сервер піднімається з образу за хвилини замість годин ручного встановлення та налаштування.
• Базові оновлення та правки безпеки приходять одним перескладанням, а не обходом усього парку машин.
• Тестове та робоче середовища складаються з одного опису — розбіжність видно до викочування, а не після.

Складання йде за кроками: Packer проганяє скрипти первинного налаштування, потім образ проганяється через автотести і лише після цього публікується в реєстр з версією та описом змін.

Час відновлення та передбачуваність відкатів

• Відновлення після відмови — це запуск відомого образу, а не розбір «що ж було налаштовано на машині, що впала».
• Відкат — перемикання на попередню версію образу за регламентом, а не імпровізація під навантаженням.
• Простій вимірюється годинами недоступності сервісу; коли складання та відновлення передбачувані, ці години скорочуються в рази.

Головний ефект — усувається цілий клас відмов, причина яких розходження середовищ і ручні правки «нашвидкоруч прямо на сервері». Передбачуваність середовищ перестає бути домовленістю в голові інженера і стає властивістю образу.

Способи складання образу: який режим вибрати під задачу

Вибір режиму визначає не швидкість першого складання, а те, як образ буде жити далі: наскільки просто оновити середовище в усіх копіях, відкотитися на попередній випуск і довести, що вузол відповідає регламенту.

На практиці вибирають між чотирма підходами — від складання з шаблону вендора до зняття зліпка з уже працюючої машини.

Складання з шаблону та з базової системи

Шаблон вендора прискорює старт — ядро, драйвери та служби вже на місці, залишається до встановити прикладне. Зворотний бік: усередину приїжджає те, що вашій ролі не потрібно, а версіонування образів прив'язується до чужого циклу випуску.

Складання з базової системи вимагає описати кожен крок у коді: пакети, користувачів, права, конфігураційні файли. Дорожче на вході, зате версія образу відповідає версії опису, а не даті зняття зліпка — оновлення середовища стає повторюваною операцією.

Доналаштування вже працюючого сервера

Зліпок з живої машини закриває задачу за годину, і на цьому його переваги закінчуються.

Правки, зроблені руками, не потрапляють в опис, тому наступний інженер не відтворить стан, а готовий образ почне дрейфувати: розходження накопичуються повільно і спливають у найнезручніший момент. Такий режим виправданий лише як разове перенесення з обов'язковою подальшою нормалізацією в код.

Ми вибираємо режим за частотою змін і вимогами до відтворюваності, а не за зручністю першого складання.

Як ми впроваджуємо конвеєр складання: етапи робіт

Конвеєр складання золотого образу AMI починається не з шаблонів, а з ревізії того, що вже працює в інфраструктурі. Поки ролі серверів, їхні служби та залежності не описані, образ залишається знімком однієї машини, і тиражувати його не можна.

1. Інвентаризація серверів: збираємо ролі, запущені служби, відкриті порти та зовнішні залежності — фіксуємо, що дійсно потрібно в образі.
2. Схема середовищ: вирішуємо, скільки образів потрібно — базовий, прикладний, під конкретну роль — і де проходять межі між ними.
3. Шаблони конфігурації: описуємо складання як код — пакети, розмітку дисків, мережеві параметри, часовий пояс, агент моніторингу, облікові записи.
4. Складання: шаблон проганяється в ізольованому середовищі та запікається в образ, тому результат не залежить від стану конкретної машини.
5. Перевірка образу перед викочуванням — окремий етап, про нього нижче.
6. Передача в експлуатацію: регламент випуску та відкату версій, порядок зняття застарілих образів.

Перевірка образу перед викочуванням

Образ піднімається в чистому середовищі та проходить перевірки: служби стартують після перезавантаження, мережеві параметри та доступи збігаються з еталоном, зайві сервіси та облікові записи вимкнено. Окремо звіряємо склад пакетів — усе, що потрапило в образ, має бути обґрунтовано шаблоном.

Без цього етапу дефект розмножується по всьому парку: одна помилка в образі дає десятки однаково неробочих серверів. Тому критерій готовності формальний — образ придатний, якщо еталонні перевірки пройшли без відхилень, а розходження з шаблоном розбираються до викочування.

Схеми, конфігурації та регламенти перескладання

Комплект за золотим образом AMI передаємо так, щоб складання можна було повторити без його автора: інженер відкриває репозиторій, читає регламент і отримує ідентичний образ. Нижче — що входить у передачу на руки.

• Опис середовищ: які контури є і чим відрізняються їхні параметри складання.
• Шаблони складання: декларативний опис образу із зафіксованими версіями пакетів.
• Реєстр версій образів: версія, батьківський образ, склад змін, де розгорнуто.
• Правила доступу та ролі в складальному контурі з журналом дій.
• Життєвий цикл образу: скільки версій зберігаємо, що йде в архів, що видаляємо.
• Регламент перескладання та оновлення базової системи з критеріями приймання.
• Порядок відкату на попередню версію, якщо нова поводиться інакше.

Правила доступу та ролі

Права розділено за зонами: інженер складає образ, але не публікує його, а випуск у загальний реєстр версій — за відповідальним за реліз. Доступ видається за ролями, кожна дія потрапляє в журнал, тому видно, чиє складання пішло в бойовий контур.

Регламент перескладання та оновлень

Базова система оновлюється за розкладом, а не за фактом збою: спочатку складання в тестовому контурі, потім перевірки, лише потім перенесення мітки версії на актуальну. В оновлення є вікно, критерії приймання та шлях назад — воно перестає бути подією з невідомим результатом.

Кейс: дрейф конфігурації скоротився до нуля

Парк із ~120 віртуальних машин складали вручну за інструкцією: інженер піднімав сервер з базового образу провайдера, доставляв пакети, правив конфігурації, підключав агента моніторингу.

Інструкція жила у вікі та розходилася з реальністю вже через тиждень після кожного релізу — правки вносили в середовище, але не в документ.

Що було до

На щомісячній звірці 30–40% машин відрізнялися від еталона хоча б одним пакетом або рядком конфігурації, а розходження накопичувалося мовчки: помітити його можна було лише в момент відмови.

Виведення нового сервера займало 3–4 години, з них половина — очікування, поки звільниться інженер, який знає порядок дій.

Кожен п'ятий інцидент у середовищі розбирався до причини виду «на цій машині інший набір бібліотек» — тобто відмови, не пов'язані з кодом, доводилося шукати в конфігурації.

Що стало після

Складання образу перевели в декларативний опис: Packer проганяє один і той самий сценарій встановлення, а готовий образ перевіряється автотестами — сервіс піднімається на тестовій машині, перевіряються порти, права та записи в журналі.

Образ стає єдиним еталоном: будь-яка правка вноситься в опис, а не в живу машину, і потрапляє в середовище лише через нове складання.

Дрейф конфігурації скоротився до нуля — звірка йде за контрольними сумами пакетів і файлів, розходження видно відразу і блокує викочування. Виведення нового сервера займає 8–10 хвилин без участі інженера, включно з перевірками.

Відмови через незбіг середовищ пішли як клас: середовище стало відтворюваним, а відкат — це повернення до попереднього образу, а не ручне лагодження.

Що робити, якщо сервери вже налаштовані вручну

Сервери, налаштовані руками, переводять на еталон без зупинки сервісів — якщо поточний стан спочатку фіксується як відтворюваний опис, а не переписується з пам'яті адміністратора.

Порядок: зняти фактичну конфігурацію, скласти золотий образ AMI, звірити розходження, перенести середовища по одному, тримати робочий відкат до кінця спостереження.

Звірка розходжень — найбільш недооцінений етап. З вузлів знімаються пакети та версії, конфіги, юніти служб, права на каталоги, завдання за розкладом і порти, що слухають; усе зводиться в маніфест, розходження по машинах — в окремий звіт.

Видно, де ручна правка несе навантаження і переходить в опис, а де залишився слід відладки — еталон не повинен успадкувати сміття разом із зайвими класами відмов.

Еталон складається з декларативного опису: пакети, налаштування, агенти моніторингу та логування, вимоги безпеки. Складання йде через Packer — образ відтворюваний, версіонується і не змінюється після запуску: правки вносяться в опис і перескладання, а не в живий сервер.

Переносимо середовищами, а не машинами — спочатку непродуктивний контур, потім група за балансувальником, після підтвердження за метриками решта.

Відкат закладено заздалегідь: колишні вузли не видаляються, а виводяться з балансування і залишаються в резерві. Якщо група на еталоні дає зростання помилок або затримок, трафік повертається на неї однією правкою маршруту — без перескладання і простою. Застарілі сервери гасимо останніми, після повного циклу оновлення і закритого вікна спостереження.

Часті технічні сумніви перед стартом

До старту зазвичай залишаються три питання: скільки займає складання з перевірками, що робити при оновленні базової системи і хто веде конвеєр після передачі. Нижче — відповіді з тією деталізацією, яка потрібна для рішення.

Що робити, коли виходить оновлення базової системи?

Образ складається з опису, а не з ручних правок на живій машині. Оновився базовий шар — конвеєр заново проганяє складання та перевірки і публікує новий золотий образ, а попередній залишається доступним для відкату.

Періодичність оновлень — за розкладом або за подією безпеки — фіксуємо в регламенті: так середовища не розходяться між собою.

Хто відповідає за конвеєр після передачі?

Передаємо репозиторій з описом образу, політики очищення реєстру, документацію та навчання вашої команди.

Далі можливі два режими: інженери замовника самі правлять опис і запускають складання або ми залишаємося на підтримці за узгодженим регламентом — з вікном реакції та плановим оновленням базових шарів.

Обговоримо задачу і повернемося з планом складання

Щоб оцінка і план спиралися на факти, а не на здогади, на вході потрібен мінімум ввідних: склад середовищ, частота змін і вимоги до відкату. Нижче — що надсилаєте ви; за цими даними ми вибудовуємо порядок робіт.

• Склад середовищ. Скільки контурів, чим вони відрізняються — набір сервісів, мережеві правила, доступи — і де зараз розходяться версії.
• Частота змін. Що змінюється в образах — системні пакети, агенти моніторингу, параметри безпеки — і як швидко це потрібно доставляти.
• Вимоги до відкату. За який час потрібно повернути попередній образ, хто приймає рішення і скільки версій тримати в зберіганні.
• Регламент випуску. Хто і як ініціює складання, які перевірки вважаються обов'язковими перед публікацією.
• Обмеження та доступи. Вимоги аудиту, політики безпеки, заборони на зовнішні джерела пакетів, порядок видачі прав.
• Цільові майданчики. Де образи розгортаються і які перевірки мають пройти до публікації.

У відповідь ви отримуєте карту середовищ, схему складання, правила версіонування та зберігання образів, а також порядок робіт з етапами та контрольними точками. Опишіть задачу у вільній формі — повернемося з оцінкою і планом складання золотого образу.