Автоматизация развертывания сервера
Я обнаружил, что постоянно настраиваю почти одинаковые серверы и VPS для ряда моих клиентов, и это может занять очень много времени. Часто единственное, что меняется между каждым развертыванием, - это другой веб-сайт, который нужно обслуживать. Есть ли простой способ автоматизировать все это и заняться скучным однообразием настройки 56 одинаковых серверов?
Серверы, которые я развернул до сих пор, были только Ubuntu, но возможно, что я начну использовать другие ОС Linux или даже Windows. До сих пор я смотрел на Capistrano, но, кажется, он сосредоточен на написании небольших программ ruby для работы, и у меня нет никаких знаний вообще
7 ответов
Puppet звучит идеально для того, что вы пытаетесь сделать, с оговоркой, что на данный момент нет поддержки Windows.
В вашем случае вы бы определили узел сервера с точки зрения всех пакетов, которые одинаковы для всех компьютеров. Затем вы определяете отдельные узлы как узлы, которые наследуются от Сервера, и настраиваете для них конкретные уникальные вещи.
Puppet декларативен - он позволяет вам описывать ваши блоки с точки зрения ресурсов, которые должен иметь каждый блок. Так что если вы хотите ssh - вы пишете класс для этого ресурса - и внутри класса вы можете включить логику о том, как ssh вызывается немного по-другому во FreeBSD и Ubuntu. Он также знает, как использовать yum внутри Redhat и apt-get внутри дистрибутивов на основе Debian, и ports в BSD. Теперь в вашем узле сервера у вас будет просто строка include ssh - и puppet сделает все правильно и включит SSH в машину, и вам не нужно будет помнить, Ubuntu, Redhat или FreeBSD.
Что приятно, так это то, что все компоненты Сервера находятся в одном месте - и если в любой момент вы добавите определение узла Сервера, ВСЕ машины обновят свою конфигурацию соответствующим образом.
Прямо сейчас я управляю только тремя коробками с помощью Puppet - но это уже окупилось. Потратив неделю на настройку блока, который мы будем использовать для демонстрации стимулов в эксперименте, оказалось, что драйвер видеокарты был слишком стар в той версии Ubuntu, которую я установил (8.04). Мне пришлось установить последнюю версию Ubuntu (9.04), но после этого мне просто нужно было apt-get и запустить puppet - и все, что я потратил на настройку недели, было восстановлено.
У Puppet есть немного кривой обучения, но я успешно избежал изучения Ruby - я знаю, что использую его, так как именно это написано в Puppet - но до сих пор мне удавалось просто изменить примеры в документация и рецепты в вики. Другим недостатком является то, что марионетка занимает немного больше времени, чтобы делать вещи в первый раз. Положительным моментом является то, что все, что вы изменяете на всех своих машинах, хранится в одном месте - это стандартная практика - сохранять конфигурацию вашего марионетки в системе контроля версий - чтобы вы всегда могли оглянуться назад и увидеть, как вы настраивали серверы в прошлом - или откат некоторых неудачных изменений.
Наконец, вот короткое видео, которое демонстрирует простую демонстрацию кукол, которая быстро начала меня.
Мы используем Cobbler и Puppet для автоматизации сборки и настройки как реальных, так и виртуальных машин.
Cobbler объединяет DHCP, PXE boot и Kickstart, чтобы сделать развертывание не более чем добавлением профиля машины и нажатием кнопки питания. Для виртуальных машин koan Команда выполняет (в нашем случае) волшебство Xen, чтобы начать установку - на dom0 Я просто набираю:
koan --system vps.fqdn --server cobbler --no-gfx
затем virsh console смотреть здание VPS без какого-либо взаимодействия.
Мы используем RHEL и настроили несколько профилей для разделения дисков, настройки сети и установки базовых пакетов для разных классов серверов. Cobbler поддерживает породы Debian и Ubuntu, но я никогда не пробовал. Напомним, что другие интересные применения Cobbler включают в себя запуск memtest ISO и обновление прошивки HP.
Как только наши системы собраны с Cobbler, Puppet вступает во владение, чтобы настроить приложения, системные демоны, зарегистрировать ящик с RHN и т. Д. Puppet работает как демон, который периодически проверяет, что конфигурация системы соответствует определенным манифестам - вы знаете, что ваши обновления прошли на все серверы. Это также отличный способ убедиться, что коробка, которая была отключена для обслуживания, имеет правильную конфигурацию, прежде чем вы вернете ее в оперативный режим.
Кукольный действительно потрясающий. Вам не нужно контролировать каждый аспект вашей конфигурации - начните с того, что он управляет чем-то простым, что вам нужно настроить на каждом устройстве (sudoers это канонический пример) и бери оттуда. Убедитесь, что ваши манифесты Puppet тоже версионированы; нет ничего лучше, чем легко откатиться до заведомо удачной конфигурации, не вспоминая, что настраивать.
Там, где я сейчас работаю, мы должны управлять Linux-частью нашей фермы серверов, которая насчитывает чуть более 300 Linux-серверов. Сюда входят в основном HP Proliants, за которыми следуют IBM 3850, некоторые блейды IBM, VMware ESX и некоторые KVM для наших внутренних серверов управления.
сапожник
Мы смотрели на сапожника, но проблема заключалась в том, что сапожник очень специфичен для RHEL/Red Hat. Нам нужно как минимум поддерживать RHEL и SLES, а Ubuntu следующая.
марионетка
Мы рассматривали Puppet, однако позже решили отказаться от него, поскольку это зависит от Ruby, что означает, что обновление Ruby может потенциально сломать нашу систему управления.
горячий провод
Hotwire - это то, что мы используем (разработано внутри, но с открытым исходным кодом), и делали это в течение последних нескольких лет. Во-первых, он инвентаризирует системы, которые будут собираться, что означает инвентаризацию центра обработки данных, стойки, оборудования, операционной системы, сети и т. Д., А во-вторых, выполняет быструю сборку и развертывание. Как только система построена, автоинвентаризация hotwire поддерживает синхронизацию инвентаря, в то время как cfengine поддерживает их. Hotwire знает об оборудовании сервера, общаясь с данными SMBIOS/DMI в BIOS через python-dmidecode.
Бонусные моменты заключаются в том, что он объединяет инвентарь и процесс сборки в один, поэтому управлять им меньше, а функция живого инвентаря хороша, как мы знаем, если что-то не так.
Недостатки заключаются в том, что пользовательский интерфейс все еще нуждается в доработке, и здесь есть ошибки, но разработка все еще остается горячей, а сообщения об ошибках исправляются относительно быстро.
Cfengine
Мы используем cfengine, потому что кроме него и марионеток, больше ничего нет. На самом деле это хороший инструмент, но "хороший" только в зависимости от того, насколько хороши ваши политики - если вы устанавливаете опасные политики, то небольшая ошибка может нанести большой ущерб. Например, по политике мы не "модифицируем" файлы, мы либо заменяем их, либо нет. Также все замененные файлы имеют заголовок, который позволяет любому редактору знать, что он будет заменен при следующем запуске (он запускается через cron каждый час).
Конфигурация и все файлы, передаваемые cfengine на серверы, также хранятся в SCM, и с помощью перехватов после фиксации, где это возможно, мы проверяем синтаксис, и если это не удается, то фиксация отклоняется. Это легко для хороших приложений, таких как Apache, но не так просто для большинства корпоративных приложений.
У меня был успех с Puppet. Шеф-повар является новым, чтобы появиться. Более подробный список параметров и сравнительную таблицу см. В статье Википедии " Сравнение программного обеспечения для управления конфигурацией с открытым исходным кодом".
Для автоматизации установки в зависимости от целевой системы:
- Debian / Ubuntu: FAI или ди предпосев
- RedHat / Fedora: Kickstart
- Novell / openSuSE: АвтоЯСТ
- Солярис: Jumpstart
- Windows: unattended.sourceforge.net
Для управления конфигурацией я бы предложил использовать puppet.
Еще один голос за марионетку здесь. Мы широко используем его для выполнения всех операций по установке и настройке серверов и приложений. 200+ узлов и подсчет. Поддержка Windows, видимо, находится в разработке, хотя в каком состоянии я не уверен.
Мы все еще изучаем начальную сторону загрузки ОС, но, как упоминалось выше, Cobbler выглядит интересно. В настоящее время мы используем сочетание загрузки PXE с предварительным заданием Debian/Ubuntu, но вряд ли это оптимально.
У меня большой успех в Puppet, но вам действительно нужно написать много конфигураций.