Как маленькие ребята могут эффективно учиться и использовать Puppet? [закрыто]

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

С тех пор как было принято решение, наши ИТ-специалисты стали слишком раздражаться. Их самые большие возражения:

• «Мы не программисты, мы системные администраторы»;
• Модули доступны онлайн, но многие отличаются друг от друга; слишком часто заново изобретают колеса, как вы решаете, какой из них отвечает вашим требованиям;
• Код в нашем репо не достаточно прозрачен, чтобы найти, как что-то работает, они должны использовать через манифесты и модули, которые они могли бы даже написать сами некоторое время назад;
• Один новый демон требует написания нового модуля, соглашения должны быть похожи на другие модули, сложный процесс;
• «Давайте просто запустим и посмотрим, как это работает»
• Тонны едва известных «расширений» в модулях сообщества: «trocla», «augeas», «hiera» ... как наши системные администраторы могут отслеживать?

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

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

Несколько замечаний о ваших очках ...

• Роль традиционного системного администрирования меняется. Приспосабливайтесь или оставайтесь позади. Я был успешным системным инженером, но мне тоже приходится переоснащаться (например, изучать Python). Сосредоточение на отдельных серверах уменьшается, поскольку абстракция оборудования благодаря виртуализации и общедоступным и частным облачным сервисам набирает силу. Это означает автоматизацию системных задач и использование управления конфигурацией для получения контроля над большим количеством серверов. Добавьте концепции DevOps к смеси, и вы увидите, что ожидания и требования клиента / конечного пользователя меняются.

• Кукольные модули, доступные онлайн, отличаются по стилю и структуре, и да, я видел много совпадений, избыточности и дублированных усилий. Один из разработчиков, с которым я работал, сказал: «Вы могли бы разработать свои собственные инструменты, потратив время на поиск в Интернете чего-нибудь, что работает!» Это заставило меня задуматься, когда я понял, что Puppet, похоже, больше нравится разработчикам, чем администраторам, которые ищут лучшие практики или правильный подход.

• Тщательно документируйте, чтобы почувствовать, как все связано. Учитывая шаткие определения и отсутствие стандартного способа работы, ваша структура управления конфигурацией действительно уникальна для вашей среды. Эту прозрачность нужно будет развивать внутри.

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

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

• Я не уверен, насколько я буду зависеть от модулей сообщества. Мне действительно пришлось начать использовать Augeas для какой-то работы , и посетовал на то, что это была функциональность, которую я считал само собой разумеющейся в CFEngine.

В целом, я чувствую, что не существует четко определенного стандарта, когда речь заходит о Puppet. У меня были проблемы с выяснением того, как организовать структуру каталогов на моем Puppetmaster, с пониманием того, как управлять подписью сертификатов, с установкой правильного обратного DNS на всех местах, с подходящим масштабированием Puppet для среды и с пониманием того, когда использовать модули сообщества вместо создания собственных. Это сдвиг в мышлении, и я вижу, как это вызвало бы панику у системного администратора. Тем не менее, это было также решение, созданное с нуля, поэтому я имел возможность оценивать инструменты. Решение пойти по этому пути основывалось на доле ума и импульсе, который был заложен в Puppet. Это стоило усилий, чтобы узнать что-то новое.

Помните, этот сайт тоже хороший ресурс.

На предыдущей работе мне было поручено выполнить пилотную реализацию Puppet. Теперь у меня есть опыт программирования, но не Ruby, поэтому у меня не так много проблем, как у других.

Тем не менее, интересно отметить, что программисты, не имеющие опыта работы с нетрадиционными парадигмами, тоже имеют проблемы с Puppet, потому что Puppet декларативный , а не императивный. В этом смысле Puppet работает почти как любой файл конфигурации: вы говорите, как все должно быть, а Puppet позаботится обо всем остальном.

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

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

Основываясь на этих двух наблюдениях, я рекомендую вам убедиться, что все продолжают добавлять некоторые классы, определения или модули кукол каждую неделю (желательно, по крайней мере, два или три раза). Тем, кто до сих пор не может привыкнуть к этому, может не хватать умения это делать.

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

• ANSIBLE : это новое, но оно основано на командах оболочки и ssh, которые могут привлечь его к традиционным системным администраторам.
• Chef : Возможно, их проблема в декларативном стиле, и в этом случае Chef будет лучше, если у них есть опыт работы с Ruby.
• SaltStack : на основе Python и с открытым исходным кодом
• CFEngine : старый, быстрый, традиционный - он может победить их на этих основаниях.

Я использовал Puppet чуть более двух лет в небольших магазинах, где я был единственным сисадмином. Самое большое препятствие, которое у меня было, - это научиться правильно разрабатывать программное обеспечение. Не было недели, чтобы я не напортачил с тем, что я сказал разработчикам не делать десяток раз. Я проверил слишком много кода, я не разбивал проверки, я не помечал, я не разветвлял, не запускал проверку синтаксиса, не использовал стандарт и т. Д. Если вы только начинаете Я бы порекомендовал некоторые из следующих.

