Что НЕ должно управляться марионеткой?

Я изучаю свой путь через управление конфигурацией в целом и использую puppet для его реализации в частности, и мне интересно, какими аспектами системы, если таковые имеются, не следует управлять с помощью puppet?

В качестве примера мы обычно принимаем как должное, что имена хостов уже настроены, прежде чем передать систему в управление марионетке. Базовая IP-связь, по крайней мере, в сети, используемой для связи с puppetmaster, должна работать. Использование puppet для автоматического создания файлов зоны DNS заманчиво, но обратные указатели DNS должны быть уже на месте, прежде чем запускать вещь, или сертификаты будут смешными.

Так я должен пропустить конфигурацию IP от марионетки? Или я должен настроить его до первого запуска Puppet, но, тем не менее, управлять IP-адресами с помощью Puppet? Как насчет систем с несколькими IP-адресами (например, для WAN, LAN и SAN)?

А как насчет IPMI ? Большинство из них, если не все, можно настроить с помощью ipmitool , что избавит вас от получения консольного доступа (физического, последовательного интерфейса , удаленного KVM и т. Д.), Чтобы его можно было автоматизировать с помощью puppet. Но перепроверять его состояние при каждом запуске агента-марионетки для меня не очень круто, и я бы хотел иметь простой доступ к системе, прежде чем делать что-либо еще.

Еще одна целая история об установке обновлений. Я не буду вдаваться в этот конкретный момент, там уже много вопросов о SF и много разных философий между разными сисадминами. Сам я решил не позволять марионетке обновлять вещи (например, только ensure => installed) и делать обновления вручную, как мы уже привыкли, оставив автоматизацию этой задачи на более поздний день, когда мы будем более уверенно в марионетке (например, добавив MCollective в микс).

Это была всего лишь пара примеров, которые я получил прямо сейчас на уме. Есть ли какой-то аспект системы, который должен быть недоступен для кукол? Или, другими словами, где находится грань между тем, что должно быть настроено во время инициализации, и «статически» сконфигурировано в системе, и чем управляется централизованное управление конфигурацией?

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

Конкретные примеры (извлеченные из вопроса, все повествования «Вот почему вы хотите управлять ими»):

Конфигурация IP-сети

ОК, конечно, вы настроили адрес / шлюз / NS на машине до того, как уронили ее в стойку. Я имею в виду, если бы вы не знали, как бы вы запустили puppet для остальной части конфигурации?

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

Или, скажем, ваша компания приобретается, и ваша новая материнская компания требует, чтобы вы изменили адрес с 192.168.0.0/24 на 10.11.12.0/24, чтобы вписаться в их систему нумерации.

Или вы внезапно получаете крупный государственный контракт - Единственный улов - вы должны включить IPv6 ПРЯМО СЕЙЧАС, или сделка сорвана ...

Похоже, что настройка сети - это то, чем мы бы хотели управлять ...

Конфигурация IPMI

Как и в случае с IP-адресами, я уверен, что вы настроите это до того, как вы положите машину в стойку. Просто здравый смысл включать IPMI, удаленную консоль и т. Д. На любой машине, которая имеет такие возможности, и эти конфигурации не нужны. не сильно изменится ...

... До того гипотетического приобретения, о котором я упоминал в разделе «Конфигурация IP» выше. Причина, по которой вы были вынуждены освободить эти адреса 192.168-net, заключается в том, что это IPMI-земля в соответствии с вашими новыми корпоративными властителями, и вам нужно обновить все свои карты IPMI СЕЙЧАС, потому что они будут топтать чье-то зарезервированное IP-пространство.

Хорошо, это немного растянуто, но, как вы сказали, со всем этим можно справиться ipmitool, так почему бы не запустить Puppet и не подтвердить конфигурацию, пока он выполняет все остальные вещи? Я имею в виду, что это не повредит ничего, поэтому мы можем также включить IPMI тоже ...

Обновления

Обновления программного обеспечения являются скорее серой областью - в моей организации мы оценили кукол для этого и обнаружили, что их «очень не хватает», поэтому мы используем их radmindдля этой цели. Нет никакой причины, по которой Puppet не может вызвать Radmind - на самом деле, если / когда мы перейдем к Puppet для управления конфигурацией, это именно то, что должно произойти!

Здесь важно установить все ваши обновления стандартным образом (либо стандартным для всей организации, либо стандартным для платформ) - нет причин, по которым Puppet не должен запускать процесс обновления, если вы тщательно протестировали все, чтобы Puppet ничего не испортил.
Нет также причины, по которой Puppet не может обратиться к инструменту, который лучше подходит для этой задачи, если вы определили, что Puppet не может делать хорошую работу самостоятельно ...

Не изобретай велосипед.

Да, вы можете иметь 50 виртуальных марионеточных пользовательских ресурсов и реализовывать их по мере необходимости в своих модулях ... но если можете, используйте LDAP.

Я говорю из горького опыта. Хотя ldap здесь не вариант, пока.

Другим примером является выталкивание файлов хостов, а не просто использование DNS.

• Марионетка не является системой оркестровки. В частности:
  • Puppet плохо подходит для оркестровки виртуальных машин, поскольку у виртуальных машин есть собственный жизненный цикл, который следует соблюдать.
  • Puppet не очень подходит для управления выпуском приложений / комплексных обновлений. Для этого могут быть использованы автономные марионеточные прогоны, но, по крайней мере, это не Пуппет под контролем, а ваши сценарии-обертки или человеческий робот, что вполне нормально.
• Puppet не является хорошей системой управления пользователями (она должна управлять каждой записью пользователя, даже удаленными пользователями, чтобы быть эффективной. Поэтому найдите другое решение)
• Puppet не является хорошей базой данных конфигурации (посмотрите на использование какой-либо внешней базы данных, а также ENC, Hiera или какого-либо подобного клея)

Конечно, вы можете делать все эти вещи с Puppet ... но это просто не лучшее решение для них. Иногда вы должны опустить молоток и пойти искать гаечный ключ.

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

Я в основном согласен с voretaq7, но с несколькими оговорками.

• Я редко когда-либо настраиваю IP-адресацию в марионетках, если только система не использует DHCP (я предполагаю, что большинство крупных «облачных» провайдеров делают это). У меня были ситуации, когда я нарушал сетевые конфигурации с помощью puppet, но не мог исправить их с помощью puppet, потому что у узла не было никакого способа связаться с хозяином puppet.

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

В моем случае у меня есть скрипт начальной загрузки, который загружает минимальный системный конфиг (Ubuntu): Ruby, Rubygems, build-essential, git и т. Д. Мои манифесты Puppet находятся под контролем версий, и я просто клонирую репозиторий. Оттуда мой скрипт начальной загрузки делает hostname --shortдопустимое предположение и пытается puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Чтобы ответить на ваш вопрос:

• Мои сценарии предполагают базовое сетевое подключение (DNS, IP) и не управляют и не изменяют его;
• Мои сценарии предполагают, что идентификатор машины верен, и не меняют его;
• Мои сценарии предположим , рубин / Rubygems / Git присутствует, но сделать это удалось впоследствии.

Думаю, вам не нужно использовать Puppet для настройки сети. Обычно это однажды настроенная вещь. Также вы можете получить немного дерьма, если у вас будут ошибки с IP или MAC или что-то подобное, что принесет марионетка.