Программа puppet для чего

Что такое puppet.

Puppet – клиент-серверное приложение для удобного распространения конфигураций – состоит из puppetmaster’а, сервера хранящего конфигурации, и puppet agent’а, работающего на конфигурируемом сервере. Puppet написан на ruby, распространяется под лицензией Apache и содержит возможности расширения функциональности с использованием ruby. Проект имеет ruby в качестве единственной зависимости, работает на Linux, Solaris, BSD , Mac OS X, поддерживает Microsoft Windows. Puppet можно использовать как для документирования конфигурации на одном сервере, так и для легкого управления конфигурацией парка серверов в гетерогенной среде. Puppet используют такие проекты как wikimedia, twitter, digg, sugarcrm и многие другие.

Основные примитивы языка. Puppet vs bash.

Описание конфигураций происходит на своем собственном декларативном языке. Декларативный язык позволяет описать желаемое состояние системы в зависимости от набора фактов – описание “как именно делать”, как правило, не требуется. Если применять некоторую конфигурацию на серверах с разными ОС (или, например, разными дистрибутивами Linux), используя bash скриптинг, получаем трудноподдерживаемый код. Puppet же позволяет быть уверенным не только в том, что изменения были применены единоразово ( случай shell-сценариев), но и что текущее состояние соответствует описанному. Простота языка позволяет использовать манифесты puppet как понятную документацию конфигурации систем.

Puppet — инструмент для управления конфигурациями [GeekBrains]

К числу основных понятий языка относятся следующие:

• ресурсы – file, package, user, exec, cron и т.д.
• классы – объединения ресурсов и зависимости между ними
• модули – самостоятельные наборы классов, например, для конфигурации определенного сервиса. Модули независимы и могут распространяться отдельно.
• факты – facts – пары “ключ-значение”, которыми оперирует puppet для выбора конфигурации ( например, hostname => mars, is_virtual => false, operatingsystem => Ubuntu, processorcount => 8 ).
• ноды – nodes – соответствие имени сервера ( ноды ) и набора классов, которые будут к ней применены. Возможно хранение нод в LDAP или использование внешнего классификатора нод – произвольного скрипта.
• манифест – конфигурационный файл puppet, в котором описаны ресурсы, классы, модули или ноды

Управление парком машин от 2 до бесконечности.

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

• синхронизация authorized_keys
• синхронизация пользователей и/или их настроек (bashrc, vimrc …)
• синхронизация правил брандмауэра
• и т.д.

В гетерогенной среде приходится учитывать “факты” в своих конфигурациях. Деплоймент новой или вышедшей из строя ноды происходит в течение нескольких минут при достаточной степени полноты описания конфигурации. Существует огромное количество написанных модулей для практически любых сервисов (их список можно получить поиском, например, на github). Деплоймент или применение каких-либо изменений для 2 или 2000 нод практически не отличаются по трудоемкости при грамотном подходе.

IaC-1. Создание сервера puppet

Как работает puppet.

Puppet agent раз в 30 минут запрашивает конфигурацию у puppetmaster:

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

Также существует подход nodeless (masterless). При данном подходе, манифеста с описанием нод не существет – мастер не нужен, вся конфигурация копируется на ноду, а настройка опирается исключительно на “факты”.

Как масштабировать puppet.

До 100 нод со стандартным периодом в 30 минут могут успешно работать с единственным puppetmaster-сервером (WEBRick Ruby-based HTTP ). Дальше начинаются проблемы. Выход – связка mod_passenger + apache + rack. При данной схеме возможно распределение нагрузки на несколько серверов. Часто используют подход со splay time – размазывание по времени нагрузки на мастер – при котором все ноды не должны обращаться к мастеру одновременно. Можно также использовать подход 1 мастер на площадку (сайт), с синхронизацией между площадками, например, через тот же git.

Опыт работы в команде

Опыт работы над “рецептами” puppet подсказывает использовать следующие практики:

• Использование environments – различных наборов манифестов для разработки и продакшна, когда выбор environment’a происходит на стороне клиента.
• Использование системы контроля версий – например, git. Очень удобным оказывается использование двух различных веток или репозиториев, для разработки и продакшна соответсвенно.

Текст тезисов доступен под лицензией Creative Commons Attribution-ShareAlike 3.0.

Источник: lvee.org

Как стать кукловодом или Puppet для начинающих

2012-12-25 в 6:02, admin , рубрики: linux, puppet, ruby, системное администрирование, метки: puppet, ruby, системное администрирование

Здравствуйте.

Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet.

Что такое система управления конфигурацией?

Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

Я искренне верю, что хороший админ — ленивый админ. Он не любит делать что-то несколько раз. Первая мысль — написать пару скриптов, в котором будет что-то наподобие:

