От голого железа до боевого сервера: инфраструктура как код без доступа к экрану

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

Мой подход — противоположный: описать весь сервер кодом и дать ему развернуться самому — от голого железа, где на руках только аварийная консоль восстановления, до боевого сервера, одной командой, без человека у экрана. Это инфраструктура как код, доведённая до логического предела, а чтобы доказать, что метод работает, я построил его на самом трудном случае, какой смог найти. Ниже — как это устроено и почему это важно, если результат оплачиваете вы.

Метод важнее платформы

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

• Самые тяжёлые условия — голое железо. Мой пример — Hetzner: на руках только физический сервер и аварийная консоль (панель Robot плюс Rescue System). Нет удобной облачной консоли, установки в один клик, готовых образов, службы метаданных — полная противоположность AWS EC2, где готовую машину подают на блюде. Я всё равно дохожу до боевого сервера автоматически. Провайдер не важен: тот же метод работает на любом голом железе — Hetzner здесь просто удобный пример.
• Самая трудная платформа — VMware ESXi. Я специально выбрал ESXi как самую неудобную для автоматической установки систему: проприетарная, только UEFI, по-настоящему недружелюбная без человека за клавиатурой. Раз я сажаю даже её на голое железо без консоли, то Proxmox VE или любой другой гипервизор и любая открытая система ставятся тем же методом элементарно.
• Самое трудное приложение — Veeam на Windows. Резервное копирование на Windows — это лишь пример полностью автоматической установки и настройки приложения в самой неудобной для него среде. На Linux тем же подходом ставится и настраивается что угодно, и там это совсем просто.

«Руками или Terraform» — неправильный вопрос

Об автоматизации инфраструктуры спорят так, будто есть только два варианта — делать руками или загнать всё в Terraform. Но так вопрос не ставится. Установка bare-metal-гипервизора и управление виртуальными машинами — разные слои, и каждый автоматизируется своим инструментом. Смешаешь их — либо переусложнишь то, что должно быть простым, либо оставишь в чьей-то памяти то, что должно быть кодом.

• L0 — система на голое железо. Живёт ниже API, на уровне аварийной консоли, поэтому Terraform сюда не дотягивается. Управляется без экрана — через Robot API провайдера и одноразовую виртуальную машину с файлом автоматической установки.
• L1 — базовая настройка хоста (mgmt-сеть, NTP, SSH, syslog, хранилища, виртуальные коммутаторы, безопасность): работа Ansible, идемпотентно, напрямую на отдельном хосте.
• L2 — сеть (роутер-VM, дополнительные IP, межсетевой экран): конфигурация как версионируемый код, который живёт внутри самого роутера.
• L3 — виртуальные машины (создание, клонирование, диски, сетевые карты): вот здесь Terraform и окупается.

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

Конвейер установки — это инфраструктура как код

Весь путь описан кодом и собран в единый конвейер: Terraform задаёт виртуальные машины, Ansible разворачивает настройку и приложения, идемпотентные сценарии (их можно безопасно запускать сколько угодно раз) готовят сам сервер, а межсетевой экран хранится как версионируемый код. Одна команда — от аварийной консоли до работающего сервера. И это не тупые макросы, вслепую повторяющие нажатия: каждый шаг проверяется по контрольным спискам и тестам, и сервер не идёт дальше, пока текущий этап не подтверждён.

Как это работает — без доступа к экрану

• Система ставится без монитора и клавиатуры. Robot API переводит сервер в режим восстановления, а установка идёт из одноразовой виртуальной машины qemu прямо на физический диск — файл kickstart для ESXi, autounattend — для Windows.
• Роутеры и виртуальные машины разворачиваются через govc по vSphere API — без экрана. Установщик OPNsense управляется автоматически по последовательному каналу через промежуточный сервер, а его конфигурация внедряется без пароля.
• Вся сеть — за один заход. Раз я работаю на уровне аварийной консоли и гипервизора, то поднимаю всю сеть в один прогон: и внутреннюю (интранет между виртуальными машинами), и внешнюю — маршрутизацию, доступ наружу и межсетевой экран на роутере OPNsense. В том числе VLAN, VPN, изолированные сегменты и защищённые каналы между площадками.
• Приложения настраиваются внутри гостевой системы через govc guest.run — даже когда SSH и WinRM наглухо закрыты межсетевым экраном. Готовность ловится по сигналу VMware Tools и появлению IP-адреса, поэтому конвейер никогда не гадает, поднялась ли гостевая система.

Надёжность, тесты и управление парком

• Идемпотентность — простыми словами. Один и тот же сценарий можно запускать сколько угодно раз без вреда: он не ломает уже настроенное, а приводит сервер к нужному состоянию независимо от того, в каком тот был. Настройка «уехала» или сам сценарий обновился — просто прогоняю ещё раз, и всё сходится к правильному результату. Никакого «поставил один раз и молись».
• Тесты на каждом шаге. Сценарии сами проверяют известные проблемы, и набор проверок постоянно растёт — каждый разбор инцидента добавляет новую проверку прямо в код, поэтому тот же сбой больше не проходит незамеченным. А каждый готовый сервер проходит автоматический нагрузочный тест (сеть, диски, процессор, задержки) с отчётом.
• Правки на весь парк сразу. Исправил один раз — и идемпотентно прогнал по всему парку одной волной.
• Откат под контролем. Любое изменение можно откатить: вернуться к предыдущей заведомо рабочей версии в git и накатить её заново, откатить виртуальную машину на снимок, сделанный перед обновлением, или пересобрать сервер из кода с нуля. Данные откатываются отдельно — снимками и резервными копиями, а не самим кодом.
• Домены и сертификаты — сразу и правильно. Все домены ведутся корректно с самого начала, а настоящие TLS-сертификаты Let’s Encrypt выпускаются и продлеваются автоматически — сайты и панели сразу открываются по HTTPS без предупреждений. Работает в любой сети, в том числе за закрытым межсетевым экраном, через вызов ACME DNS-01.
• Безопасность прежде всего. Секреты зашифрованы GPG на аппаратном ключе YubiKey; открытый текст никогда не попадает в репозиторий.

