Я начал использовать Puppet перед развертыванием новой инфраструктуры и просто купил ( уважаемую ) книгу на эту тему. Я не думаю, что большинство людей получают профессиональное обучение кукол. Я работал над примерами, пока не смог сформировать процесс в своей среде. Это был декабрь 2011 года, поэтому в течение нескольких недель я смог понять основы и создать производственную среду. Я не был новичком в управлении конфигурациями, имея опыт работы с CFEngine , но многие из ваших проблем сисадминов находят отклик. Я допускал ошибки и несколько раз проводил рефакторинг, но все получалось удовлетворительно.
Несколько замечаний о ваших очках ...
Роль традиционного системного администрирования меняется. Приспосабливайтесь или оставайтесь позади. Я был успешным системным инженером, но мне тоже приходится переоснащаться (например, изучать Python). Сосредоточение на отдельных серверах уменьшается, поскольку абстракция оборудования благодаря виртуализации и общедоступным и частным облачным сервисам набирает силу. Это означает автоматизацию системных задач и использование управления конфигурацией для получения контроля над большим количеством серверов. Добавьте концепции DevOps к смеси, и вы увидите, что ожидания и требования клиента / конечного пользователя меняются.
Кукольные модули, доступные онлайн, отличаются по стилю и структуре, и да, я видел много совпадений, избыточности и дублированных усилий. Один из разработчиков, с которым я работал, сказал: «Вы могли бы разработать свои собственные инструменты, потратив время на поиск в Интернете чего-нибудь, что работает!» Это заставило меня задуматься, когда я понял, что Puppet, похоже, больше нравится разработчикам, чем администраторам, которые ищут лучшие практики или правильный подход.
Тщательно документируйте, чтобы почувствовать, как все связано. Учитывая шаткие определения и отсутствие стандартного способа работы, ваша структура управления конфигурацией действительно уникальна для вашей среды. Эту прозрачность нужно будет развивать внутри.
Я бы сказал, что достаточно просто продублировать модуль для размещения нового демона или добавить сервис в существующий манифест, в зависимости от того, как вы организовали свои серверы и роли.
Я потратил много времени на тестирование одной цели, прежде чем вносить изменения в большие группы серверов. Запуск puppetd вручную на репрезентативном сервере позволил мне отладить изменения и оценить их влияние. Может быть, это немного консервативно, но это было необходимо.
Я не уверен, насколько я буду зависеть от модулей сообщества. Мне действительно пришлось начать использовать Augeas для какой-то работы , и посетовал на то, что это была функциональность, которую я считал само собой разумеющейся в CFEngine.
В целом, я чувствую, что не существует четко определенного стандарта, когда речь заходит о Puppet. У меня были проблемы с выяснением того, как организовать структуру каталогов на моем Puppetmaster, с пониманием того, как управлять подписью сертификатов, с установкой правильного обратного DNS на всех местах, с подходящим масштабированием Puppet для среды и с пониманием того, когда использовать модули сообщества вместо создания собственных. Это сдвиг в мышлении, и я вижу, как это вызвало бы панику у системного администратора. Тем не менее, это было также решение, созданное с нуля, поэтому я имел возможность оценивать инструменты. Решение пойти по этому пути основывалось на доле ума и импульсе, который был заложен в Puppet. Это стоило усилий, чтобы узнать что-то новое.
Помните, этот сайт тоже хороший ресурс.
puppetd -tпробую пару коробок, прежде чем отправлять их на все серверы. Никогда не случается так, что у пары есть что-то уникальное, что приводит к сбою моих обновлений на них. Кукольный намного проще, когда у вас есть контролируемая и согласованная среда для начала.На предыдущей работе мне было поручено выполнить пилотную реализацию Puppet. Теперь у меня есть опыт программирования, но не Ruby, поэтому у меня не так много проблем, как у других.
Тем не менее, интересно отметить, что программисты, не имеющие опыта работы с нетрадиционными парадигмами, тоже имеют проблемы с Puppet, потому что Puppet декларативный , а не императивный. В этом смысле Puppet работает почти как любой файл конфигурации: вы говорите, как все должно быть, а Puppet позаботится обо всем остальном.
После пилота у меня была возможность обучить дюжину других администраторов с Puppet, а также выступать с презентациями об этом в двух мероприятиях. Мой опыт основан на том, что некоторые администраторы приняли его, а некоторые нет. Все они были традиционными администраторами без навыков программирования и разного уровня знаний.
Одна особенность, которую я заметил, заключается в том, что Puppet требует постоянной практики. Люди, которые были обучены, написали модули, а затем провели целый месяц или два, делая что-то еще, вернулись в Puppet с небольшим полезным навыком. Люди, которые продолжали делать маленькие вещи каждую неделю, никогда не теряли способность.
Основываясь на этих двух наблюдениях, я рекомендую вам убедиться, что все продолжают добавлять некоторые классы, определения или модули кукол каждую неделю (желательно, по крайней мере, два или три раза). Тем, кто до сих пор не может привыкнуть к этому, может не хватать умения это делать.
Опять же, если бы Puppet был навязан им сверху, они могли бы просто реагировать на то, что они воспринимают как руководство, вмешивающееся в то, как они выполняют свою работу - что на самом деле было бы достаточно верно. Возможно, это позволит им выбрать, какую систему управления конфигурацией использовать, что улучшит ситуацию. Вот несколько альтернатив:
источник
Я использовал Puppet чуть более двух лет в небольших магазинах, где я был единственным сисадмином. Самое большое препятствие, которое у меня было, - это научиться правильно разрабатывать программное обеспечение. Не было недели, чтобы я не напортачил с тем, что я сказал разработчикам не делать десяток раз. Я проверил слишком много кода, я не разбивал проверки, я не помечал, я не разветвлял, не запускал проверку синтаксиса, не использовал стандарт и т. Д. Если вы только начинаете Я бы порекомендовал некоторые из следующих.
Таким образом, я затронул все эти проблемы, как и большинство моих друзей-сисадминов. Потребуется некоторое время, чтобы освоить систему управления конфигурацией. Как только вы это сделаете, вы удивитесь, как вы жили без него. «Войти на сервер и внести изменения вручную? Ick.»
источник
Похоже, чертовски хорошая идея начать рано - Puppet - это больше, чем просто управление конфигурацией, это форма документации.
Им нужно изменить отношение.
Опять отношение. Вы можете создать файл conf для сервера, верно? Вы можете облегчить в / вещи шаблонной «программист» , как ваши потребности и сложность эволюционируют .
Сложно ответить - я всегда предпочитаю модули puppetlabs, а не так много, и даже не так много. Решение судить наверняка. На мой взгляд, некоторые модули «слишком вычурные».
Это не похоже на проблему марионеток, но, скорее, на организационную или документальную проблему?
Этот демон может быть классом, если им достаточно просто управлять. Я не уверен, что вы подразумеваете под соглашениями, марионетка навязывает вам соглашения, не так ли? Или мы говорим о форматировании кода?
Не так уж плохо для идеи, если вы принимаете это медленно и безопасно. Я бы все еще начал с ВМ, чтобы понять суть вещей.
Модули postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl. Выберите, что вы хотите, и используйте его? Я думаю, это звучит больше как отношение ...
Я не посещал никаких курсов - в то время как я являюсь программистом более сисадмина, я нашел , что это не нужно много навыков программирования , чтобы получить что - нибудь выполнено.
Документация Puppet, если следовать ей, является довольно тщательной. Просто обратите внимание на встроенные типы и потратьте некоторое время на изучение того, как другие модули собраны вместе. Я бы не сказал, что это супер легко, но не трудно. Подготовка инфраструктуры к марионеткам занимает немного времени, но затрачиваемое время гарантированно будет хорошо потрачено при расширении.
источник
ПОЦЕЛУЙ (Делайте это просто глупо) - Не используйте новые технологии только потому, что они есть, а потому, что у вас есть требования к ним, используйте минимальный уровень, необходимый для вашего развертывания, обновляйте по мере необходимости, не пытайтесь идти в ногу с кровотечением край. Если вы начинаете с базовой установки и опираетесь на нее, ее легче освоить по ходу работы, и им не требуется курс (доступны ли они вообще?).
Другая область, на которую вы можете посмотреть, это ваши системные администраторы. Если они не умеют программировать, то достаточно ли они продвинуты для большого развертывания, где большая часть работы должна быть написана сценариями, какими инструментами вы пользуетесь?
источник
Я также работаю для некоммерческой организации и отвечал за то, чтобы изначально принести Linux-боксы на дом, а вскоре после этого - Puppet для управления ими. Мы сделали пару конкретных вещей, которые действительно помогли добиться успеха.
В первую очередь я старался держаться подальше от сторонних модулей. Встроенные инструменты управляют 90% нашего менеджмента. Самая большая сторонняя утилита, которую я использую, - это модуль брандмауэра. Любые пользовательские факты и т. Д. Разрабатываются с участием всей команды. Мы разработали шаблонный модуль и сохранили стандартное управление файлами, пакетами, сервисами и т. Д. На основе этого шаблона.
Во-вторых, после стандартизации использования встроенных модулей мы начали использовать Git и Atlassian's Crucible - кстати, бесплатно для некоммерческих организаций - для проверки всех изменений конфигурации. Это обеспечивает желаемую прозрачность.
В-третьих, я автоматизировал настройку Puppet, чтобы новые хосты можно было добавлять автоматически с набором параметров по умолчанию. Есть несколько способов решения этой проблемы. Поскольку у меня уже была полная среда Kickstart, я решил добавить туда скрипт.
источник
Мои времена изменились к худшему: от такой седобородой, как я, ожидали, что она станет лучшим программистом, чем профессиональные программисты, иначе никогда бы не сменили системного администратора .
Теперь у нас есть «системные администраторы», которые в основном являются пользователями настольных систем Windows, которые в какой-то момент перешли на Linux и не могут программировать, и не находят в этом ничего плохого.
Слон в комнате - вот почему руководство терпит такое разрушительное отношение. Разрушительно для кого или что? Для бизнеса и инфраструктуры.
Возвращаясь к теме Puppet [, CFEngine, Chef]: как только кто-то устанавливает решение, подобное этому, он проигрывает. Все проигрывают. Почему? Потому что, кто бы ни придумал эту идею, он не способен проектировать инкапсулированное управление конфигурацией в виде красивых, чистых пакетов операционной системы Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Когда вам нужно использовать автоматизированный хакерский инструмент, такой как Puppet (или Chef, или CFEngine), это означает, что вам не хватает средств для проектирования и реализации процесса, который, благодаря той же конструкции, обеспечивал бы полную чистоту и полное отключение управляемых систем. автоматизированный и полностью неинтерактивный.
Другим важным моментом является то, что если вам нужно иметь Puppet или какое-либо подобное решение для исправления кем-либо хакерской конфигурации системы или приложения вручную, это также приводит к тому, что у вас нет опыта в разработке процесса, и в этом процессе создается среда, в которой конфигурируется конфигурация. на отдельные компоненты. В сущности, тот, кто реализует Puppet и тому подобное, не имеет понятия владельцев компонентов, выпусков, управления конфигурацией, модели зрелости возможностей. Это быстро превращается в очень серьезную проблему в отрасли.
Зачем нужен Ruby, когда комплексное комплексное управление конфигурацией может быть инкапсулировано в разделы пакетов операционной системы preinstall, postinstall, preremove и postremove только с помощью программ оболочки Bourne, AWK и sed? То, что кто-то пойдет на изучение эзотерического языка Ruby и его диалекта в контексте Puppet, совершенно не нужно. Проблема управления конфигурацией легко решаема (и, конечно, решена) с помощью программ оболочки и AWK, и немного sed (1) здесь и там в качестве клея.
Это даже круче, если посмотреть, как это делают Kickstart, AutoYaST или JumpStart, без единой строчки кода , и возможность запрашивать операционную систему с помощью встроенных инструментов, без необходимости какого-либо эзотерического или дополнительного программного обеспечения , без клиента-сервера. необходимая архитектура (SSH более чем хорошо, более чем хорошо), и ваша операционная система должна быть в курсе всех изменений, внесенных в нее.
... Или вы можете просто шаблонировать ваши файлы конфигурации с помощью переменных оболочки, даже обратных кавычек (например
ls -1 ...), и написать сценарий оболочки, который использует AWK для вызова eval (1) и развернуть все переменные в шаблоне, тем самым используя точно такой же мощный Парсер, который имеет встроенные оболочки. Зачем делать это сложным, когда это может быть очень, очень просто? Где вы будете хранить значения конфигурации? Почему, где угодно, например, файлы pkginfo (4) или база данных, например, Oracle, или почти везде . Нет необходимости в ультракомплексных решениях. Библиотека, о которой я упоминал выше, может быть просто получена из разделов preinstall или postinstall в пакетах операционной системы, тем самым удаляя дублирование и используя центральный фрагмент кода ...Но, прежде всего, я считаю, что приведенная выше цитата является примером следующего поколения системных администраторов, нуждающихся в обучении не системных администраторов, а системных инженеров . Найдите себе седоборода и зарегистрируйтесь как ученик.
источник