Миф: Infrastructure as Code нужен только большим командам

MAATRIX

«У меня один VPS и один сайт, зачем мне Terraform» — фраза, которую слышишь от соло-разработчиков и владельцев маленьких проектов почти дословно одинаковой. Звучит логично: Terraform и Ansible ассоциируются с десятками серверов, инженерными командами и сложными пайплайнами, а тут — один сервер, который вы настроили сами и который просто работает. Проблема в том, что польза от Infrastructure as Code не появляется резко на пятидесятом сервере — она начинается с первого, просто на маленьком масштабе её не замечают, пока не наступает момент, когда сервер нужно восстановить по памяти.

Откуда берётся миф про «это не для меня»

Миф держится на реальном наблюдении: контент про IaC действительно в основном рассчитан на команды. Статьи и доклады про Terraform часто рассказывают про мультирегиональные развёртывания, модули с десятками переменных, отдельные окружения dev/stage/prod и код-ревью инфраструктурных изменений в пул-реквестах. Если у вас один сервер под личный проект, это выглядит как оверинжиниринг — и в таком объёме им бы и было.

Здесь смешиваются две разные вещи: сам принцип (конфигурация описана в файлах, а не введена руками и держится в голове) и конкретный инструментарий уровня enterprise (модули, роли, состояние в удалённом backend, CI/CD для инфраструктуры). Миф превращает вторую часть в обязательное условие первой. На деле принцип работает и на одном сервере с одним плейбуком на тридцать строк — просто выглядит гораздо скромнее, чем то, что показывают на конференциях.

Второй источник мифа — субъективная оценка риска. Пока сервер один и настраивали его лично вы, кажется, что риска нет: «я помню, что делал». Это работает ровно до первого случая, когда сервер нужно восстановить не вам, не сразу, или через полгода, когда память уже не такая свежая. У одного сервера риск потери контекста ничуть не ниже, чем у пятидесяти — просто цена ошибки меньше в абсолютных числах, и поэтому её проще не замечать.

Цена ручной настройки, пока всё «просто работает»

Ручное администрирование не платит по счетам сразу — оно накапливает скрытый долг, который выставляется в момент, когда меньше всего этого ждёшь. Три сценария, с которыми рано или поздно сталкивается почти любой, кто держит сервер вручную:

• Сервер упал или хостер мигрировал вас на новое железо. Нужно поднять всё заново: тот же nginx, те же правила firewall, та же версия рантайма, тот же список systemd-юнитов. Если конфигурация только в голове — вы восстанавливаете её методом «вроде вспомнил», и часть настроек неизбежно теряется или воспроизводится чуть иначе.
• Понадобился второй сервер. Второй регион, staging для тестов перед продакшеном, резервный узел на случай аварии первого. Ручная синхронизация двух серверов «на глаз» держится месяц-два, а потом они расходятся — на одном обновили пакет, на другом забыли, и вы узнаёте об этом в худший момент.
• К проекту подключился кто-то ещё. Даже если это не наёмный сотрудник, а фрилансер на разовую задачу или сооснователь — единственный источник знаний об инфраструктуре до этого момента был у вас в голове, и передать его словами за один созвон почти невозможно.

Ни один из этих сценариев не про масштаб команды. Они про время: рано или поздно конфигурация, которую держали в памяти, понадобится воспроизвести — себе самому, но в других обстоятельствах.

Воспроизводимость: главная выгода даже для одного сервера

Воспроизводимость — это способность получить идентичный результат повторно, не полагаясь на память. Для команды из полусотни инженеров это про масштабирование. Для одного разработчика с парой серверов — про время восстановления после аварии и цену переезда.

Представьте реалистичный случай: VPS с вашим проектом отваливается ночью, хостер сообщает о проблеме с железом и предлагает поднять новый сервер вместо старого. Без IaC это означает: зайти по SSH на новую машину, вспомнить и переустановить пакеты, восстановить конфиги nginx или Caddy, поднять базу данных с нужными параметрами, настроить firewall, добавить SSH-ключи, восстановить cron-задачи. Час-два работы в стрессе, и есть шанс что-то упустить — например, забыть один заголовок в конфиге reverse-proxy, который был добавлен полгода назад ради конкретного edge case и с тех пор о нём никто не вспоминал.

С IaC та же ситуация выглядит иначе. Если базовая настройка сервера описана Ansible-плейбуком:

- hosts: new_server
  become: true
  roles:
    - base-setup      # пользователь без root, SSH-ключи, обновления
    - firewall         # UFW/nftables правила
    - docker           # установка Docker + docker-compose
    - nginx-proxy       # reverse-proxy с вашими конфигами из репозитория

Вы прогоняете один плейбук на свежем сервере — и получаете тот же результат, что и на первом, без ручного повторения десятка шагов по памяти. Это не гарантирует нулевой простой (данные всё равно нужно восстановить из бэкапа, DNS всё равно нужно переключить), но сокращает время восстановления инфраструктурной части с часов до минут и убирает человеческий фактор именно из той части процесса, где ошибки цепляются друг за друга. Про план действий на случай именно такой аварии у нас есть отдельный разбор — disaster recovery plan для малого бизнеса, где IaC — только одна из частей, наравне с бэкапами и инструкцией восстановления.

Второй практический случай — переезд, не обязательно аварийный. Хочется сменить хостера, перенести сервер в другую локацию или просто обновить систему на новом VPS вместо накопившихся полутора лет патчей поверх патчей. С воспроизводимой конфигурацией это плановая задача на вечер: поднять новый сервер, прогнать код, переключить DNS. Без неё — это тот проект, который откладывается месяцами, потому что «сначала нужно разобраться, что вообще сейчас настроено».

