Legacy-часть инфраструктуры компании представляет собой долгоживущие серверы, конфигурация которых поддерживается регулярными прогонами Ansible playbook (каждую ночь "подгоняющими" состояние серверов к желаемому), и команда рассматривает переход к иммутабельной модели (пересборка образов и замена серверов целиком вместо точечного исправления). Какие риски и выгоды несёт такой переход, и почему для части legacy-системы полный переход может быть неоправдан?

Короткий ответ

Иммутабельная модель (сборка нового образа при каждом изменении и замена инстансов, а не патчинг на месте) устраняет накопленный configuration drift между серверами и делает откат предсказуемым (просто разворачивается предыдущий образ), но требует, чтобы приложение переносило потерю локального состояния при пересоздании инстанса (externalized state, graceful shutdown, время на прогрев), и плохо подходит для систем, где локальное состояние на сервере тяжело или невозможно извлечь (например, старые монолиты с файловым хранилищем на диске без плана миграции на внешнее хранилище) без дополнительной архитектурной работы.

Как это работает подробнее

при текущей модели Ansible playbook выполняется регулярно и приводит состояние к желаемому "по верху" уже работающего сервера, что со временем накапливает незамеченный drift в местах, не покрытых playbook (вручную поставленные пакеты, файлы, оставленные при инцидентах), и этот drift обнаруживается только когда playbook случайно это трогает или происходит инцидент; иммутабельная замена целиком устраняет такой накопленный drift просто потому, что новый инстанс собирается с нуля из зафиксированного образа.

Сравнение

• Компромисс. Полный переход на иммутабельную модель даёт сильную гарантию отсутствия drift и предсказуемый откат, но стоит дорого для систем с тяжёлым локальным состоянием и требует архитектурных изменений в самом приложении; сохранение модели continuous configuration management дешевле в моменте, но несёт риск накопленного drift и более сложного disaster recovery (нужно восстанавливать состояние сервера, а не просто разворачивать образ). Решение должно оцениваться по остаточному жизненному циклу системы и стоимости рефакторинга state-зависимых частей, а не по общей моде на иммутабельность.

Пример кода

example.txtКопировать

Было:  server (живёт месяцы/годы) --(каждую ночь)--> ansible-playbook приводит к желаемому состоянию
Стало: image build (CI) --(pipeline)--> новый instance --(health check OK)--> переключение трафика
                                                     --> старый instance удаляется
# compromise-шаг: усилить обнаружение drift без полного перехода на immutable
- hosts: legacy_app
  gather_facts: false
  tasks:
    - name: Report drift without changing anything
      ansible.builtin.command: true
      check_mode: true

Что использовать на практике

• Практика. для части legacy-системы стоимость рефакторинга приложения под stateless/иммутабельную модель (вынос состояния, доработка graceful shutdown, пересмотр процедур бэкапа) может быть выше, чем выгода от устранения drift, особенно если система стабильна и близка к концу жизненного цикла; в этом случае разумнее продолжать модель с continuous configuration management, но усилить именно обнаружение drift (периодические отчёты Ansible в check-mode, алерты на незапланированные изменения) вместо полного архитектурного перехода.

Подводные камни

• Ошибка. Не выполняйте изменение без проверки плана, резервной копии состояния и понятного способа отката; для production согласуйте окно работ и исключите параллельные операции.