💻 IAC

Infrastructure as Code — способ управлять ИТ-инфраструктурой с помощью кода: описывать серверы, сети, хранилища и окружения в файлах, хранить их в репозитории и применять изменения автоматически.

Status: In progress

1. Проблематика

Infrastructure as Bash History

«Как установить сервер?» — «Смотри в моей .bash_history за прошлый вторник.»

Настройка = череда apt install, sed, systemctl без зафиксированного описания.

Проблемы:

• невоспроизводимость на другом хосте
• нет версионирования и аудита «кто что менял»
• хрупкость: одна ошибка в цепочке ломает всё неочевидно

Дрифт конфигураций (Configuration Drift)

Постепенное расхождение текущего состояния сервера с желаемым (из кода или эталона).

Почему бывает:

• ручные правки мимо автоматизации
• обновления не на всех узлах одинаково
• автоматизация покрывает не всё

Последствия: сбои, сложная отладка, серверы превращаются в «снежинки».

Серверы-снежинки (Snowflake / Pets)

Уникальные, часто вручную накопленные конфигурации. Каждый хост «особенный».

Проблемы: не восстановить 1:1 после аварии, трудно масштабировать, тяжело сопровождать.

Серверы-фениксы (Phoenix / Cattle)

Взаимозаменяемые узлы: конфиг в коде, хост можно уничтожить и поднять заново через Ansible / Terraform / образ.

Плюсы: воспроизводимость, масштабирование, быстрая замена при сбое.

Практики улучшения

• переиспользование и переменные вместо «магических» констант в коде
• атомарные задачи
• VCS, code review, тесты — как у обычного ПО

2. Выгоды IaC

Снижение затрат

Один инженер через код ведёт много машин; рутина автоматизируется; облако можно гасить, когда не нужно (например, через Terraform).

Скорость

Среды и серверы поднимаются за минуты по одному описанию; изменения на парке узлов — согласованно; восстановление ближе к «пересоздать феникс».

Меньше рисков

Меньше ручных опечаток; желаемое состояние в коде; откат и ревью через Git; меньше дрифта при дисциплине применения.

3. Паттерны

Идемпотентность

Операция идемпотентна, если повторный запуск даёт тот же результат и не ломает уже настроенную систему.

В IaC это база декларативных инструментов: можно смело гонять playbook / apply снова.

Пример Ansible:

- name: Установить Nginx
  apt:
    name: nginx
    state: present

• уже установлен → ничего не меняет
• нет → установит
• повторный запуск → снова «Nginx есть»

Кратко: Ansible — конфиг серверов (модули), Terraform — инфраструктура (API + state), Kubernetes — желаемое состояние нагрузки (контроллеры + манифесты).

Императивный подход

Описываешь как — шаги по порядку.

apt-get update
apt-get install -y nginx
systemctl start nginx
echo "Привет" > /var/www/html/index.html

Плюсы: просто, полный контроль, без тяжёлых инструментов. Минусы: плохо масштабируется, нет сверки с текущим состоянием, легко накопить ошибки.

Декларативный подход

Описываешь что должно быть; инструмент сам сходится к состоянию (обычно идемпотентно).

- hosts: webservers
  tasks:
    - name: Установить Nginx
      apt:
        name: nginx
        state: present
    - name: Nginx запущен
      service:
        name: nginx
        state: started
        enabled: true

Плюсы: масштаб, повторные прогоны, меньше сюрпризов. Минусы: нужно учить инструмент, меньше контроля над каждым шагом.

4. Push и Pull

Push

Управляющий узел сам применяет конфиг к целям (SSH, API).

Примеры: Ansible по SSH, Terraform → API облака.

+ быстро, часто без агента (Ansible) − нужен доступ до узлов / API, на очень больших парках сложнее

Pull

Агенты на узлах сами забирают конфиг с центра.

Примеры: Puppet Agent, kubelet ← API Kubernetes.

+ лучше масштаб, узлы автономнее − нужны агенты, возможна задержка цикла pull

5. Карта инструментов

Инструмент	Push / Pull	Подход	Зачем
Ansible	Push (SSH)	Declarative (playbooks)	Конфиг ОС и приложений
Ansible ad-hoc	Push	Imperative	Разовые команды
Terraform	Push (API)	Declarative	Облачная / DC инфраструктура + state
Kubernetes	Pull (kubelet)	Declarative	Поды, сервисы, желаемое состояние кластера
Puppet	Pull (agent)	Declarative	Долгоживущий CM на агентах
SaltStack	Push / Pull	Dec / Imp	Гибкий CM, reactor-события

Подробный разбор playbooks — в разделе ANSIBLE.

6. Управление конфигурациями (кратко)

Цели CM: контроль изменений, управляемый жизненный цикл, предсказуемое качество.

На примере Ansible:

Задача	Как проявляется
Идентификация	inventory, playbooks, роли в Git
Контроль	идемпотентные модули, повторный прогон безопасен
Учёт состояния	facts (setup)
Процесс разработки	Git + CI (Jenkins, GitLab CI…)
Сборка / окружения	одни playbooks, разные -e target=… / inventory

ansible-playbook deploy.yml -e "target=webservers_dev"
ansible-playbook deploy.yml -e "target=webservers_prod"

Вопросы

В разработке..