Я изучаю управление конфигурациями в целом и использую кукольный чтобы реализовать это, в частности, и мне интересно, какие аспекты системы, если таковые имеются, должны не управлять марионеткой?
В качестве примера мы обычно считаем само собой разумеющимся, что имена хостов уже настроены до передачи системы в распоряжение руководства марионетки. Базовое IP-соединение, по крайней мере, в сети, используемой для связи с кукловодом, должно работать. Заманчиво использовать марионетку для автоматического создания файлов зоны DNS, но обратные указатели DNS должны быть уже установлены перед запуском, иначе сертификаты будут забавными.
Так что я должен оставить конфигурацию IP из марионетки? Или мне следует настроить его перед первым запуском марионетки, но все же управлять IP-адресами с помощью марионетки? А как насчет систем с несколькими IP-адресами (например, для WAN, LAN и SAN)?
Что о IPMI? Вы можете настроить большую часть, если не все, с помощью ipmitool, избавляя вас от получения консольного доступа (физического, последовательного интерфейса, удаленного KVM и т. д.), чтобы его можно было автоматизировать с помощью марионетки. Но повторная проверка его состояния при каждом запуске марионеточного агента не кажется мне крутой, а простой доступ к системе без отключения света - это то, что я хотел бы иметь, прежде чем делать что-либо еще.
Другая целая история про установку обновлений. Я не собираюсь останавливаться на этом конкретном моменте, уже есть много вопросов по научной фантастике и множество различных философий между разными системными администраторами. Я сам решил не позволять марионетке обновлять вещи (например, только ensure => installed) и выполнять обновления вручную, как мы уже привыкли, оставляя автоматизацию этой задачи на более поздний день, когда мы будем более уверены в марионетке (например, добавив MCollective к смеси).
Это всего лишь пара примеров, которые сейчас у меня в голове. Есть ли какой-либо аспект системы, который следует оставить вне досягаемости марионеток? Или, говоря другими словами, где проходит грань между тем, что должно быть настроено во время инициализации и «статически» настроено в системе, и тем, что обрабатывается посредством централизованного управления конфигурацией?
Главное правило: Если вы используете управление конфигурацией, управляйте каждым аспектом конфигурации, который вы можете. Чем больше вы централизуете, тем легче будет масштабировать вашу среду.
Конкретные примеры (взяты из вопроса, все рассказы «Вот почему вы хотите управлять этим»):
Хорошо, конечно, вы настроили адрес / шлюз / NS на машине до того, как бросили ее в стойку. Я имею в виду, если бы вы этого не сделали, как бы вы запустили puppet, чтобы сделать остальную часть конфигурации?
Но предположим, что теперь вы добавляете еще один сервер имен в свою среду и вам нужно обновить все свои машины. Разве вы не хотите, чтобы ваша система управления конфигурацией сделала это за вас?
Или скажите, что ваша компания приобретается, а ваша новая материнская компания требования которые вы меняете с адреса 192.168.0.0/24 на 10.11.12.0/24, чтобы соответствовать их системе нумерации.
Или вы внезапно получаете крупный государственный контракт - единственная загвоздка - вам нужно включить IPv6. ПРЯМО СЕЙЧАС или сделка сорвана ....
Похоже, мы хотели бы управлять конфигурацией сети ...
Как и в случае с IP-адресами, я уверен, что вы настроили это до того, как поместите машину в стойку - просто разумно включить IPMI, удаленную консоль и т. Д. На любой машине, которая имеет такую возможность, и эти конфигурации не мало что изменится ...
... До того гипотетического приобретения, о котором я упоминал выше в разделе «Конфигурация IP», - причина, по которой вы были вынуждены освободить эти 192.168-сетевые адреса, заключается в том, что это IPMI-земля в соответствии с вашими новыми корпоративными повелителями, и вам нужно обновить все свои карты IPMI. СЕЙЧАС, потому что они собираются попирать чье-то зарезервированное IP-пространство.
Хорошо, здесь это немного натянуто, но, как вы сказали, всем этим можно управлять с помощью ipmitool, так почему бы Puppet не запустить инструмент и не подтвердить конфигурацию, пока он выполняет все остальные операции? Я имею в виду, что это ничего не повредит, так что мы можем также включить IPMI ...
Обновления программного обеспечения - это скорее серая зона. В моей организации мы оценили марионетку для этого и обнаружили, что ее "крайне не хватает", поэтому мы используем radmind для этого. Хотя нет причин, по которым Puppet не может вызвать radmind - на самом деле, если / когда мы перейдем на Puppet для управления конфигурацией, это именно то, что произойдет!
Здесь важно, чтобы все ваши обновления были установлены стандартным способом (стандартным для всей организации или стандартным для платформ) - нет причин, по которым Puppet не должен запускать процесс обновления, если вы тщательно протестировали все, чтобы Puppet ничего не испортил.
Также нет причин, по которым Puppet не может обратиться к инструменту, который лучше подходит для этой задачи, если вы определили, что Puppet не может справиться самостоятельно ...
Не изобретайте велосипед.
Да, вы можете иметь 50 марионеточных виртуальных пользовательских ресурсов и реализовать их по мере необходимости в своих модулях ... но если можете, используйте LDAP.
Я говорю из горького опыта. Хотя ldap здесь пока недоступен.
Другой пример - выталкивание файлов hosts, а не просто использование DNS.
Конечно, вы можете делать все это с помощью Puppet ... но это не лучшее решение для них. Иногда стоит положить молоток и пойти поискать гаечный ключ.
Puppet, однако, чрезвычайно хорош для поддержания базовой конфигурации для машины и установки инструментов, которые позволяют вам выполнять виртуальную машину и выпускать оркестровку, управлять пользователями и т. Д.
Я в основном согласен с voretaq7, но с несколькими оговорками.
Я редко когда-либо настраиваю IP-адресацию в марионетке, если система не использует DHCP (я предполагаю, что это делают большинство крупных «облачных» провайдеров). У меня были ситуации, когда я нарушал сетевые конфигурации с помощью марионетки, но не мог исправить их с помощью марионетки, потому что у узла не было возможности связаться с мастером марионеток.
Я совершенно твердо убежден, что управление обновлениями находится в руках системных инструментов, и я не считаю, что использование puppet в качестве прославленного cron является улучшением.
В моем случае у меня есть сценарий начальной загрузки, который загружает минимальную конфигурацию системы (Ubuntu): Ruby, Rubygems, build-essential, git и т. Д. Мои манифесты Puppet хранятся под контролем версий, и я просто клонирую репозиторий. Отсюда мой сценарий начальной загрузки предполагает, что hostname --short действительно, и попытки puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.
Чтобы ответить на ваш вопрос:
Думаю, вам не нужно использовать марионетку для настройки сети. Обычно это когда-то настроенная вещь. Также вы можете получить некоторую ерунду, если у вас будет ошибка (-ы) с IP или MAC или что-то подобное, что принесет марионетка.