Конфигурация как документация: git вместо головы администратора

У ручной настройки почти никогда нет документации, которая не устаревает. Даже если вы честно ведёте заметки в Notion или текстовом файле, они начинают расходиться с реальностью с первого же изменения, внесённого «по-быстрому» без записи. Через полгода заметки врут примерно так же уверенно, как молчание.

IaC-код в этом смысле не является отдельной документацией, которая может устареть — он и есть текущая конфигурация. Если в плейбуке написано, что порт 8080 проброшен наружу, значит он проброшен, потому что именно этот код применили последним. Расхождение возможно только в одном случае — если кто-то поменял что-то руками в обход кода, и это отдельная дисциплина, о которой ниже.

Практический эффект — история изменений. git log по репозиторию с конфигурацией сервера отвечает на вопросы, на которые раньше приходилось искать ответ в переписке или вспоминать самому:

git log --oneline -- roles/nginx-proxy/
a4f21c3 добавить лимит на размер тела запроса для /upload
9b0e77a вернуть старый таймаут — 30s резал долгие апдейты
2d1a980 добавить security-заголовки после аудита

Каждая строчка — это не просто факт изменения, а обычно ещё и причина, если коммиты писать по-человечески. Через год вы не гадаете, зачем в конфиге стоит нестандартный таймаут — открываете коммит и видите объяснение. Ручная настройка такой истории не оставляет: в лучшем случае остаётся комментарий в самом конфиге, который со временем тоже теряет контекст.

Это же касается передачи проекта. Если вам нужно нанять DevOps-фрилансера на разовую задачу или передать инфраструктуру партнёру, репозиторий с IaC-кодом — это готовое описание системы, которое можно прочитать за час, вместо созвона, где вы пытаетесь вспомнить и надиктовать всё, что настраивали за последний год.

Меньше ручных ошибок в редких, но критичных изменениях

Есть особая категория изменений, которая вредит непропорционально своей частоте: то, что делается редко, но имеет высокую цену ошибки. Обновление правил firewall, смена SSL-сертификата, миграция базы на новый диск, правка конфигурации reverse-proxy для нового домена. Такие задачи выполняются раз в несколько месяцев, а то и раз в год — и именно поэтому в них чаще ошибаются: рутинные операции руки помнят, редкие — нет.

Классический случай — правка firewall вручную через SSH:

# Открыть порт для нового сервиса, забыв про порядок правил
ufw allow 5432/tcp
# Через месяц: "а почему база данных доступна из интернета?"

Дело не в том, что ufw allow — плохая команда. Дело в том, что при ручном вводе легко забыть контекст: что это правило временное для отладки, что порт должен быть открыт только для одного IP, а не для всех. В плейбуке то же правило описывается вместе с намерением и живёт в ревью:

- name: Разрешить доступ к PostgreSQL только с бэкенд-сервера
  ufw:
    rule: allow
    port: '5432'
    proto: tcp
    src: "{{ backend_server_ip }}"

Прочитать такое правило через полгода и понять, что оно означает и зачем существует, — секундное дело. Восстановить логику из голого ufw allow 5432/tcp в истории команд — уже нет.

То же самое с обновлениями системы. Ручное «зашёл, накатил apt upgrade, что-то не завелось, откатывал наугад» — сценарий, который для одного сервера случается регулярно именно потому, что обновления делаются нечасто и вы каждый раз немного забываете нюансы предыдущего раза. Если процесс описан кодом (даже простым bash-скриптом, который логирует шаги и делает снапшот перед обновлением), ошибка воспроизводимого действия хотя бы предсказуема — а не зависит от того, что вы вспомните в моменте.

Разумный порог входа: когда хватит скрипта, а когда нужен Terraform

Здесь стоит признать честно: не всегда нужен полноценный Terraform с удалённым state, модулями и отдельным CI для инфраструктуры. Для одного-двух серверов это часто действительно избыточно — время на освоение и поддержку такой обвязки может не окупиться. Но из этого не следует, что для маленького проекта не нужно вообще ничего — просто порог входа нужен свой, а не скопированный из статьи про инфраструктуру на полсотни серверов.

Разумная лестница усложнения выглядит так:

Минимальный полезный шаг — даже не Ansible, а просто хранение конфигов в git вместо того, чтобы они существовали только на сервере. Скопировать /etc/nginx/nginx.conf, docker-compose.yml и список установленных пакетов в отдельный репозиторий — уже даёт часть выгоды: историю изменений и возможность посмотреть, что было раньше, без доступа к самому серверу. Мы показывали, как устроен этот путь целиком — от одного плейбука до системы — в статье Infrastructure as Code: с чего начать. Если решите начать с Ansible, есть пошаговая установка на практике — Ansible на Ubuntu 24.04; если ближе декларативный подход к самим серверам — основы Terraform для VPS.

Важна и обратная граница: не стоит внедрять полный набор инструментов только потому, что «так правильно». Terraform ради одного сервера, который не пересоздаётся годами, — это время на изучение state-файлов и backend без реальной окупаемости. Здесь миф работает в обе стороны: одни решают, что IaC им вообще не нужен, другие — что нужен сразу максимальный набор enterprise-инструментов. Оба решения одинаково нерациональны, если не отталкиваться от реального размера задачи.

Частые вопросы