servers=»server00 server01 server02 server03 server04″ for server in $servers ; do scp /path/to/job/file/job.sh $server:/tmp/job.sh ssh $server sh /tmp/job.sh done
#!/bin/bash apt-get update apt-get install nginx service nginx start

Вроде всё стало легко и хорошо. Нужно что-то сделать — пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен — всё станет хорошо.

До поры.

Теперь представьте, что серверов стало больше. Например, сотня. А изменение долгое — например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.

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

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

Для сравнения: манифест puppet, выполняющий ту же работу, что и пара скриптов из начала топика:

class nginx < package < ‘nginx’: ensure =>latest > service < ‘nginx’: ensure =>running, enable => true, require => Package[‘nginx’] > > node /^server(d+)$/

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

Что такое Puppet?

Puppet — система управления конфигурацией. Архитектура — клиент-серверная, на сервере хранятся конфиги (в терминах puppet они называются манифесты), клиенты обращаются к серверу, получают их и применяют. Puppet написан на языке Ruby, сами манифесты пишутся на особом DSL, очень похожем на сам Ruby.

Первые шаги

Давайте забудем о клиентах, серверах, их взаимодействии и т.п. Пусть у нас есть только один сервер, на котором установлена голая ОС (здесь и далее я работаю в Ubuntu 12.04, для других систем действия будут несколько отличаться).

Сначала установим puppet последней версии.

wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb dpkg -i puppetlabs-release-precise.deb apt-get update apt-get install puppet puppetmaster

Замечательно. Теперь у нас в системе установлен puppet и с ним можно играть.

Hello, world!

Создадим первый манифест:

file < ‘/tmp/helloworld’: ensure =>present, content => ‘Hello, world!’, mode => 0644, owner => ‘root’, group => ‘root >
$ puppet apply helloworld.pp /Stage[main]//File[/tmp/helloworld]/ensure: created Finished catalog run in 0.06 seconds
Немного о запуске

Манифесты, приведённые в этом топике можно применять вручную с помощью puppet apply. Тем не менее, в последующих топиках для работы будет использоваться master-slave конфигурация (стандартная для Puppet).

Теперь посмотрите на содержимое файла /tmp/helloworld. В нём окажется (удивительно!) строка «Hello, world!», которую мы задали в манифесте.

Вы можете сказать, что можно было сделать echo «Hello, world!» > /tmp/helloworld , это было бы быстрее, проще, не пришлось бы думать, писать какие-то страшные манифесты и вообще это нафиг никому не нужно это как-то слишком сложно, но задумайтесь серьезнее. На самом деле, необходимо было бы написать touch /tmp/helloworld echo «Hello, world!» > /tmp/helloworld chmod 644 /tmp/helloworld chown root /tmp/helloworld chgrp root /tmp/helloworld , чтобы гарантированно добиться того же результата.

Давайте по строкам разберём, что именно содержится в нашем манифесте:

file < ‘/tmp/helloworld’: ensure =>present, # файл должен существовать content => ‘Hello, world!’, # содержимым файла должна являться строка «Hello, world!» mode => 0644, # права на файл — 0644 owner => ‘root’, # владелец файла — root group => ‘root’ # группа файла — root >

В терминах Puppet здесь описан ресурс типа файл с названием (title) /tmp/helloworld.

Ресурсы

Ресурс — это самая мелкая единица абстракции в Puppet. Ресурсами могут быть:

• файлы;
• пакеты (Puppet поддерживает пакетные системы многих дистрибутивов);
• сервисы;
• пользователи;
• группы;
• задачи cron;
• и т. д.

Синтаксис ресурсов вы можете невозбранно подсмотреть в документации.

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

include webserver; webserver::vhost < ‘example.com’: ensure =>present, size => ‘1G’, php => false, https => true >

Puppet при этом будет создавать logical volume размером в 1 ГиБ на сервере, монтировать его куда положено (например в /var/www/example.com), добавлять нужные записи в fstab, создавать нужные виртуальные хосты в nginx и apache, рестартовать оба демона, добавлять в ftp и sftp пользователя example.com с паролем mySuperSecretPassWord с доступом на запись в этот виртуальный хост.

Вкусно? Не то слово!

Причем, самое вкусное, на мой взгляд — это не автоматизация рутины. Если вы например, идиот, и постоянно пересетапливаете ваши серверы в продакшне, Puppet позволит подхватить старый любовно созданный набор пакетов и конфигов с нуля в полностью автоматическом режиме. Вы просто устанавливаете Puppet-агент, подключаете его к вашему Puppet-мастеру и ждёте. Всё придёт само. На сервере волшебным (нет, правда волшебным!) образом появятся пакеты, разложатся ваши ssh-ключи, установится фаервол, придут индивидуальные настройки bash, сети, установится и настроится весь софт, который вы предусмотрительно ставили с помощью Puppet.
Кроме того, Puppet при старании позволяет получить самодокументируемую систему, ибо конфигурация (манифесты) сами же являются костяком документации. Они всегда актуальны (они же работают уже), в них нет ошибок (вы же проверяете свои настройки перед запуском), они минимально подробны (работает же).

