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

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

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

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

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

107 голосов | спросил drumfire 6 J0000006Europe/Moscow 2012, 12:38:07

7 ответов


102

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

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

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

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

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

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

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

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

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

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

ответил ewwhite 6 J0000006Europe/Moscow 2012, 13:02:48
30

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

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

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

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

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

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

  • ANSIBLE : это новое, но оно основано на командах оболочки и ssh, которые могут привлекать его к традиционным сисадмины.
  • Шеф-повар : Возможно, их проблема носит декларативный стиль, и в этом случае шеф-повар будет лучше, если у них будет опыт Ruby .
  • SaltStack : на основе Python и с открытым исходным кодом
  • CFEngine : старый, быстрый, традиционный - он может победить их на тех основаниях.
ответил Daniel C. Sobral 6 J0000006Europe/Moscow 2012, 19:59:31
11

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

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

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

ответил kashani 6 J0000006Europe/Moscow 2012, 22:04:22
7
  

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

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

  

Поскольку решение принято, наши ИТ-ребята тоже стали слишком   слишком часто раздражался.

Им нужна корректировка отношения.

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

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

  

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

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

  

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

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

  

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

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

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

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

  

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

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modules .. Выберите, что вы хотите и используете? Думаю, этот звук больше похож на вещь отношения ...

  

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

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

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

ответил thinice 6 J0000006Europe/Moscow 2012, 18:04:25
6

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

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

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

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

ответил Tim Brigham 6 J0000006Europe/Moscow 2012, 17:50:23
5

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

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

ответил JamesRyan 6 J0000006Europe/Moscow 2012, 13:18:41
4
  

«Мы не программисты, мы сисадмины»

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

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

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

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

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

  

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

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

  

Приятно чувствовать, что ваш манифест Puppet настраивает всю машину или новую службу с нуля.

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

  

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

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

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

ответил UX-admin 11 FebruaryEurope/MoscowbWed, 11 Feb 2015 15:28:11 +0300000000pmWed, 11 Feb 2015 15:28:11 +030015 2015, 15:28:11

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132