← вся теориятеория к собесу · Инфраструктура данных

IaC и конфигурация инфраструктуры

IaC: инфраструктура кодом

Infrastructure as Code описывает кластеры, бакеты, базы и сети кодом в git - с ревью, историей и повторяемостью. Собес проверяет, понимаешь ли ты роль state и что такое дрейф.

Стержень: менять инфраструктуру только через код; ручные правки в консоли создают дрейф, который снесёт следующий apply.

// Формулировки: «зачем IaC вместо консоли?», «что такое terraform state?», «что такое дрейф?».

Terraform: plan, apply, state

IaC описывает инфраструктуру кодом в git: её ревьюят, у неё есть история, она воспроизводима. Кликанье в консоли не воспроизводится и не ревьюится.

Модель Terraform: декларация желаемого → plan (diff против текущего состояния) → apply. State-файл - источник знания о том, что уже создано; его держат в удалённом бэкенде с локами и никогда не в git.

// plan читают перед apply как diff в код-ревью: строка «3 to destroy» на проде должна быть замечена до применения, а не после. CI гоняет plan на каждый PR автоматически.

state: карта соответствия кода и реальных ресурсов
plan / apply: предпросмотр изменений / их применение

Дрейф и окружения

Дрейф - ручные правки в облаке мимо кода. Следующий apply их либо снесёт, либо упадёт на расхождении. Правило одно: менять только через код; руками - только в инцидент, с последующим портированием изменения обратно в код.

Окружения делают модулями: один модуль разворачивает dev, stage, prod с разными параметрами. Копипаста стеков по средам расползается за месяц - правку вносят в две из трёх копий и забывают третью.

// Легализация кликнутого руками - через terraform import, чтобы затащить существующий ресурс под управление кода. Худшее из состояний - «часть в коде, часть руками» параллельно.

drift: расхождение реальности с кодом из-за ручных правок
module: переиспользуемый блок инфраструктуры с параметрами

Ansible и секреты

Terraform создаёт ресурсы, Ansible (конфиг-менеджмент) настраивает существующие машины - пакеты, конфиги, сервисы - идемпотентными плейбуками. Связка классическая: один создаёт, другой настраивает.

Секреты не хранят в state и не кладут в git открытым текстом - им место в vault, менеджерах секретов или sops.

// Важная тонкость: state сам содержит чувствительное (пароли созданных БД, ключи), поэтому доступ к state это фактически доступ ко всей инфраструктуре, и его защищают так же строго.

идемпотентный плейбук: повторный прогон не меняет уже настроенное
Terraform / Ansible: создаёт ресурсы / настраивает существующие машины

Как отвечать: «Что такое дрейф в IaC и как его избегать?»

Дрейф это расхождение между тем, что описано в коде инфраструктуры, и тем, что реально в облаке, возникшее из-за ручных правок мимо кода. Кто-то зашёл в консоль и поменял настройку руками, а в коде этого нет. Опасен он двумя способами: следующий terraform apply либо молча снесёт ручную правку, вернув к коду, либо упадёт на неожиданном расхождении, и то и другое - сюрприз в неподходящий момент. Избегаю просто по правилу: инфраструктуру меняю только через код, plan прогоняю на PR и читаю его как diff, ловя опасные строки вроде replace или destroy до применения. Руками лезу только во время инцидента, когда нельзя ждать пайплайн, но сразу после порчу это изменение обратно в код, чтобы система вернулась в состояние «код - единственный источник правды». А кликнутое исторически легализую через terraform import. Худшее - жить в режиме «часть в коде, часть руками».

Почему это сильный ответ: определён дрейф, названы оба способа, которыми он вредит (apply снесёт/упадёт), и дана дисциплина (только через код, plan-ревью, инцидент с портированием, import).

На чём валят

−State в git или локально у одного инженера - конфликты и потерянная инфраструктура.
−apply не читая plan - «-/+ replace» пересоздал прод-БД.
−Ручной фикс в облаке без порта в код - снесён следующим apply.
−Секрет в tfvars в репозитории - он теперь в истории навсегда.
−Три копии почти одинакового стека по средам вместо модуля - правки в двух из трёх.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

