Docker Swarm: що ламається при ручному керуванні контейнерами
Коли сервіси піднімають вручну, кожен запуск — це docker run по SSH або docker compose up на конкретній машині.
Рестарт-політика задана не всюди, тому процес, що впав, просто залишається лежати: контейнер є у списку, порт слухає хтось інший або ніхто, а дізнаєтеся ви про це зі звернень користувачів, а не з моніторингу.
Заодно губиться інвентар — на якому вузлі що живе і яка ревізія образу крутиться, пам'ятає лише той інженер, який це запускав.
Оновлення в такій схемі завжди валить весь сервіс: старий контейнер зупиняють, новий піднімають, і між цими двома кроками сервіс недоступний. Відкат теж ручний — повернути попередній тег образу і повторити ту саму послідовність, з тим самим вікном простою. Чим більше реплік, тим довша пауза, і тим вища ймовірність, що нова версія не підніметься взагалі.
Відмова вузла б'є по всій послузі одразу, якщо репліки не рознесені і немає механізму, який перенесе завдання на живі машини. Відновлення зводиться до того, що хтось заходить на вцілілі сервери і запускає контейнери заново, вручну і з пам'яті.
Стан вузлів при цьому ніхто не бачить: немає єдиної картини, де що розміщено, скільки ресурсів вільно і які завдання не змогли стартувати.
Docker Swarm дає саме ті примітиви, яких бракує при ручному керуванні контейнерами — декларативний опис сервісу, задану кількість реплік, перезапуск завдань, що впали, і перенесення їх з вузла, що вибув.
Далі розбираємо, як це закривається на практиці: що налаштовується до першого docker stack deploy, де вузькі місця і як проходить оновлення без вікна недоступності.
Що дає оркестрація контейнерів: ефект в експлуатації
Служба описується декларативно: скільки реплік тримати, які ліміти за процесором і пам'яттю, чим перевіряти живучість. Далі оркестратор сам підтримує цей стан — контейнер, що впав, перезапускається, а завдання з вузла, що випав, переїжджає на вільний. Клас відмов «сервіс лежить, поки черговий не помітить» зникає з експлуатації цілком.
Час відновлення скорочується з десятків хвилин до секунд. Раніше оповіщення будило інженера, той заходив на сервер і піднімав процес руками; тепер перезапуск і перерозміщення йдуть автоматично, а перевірка живучості не пускає трафік у ще не готовий контейнер.
Простій на планових роботах теж зникає: оновлення котиться по одній репліці, решта продовжують обслуговувати запити.
Відмовостійкість кластера тримається на кворумі керуючих вузлів: поки їх більшість на зв'язку, стан служб зберігається і перерозподіляється. Втрата робочого вузла не валить сервіс — навантаження перетікає на решту машин, а вузол, що повернувся, входить у стрій без ручних дій.
Навантаження на сервери стає передбачуваним: ліміти і резервування не дають одному сервісу з'їсти ресурси сусідів, а розміщення за мітками розводить важкі завдання по різних машинах.
Ми збираємо це на Docker Swarm — оркестрація не тягне за собою окремий шар абстракцій і обслуговується тією ж командою, що і самі сервіси.
Варіанти розгортання кластера: порівняння підходів
Вибір між одним сервером і кластером — це вибір класу відмов, а не розміру навантаження. У Docker Swarm один вузол означає, що зупинка машини кладе всі сервіси до ручного втручання, а оновлення ядра чи перезапуск демона перетворюється на вікно недоступності.
Щойно з'являються вимоги до безперервності, розмова переходить до варіантів з кількома вузлами — і тут важливо заздалегідь зрозуміти, хто експлуатує платформу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один сервер | Навантаження вкладається в один вузол, короткі простої допустимі, важливий швидкий запуск | Точка відмови: падіння машини зупиняє все; немає кворуму керуючих вузлів і реплік між серверами; обслуговування = простій |
| Свій кластер на своїх серверах | Потрібен контроль над ядром, дисковими томами і мережею, є вимоги до розміщення даних | Відмовостійкість керуючих вузлів, оновлення хостів, резервне копіювання стану кластера і чергування — на вашому боці |
| Керований кластер | Своєї команди експлуатації немає, навантаження змінюється, важлива швидкість виходу в продакшн | Обмежений доступ до вузлів і демона, не всі привілейовані режими і хостові томи доступні, прив'язка до API провайдера |
Свій кластер на своїх серверах окупається там, де важливі передбачуваність розміщення і повний доступ до вузлів: три керуючі машини тримають кворум при відмові однієї, робочі вузли додаються під навантаження, а мережа між сервісами будується поверх хостів без зовнішніх посередників.
Керований варіант знімає з команди оновлення і моніторинг, але натомість обмежує низькорівневі налаштування — частина завдань просто не вирішується в його межах.
Тому ми спершу рахуємо профіль навантаження і вимоги до простоїв, а потім обираємо шлях: перевести один сервер у кластер пізніше дешевше, ніж лагодити архітектуру, обрану під чужу модель експлуатації.
Порядок впровадження: від аудиту до передачі в експлуатацію
Впровадження розбито на етапи, і в кожного на виході — артефакт. Так результат відтворюваний і не залежить від того, хто саме вів роботи: від аудиту інфраструктури до передачі в експлуатацію.
- Аудит інфраструктури — інвентаризуємо сервіси, залежності, точки зберігання даних і секретів, доступні вузли і канали зв'язку. Фіксуємо вузькі місця: єдиний вузол під піком, ручні правки конфігурацій, відсутність копій стану кластера.
- Проєктування схеми кластера — визначаємо кількість керуючих і робочих вузлів, кворум, рознесення по зонах, внутрішні мережі і правила доступу між сервісами. Узгоджуємо, що саме має пережити відмову вузла, а що — відмову зони.
- Налаштування сервісів — описуємо служби: кількість реплік, обмеження за ресурсами, перевірки стану, порядок почергового оновлення і повернення на попередню версію. Конфігурації і секрети тримаємо поза образами, щоб середовище піднімалося однаково на будь-якому вузлі.
- Перевірка відмовостійкості — навмисно виводимо вузли з обслуговування, гасимо керуючий вузол, рвемо зв'язок між зонами, даємо пікове навантаження. Дивимося, чи відновлюються репліки самі і скільки займає повернення в норму.
- Навчання команди — показуємо вашим інженерам штатні операції: викатка версії, відкат, масштабування, читання стану кластера, розбір інциденту. Віддаємо регламенти, щоб типові завдання вирішувалися без нас.
- Передача в експлуатацію — віддаємо конфігурації, схему, політики резервного копіювання і моніторингу, інструкції з відновлення. Першу планову викатку проходимо разом з вашою командою і закриваємо роботи за чек-лістом.
Що залишається у вашої команди: конфігурації та регламенти
Усі зміни в кластері залишаються у вигляді файлів і документів у вашому репозиторії, а не в листуванні і не в голові інженера.
Після передачі ви розгортаєте стек, оновлюєте сервіси і відкочуєтеся без нас: у кожного регламенту є команда, очікуваний результат і ознака, за якою видно, що щось пішло не так.
- Файли конфігурації: маніфести стеку з усіма сервісами, мережами, томами і мітками розміщення — розгортання однією командою.
- Схеми: топологія кластера, ролі менеджерів і воркерів, точки входу трафіку і зв'язки із зовнішнім сховищем стану.
- Політики доступу до реєстру образів: хто публікує теги, які образи вважаються перевіреними, як обмежено читання з робочих вузлів.
- Регламент оновлення і відкату: порядок викатки сервісу, перевірка готовності, умови зупинки і повернення на попередню версію без простою.
- Інструкції для чергової зміни: що дивитися при недоступності сервісу, як вивести вузол з ротації і як передати зміну.
- Документація з резервного копіювання: що саме зберігається і як перевіряється відновлення кластера на чистому майданчику.
- Карта моніторингу: які метрики і оповіщення заведені на сервіси, кому вони приходять і на що реагувати в першу чергу.
- Чек-лісти приймання: набір перевірок після правки конфігурації, щоб зміна не пішла в робоче середовище неперевіреною.
Кейс: як скоротили простій служби доставки після збою вузла
Замовник — регіональна служба доставки з власною диспетчерською системою: приймання замовлень, розподіл кур'єрів і трекінг. Застосунок жив на двох серверах, розгортання йшло вручну за інструкцією: зупинити службу, оновити файли, підняти заново, перевірити логи. Поки інженер не завершував перевірки, частина замовлень не приймалася.
Що показували заміри до переходу
Падіння одного вузла зупиняло приймання замовлень на 40-50 хвилин: черговий піднімав службу руками, звіряючи конфігурацію за нотатками в репозиторії.
Випуск оновлення займав близько пів години рутинних кроків, а дрібні розбіжності між серверами призводили до 8-10 ручних втручань на тиждень — від правки змінних середовища до перезапуску завислих процесів.
Що змінили
Зібрали кластер на Docker Swarm з трьох вузлів і перевели застосунок у контейнери з однаковим описом середовища. Ролі розподілили так, щоб керуючі вузли залишалися в кворумі при втраті одного з них, а робочі несли навантаження.
Сервіси отримали health-check і правило перезапуску: завдання, що впало, переплановується на живий вузол без участі людини. Оновлення випускаємо через rolling update — по кілька реплік за раз, з очікуванням готовності і автовідкатом на попередній образ, якщо перевірки не пройшли. Реєстр образів чистимо за правилом зберігання останніх збірок.
Після переходу простій при відмові вузла скоротився до 20-40 секунд — трафік перехоплюють репліки на живих вузлах.
Випуск оновлення займає 3-4 хвилини і не вимагає зупинки приймання замовлень, а кількість ручних втручань знизилася до одного-двох на тиждень: здебільшого планові роботи.
Час від коміту до працюючої версії в кластері скоротився з кількох годин очікування вікна до одного проходу випуску.
Чим Docker Swarm відрізняється від Kubernetes і коли він доречний
Різниця не в тому, який оркестратор «потужніший», а в ціні супроводу.
Docker Swarm — частина движка контейнеризації: кластер збирається з кількох вузлів однією командою, сервіси описуються декларативно (образ, кількість реплік, правила розміщення), а стан керуючих вузлів реплікується між ними.
Kubernetes — окрема платформа з розширюваною моделлю API, власним планувальником і великим набором розширень; її потрібно ставити, оновлювати і обслуговувати як самостійну систему.
На практиці це різниця в ролях і режимі роботи. Swarm закриває мережу між вузлами, оновлення сервісів без простою і перезапуск завдань, що впали, з коробки — супровід тягне один інженер, а резервна копія зводиться до знімка стану керуючих вузлів.
Kubernetes дає тонкі політики розміщення, автомасштабування за метриками і розділення кластера між командами, але натомість вимагає адресації компонентів, перенесення маніфестів при зміні версій API і постійного власника платформи.
| Критерій | Docker Swarm | Kubernetes |
|---|---|---|
| Поріг входу | Кластер з кількох команд, декларація сервісів | Набір маніфестів, ролі доступу, окремі компоненти |
| Супровід | Керуючі вузли реплікують стан самі | Оновлення компонентів і версій API за регламентом |
| Масштаб | Десятки вузлів, однорідне навантаження | Сотні вузлів, кілька незалежних команд |
| Розширюваність | Драйвери мереж і сховищ | Оператори, власні типи ресурсів |
Звідси критерій вибору. При 3-10 вузлах, однорідних сервісах без локального стану і відсутності окремої команди на платформу Swarm дає оркестрацію вбудованими засобами. Якщо сервіс один, оркестратор не потрібен узагалі — достатньо файлу Compose і системного юніта автозапуску.
Kubernetes виправданий там, де кластер ділять кілька продуктових команд, потрібні оператори баз даних і автомасштабування під пікове навантаження.
Ми починаємо з карти сервісів і профілю навантаження: де живе стан, як часто релізи, який простій допустимий. За цими даними видно, де оркестратор надлишковий, а де економія на ньому обернеться ручним чергуванням.
Технічні сумніви: відмовостійкість, оновлення, відкат
Відмовостійкість у Docker Swarm тримається на кворумі керуючих вузлів: поки їх більшість, кластер зберігає стан і продовжує планувати завдання. Нижче — відповіді на сумніви, які найчастіше звучать перед запуском.
Що станеться, якщо вузол вийде з ладу?
Кластер перепланує завдання з втраченої машини на вільні. Сервіс з кількома репліками переживає втрату вузла без зупинки — заздалегідь задаємо правила розміщення і резерв, щоб контейнерам було куди переїхати.
Як оновлення проходить без простою?
Викочуємо почерговою заміною завдань з обмеженим паралелізмом і паузою між партіями: частина реплік завжди залишається в роботі і приймає трафік. Перевірка стану відсікає екземпляри, які не піднялися, — оновлення гальмує на них, а не веде сервіс цілком.
Як відкотити невдалий реліз?
Образи версіонуються, тому повернення — це запуск попередньої версії сервісу, а не перезбирання з вихідників. Налаштовуємо автоматичний відкат при провалі перевірок і репетируємо сценарій на стенді, щоб повернення займало хвилини.
Що входить у підтримку кластера після запуску?
Спостереження за вузлами і сервісами, оновлення самого движка, ротація доступів, резервні копії стану кластера і розбір інцидентів. Плюс планові перевірки: гасимо вузол і дивимося, як кластер відпрацьовує втрату.
Обговоримо задачу: що уточнимо до початку робіт
До оцінки робіт фіксуємо вихідні дані — інакше план впровадження будується на припущеннях і переглядається вже на середині. Нижче те, що розбираємо на першій розмові, щоб обговорити задачу предметно і не повертатися до базових питань.
- Де розміщуються сервіси: власні сервери, приватна хмара чи кілька майданчиків, наскільки стійкий зв'язок між ними.
- Які вимоги до простою: чи допустиме коротке переривання при оновленні, чи навантаження потрібно переносити без зупинки.
- Як влаштовано зберігання даних: де лежать бази і стани, чи потрібна реплікація і резервні копії між вузлами.
- Як випускаються оновлення: скільки середовищ, хто запускає розкатку, чи потрібна автоматизація збірки образів і відкату на попередню версію.
- Як розподілені доступи: хто керує кластером, чи потрібні журнал дій і розділення ролей.
- Хто супроводжує систему далі: своя команда чи підрядник, який обсяг документації потрібен для передачі.
- Що вже працює: чинна конфігурація, минулі спроби, вікна, в які можна вносити зміни.
Якщо сервісів і вузлів небагато, скажемо прямо: складна оркестрація не окупає себе, вистачить простішої схеми.
Відповіді знімають невизначеність до старту — після розмови повертаємося з оцінкою робіт і планом впровадження за етапами, де окремо вказано, що робимо ми і що потрібно від вашого боку.
