Последствия использования шаблонов и клонирования VMware для предоставления серверов Linux вместо PXE

Кажется, есть преимущества в скорости при использовании шаблонов VMware для создания новых виртуальных машин. Однако меня беспокоят возможные менее очевидные последствия для безопасности и гибкости. Например:

• Первая загрузка сгенерированных ключей
• Собственные методы VMware для настройки параметров сервера (IP-адреса, имя хоста и т. Д.)

В магазине, где почти полностью VMware, а большинство Linux - дистрибутивы на основе RHEL, кто-нибудь сталкивался с некоторыми подводными камнями при подготовке из шаблонов? Как насчет проблем при клонировании?

КСТАТИ: Независимо от начального метода обеспечения, он будет в первую очередь использоваться в качестве начальной загрузки для Puppet для остальной части конфигурации.

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

Я работал в большой Linux-ориентированной среде VMware, где процесс развертывания был не таким автоматизированным, как следовало бы. Мы опирались на шаблоны vSphere для систем RHEL, но после первоначального клона потребовалось немало ручной работы.

Преимущества шаблона:

• Шаблоны хороши, если вы запекаете в шаблоне другие приложения, параметры конфигурации и вещи, которые выходят за пределы возможностей управления конфигурацией. ( например, сложный стек приложений Oracle )
• Время клонирования зависит от вашей системы хранения и инфраструктуры vSphere. Я видел очень медленные и ресурсоемкие работы по клонированию.
• Например, если вы используете Red Hat / CentOS / Debian / Ubuntu, вы можете воспользоваться этой sys-unconfigкомандой, чтобы «отключить» систему перед созданием шаблонов. Это эквивалент Linux для Microsoft, Sysprepи он удаляет правила сетевого интерфейса, ключи SSH, настройки сети и т. Д.
• Инструменты VMware для назначения IP-адресов в порядке и не представляют особой проблемы для основных операционных систем Linux.

Преимущества развертывания PXE / kickstart:

• Обычно быстрее, чем шаблонирование / клонирование, при условии, что у вас есть локальный репозиторий и сетевой загрузочный образ.
• Более гибкая в том, что вы можете вносить изменения в ваши изображения / мастер без цикла конвертации шаблона в виртуальную машину, модификации, реконвертации и клонирования.
• Лучше всего в сочетании с решением для управления конфигурацией.

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

Особенности зависят от дистрибутива, но я дам вам несколько вещей CentOS / RHEL, которые нужно помнить при создании шаблона.

• Удалить ключи в /etc/ssh/
• Удалите строки SUBSYSTEM,/etc/udev/rules.d/70-persistent-net.rules которые относятся к вашим сетевым картам

Оба из них будут перегенерированы при первой загрузке.

Вам нужен способ запуска обновлений после развертывания шаблона.

С vSphere вы можете определить сеть и имя хоста. Как пользователь Puppet, я могу просто установить клиент Puppet в свой шаблон вместе со стандартным puppet.conf. Если я использую несколько сред, тогда мне нужен отдельный шаблон для каждой среды.

Когда вы изменяете шаблон, вы должны помнить, чтобы удалить файлы выше.

Лично, хотя развертывание из шаблона незначительно быстрее, я все равно предпочитаю подготовку из PXE, поскольку она более гибкая.

Ознакомьтесь с разделом « Подготовка виртуальных машин с шаблонами Linux» и публикацией, на которую он ссылается, « Создание готового образа для кукол (CentOS / Fedora)» . Может быть, это помогает.

Кстати, мне очень нравится ваша идея развернуть виртуальные машины JeOS, а затем использовать Puppet для настройки его на БД, в Web или на любой другой сервер.

Еще одним плюсом для запуска Linux-VM является то, что хосты будут автоматически полностью исправлены при установке (виртуальные машины получают последние пакеты из локальных репозиториев).

Очевидно, что вы можете достичь того же, если будете поддерживать свои шаблоны в актуальном состоянии, но я не видел, чтобы это происходило в средах, над которыми я работал.

Раздел% post наших файлов кикстарта (да, у нас есть несколько в зависимости от того, для каких систем мы устанавливаем, например, 32 или 64 бита) просто устанавливает агент cfengine, и оттуда хосты управляются cfengine.

Я не рассчитал это, но я сомневаюсь, что клонирование будет быстрее, когда будет создана инфраструктура. Плюс, если это так, вы также можете установить настоящие хосты ;-)

Для систем на основе Debian мы использовали FAI , что тоже замечательно.