#iac_config1 / 5
Зачем Terraform ведёт файл состояния (state) и чем он важен в команде?
A)State хранит исходный код инфраструктуры, заменяя собой git-репозиторий проекта
B)State нужен для красивого вывода и на вычисление изменений (plan) не влияет
C)State = карта код↔реальные ресурсы для plan; remote+lock для командной работы
D)Файл состояния лучше держать локально у каждого инженера, чтобы они работали независимо
показать ответ и разбор
+C)State = карта код↔реальные ресурсы для plan; remote+lock для командной работы
// разбор: Terraform хранит state — карту между ресурсами в коде и реально созданными объектами (их id, атрибуты). Без него Terraform не знал бы, что уже создано, и не смог бы вычислить разницу между кодом и реальностью (plan) — что создать, изменить, удалить. В команде state держат не локально, а в удалённом бэкенде (S3, Terraform Cloud) с блокировкой (locking), чтобы двое не запускали apply одновременно и не портили состояние гонкой. Ещё есть дрейф: если инфру поменяли вручную мимо Terraform, реальность разойдётся со state — потому ручные правки в IaC-управляемой инфре и не приветствуются.
#iac_config2 / 5
Какие главные выгоды даёт IaC по сравнению с ручной настройкой инфраструктуры?
A)IaC ускоряет работу самих приложений на серверах, оптимизируя их код во время развёртывания
B)Главная выгода IaC — что инфраструктуру больше не нужно нигде описывать, всё создаётся само
C)IaC полезен для очень больших компаний, а для команды из двух инженеров он бесполезен
D)Воспроизводимость, версионирование и ревью изменений, аудит истории и одинаковость сред — инфра поднимается идентично и предсказуемо
показать ответ и разбор
+D)Воспроизводимость, версионирование и ревью изменений, аудит истории и одинаковость сред — инфра поднимается идентично и предсказуемо
// разбор: IaC переносит на инфраструктуру инженерные практики кода. Воспроизводимость: то же окружение поднимается одной командой в любой среде/регионе, а не собирается вручную. Версионирование и ревью: изменения инфры идут через git и pull request — их видно, обсуждают, откатывают. Аудит: история git показывает, кто/что/когда менял. Одинаковость сред: dev, staging, prod из одного кода различаются лишь параметрами — исчезает «на проде другая инфра». Плюс восстановление после аварии (пересоздать из кода) и меньше человеческих ошибок ручного клика. Ценой — кривая обучения и дисциплина не править инфру мимо кода.
#iac_config3 / 5
Как правильно управлять конфигурацией приложения между средами (принцип 12-factor)?
A)Конфиг в env-переменных вне кода — один образ, разные среды
B)Конфигурацию каждой среды нужно хардкодить прямо в код и пересобирать образ под каждую среду
C)Конфиг всех сред держат в одном файле внутри образа, а нужную секцию выбирают флагом при сборке
D)Разницы, где хранить конфигурацию, нет — на переносимость приложения это никак не влияет
показать ответ и разбор
+A)Конфиг в env-переменных вне кода — один образ, разные среды
// разбор: 12-factor предписывает строго отделять конфигурацию (адреса БД, флаги, лимиты, различающиеся между средами) от кода и хранить её в окружении — переменных, подставляемых при запуске (в K8s — ConfigMap/Secret). Тогда один неизменяемый артефакт/образ ведёт себя по-разному в dev/stage/prod в зависимости от подставленного конфига, без пересборки и без хардкода. Захардкоженные в код параметры среды (прод-хост БД прямо в файле) ломают переносимость и опасны (особенно секреты). Правило: код одинаков везде, различия — только в конфиге из окружения.
#iac_config4 / 5
Зачем нужен отдельный менеджер секретов (Vault, secret manager), а не просто env-переменные?
A)Секрет-менеджер нужен чтобы хранить секреты в открытом виде в одном общем файле
B)Централизованное хранение/ротация/аудит/контроль доступа к секретам
C)Env-переменные решают все задачи с секретами, отдельный менеджер не даёт нового
D)Менеджер секретов — это то же самое, что git-репозиторий, с паролями вместо кода
показать ответ и разбор
+B)Централизованное хранение/ротация/аудит/контроль доступа к секретам
// разбор: Простые env-переменные и файлы плохо масштабируются для секретов: их трудно ротировать, они оседают в конфигах, логах, истории, и непонятно, кто к чему имеет доступ. Секрет-менеджер (HashiCorp Vault, облачный Secret Manager) решает это: централизованно хранит секреты (зашифровано), выдаёт их приложениям по политикам доступа (кто что может), ведёт аудит обращений, поддерживает ротацию и короткоживущие (dynamic) секреты, выдаваемые на время. Так секрет не разбросан по средам, а его утечку/отзыв легко локализовать. Для дата-платформы с множеством подключений к источникам это управляемость и безопасность доступов.
#iac_config5 / 5
Как контейнеры и IaC вместе обеспечивают воспроизводимое окружение dev == prod?
A)Воспроизводимость целиком обеспечивает только Docker, инфраструктура на неё никак не влияет
B)Dev и prod не получается сделать идентичными, поэтому различия окружений неизбежны и нормальны
C)Образ фиксирует зависимости приложения, IaC — окружающую инфраструктуру; вместе они поднимают идентичное окружение в любой среде из кода
D)Для воспроизводимости достаточно одинаковых версий кода в git, окружение роли не играет
показать ответ и разбор
+C)Образ фиксирует зависимости приложения, IaC — окружающую инфраструктуру; вместе они поднимают идентичное окружение в любой среде из кода
// разбор: Воспроизводимость складывается из двух слоёв. Docker-образ фиксирует само приложение и его зависимости (версии библиотек, интерпретатора) — оно одинаково запускается везде. IaC (Terraform/K8s-манифесты) фиксирует инфраструктуру вокруг: сколько узлов, какие сети, кластеры, ресурсы, конфиг. Вместе они дают окружение, поднимаемое из кода идентично в dev, staging и prod — исчезает «на моей машине работает» и «на проде инфра другая». Различия между средами сводятся к параметрам (размер кластера, конфиг), а не к неучтённым ручным настройкам. Это фундамент предсказуемых развёртываний.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Инфраструктура данных