Підготувала другий сервер із коду

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

Завдання. Машину треба було створювати з репозиторію, і вона мала з’являтися одразу за своїм брандмауером, а не отримувати його трохи згодом.

Дія. Увесь задум тримався на порядку. Плей брандмауера виконується перед плеєм сервера, тож набір правил існує ще до того, як з’являється що захищати; в іншого провайдера теги призначаються до хмарного брандмауера, бо брандмауерові, який вибирає цілі за тегами, потрібно, щоб ці теги вже існували. Брандмауери обох провайдерів налаштовано безпосередньо через їхні REST API за допомогою універсального HTTP‑завдання, а не через колекцію постачальника: так зникає залежність разом із дрейфом її версій, а платою стає ручний опис структури запитів. Роль, що створює машину, підхоплює наявну, якщо та вже є, а не дублює її, тож повторний запуск безпечний. Крім того, в окремому файлі її задокументовано як єдину роль у репозиторії, що витрачає гроші: тип інстансу, регіон, характеристики та щомісячну вартість у євро записано, бо плей, за який комусь виставлять рахунок, має казати про це там, де це прочитають. Саме цей плей і не можна відрепетирувати звичним способом: універсальне HTTP‑завдання не оголошує підтримки режиму перевірки (check mode), тож пробний прогін пропускає в ньому всі завдання. Тому репетицію проводять на плеї брандмауера — це безкоштовно й оборотно.

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