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

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

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

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

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

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

Несколько замечаний по вашим пунктам…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"Мы не программисты, мы системные администраторы";

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

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

Трудный вопрос. Я всегда предпочитаю модули puppetlabs, хотя даже я их не использую много. Это точно требует суждения. На мой взгляд, некоторые модули слишком “расфуфыренные”.

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

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

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

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

"Давайте просто запустим это и посмотрим, как это работает"

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

Множество едва известных ‘расширений’ в модулях сообщества: ‘trocla’,
‘augeas’, ‘hiera’… как нашим системным администраторам
следить за этим?

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

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

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

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

KISS (Делайте просто, глупо) – Не используйте новые технологии только потому, что они существуют, а потому, что они вам нужны, используйте минимально необходимое для вашего развертывания, обновляйте по мере необходимости, не пытайтесь следовать за последними новинками. Если вы начнете с базовой настройки и будете наращивать ее, вам будет проще осваиваться по мере прохождения, и им не нужно будет проходить курс (а такие курсы вообще существуют?).

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

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

Прежде всего, я старался избегать третьих сторонных модулей. Встроенные инструменты обрабатывают 90% нашего управления. Самый крупный сторонний инструмент, который я использую, – это модуль файрвола. Любые пользовательские факты и т. д. разрабатываются с вовлечением всей команды. Мы разработали модуль-шаблон и сохраняем управление файлами, пакетами, службами и т. д. стандартизированными на основе этого шаблона.

Во-вторых, после стандартизации использования встроенных модулей мы начали использовать Git и Crucible от Atlassian – бесплатный для некоммерческих организаций, кстати – для проведения проверок всех изменений конфигурации. Это обеспечивает необходимую прозрачность.

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

“Мы не программисты, мы системные администраторы”

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

Теперь у нас есть “системные администраторы”, которые в основном являются пользователями рабочего стола Windows, которые в какой-то момент перешли на Linux и не могут программировать, и не находят в этом ничего неправильного.

Слон в комнате — это то, почему руководство терпит такое разрушительное отношение. Разрушительное для кого или чего? Для бизнеса и инфраструктуры.

Возвращаясь к теме Puppet[, CFEngine, Chef]: как только внедряется такое решение, все проигрывают. Почему? Потому что тот, кто придумывает идею, не способен проектировать инкапсулированное управление конфигурацией в виде красивых, чистых, Kickstart[, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM] пакетов операционных систем. Когда вам нужно использовать автоматизированный инструмент для взлома, как Puppet (или Chef, или CFEngine), это означает, что вам не хватает средств для проектирования и внедрения процесса, который, согласно тому же проекту, будет полностью чистым и автономным управляемыми системами, полностью автоматизированными и совершенно не интерактивными.

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

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

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

Классно видеть, как ваш Puppet-манифест конфигурирует всю машину или новую службу с нуля.

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

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

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

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