Когда серверов десять, администратор держит их конфигурацию в голове и в нескольких bash-скриптах. Когда серверов сто, голова перестаёт справляться: машины расходятся в настройках, обновление пакета на одной ломает соседнюю, а воспроизвести упавший узел с нуля занимает дни. Управление конфигурацией решает эту проблему радикально – описывает желаемое состояние сервера кодом, а инструмент сам приводит реальную систему к этому состоянию. Так инфраструктура превращается в текст, который хранится в Git, проходит ревью и разворачивается предсказуемо. Два зрелых инструмента закрепились на рынке: Puppet и Chef.
Декларативный Puppet против императивного Chef
Puppet использует декларативный подход. Вы описываете на собственном DSL, что должно быть на сервере: пакет nginx установлен, конфиг лежит по такому пути, сервис запущен. Порядок применения Puppet вычисляет сам через граф зависимостей. Манифесты читаются как спецификация, и это удобно для команд, где инфраструктуру правят не только программисты.
Chef ближе к разработчикам. Рецепты пишутся на чистом Ruby, и вы фактически программируете порядок действий. Это даёт больше гибкости в сложной логике – условия, циклы, обращение к внешним данным выражаются естественно. Платой становится более высокий порог входа: чтобы поддерживать Chef-кухню, нужен человек, читающий Ruby.
Оба инструмента работают по модели «клиент-сервер»: центральный мастер хранит описания, агенты на узлах периодически запрашивают свою конфигурацию и приводят машину в нужное состояние. Оба идемпотентны – повторный прогон ничего не ломает, если система уже соответствует описанию.
Воспроизводимость как требование, а не удобство
Для госсектора и регулируемого бизнеса главная ценность здесь – не скорость, а аудируемость. Каждое изменение сервера проходит через систему контроля версий: видно, кто, когда и зачем правил настройку. Конфигурация продакшена перестаёт быть устным знанием уволившегося админа и становится активом компании.
Это напрямую связано с тем, о чём мы писали в материале про автоматизацию развёртывания и DevOps: управление конфигурацией – фундамент, на котором стоит вся остальная автоматизация. Без описанной кодом инфраструктуры выкатка приложений остаётся ручной и хрупкой. А связка с непрерывной интеграцией на Jenkins замыкает цикл: тот же конвейер, что собирает и тестирует код, может прогонять манифесты Puppet на тестовом стенде и подтверждать, что новая конфигурация не сломает рабочие узлы.
Когда внедрять и с чего начинать
Не нужно описывать всю инфраструктуру разом. Разумная стратегия – взять один тип узлов, например веб-серверы, и довести их до полного управления через код. Затем расширять охват: базы данных, очереди, балансировщики. Параллельно стоит навести порядок в хранении данных – мы разбирали это на примере архива видеоданных, где предсказуемая конфигурация хранилищ критична не меньше, чем у вычислительных узлов.
Выбор между Puppet и Chef определяется командой. Если инфраструктуру ведут системные администраторы, берите Puppet с его декларативной читаемостью. Если за инфраструктуру отвечают разработчики и нужна сложная логика – Chef ляжет естественнее.
Вывод
Управление конфигурацией перестало быть экспериментом и стало промышленной практикой. Puppet и Chef решают одну задачу разными средствами: превращают руками настроенные серверы в воспроизводимый, проверяемый код. Оба инструмента ложатся в основу построения и автоматизации инфраструктуры – от первого пилотного узла до полного описания контура. Это снижает зависимость от конкретных людей, ускоряет восстановление после сбоев и даёт прозрачность, которую требуют аудит и регулятор.
