Автоматическая установка Linux через Preseed, Kickstart, Autoinstall

Preseed: почему ручная установка Linux не масштабируется

Ручная установка Linux масштабируется до первых десяти машин — дальше начинаются расхождения конфигураций. Разметку диска на каждой новой машине делают по памяти: где-то корень на 40 ГБ, где-то на 100, тома получают разные размеры, а раздел подкачки отдельным блоком есть только на половине серверов. Формально это один и тот же сервер, фактически — десять разных.

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

Ошибки при развёртывании стоят не переделанной установки, а ночных простоев. Ввод новой машины занимает часы и держится на инженере, который помнит порядок шагов; в спешке шаги меняются, и результат становится невоспроизводимым. Тиражирование в другую зону или восстановление после отказа превращается в отдельный проект со своим графиком.

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

Что даёт автоматическая установка серверов: эффект в цифрах

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

• Время развёртывания сервера. Узел проходит путь от включения до готовности к роли за минуты вместо часов ручных кликов — разметка диска, сеть, набор пакетов и доступы берутся из файла ответов.
• Доля операций без ручного участия. Установка, базовая настройка и подключение к мониторингу идут без входа инженера в консоль; вручную остаются только решения, требующие выбора.
• Снижение ручных ошибок. Опечатка в разметке, забытый раздел под журналы, разошедшийся набор пакетов — эти причины уходят, потому что шаблон один и проходит проверку в репозитории.
• Повторяемость конфигураций. Две машины из одного шаблона неотличимы по составу пакетов, параметрам ядра и настройкам доступа: «особенных» узлов, которые нельзя пересобрать, не остаётся.
• Единый шаблон установки. Preseed для Debian и производных, Kickstart для семейства Red Hat, Autoinstall для актуальных сборок — носитель разный, правила описаны одинаково.
• Инциденты из-за разной настройки. Доля сбоев, где корнем была рассинхронизация машин, падает до единичных случаев, а восстановление узла сводится к повторному запуску шаблона.

Сравнение Preseed, Kickstart и Autoinstall: что выбрать

Все три подхода закрывают одну задачу — автоматическая установка Linux без ручных ответов на вопросы инсталлятора. Разница в семействе дистрибутивов и в том, насколько декларативно описан узел. На практике выбор диктует существующий парк машин, а не предпочтения инженера.

Где какой шаблон уместен

Границы размываются: preseed дополняют скриптами после установки, kickstart — разделом с командами донастройки, autoinstall — модулями, которые доводят узел до рабочего состояния. Шаблон ответов установщика остаётся единственным источником правды о разметке, поэтому его хранят в контроле версий вместе с образами.

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

Этапы внедрения автоматической установки: от аудита до приёмки

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

1. Аудит инфраструктуры. Инвентаризация парка: модели, контроллеры дисков, сетевые карты, текущие способы загрузки и накопленные ручные правки. На выходе — таблица групп машин и перечень того, что требует отдельного профиля.
2. Схема разметки диска. Для каждой роли — гипервизор, база данных, приложение, рабочая станция — утверждаем единую схему: загрузочный раздел, корень, отдельные тома под данные и логи, правила шифрования.
3. Каталог профилей машин. Шаблоны Preseed, Kickstart и Autoinstall сводим в один репозиторий: базовый профиль, слои под роли, переменные сети и имени узла. Один источник правды вместо копий, изменения — через ревью.
4. Сервис установки. Загрузка по сети и локальное зеркало пакетов: десятки машин ставятся параллельно и не зависят от внешнего канала.
5. Тестовый стенд. Проверяем не только удачный путь: повтор установки, обрыв сети, отсутствие диска, разный объём памяти. Отдельно — поведение при сбое и корректность отката.
6. Пилотная группа. 5-10 машин из разных групп: замеряем время до готового узла и долю установок без ручных вмешательств, правим профили по факту.
7. Регламент развёртывания и приёмка. Передаём документацию: как добавить роль, обновить профиль, оформить исключение. Профили версионируются — у заказчика остаётся воспроизводимый процесс.

Комплект поставки: конфигурации, схемы и регламенты

После сдачи установочного контура у заказчика остаётся рабочий комплект, а не набор файлов на чьём-то ноутбуке. Всё, что относится к автоматической установке Linux — ответы для Preseed, Kickstart и Autoinstall, разметка, доступы и порядок правок — лежит в вашем репозитории и описано так, чтобы новый инженер разобрался без обращения к нам.

