Шесть месяцев назад в нашем некоммерческом проекте мы решили начать миграцию нашего системного управления в среду, управляемую Puppet, потому что мы ожидаем, что количество наших серверов значительно вырастет в период с настоящего момента до года.
После того, как решение было принято, наши айтишники стали слишком часто слишком раздражаться. Их самые большие возражения:
Я понимаю, почему большая организация отправляет своих системных администраторов на курсы Марионеток, чтобы они стали мастерами Марионеток. Но как меньшие игроки смогут выучить Puppet на профессиональном уровне, если они не ходят на курсы, а в основном изучают его через браузер и редактор?
Я начал использовать Puppet до развертывания новой инфраструктуры и просто купил (уважаемый) книга по теме. Я не думаю, что большинство людей действительно получают профессиональное обучение кукольному искусству. Я работал над примерами, пока не смог приспособить процесс к своей среде. Это был декабрь 2011 года, так что через несколько недель я смог понять основы и создать производственную структуру. Я не был новичком в управлении конфигурацией, имея CFEngine фон, но многие из проблем ваших системных администраторов находят отклик. Я допустил ошибки, и мне пришлось несколько раз рефакторинг, но все работало удовлетворительно.
Несколько заметок по вашим пунктам ...
Роль традиционного системного администратора меняется. Приспосабливайтесь или оставайтесь позади. Я был успешным системным инженером, но мне тоже нужно переоснастить (например, изучение Python). Акцент на отдельные серверы уменьшается по мере того, как абстракция оборудования за счет виртуализации и общедоступных и частных облачных сервисов набирает обороты. Это означает автоматизацию системных задач и использование управления конфигурацией для получения контроля над большим количеством серверов. Добавить Концепции DevOps к смеси, и вы увидите, что ожидания клиентов / конечных пользователей и требования меняются.
Модули Puppet, доступные в Интернете, различаются по стилю и структуре, и да, я видел много дублирования, дублирования и дублирования усилий. Один разработчик, с которым я работал, сказал: «Вы могли бы разработать свои собственные инструменты, потратив время на поиски в Интернете того, что работает!» Это заставило меня задуматься, когда я понял, что Puppet, похоже, больше нравится разработчикам, чем администраторам, которые ищут лучшие практики или правильно подходить.
Тщательно документируйте, чтобы понять, как все взаимосвязано. Учитывая шаткие определения и отсутствие стандарт Таким образом, ваша структура управления конфигурацией действительно уникальна для вашей среды. Эту прозрачность нужно развивать внутри.
Я бы сказал, что достаточно легко продублировать модуль для размещения нового демона или добавить службу в существующий манифест, в зависимости от того, как вы организовали свои серверы и роли.
Я потратил много времени на тестирование одной цели, прежде чем вносить изменения в более крупные группы серверов. Запуск puppetd вручную на репрезентативном сервере позволил мне отлаживать изменения и оценивать их влияние. Возможно, это немного консервативно, но это было необходимо.
Я не уверен, насколько я буду зависеть от модулей сообщества. Я должен был начать использовать Augeas для работы, и посетовал на то, что это была функция, которую я считал само собой разумеющейся в CFEngine.
В целом, мне кажется, что для Puppet нет четко определенного стандарта. Мне было сложно понять, как организовать структуру каталогов на моем Puppetmaster, понять, как управлять подписью сертификатов, получить правильный обратный DNS на месте везде, правильное масштабирование Puppet для окружающей среды и понимания, когда использовать модули сообщества, а не создавать свои собственные. Это сдвиг в мышлении, и я вижу, как это может вызвать панику у системного администратора. Однако это тоже было решение, созданное с нуля, поэтому я имел возможность оценить инструменты. Решение пойти по этому пути было основано на сознании и импульсе, стоящем за Puppet. Чтобы узнать что-то новое, стоило усилий.
Помните, этот сайт тоже хороший ресурс.
На предыдущей работе мне было поручено провести пилотную реализацию Puppet. Теперь у меня есть опыт программирования, хотя и не на Ruby, поэтому у меня нет таких проблем, как у других.
Однако интересно отметить, что программисты без опыта работы с нетрадиционными парадигмами есть проблемы и с Puppet, потому что Puppet декларативный, не обязательно. В этом смысле Puppet работает почти так же, как любой файл конфигурации: вы говорите, как должно быть, а Puppet позаботится обо всем остальном.
После пилота у меня была возможность обучить дюжину других администраторов работе с Puppet, а также провести презентации на двух мероприятиях. Из этого опыта я понял, что некоторые администраторы приняли это, а некоторые нет. Все они были обычными администраторами, без навыков программирования и разного уровня знаний.
Я заметил одну особенность: Puppet требует постоянный практика. Люди, которые прошли обучение, написали модули, а затем потратили месяц или два на что-то еще, вернулись в Puppet с небольшим количеством полезных навыков. Люди, которые каждую неделю занимались в нем мелочами, никогда не теряли способности.
Основываясь на этих двух наблюдениях, я рекомендую вам убедиться, что все продолжают добавлять какой-нибудь класс, определение или модуль Puppet каждую неделю (желательно как минимум два или три раза). Тем, кто все еще не может к этому привыкнуть, может действительно не хватать навыков для этого.
С другой стороны, если Puppet был навязан им сверху, они могли бы просто реагировать на то, что они воспринимают как вмешательство руководства в то, как они выполняют свою работу, - что на самом деле было бы достаточно правдой. Может случиться так, что позволив им выбрать который использование системы управления конфигурацией улучшит ситуацию. Вот несколько альтернатив:
Я использую Puppet чуть более двух лет в небольших магазинах, где я был единственным системным администратором. Самым большим препятствием, с которым я столкнулся, было научиться правильно разрабатывать программное обеспечение. Не прошло и недели, чтобы я не облажался в чем-то, что я говорил разработчикам не делать дюжину раз. Я проверил слишком много кода, я не разбивал проверки, не отмечал теги, не выполнял ветвления, не запускал средство проверки синтаксиса, не использовал стандарт и т. Д. Если вы только начинаете я бы порекомендовал некоторые из следующего.
Таким образом, я столкнулся со всеми этими проблемами, как и большинство моих друзей-системных администраторов. Чтобы научиться пользоваться системой управления конфигурациями, потребуется некоторое время. Как только вы это сделаете, вы удивитесь, как вы когда-либо жили без него. «Войти на сервер и внести изменения вручную? Крик».
Шесть месяцев назад в нашем некоммерческом проекте мы решили начать миграцию нашего системного управления в среду, управляемую 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, если следовать ей, достаточно тщательна. Просто обратите внимание на встроенные типы и потратьте некоторое время на изучение того, как собираются другие модули. Я бы не сказал, что это очень просто, но и не сложно. Подготовка инфраструктуры к марионетке занимает немного времени, но затраченное время гарантированно будет потрачено не зря при расширении.
KISS (Держите это просто глупо) - не используйте новые технологии только потому, что они есть, а потому, что у вас есть требования к ним, используйте минимум, который требуется для вашего развертывания, обновляйте по мере необходимости, не пытайтесь не отставать от кровотечения край. Если вы начнете с базовой настройки и будете опираться на нее, ее будет легче освоить на ходу, и им не понадобится курс (доступны ли они вообще?).
Другая область, на которую вы можете обратить внимание, - это ваши системные администраторы. Если они тоже не умеют программировать, то достаточно ли они продвинуты для крупномасштабного развертывания, когда большая часть работы требует написания сценариев, независимо от используемых вами инструментов?
Я также работаю в некоммерческой организации и отвечал за то, чтобы сначала доставить в дом 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, если комплексное, сквозное управление конфигурацией можно инкапсулировать в разделы пакетов операционной системы до и после установки, до и после удаления, просто используя программы оболочки 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, или в значительной степени везде. Нет необходимости в сверхсложных решениях. Библиотека, о которой я упоминал выше, может быть просто источник из разделов до или после установки в пакетах операционной системы, тем самым устраняя дублирование и используя центральную часть кода ...
Но, прежде всего, я считаю, что приведенная выше цитата является примером следующего поколения системных администраторов, нуждающихся в обучении не со стороны системных администраторов, а со стороны системные инженеры. Найди себе седобородого и записывайся в ученики.