1. Поймите, что вы разрабатываете программное обеспечение, которое вы либо не знаете, либо делаете плохо. Это ожидается, потому что это новое.
2. Инфраструктура как код - это реальность, и как только вы преодолеете горб, она станет достаточно мощной. Я хотел бы пригласить некоторых разработчиков, показать им ваш текущий процесс разработки (или его отсутствие), не обижаться, когда они поднимают брови, и серьезно относиться к их предложениям. Я бы порекомендовал использовать любую систему и процесс, используемый вашими разработчиками, если это не является совершенно неуместным.
3. Кукольные сторонние модули сосут 90% времени. Я бы прочитал их. Я бы украл у них идеи. Я бы не стал тянуть их в свою систему без серьезных правок. Тем не менее, я бы включил в программу puppet stdlib, которая добавляет хорошую функциональность.
4. augeas и hiera. Изучите эти два. Первый позволяет сложное редактирование существующих файлов на месте. Второе - это внешнее хранилище данных.
5. Отдельный код от данных. Это одна из самых сложных концепций для изучения. Жесткое кодирование значений, таких как «Мониторинг хостов», в код вашего модуля - это плохо. Поместить их в хранилище данных (db, yaml (Hiera использует это по умолчанию), csv, что угодно), которое могут потреблять ваши модули, - это хорошо. Примером является веб-приложение, которое использует Mysql. Это позволяет раздвигать код и данные по отдельности. Это делает ваш процесс разработки проще.
6. парсер puppet validate и puppet-lint являются частью процесса проверки до или после кода. Также тесты rspec могут быть хорошей идеей, как только вы наберете скорость.
7. написать руководство по стилю / код стандарта и использовать его. «где код, устанавливающий Apache» - распространенная проблема. Если ваши модули в основном одинаковы, это должно быть легко.

Таким образом, я затронул все эти проблемы, как и большинство моих друзей-сисадминов. Потребуется некоторое время, чтобы освоить систему управления конфигурацией. Как только вы это сделаете, вы удивитесь, как вы жили без него. «Войти на сервер и внести изменения вручную? Ick.»

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

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

С тех пор как было принято решение, наши ИТ-специалисты стали слишком раздражаться.

Им нужно изменить отношение.

"We're not programmers, we're sysadmins";

Опять отношение. Вы можете создать файл conf для сервера, верно? Вы можете облегчить в / вещи шаблонной «программист» , как ваши потребности и сложность эволюционируют .

Модули доступны онлайн, но многие отличаются друг от друга; слишком часто заново изобретают колеса, как вы решаете, какой из них отвечает вашим требованиям;

Сложно ответить - я всегда предпочитаю модули puppetlabs, а не так много, и даже не так много. Решение судить наверняка. На мой взгляд, некоторые модули «слишком вычурные».

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

Это не похоже на проблему марионеток, но, скорее, на организационную или документальную проблему?

Один новый демон требует написания нового модуля, соглашения должны быть похожи на другие модули, сложный процесс;

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

"Let's just run it and see how it works"

Не так уж плохо для идеи, если вы принимаете это медленно и безопасно. Я бы все еще начал с ВМ, чтобы понять суть вещей.

Тонны едва известных «расширений» в модулях сообщества: «trocla», «augeas», «hiera» ... как наши системные администраторы могут отслеживать?

Модули postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl. Выберите, что вы хотите, и используйте его? Я думаю, это звучит больше как отношение ...

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

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

Документация 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 и тому подобное, не имеет понятия владельцев компонентов, выпусков, управления конфигурацией, модели зрелости возможностей. Это быстро превращается в очень серьезную проблему в отрасли.

Работа с Puppet также помогла мне выучить Ruby, который пришел на смену Bash в качестве моего языка системных инструментов по умолчанию ».

Зачем нужен Ruby, когда комплексное комплексное управление конфигурацией может быть инкапсулировано в разделы пакетов операционной системы preinstall, postinstall, preremove и postremove только с помощью программ оболочки Bourne, AWK и sed? То, что кто-то пойдет на изучение эзотерического языка Ruby и его диалекта в контексте Puppet, совершенно не нужно. Проблема управления конфигурацией легко решаема (и, конечно, решена) с помощью программ оболочки и AWK, и немного sed (1) здесь и там в качестве клея.

Приятно видеть, как ваш манифест Puppet настраивает всю машину или новый сервис с нуля.

Это даже круче, если посмотреть, как это делают Kickstart, AutoYaST или JumpStart, без единой строчки кода , и возможность запрашивать операционную систему с помощью встроенных инструментов, без необходимости какого-либо эзотерического или дополнительного программного обеспечения , без клиента-сервера. необходимая архитектура (SSH более чем хорошо, более чем хорошо), и ваша операционная система должна быть в курсе всех изменений, внесенных в нее.

5. Отдельный код от данных. Это одна из самых сложных концепций для изучения. Жесткое кодирование значений, таких как «Мониторинг хостов», в код вашего модуля - плохо. Поместить их в хранилище данных (db, yaml (Hiera использует это по умолчанию), csv, что угодно), которое могут потреблять ваши модули, - это хорошо. Примером является веб-приложение, которое использует Mysql. Это позволяет раздвигать код и данные по отдельности. Это делает ваш процесс разработки проще.

... Или вы можете просто шаблонировать ваши файлы конфигурации с помощью переменных оболочки, даже обратных кавычек (например ls -1 ...), и написать сценарий оболочки, который использует AWK для вызова eval (1) и развернуть все переменные в шаблоне, тем самым используя точно такой же мощный Парсер, который имеет встроенные оболочки. Зачем делать это сложным, когда это может быть очень, очень просто? Где вы будете хранить значения конфигурации? Почему, где угодно, например, файлы pkginfo (4) или база данных, например, Oracle, или почти везде . Нет необходимости в ультракомплексных решениях. Библиотека, о которой я упоминал выше, может быть просто получена из разделов preinstall или postinstall в пакетах операционной системы, тем самым удаляя дублирование и используя центральный фрагмент кода ...

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