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


67

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

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

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

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

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

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


1
Хороший вопрос Мне любопытно, есть ли что-то кроме машинно-специфических конфигов, для которых вы не должны использовать puppet. Ну, это и Windows машины.
HopelessN00b

6
<vague> Вы не должны управлять вещами в марионетках, когда лучше / легче управлять ими другим способом. </ vague>: p
Zoredache

1
В связи с преобладанием в эти дни компаний, использующих Puppet, я вижу, что этот вопрос будет привлекать большое внимание в течение следующих нескольких лет
Даниэль Ли,

Ответы:


24

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

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


Конфигурация 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 не может делать хорошую работу самостоятельно ...


Re: Обновления. Одна вещь, которая может создать вам проблемы с Puppet, запускающим ваши обновления, - это когда исправляется критический сервис, например: mysql, apache - вы не хотите, чтобы те перезапускались по прихоти. Puppet предлагает способы блокировки версий этих пакетов, поэтому я избежал этого, наслаждаясь общими обновлениями для других гаек и болтов.
худой

@thinice Это хороший момент, но мой обычный контрапункт к этому - бить людей по затылку и кричать REDUNDANCY действительно очень громко :-) (С Radmind это хуже, потому что это просто взрывает файловую систему. Наша политика заключается в том, чтобы чтобы балансировщик нагрузки выгружал половину серверов, чтобы мы могли их исправлять / тестировать, затем мы перемещали всех на исправленные машины, чтобы мы могли выполнять вторую половину. Работает хорошо, но вам нужна встроенная избыточность в вашей среде.)
voretaq7

10

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

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

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

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


3
Я узнаю все эти слова, но я все еще не уверен, что ты пытаешься сказать.
Крис С

2
Я пытаюсь сказать; марионетка является центральным местом для «информации». Так же, как DNS и LDAP. Не пытайтесь выполнять свою работу с помощью puppet, это просто ерунда ... Я говорю это, видя, как гигантские файлы / etc / hosts выталкиваются с помощью puppet каждый раз, когда новый хост присоединяется к сети.
Sirex

3
Люди действительно используют Puppet вместо LDAP для управления учетными записями пользователей?
Джоэл Э Салас

2
У каждого инструмента есть свое место, но использование puppet для управления учетными записями пользователей или LDAP для хранения файлов является злоупотреблением .
Хьюберт Карио

1
Это, конечно, ab use ...
jldugger

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

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

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


Больше придирки: Puppet может быть настроен на добавление и удаление пользователей с или без управления каждым пользователем. Тем не менее ... это не бесполезно, чтобы не управлять каждым пользователем, и ужасно управлять каждым пользователем. Я использую Puppet для добавления учетных записей служб, но не учетных записей пользователей.
Art Hill

2

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

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

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


1

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

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

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

0

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


2
Никогда не приходилось менять шлюз по умолчанию на сервере 100+ вручную? Lucky you;)

@EricDANNIELOU Я полагаю, что это можно было бы принять за +1, чтобы позволить марионетке управлять настройкой IP сетевых интерфейсов;)
Luke404

@EricDANNIELOU Попробуйте сделать это с помощью bash, цикла «for» и соответствующих прав пользователя (sudo для root или root напрямую) и sed / perl / etc. :)
Евгений Яблоков

1
Я не думаю, что bash-цикл for и грязные сценарии sed / awk / vi более безопасны, чем scm для настройки сети. И после того, как вы настроили puppet для всего остального, использовать ssh «for» не очень удобно только для конфигурации сети.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.