Никакого «чёрного ящика»: проверяемость и прозрачность

Самый большой плюс подхода — не скорость, а то, что заказчик получает полностью проверяемую и прозрачную установку вместо «чёрного ящика», который приходится принимать на веру.

• Всё живёт в git. Конфигурация, сценарии и описание инфраструктуры хранятся в системе контроля версий: у каждого изменения видно, кто, что и когда поменял; можно вернуться к любой прошлой версии, сравнить любые две и провести проверку кода перед применением. Git — единый источник правды и основа и для аудита, и для отката.
• Я сам проверяю всю развёртку. Не «сдал и забыл» — каждый сервер довожу и проверяю от начала до конца, а перепроверить за мной может любой по коду.
• Код вычитывают сторонние эксперты. Привлекаю к разбору внешних экспертов, поэтому решение проходит не одну пару глаз.
• Нет человеческого фактора. Машина выполняет один и тот же путь одинаково — без усталости, забытых галочек и «сделал по-своему». Люди заняты проверкой и разбором, а не ручным вводом, где и рождаются ошибки.
• Доработки — отдельными обновлениями. Любое улучшение или исправление выходит отдельным обновлением и идемпотентно раскатывается на весь парк — видно, что именно оно меняет.
• Двойное тестирование. Сначала проверяется сама конфигурация, затем всё развёртывание прогоняется на тестовой среде — и только потом попадает на рабочие серверы.
• Документация, которую действительно можно читать. Основной язык — английский, ключевое для администраторов дублируется на русский, при необходимости адаптируется на любой язык.
• Всё поддаётся аудиту. И первичная установка, и каждое последующее обновление зафиксированы в коде и журналах — любой шаг можно поднять и перепроверить. Вы видите полную картину: что ставится, как проверено и что меняет каждое обновление.

Технологии

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

Инструмент	Что это и что даёт
git	Система контроля версий — здесь весь код и конфигурация. Полная история (кто, что, когда), возврат к любой версии, проверка кода. Единый источник правды.
Terraform	Описывает саму инфраструктуру как код — какие виртуальные машины и ресурсы нужны — и создаёт их по этому описанию.
Ansible	Описывает нужное состояние серверов и приложений (настройки, установленный софт) и приводит систему к нему.
VMware ESXi / Proxmox VE	Гипервизор. ESXi — самый трудный пример; Proxmox и любой открытый ставятся тем же методом.
OPNsense	Маршрутизатор и межсетевой экран отдельной виртуальной машиной — здесь живут сложная маршрутизация трафика, проксирование и VPN.
govc	Управление виртуальными машинами по vSphere API — без консоли.
qemu (в режиме восстановления)	Временная виртуальная машина в аварийной среде, чтобы поставить систему на голое железо.
kickstart / autounattend	Файлы автоматической установки системы без человека (Linux · ESXi · Windows).
Let’s Encrypt	Бесплатные TLS-сертификаты через ACME DNS-01 с автоматическим продлением.
GPG + YubiKey	Секреты шифруются на аппаратном ключе — открытый текст не попадает в репозиторий.
Veeam	Пример приложения, которое ставится и настраивается полностью автоматически (Windows).

Почему это важно, если платите вы

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

Так я и веду инфраструктуру как fractional CTO — тем же подходом от первых принципов, что и при оценке зрелости IT-департамента: не как услугу, которую нельзя проверить, а как прозрачный, поддающийся аудиту актив, которым владеете вы. Если хотите применить это к своим серверам — напишите мне здесь.

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

Не избыточно ли полностью автоматизировать установку из двух серверов?

Окупается не первая установка — для одной машины кликнуть быстрее. Окупается всё, что после: повторяемость, аудит, откат и обновления на весь парк. Метод масштабируется с двух серверов до двухсот без изменений, а пересборка с нуля стоит одной команды, а не потерянного дня.

Почему VMware ESXi, если это самый трудный случай?

Именно потому, что самый трудный. Докажи метод на худшей для автоматической установки системе — и всё остальное становится лёгким. Метод не привязан к VMware: Proxmox VE или любой другой гипервизор встаёт в тот же конвейер, а весь набор может быть целиком на открытом коде.

Не привязывает ли это меня к Hetzner или VMware?

Нет. Hetzner и ESXi — намеренно выбранные трудные примеры, а не требования. Тот же принцип работает на любом голом железе у любого провайдера, и у каждого проприетарного куска есть открытая замена в том же конвейере.

Как вы ставите систему без доступа к консоли?

Robot API переводит сервер в режим восстановления, а установка идёт из одноразовой виртуальной машины qemu прямо на физический диск по файлу автоматической установки (kickstart для ESXi, autounattend для Windows). Дальше управление берёт govc по vSphere API — по-прежнему без экрана.

Источники и инструменты

• Terraform и Ansible — инфраструктура и конфигурация как код.
• VMware vSphere / ESXi и Proxmox VE — слой гипервизора; Proxmox без участия человека на голом железе.
• govc (govmomi) — управление vSphere по API, без консоли.
• OPNsense — роутер и межсетевой экран отдельной VM.
• Hetzner dedicated и Rescue System — голое железо у любого провайдера (пример здесь).
• kickstart / autounattend — файлы автоматической установки систем.
• Let’s Encrypt (ACME DNS-01), GnuPG и YubiKey — сертификаты и секреты.

---

Нужна консультация?

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