Ещё немного магии

Немного о кроссдистрибутивности

В Puppet есть возможность использовать кроссдистрибутивные манифесты, это одна из целей, для которых он создавался. Я намеренно никогда не пользовался этим и вам не рекомендую. Парк серверов должен быть максимально гомогенным в плане системного ПО, это позволяет не думать в критические моменты «айблин, тут
rc.d, а не init.d» (реверанс в сторону ArchLinux) и вообще позволяет меньше думать на рутинных задачах.

Многие ресурсы зависят от других ресурсов. Например, для ресурса «сервис sshd» необходим ресурс «пакет sshd» и опционально «конфиг sshd»
Посмотрим, как это реализуется:

file < ‘sshd_config’: path =>’/etc/ssh/sshd_config’, ensure => file, content => «Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes», mode => 0644, owner => root, group => root, require => Package[‘sshd’] > package < ‘sshd’: ensure =>latest, name => ‘openssh-server’ > service < ‘sshd’: ensure =>running, enable => true, name => ‘ssh’ subscribe => File[‘sshd_config’], require => Package[‘sshd’] >

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

Самые вкусные строчки здесь — это строчки зависимостей — require и subscribe.

Puppet поддерживает много вариантов описания зависимостей. Подробно, как всегда, можно прочитать в документации.

• Require означает ровно то, что ожидается. Если ресурс А зависит (require) от ресурса Б, то Puppet сначала обработает ресурс Б, а потом вернётся к ресурсу А.
• Subscribe даёт чуть более хитрое поведение. Если ресурс А подписан (subscribe) на ресурс Б, то Puppet сначала обработает ресурс Б, а потом вернётся к ресурсу А (поведение как у require), и далее при изменениях Б, будет заново обрабатываться А. Это очень удобно для создания сервисов, зависящих от их конфигов (как в примере выше). Если конфиг изменяется, сервер перезапускается, не нужно самому об этом беспокоиться.

Существуют также notify, before, но мы их здесь касаться не будем. Интересующимся — в уже упопомянутую документацию.

Итог

На текущий момент мы уже научились писать простые манифесты с указанием зависимостей между ресурсами. Очень многие простые демоны ложатся в модель «пакет-конфиг-сервис», поэтому даже в таком виде puppet уже годится для использования.
В последующих топиках будет описано, как использовать более мощные возможности puppet при создании сферического LAMP-хостинга в вакууме (если есть другие идеи сферического проекта для обучения — добро пожаловать в личку или в комментарии).

Источник: www.pvsm.ru

☁️ Что такое Puppet?

В DevOps мы хотим автоматизировать как можно больше задач.

Ручная настройка окружения занимает недели при огромных инфраструктурах.

Puppet помогает автоматизировать ручные задачи для быстрого создания систем и развертывания приложений.

Динамическое управление инфраструктурой лежит в основе Puppet.

В этой статье объясняется, что такое Puppet, какие проблемы он решает и как успешно использовать Puppet для автоматизации ручных задач в качестве команды DevOps.

Что такое Puppet ?

Puppet – это инструмент IaC (Infrastructure as Code) для управления несколькими серверами.

Написанный в основном на языке Ruby, Puppet работает на различных Unix-подобных системах и поддерживает Windows.

Программное обеспечение является очень зрелым, его первоначальный выпуск состоялся в 2005 году.

Puppet поставляется как бесплатное программное обеспечение с открытым исходным кодом, а для сложных инфраструктур также доступна проприетарная версия.

Для чего используется Puppet?

Puppet автоматизирует управление конфигурацией и развертывание серверов.

Программное обеспечение позволяет “дергать за ниточки” и управлять состоянием сразу нескольких систем, а такой подход сокращает ручную настройку и управление серверами по отдельности.

Puppet определяет желаемое состояние системы, а не то, как его достичь.

Конфигурация применяется к различным платформам и устройствам и поддерживает состояние во всей инфраструктуре.

В целом, системным администраторам меньше нужно тушить пожары, что позволяет команде DevOps внедрять новые и лучшие серверные решения.

Управление конфигурацией Puppet

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

Однако при работе с обширной инфраструктурой сценарии автоматизации не масштабируются.

Управление конфигурациями обеспечивает решение для обширных конфигураций инфраструктуры.

Эта практика считается основой DevOps и позволяет часто и более надежно выпускать программное обеспечение в рамках налаженного конвейера DevOps.

Управление конфигурацией сервера происходит благодаря подходу “инфраструктура как код”.

В случае с Puppet код управления сервером находится в коде Puppet, который похож на Ruby.

