Иммутабельная инфраструктура¶
Серверы как домашний скот, а не домашние питомцы (Pets vs. Cattle)¶
Есть два подхода к управлению инфраструктурой:
- "Домашние питомцы" (Pets) - серверы с именами, за которыми ухаживают, лечат, к которым привязываются.
- "Домашний скот" (Cattle) - серверы с номерами, которых легко заменить на новые. Их потерю никто не заметит.
Иммутабельная инфраструктура реализует второй подход, возводя его в абсолют.
Иммутабельная инфраструктура - это подход, при котором серверы и компоненты инфраструктуры никогда не модифицируются после развертывания. Вместо изменений "на лету" создается новая версия компонента, которая полностью заменяет старую.
Ключевые принципы 1. Версионность и воспроизводимость: каждый сервер содержит метаданные, позволяющие точно определить, из чего он собран и как воспроизвести его в идентичном виде. 2. Детерминированность сборки: если два инженера собирают сервер из одного описания в разное время, результат должен быть бинарно идентичен. 3. Эфемерность: серверы создаются для выполнения конкретной задачи и уничтожаются, когда она завершена или при возникновении проблем.
Иммутабельность дает много полезных удобств: - Предсказуемость и консистентность: "на дев работает, на проде нет" - незадокументированные ручные изменения на проде. Решение: идентичные артефакты на всех средах. Netflix писали о том, что 80% инцидентов в AWS были вызваны конфигурационным дрифтом и после перехода на иммутабельные образы количество инцидентов сократилось на 60%. - Упрощение отката (Rollback): тут понятон, что вместо сложного отката типа $ git revert, $ ansible-playbook rollback.yml, проверка зависимостей... можно просто запустить предыдущую версию: $ terraform apply -var="image_version=v1.2.3". Среднее время восстановления (MTTR) при использовании иммутабельной инфраструктуры сокращается с часов до минут. - Улучшение безопасности: вместо "обнаружена CVE-уязвимость - срочно катим патч на все серверы (а что-то не взлетело, что-то не запустилось, что-то пропустили...) собираем новый образ с протестированным патчем и постепенно заменяем старые уязвимые серверы новыми пропатченными. - и многое другое.
Очень полезно иметь примерно такой дашборд:
┌─────────────────────────────────────────────────────┐
│ Иммутабельная инфраструктура - Общее состояние │
├─────────────────────────────────────────────────────┤
│ Версии в продакшене: │
│ • v2.3.1: 958 инстансов (95,8%) │
│ • v2.3.0: 42 инстанса (4,2%) ← Требует внимания │
│ │
│ Последние развертывания: │
│ • v2.3.1: 15 минут назад, 0 ошибок │
│ • v2.3.0: 3 дня назад │
│ │
│ Автоматическое восстановление (24ч): │
│ • Всего инцидентов: 124 │
│ • Авто-лечение: 122 (98,4%) │
│ • Ручное вмешательство: 2 (1,6%) │
└─────────────────────────────────────────────────────┘
Иммутабельная инфраструктура это не только технология, но и культурный сдвиг:
- инженеры отвечают не за конкретные серверы, а за сервис в целом
- ценность смещается от умения починить любой сервер к умению построить надежную систему
- возможность в любой момент откатить к рабочей версии снижает стресс развертываний
- система восстанавливается сама, не требуя ночных звонков и подъемов
Как заметил один SRE из Google: "Лучшая часть моей работы - наблюдать, как система, которую я построил, автоматически восстанавливается от сбоя, о котором я даже не знал".