• Файлы ответов по профилям — отдельный шаблон на роль машины (веб-узел, база данных, балансировщик), с комментариями к каждому неочевидному параметру и вынесенными наружу переменными вместо зашитых значений.
• Соответствие «профиль — железо» — таблица, по которой выбирается шаблон при вводе нового узла, чтобы конфигурацию не копировали наугад и не правили в спешке.
• Карта разметки — схемы разделов, группы томов, порядок монтирования и запас места под логи и резервные копии, согласованный с политиками хранения данных.
• Политики доступа к сервису установки — кто и по какому ключу обращается к загрузочному серверу и репозиторию пакетов, срок жизни записей, порядок их отзыва при уходе сотрудника.
• Регламент установки — пошаговый порядок для дежурной смены: проверка контрольных сумм образов, выбор профиля, контроль результата по журналам, действия при сбое на каждом этапе.
• Порядок изменений — любая правка шаблона проходит пробный прогон в виртуальной среде и проверку вторым инженером, только потом попадает в рабочий контур; откат к предыдущей версии описан.
• Передача знаний команде — разбор контура с вашими инженерами, порядок приёмки нового узла и назначенный ответственный, чтобы поддержка не зависела от одного человека.

Кейс: парк серверов без ручных установок

Парк из нескольких десятков узлов разворачивался руками: инженер подключал образ, отвечал на вопросы установщика, отдельно настраивал сеть, разметку и доступы. Ввод одной машины занимал 3–4 часа, установки ставили в ночные окна, а расхождения в конфигурациях всплывали уже при вводе в эксплуатацию. Дежурная смена тратила время на разбор однотипных сбоев вместо реальных задач.

Начали с инвентаризации: разложили машины по классам — веб-узлы, базы, служебные хосты — и под каждый описали ответы установщика в файле-шаблоне. Для парка на Debian это Preseed, для других семейств — Kickstart и Autoinstall; логика одна: разметка диска, часовой пояс, сеть, ключи доступа, набор пакетов и первичные настройки безопасности задаются заранее, а не вводятся вручную. Шаблон версионируется и прогоняется на стенде, поэтому новая версия профиля не ломает уже развёрнутые узлы.

Что изменили в процессе

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

Метрики до и после

• Время ввода узла: 3–4 часа → 20–30 минут, включая проверку.
• Доля однотипных отказов на старте: примерно каждый пятый узел → единичные случаи.
• Ночные окна для установок: нужны → не нужны, развёртывание идёт в рабочее время.
• Новый класс машин: неделя ручной работы → день на подготовку шаблона.
• Нагрузка дежурной смены: рутинные установки → разбор реальных сбоев.

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

Что делать, если часть парка уже развёрнута вручную?

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

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

Дальше собираем эталонный шаблон ответа автоматической установки. Общее для всех — базовый набор пакетов, разметка диска, сетевые параметры, ключи доступа, источники обновлений; всё ролевое выносим в переменные. Один пресет тогда даёт и узел приложений, и сервер базы, без ручной доводки после установки.

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

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

Частые технические сомнения и ответы на них

Частые вопросы по автоматической установке у инженеров совпадают: как один профиль ляжет на разное железо, безопасно ли держать в нём учётные данные, как обновлять шаблон без риска для работающих машин и что делать при неудачной раскатке. Ниже — короткие ответы по каждому.

Шаблон установки — это не дыра в безопасности?

Файл ответов содержит учётные данные установщика, поэтому хранится в закрытом репозитории, передаётся по шифрованному каналу и удаляется с машины после завершения установки. Пароли подставляются при сборке профиля, а не лежат в нём открытым текстом; правка — по ролям с журналом изменений.

Как обновлять профили, не ломая установленные машины?

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

Что делать, если установка прошла неудачно?

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

Обсудим задачу: с чего начинается внедрение

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

• инвентаризация: роли узлов, различающиеся модели, объём дисков, текущая разметка и способ загрузки;
• сеть загрузки: есть ли контур удалённой установки, свой DHCP или его нужно изолировать от рабочего;
• целевое состояние: LVM или RAID, шифрование, файловая система, точки монтирования;
• параметры системы: учётные записи и ключи доступа, часовой пояс, локаль, обязательный набор пакетов;
• нестандартные случаи: машины без проводной сети, узлы с UEFI и включённым Secure Boot, повторная переустановка поверх существующей;
• контроль после установки: какие проверки должны проходить автоматически, прежде чем узел попадёт в работу.

Механизм ответов выбираем под дистрибутив — Preseed, Kickstart или Autoinstall. Важно, чтобы один шаблон покрывал весь парк без ручных правок на месте, иначе автоматизация превращается в ту же ручную установку, только длиннее.

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

Опишите задачу, парк и ограничения по доступам — вернёмся с оценкой, планом работ и предложением по варианту старта.