Этот язык является декларативным и описывает конфигурацию на основе моделей.

Как работает Puppet?

Puppet использует клиент-серверный подход и состоит из следующих систем:

Puppet Master – это сервер с демоном Puppet Master, который управляет важной системной информацией для всех узлов с помощью манифестов.

Агенты Puppet – это узлы с установленным на них Puppet с запущенным демоном Puppet Agent.

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

Топология и архитектура Puppet

Puppet использует архитектуру клиент/сервер, состоящую из Puppet Master и Puppet Agents.

Агенты Puppet используют режим pull для опроса мастера и получения информации о конфигурации конкретного узла и сайта.

Топология проходит через следующие шаги:

• Хост, на котором запущен демон Puppet Agent, собирает всю информацию (факты) о себе, и агент отправляет эти факты на Puppet Master.
• Puppet Master использует эти данные для создания каталога конфигурации хоста и отправляет его обратно Puppet Agent.
• Агент Puppet настраивает себя на основе каталога и отчитывается перед Puppet Master.

Puppet использует утилиту под названием Facter для обнаружения информации о системе.

Эта утилита по умолчанию поставляется вместе с установкой Puppet.

Puppet Master

Puppet Master – это демон, работающий на выделенном сервере.

Puppet Master – это источник информации и орган управления конфигурацией хоста сервера.

Мастер отправляет инструкции всем узлам-агентам и контролирует конфигурацию системы.

Puppet Master отвечает за выполнение следующих задач:

• Создание каталога для агентов.
• Передача файлов с файлового сервера агентам.
• Принятие SSL-сертификатов от агентов.
• Хранение конфигурационных манифестов.

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

Однако не все действия требуют повышенных привилегий.

Агенты Puppet

Агент Puppet – это демон Puppet, запущенный в системе или на хосте.

Агенты имеют определенные привилегии на узле, чтобы применять каталоги конфигурации, полученные от Puppet Master.

Для получения разрешений на связь агент запрашивает SSL-сертификат при первом контакте с мастером.

Сертификат проверяется каждый раз, когда агент запрашивает у мастера обновления конфигурации перед отправкой информации.

Мастер также аутентифицирует агентов, чтобы убедиться в правильности информации о конфигурации.

Агенты Puppet изменяют конфигурацию системы и требуют рутовых прав для выполнения задач.

Шифрование и безопасность в Puppet

Puppet использует OpenSSL для связи и безопасности.

Основываясь на протоколах SSL и TLS, Puppet использует стандартное шифрование SSL/TLS и SSL-сертификаты для аутентификации и проверки агентов/мастеров.

Кроме того, Puppet шифрует поток трафика между агентами и серверами с помощью SSL/TLS, используя SHA-256 в качестве хэша по умолчанию.

Методы шифрования в Puppet обеспечивают следующее:

• Аутентификацию и проверку подлинности мастера/агента.
• Предотвращение утечки данных между мастером и агентами.
• Мастер генерирует собственный сертификат ЦС, закрытый ключ, CRL (список отзыва сертификатов) и сертификат сервера. Сертификат сервера отправляется агентам для обеспечения связи SSL и TLS.

Преимущества Puppet и почему вы должны его использовать

Puppet – один из самых давних и популярных инструментов автоматизации управления конфигурацией.

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

1. Открытый исходный код

Puppet имеет открытый исходный код, что делает технологию расширяемой.

Пользовательские библиотеки и модули обогащают отдельные проекты в соответствии с вашими потребностями.

Преимуществом открытого исходного кода также является наличие активного сообщества.

Множество обсуждений, форумов и экспертов готовы помочь и ответить на вопросы.

2. Абстракция ресурсов

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

апомнить все команды – непосильная задача.

Facter помогает Puppet разобраться со спецификой и добиться абстракции.

Данные, относящиеся к конкретной системе, и детали ОС – все это знакомо Puppet благодаря Facter.

3. Идемпотентность

Избыточные конфигурации – сложная проблема при работе с многочисленными серверами, а Puppet стремится применять только те изменения, которые влияют на систему.

Если желаемое состояние инфраструктуры достигнуто, Puppet не выполняет команды.

Эта функция Puppet известна как idempotency, она помогает уменьшить избыточность и повысить эффективность.

4. Кросс-платформенность

Puppet охватывает широкий спектр платформ, что увеличивает количество серверов в процессе автоматизации конфигурации.

Инструмент работает на Windows, OS X, системах на базе Debian, Fedora, Gentoo, RHEL и Solaris.

5. Гибкиость

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

Puppet также помогает периодически планировать определенные действия по обслуживанию.

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

• ⏏️ Как установить Puppet Bolt для автоматизации задач сисадмина?
• Понимание основных компонентов Ansible – часть 1
• ☸️ Полный список инструментов DevOps

Источник: itisgood.ru