Docker Compose production: де ламається конфігурація
Docker Compose зручно описує оточення однієї машини, поки йдеться про стенд. У production до того ж файлу додаються перевизначення, копії на різних серверах і правки під час інцидентів — так починається дрейф конфігурації. Перевірена збірка стартує в бою з іншим набором томів, лімітів та адрес.
Окрема біда — змінні середовища. Паролі, адреси баз і зовнішніх сервісів нерідко вшиваються в образ на етапі збірки замість подання контейнеру під час запуску.
Тоді той самий образ несе налаштування стенда: бойовий контейнер звертається до тестової бази, і це з'ясовується за логами, а не на перевірці конфігурації.
Відкат релізу ламається з тієї ж причини. Повернення до попереднього образу не повертає налаштування — файл залишається поточним, тому старий код піднімається з новими змінними та томами й тягне за собою чужі значення. Поки конфігурація не версіонується разом з артефактом, відкат не можна вважати безпечною операцією.
Розходяться середовища й через дрібниці: ім'я проєкту, мережа, точки монтування, політика перезапуску, порядок старту залежних сервісів. Кожна така відмінність — окремий клас відмов, від переповненого диска до сервісу, що піднявся раніше за базу. Розгалуження за іменем середовища в межах одного файлу проблему не знімають, а ховають.
Лікується це розділенням: спільний файл з описом сервісів, окремі файли для стенда й бою, усі значення — лише зі змінних середовища, перевірка конфігурації перед викладкою, налаштування прив'язані до того самого артефакту, що й код. Тоді відкат повертає й образ, і конфігурацію цілком. Розбираємо, як вибудувати цей контур у вас.
Що дає роздільне налаштування середовищ
Конфігурація, вшита всередину образу, ламає саму ідею просування одного артефакту: щоб змінити адресу бази або ліміт з'єднань, доводиться перезбирати образ, а отже — знову проходити весь шлях перевірок.
Відмінності між тестовим і промисловим контуром накопичуються в шарах, і передбачувано відтворити збірку на іншій машині вже не виходить.
Роздільне налаштування переносить відмінності у змінні середовища, файли, що монтуються, і перевизначення в окремому описі контуру.
Образ залишається незмінним і просувається рівно той самий, що перевіряли на тестовому стенді: Docker Compose підставляє параметри на старті, а не на етапі збірки.
Звідси час викочування: оновлення зводиться до перезапуску сервісу з новим набором параметрів, без перезбирання й прогону всього контуру заново. Відкат — повернення до попереднього набору змінних, десятки секунд замість повторної збірки та повторних перевірок.
Простій сервісу обмежений часом зупинки одного контейнера, а не всього стеку, якщо перезапускати по одному.
Відновлення прискорюється завдяки тому, що стан винесено в томи та зовнішні сервіси, а сам контейнер стає замінним.
Зникає цілий клас відмов, де перезбирання образу забирало накопичені дані або залишало стенд у напівзібраному вигляді: підняти контур з нуля — це підняти ті самі образи з тими самими параметрами.
Частка інцидентів, спричинених розходженням контурів, падає: перевірки йдуть на тому самому артефакті, що потрапить у промисловий контур, і відмінність залишається лише в значеннях параметрів.
Відтворюваність збірки перестає залежати від того, хто і в якому порядку правив конфігурацію на сервері.
Способи організації середовищ: порівняння варіантів
Вибір способу опису середовищ визначає, скільки ручної роботи потребує кожен реліз і як часто правка потрапляє не в той контур. Нижче — чотири схеми, які реально застосовують для staging і production, і межі, за якими кожна починає заважати.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один спільний файл конфігурації | один контур, невеликий проєкт, рання стадія | правки для різних середовищ живуть поруч, ризик зачепити бойовий контур зростає з кожною новою послугою |
| Файли накладання | базовий набір сервісів спільний, відмінності — порти, ліміти, змінні | за трьох і більше контурів комбінації накладання стає важко відстежувати вручну |
| Шаблони середовищ із підстановкою значень | значення надходять зі змінних середовища та секретів | без перевірки шаблону одрук у імені змінної спливає лише під час запуску |
| Окремий репозиторій конфігурацій | кілька команд і контурів, потрібні рев'ю та історія змін | потребує регламенту доступу й синхронізації з репозиторіями сервісів |
На практиці схеми майже завжди поєднують: базовий набір сервісів тримають в одному файлі, відмінності виносять у накладання, а конкретні значення — у шаблони. Окремий репозиторій конфігурацій виправданий, коли контурів більше двох і зміна перед розгортанням має проходити рев'ю.
Ми вибираємо варіант за кількістю середовищ і частотою правок, а не за звичкою: зайвий шар абстракції тут дорожчий, ніж його відсутність.
Порядок впровадження: від аудиту до передачі
Роботу починаємо не з переписування файлів, а з інвентаризації: compose-файли, файли-накладання для стенда, змінні середовища, зовнішні томи та мережі. Часто відмінність між промисловим і тестовим контуром тримається в голові одного інженера, а не в конфігурації.
- Аудит конфігурації. Склад сервісів, джерела образів, томи, порти, продубльовані параметри. Позначаємо місця, де середовище підміняється вручну.
- Схема середовищ. Базовий файл плюс накладання для стенда й промислового контуру; паролі та токени переходять з репозиторію в окреме сховище.
- Налаштування сервісів. Теги образів, ліміти ресурсів, політика перезапуску, перевірки працездатності, порядок запуску залежностей.
- Перевірка на стенді. Повний цикл: підняття з нуля, оновлення, відкат на попередній тег, падіння окремого сервісу, перезапуск вузла.
- Регламент викочування. Порядок дій, критерії зупинки, читання логів, процедура відкату та дії у разі зміни схеми даних.
- Передача документації. Карта сервісів, схема мереж і томів, опис змінних, інструкції для чергового, чек-ліст типових збоїв.
На виході — відтворюваний процес: однаковий набір команд піднімає стенд і промисловий контур, оновлення та відкат займають хвилини, а знання про устрій не залишається в однієї людини.
Артефакти, що передаються: файли, схеми, регламенти
На виході замовник отримує не налаштований сервер, а комплект, за яким середовище піднімається з нуля на іншій машині та передається новому інженеру без усних пояснень. Нижче — що саме фіксується в репозиторії та документації.
- Файли середовищ — базовий compose-файл плюс перевизначення для staging і production: відрізняються ліміти, томи та адреси зовнішніх сервісів, а не логіка застосунку.
- Список змінних середовища — які обов'язкові, які мають значення за замовчуванням і що подається зі сховища секретів, а не лежить у репозиторії.
- Схема сервісів — карта залежностей: хто з ким спілкується, які порти публікуються назовні, які томи переживають перезапуск контейнера.
- Політики доступу — ролі в репозиторії та панелі керування, хто має право викочувати в production, як видаються й відкликаються доступи.
- Регламент відкату — покроковий порядок у разі невдалого релізу: повернення на попередній образ, точки перевірки стану, за який час середовище приходить у робочий стан.
- Перевірки та спостережуваність — умови готовності сервісу, правила перезапуску, куди надходять логи та алерти, за якими ознаками видно деградацію.
- Інструкції для команди — як підняти середовище на своїй машині, як додати новий сервіс, як збирається та публікується образ.
Комплект оновлюється разом з інфраструктурою: розходження між документацією та фактичним станом середовища перевіряємо на кожному релізі.
Кейс: як два контури перестали розходитися в налаштуваннях
На старті staging і production жили в двох незалежних наборах файлів: різні імена сервісів, свої змінні середовища та томи, перевірки готовності налаштовані лише на проді.
Правки в staging не доходили до production, і перед кожним релізом інженер вручну звіряв конфігурації — звірка займала 40–60 хвилин, а розходження спливали вже на живому трафіку.
Ми звели обидва контури до одного опису на Docker Compose: базовий файл із сервісами, мережами та перевірками готовності, поверх — два файли перевизначення, де відрізняються лише змінні середовища, ліміти ресурсів і політика перезапуску.
Секрети винесені в окремі файли середовища поза репозиторієм, а порядок старту заданий через умови готовності залежностей.
Час викочування скоротився з 45 до 8 хвилин: збірка та запуск ідуть однією командою, ручних кроків на сервері не залишилося.
Кількість інцидентів, пов'язаних з конфігурацією, впала з 5–6 за квартал до нуля за порівнянний період, частка ручних правок під час викочування — з третини до нуля.
Ключовий ефект не в самій автоматизації, а в тому, що staging перестав бути «приблизно схожим» на production. Відкат також описаний конфігурацією: попередній набір запускається тією ж командою, а стан даних зберігається в томах.
Що робити, якщо staging і production уже розійшлися?
Розходження майже ніколи не починається з файлу конфігурації. Воно з'являється з ручних правок на бойовому сервері: виправили змінну, додали том, змінили політику перезапуску — і в репозиторій це не повернули.
Тому спочатку знімаємо фактичний стан працюючих контейнерів і порівнюємо з описаним у файлах: розходження налаштувань на цьому рівні зазвичай ширше, ніж очікують.
Далі фіксуємо джерело істини. Спільний базовий файл описує те, що однакове: образи, залежності, внутрішні мережі, перевірки працездатності, порядок запуску.
Відмінності — адреси, параметри підключення, ліміти, публікація портів, монтування даних — переходять у файли-перевизначення за середовищем. Тоді staging і production відрізняються коротким і передбачуваним списком, а не двома незалежними описами.
План вирівнювання будується за пріоритетами, а не за зручністю правок. Спочатку те, що створює незворотні відмінності: схема даних, міграції, формати файлів, вміст томів — помилка тут найдорожча. Потім конфігурація застосунків і змінні середовища.
Останніми — налаштування виконання: ліміти, політики перезапуску, розміщення сервісів; їхні правки оборотні й застосовуються почерговим перезапуском.
Простій не обов'язковий: сервіси переводимо по одному, перевіряючи результат після кожного кроку. Міграції робимо розширювальними — новий формат спочатку підтримують обидва середовища, і лише потім старе прибирається.
Завершуємо правилом: будь-яка ручна правка на сервері або переноситься у файл, або відкочується, а порівняння середовищ стає регулярною перевіркою під час постачання. Інакше вони розійдуться знову.
Секрети, томи та міграції: часті технічні питання
Секрети в Compose не потрапляють у файл опису сервісів: там залишаються лише імена змінних, а значення підставляє середовище виконання із зовнішнього сховища.
Для стенда й бойового контуру набори різні — адреси, рівні логування, доступи до зовнішніх сервісів, — а логіка запуску одна, тому поведінка збігається.
Дані живуть в іменованих томах, окремо від життєвого циклу контейнера: перезбирання образу або перезапуск сервісу їх не зачіпають, а видалення тому залишається усвідомленою операцією з копією.
Міграції схеми йдуть окремим кроком до старту застосунку — нова версія коду не повинна зустрічати старий стан бази.
Що станеться з даними під час оновлення релізу?
Нічого: томи не перестворюються разом із контейнером. Оновлення підміняє образ, вміст тому залишається на місці. Перед ризикованими міграціями робимо копію та перевіряємо відновлення на стенді.
Чи можна відкотити реліз?
Код — поверненням попереднього тегу образу, це хвилини. Схема бази відкочується лише заздалегідь підготовленим зворотним кроком міграції; якщо він небезпечний — відновленням із копії.
Як розділяються середовища?
Спільний шаблон опису сервісів плюс окремі набори значень для стенда й бойового контуру. Відмінності — параметри підключень і профілі зовнішніх сервісів, а не розбіжні інструкції запуску.
Хто отримує доступ до секретів?
Лише сервіси, яким вони потрібні, і черговий інженер — через журнал доступів. Ротація значень планова: вона не потребує перезбирання образів і не зупиняє роботу середовища.
Обговоримо задачу й повернемося з оцінкою та планом
Оцінку за такою задачею не можна дати «на око» — вона залежить від того, скільки сервісів, як вони пов'язані та що вже автоматизовано. Тому просимо надіслати те, що є: поточні compose-файли, образи інструкцій збірки, змінні середовища без секретів. За ними відразу видно, де залежності вшиті жорстко, а де вже винесені в конфігурацію.
- Схему сервісів і зв'язків: хто з ким спілкується, які томи та мережі спільні, що має бути доступним ззовні.
- Відмінності контурів: чим staging відрізняється від production за ресурсами, репліками, змінними та зовнішніми інтеграціями.
- Як деплой і відкат влаштовані зараз: скрипти, конфігурація безперервної інтеграції, ручні кроки, простій під час викочування.
- Цільову інфраструктуру: кількість хостів, де зберігаються образи, як видаються секрети, обмеження за мережею.
- Роботу з даними: міграції схеми, резервні копії, що не можна втрачати під час перезапуску контейнерів.
- Обмеження: вікна обслуговування, регламенти безпеки, очікувані терміни запуску.
Із цього набору збираємо оцінку робіт, план впровадження за етапами, склад команди та терміни — без припущень, які потім перетворюються на переробки. Якщо частини даних немає, це теж робочий випадок: скажемо, що потрібно зібрати перед стартом. Опишіть задачу — повернемося з оцінкою та планом.
