Деплой и инфра
Infrastructure as Code: тест с выбором
Суть Синтез по всему модулю IaC в формате с выбором — декларативное желаемое состояние, движок diff в plan/apply, удалённое состояние, locking, drift и иммутабельная инфраструктура.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь модуль. Каждый отражает решение, которое ты принимаешь в терминале во время реального окна изменений, — не определение для пересказа, а компромисс, который надо взвесить, пока прод под наблюдением.
Цель
Убедись, что умеешь связать декларативное желаемое состояние, движок diff в plan/apply, роль файла состояния, locking при конкурентности и обработку drift — синтез, к которому вёл урок.
Викторина
Completed
Твой конфиг объявляет S3-бакет. Ты запускаешь apply один раз, затем ещё раз — без изменений в конфиге и без изменений вне инструмента. Что должно произойти на втором apply и какое свойство это гарантирует?
Heads-up Это был бы императивный скриптинг. IaC сходится к состоянию: записанный файл состояния даёт инструменту увидеть, что бакет уже есть, поэтому изменение не предлагается. Накопление дубликатов — ровно то, что idempotency предотвращает.
Heads-up Инструмент не выдаёт create вслепую — сначала он делает diff против состояния, видит, что бакет уже под управлением, и считает пустой plan. Ни ошибки, ни дубликата.
Heads-up Destroy/recreate происходит только при изменении неизменяемого атрибута. Неизменённый конфиг даёт пустой diff; ничего не трогается.
Викторина
Completed
Коллега спрашивает: 'Зачем вообще держать файл состояния? Просто делай refresh против живого облака каждый раз и diff против него.' Какой самый сильный довод, что файл состояния не опционален?
Heads-up Скорость — побочный плюс, а не суть. plan и apply всё равно делают refresh против провайдера. Незаменимая роль — идентичность: отображение символьных имён конфига на конкретные ID ресурсов.
Heads-up Облачные API безусловно дают чтение — именно так работает refresh. Пробел, который refresh не закрывает, — владение: знать, каким живым ресурсом управляет данный блок конфига.
Heads-up Желаемое состояние живёт в твоём коде .tf / Pulumi под версионным контролем, а не в состоянии. State записывает последнюю известную реальность и отображение id-на-ресурс.
Викторина
Completed
Два CI-джоба запускают `terraform apply` против одного бэкенда с разницей в девять секунд, locking отключён через `-lock=false`. Какой основной режим отказа?
Heads-up -lock=false явно отказывается от лока, который бэкенд иначе бы взял. Без него конкурентные записи гонятся; именно поэтому существует state locking.
Heads-up Это не чистый last-writer-wins. Оба плана считались против движущейся цели, поэтому слитый результат может не описывать никакую реальность — несогласованное, испорченное состояние.
Heads-up Нет межкомандной атомарной транзакции на файле состояния. Гонку предотвращает только явный лок, взятый до записи, — который -lock=false отключает.
Викторина
Completed
CI-прогон упал посреди apply и оставил несвежий лок. Следующий пайплайн быстро падает с `Error acquiring the state lock`. Джуниор хочет сразу запустить `terraform force-unlock` и повторить apply. В чём предостережение сеньора?
Heads-up Ошибка лока может равно означать, что легитимный apply в полёте. Force-unlock такого посреди записи — ровно как испортить состояние. Сначала подтверди, что ничего не пишет.
Heads-up Лок живёт в бэкенде, а не на раннере — перезагрузка ничего не даёт. force-unlock — это поддерживаемый инструмент; дисциплина в том, чтобы сперва убедиться в отсутствии активного писателя, затем сделать plan заново.
Heads-up Это полностью отключает locking и возвращает гонку конкурентности. Исправление — снять один несвежий лок через force-unlock, а не отказаться от locking.
Викторина
Completed
Во время инцидента в 2 ночи коллега вручную поправил правило security-group в консоли, чтобы остановить кровотечение. Код никто не трогал. Рутинный `terraform apply` запускается во вторник утром. В чём опасность и что должно было произойти сначала?
Heads-up Всё наоборот. Всё, чего нет в желаемом конфиге, трактуется как drift для устранения. Ручное правило удаляется, если кто-то сначала не закодифицирует его.
Heads-up Apply не падает на drift — он тихо планирует изменение, примиряющее реальность обратно к конфигу. Эта тишина и есть опасность.
Heads-up Наоборот: ручного изменения нет в конфиге, поэтому apply его стирает. Drift проявляется в plan; исправление — решить намерение и обновить конфиг, когда изменение должно остаться.
Викторина
Completed
Сгенерированный пароль БД попадает в output Terraform, а файл состояния лежит в S3-бакете, который могут читать несколько инженеров. В чём экспозиция и какой правильный паттерн?
Heads-up Пометка output как 'sensitive' лишь скрывает его из вывода CLI; в state он по-прежнему хранится в открытом виде по умолчанию. Читатели бакета всё равно его имеют.
Heads-up Контроль доступа к бакету сужает радиус поражения, но секрет всё равно в state в открытом виде — любой будущий читатель, бэкап или реплицированная копия его утечёт. Не клади его туда вообще.
Heads-up И outputs, и атрибуты ресурсов сериализуются в файл состояния. Именно поэтому пароль, прогнанный через state, доступен любому, кто может его прочитать.
Итог
Сквозная линия: ты объявляешь желаемое состояние, plan делает diff против записанного файла состояния (сначала refresh провайдера), а apply исполняет diff идемпотентно. Файл состояния — карта идентичности, одновременно источник истины и опасность: держи его в версионируемом, залоченном удалённом бэкенде, никогда не прогоняй через него секреты и встречай drift осознанно через plan -refresh-only, решая намерение до того, как apply тихо откатит аварийное исправление. Склоняйся к иммутабельной инфраструктуре, чтобы дрейфить было нечему.