Сервери, які можна відтворити з нуля

Ситуація. Engineer ApS обслуговує власну інфраструктуру — сайт, git‑сервер, базу даних, резервні копії, пересилання пошти й DNS, — і передати її експлуатацію не було кому. Компанія з однієї людини ламається так само, як велика, але не має жодного резерву, тож звичне рішення — людина, яка пам’ятає, як налаштовано хост, — тут найменш доступне з усіх.

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

Дія. З цього виросли 19 плейбуків і 34 ролі — 12 065 рядків YAML. Структура тут важить більше, ніж обсяг. Склад задають дані, а не прапорці: хост входить до групи свого рівня, і змінні цієї групи оголошують, які ролі на ньому виконуються, тож підготовка хостів (provisioning) без жодних аргументів приводить кожен хост до оголошеного стану. Ідемпотентність — це контракт, а не побажання: після converge хост звітує про нуль змін, а плей, який не може цього гарантувати, ще не завершено. Чотири простори імен команд не дають цим обіцянкам змішатися: гейт, що не торкається жодного хоста; звіти, які читають хост і ніколи його не змінюють; підготовка, що приводить хост у відповідність до репозиторію; і верифікація, яка свідомо змінює хост і повертає вердикт.

Результат. Інфраструктуру можна відтворити з репозиторію, а все, що трималося лише на чиїйсь пам’яті, тепер стало перевірками, які обривають прогін. Ціна відчутна: будь‑яку зміну вносити повільніше, ніж просто відредагувати файл на сервері, а converge, застосований наполовину, гірший за той, що відмовляється виконуватися, — тому згодом перед ним додали попередній плей (preflight). На цей компроміс пішли свідомо, і він себе виправдав.