Что такое puppet в linux

Обновлено: 02.07.2024

Для управления конфигурациями серверов, их обслуживания на всём жизненном цикле имеет актуальное значение связка работы трёх компонентов: foreman, puppet, ansible.

  • Foreman - инструмент, предназначенный для помощи системным администраторам в управлении серверами, обеспечивающий простой способ взаимодействия с системами управления конфигурациями (Ansible, Puppet и др.) для автоматизации задач администрирования и развертывания приложений. Foreman поддерживает web-интерфейс, API и CLI, которые можно использовать для предоставления, настройки и мониторинга серверов. Подходит для инфраструктур любых размеров.
  • Puppet - инструмент управления конфигурацией, который помогает системным администраторам автоматизировать предоставление, настройку и управление серверной инфраструктурой.
  • Ansible - система управления конфигурациями, использующаяся для автоматизации настройки и развертывания программного обеспечения. Позволяет автоматизировать сложные задачи, например, непрерывное развертывание или непрерывное обновление без простоев.

Сервер: 10.0.2.120 master.astra.lan

Клиент: 10.0.2.121 agent1.astra.lan

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

На стенде отсутствует настроенный DNS-сервер, поэтому для разрешения IP-адресов используются файлы /etc/hosts на сервере и на клиенте.

Настройка сервера

Имя и адрес сервера

Коммуникация между Puppet Server и Puppet Agent осуществляется по имени хоста. Для правильной работы нужно либо настроить DNS-сервер, либо указать адреса хостов в файлах /etc/hosts на всех хостах.
Для сервера используем имя master.astra.lan, и команда назначения имени будет иметь следующий вид (команда выполняется на сервере):

sudo hostnamectl set-hostname master.astra.lan

Осуществить настройку каждой машины через файл /etс/hosts, для чего внести в файл указание IP-адреса Puppet Server (10.0.2.120) и его имён (master.astra.lan, master и pupet). В итоге файл /etc/hosts на сервере должен выглядеть примерно так:

Подразумевается, что серверу назначен статический IP-адрес 10.0.2.120, а клиенту - 10.0.2.121.

Настройка локалей на сервере.

Проверить наличие локали en_US.utf8 выполнив команд у:

locale -a | grep en_US.utf8

Если локали en_US.utf8 нет, то добавить её, выполнив следующие команды

echo "en_US.UTF-8 UTF-8" | sudo tee -a /etc/locale.gen
sudo locale-gen

Или можно выбрать нужные локали, включая локаль en_US.UTF-8 UTF-8 , в интерактивном режиме, выполнив следующие команды:

Установка Puppet Server

Для установки выполнить на сервере следующие команды:

sudo apt update
sudo apt install puppetserver

Для коммуникации Puppet Server использует IP-порт 8140. Если включен межсетевой экран, то разрешить коммуникации через этот порт. Для сетевого экрана ufw:

Разрешить автоматический запуск Puppet Server и запустим его:

sudo systemctl enable puppetserver
sudo systemctl start puppetserver

Проверить статус сервиса:

sudo systemctl status puppetserver

Имя и адрес клиентского компьютера

Настроить статический IP-адрес сервера (далее - 10.0.2.121)

Задать имя компьютера:

sudo hostnamectl set-hostname agent1.astra.lan

Настроить разрешение имён сервера и клиента с помощью файла /etc/hosts. Файл /etc/hosts на клиентском компьютере должен иметь примерно такой вид:


Можно просто скопировать ранее созданный файл /etc/hosts с сервера.

Установка агента

Для установки агента выполнить на компьютере-агенте следующие команды (при этом будет установлен агент и сервер SSH для удалённого управления агентом):

sudo apt update
sudo apt install puppet-agent ssh

Отредактировать файл /etc/puppetlabs/puppet/puppet.conf, добавив/заменив в секции main параметры:

Для коммуникации агент, как и Puppet Server, использует IP-порт 8140. Если включен межсетевой экран, то разрешить коммуникации через этот порт. Для сетевого экрана ufw:

Добавить службу Puppet Agent в автозагрузку и запустить её:

sudo systemctl enable puppet
sudo systemctl start puppet

Настройка доступа по ssh

На клиентской машине задать пароль root и разрешить root-доступ по ssh, для чего в файле /etc/ssh/sshd_config раскомментировать параметр PermitRootLogin, изменить его значение на yes и перезапустить сервер SSH (команды выполняются на клиентской машине):

Подписание сертификатов клиента

При первом запуске клиентская служба Puppet Agent отправит на Puppet Server запрос на подпись сертификата. Для просмотра списка запросов на подпись сертификата выполнить на сервере следующую команду:

Requested Certificates: agent1.astra.lan (SHA256) F7:D5:E5:AB:AA:86:7F:EF:19:3D:D9:B9:E3:E9:63:DC:AE:31:17:57:67:3D:2B:D7:A5:1C:71:E3:46:E0:A7:1E

В примере выше сервер сообщает, что у него имеется один запрос на подпись сертификата от клиента с именем agent1.astra.lan.

Successfully signed certificate request for agent1.astra.lan

Для проверки правильности работы агента можно на клиентской машине после подписания сертификата выполнить следующие команды:

sudo systemctl stop puppet

Выполнить тестирование работы службы, в процессе которого служба запросит и получит сертификат:

Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for agent1.astra.lan
Info: Certificate Request fingerprint (SHA256): F7:D5:E5:AB:AA:86:7F:EF:19:3D:D9:B9:E3:E9:63:DC:AE:31:17:57:67:3D:2B:D7:A5:1C:71:E3:46:E0:A7:1E
Info: Downloaded certificate for agent1.astra.lan from puppet
Info: Using configured environment 'production'
Info: Retrieving pluginfacts Info: Retrieving plugin
Info: Retrieving locales
Info: Caching catalog for agent1.astra.lan
Info: Applying configuration version '1568370748'
Info: Creating state file /opt/puppetlabs/puppet/cache/state/state.yaml Notice: Applied catalog in 0.02 seconds

Повторно запустить службу:

sudo systemctl start puppet

Установить пакеты Ansible и Foreman, выполнив на сервере следующие действия:

Установить пакет ansible из репозитория:

sudo apt install ansible

Настройка /etc/ansible/hosts

Отредактировать файл /etc/ansible/hosts, добавив в файл секцию [agents] (т.е. добавив группу серверов, с названием этой группы agents). В этой группе пока будет один сервер с именем agent1.astra.lan и IP-адресом 10.0.2.121:

echo -e "agents:\n hosts:\n agent1.astra.lan:\n ansible_user: root" | sudo tee -a /etc/ansible/hosts

В результате файл /etc/ansible/hosts должен иметь следующий вид:

Ansible использует подключение ssh без запроса пароля по ключу, поэтому нужно сгенерировать ключ:

И после создания ключа передать его на нужные узлы:

Проверить работу Ansible, выполнив пинг на группу серверов agents:

agent1.astra.lan | SUCCESS => "changed": false,
"ping": "pong"
>

Базовая настройка Foreman

В случае, если ОС была установлена без графической оболочки, то установить пакет shared-mime-info, команда:

sudo apt install shared-mime-info

Установить пакет foreman-installer:

sudo apt install foreman-installer

Перед выполнением дальнейших действий следует проверить, что в файле /etc/debian_version указано значение 9.0, и, если там указано иное значение, заменить его на 9.0.

Запустить установщик:

После установки в строке "Initial credentials are admin / . " будет указан логин admin и указан автоматически созданный пароль для входа в web-интерфейс, его рекомендуется запомнить чтобы использовать для входа в web-интерфейс.В дальнейшем пароль возможно изменить с помощью команды:

sudo foreman-rake permissions:reset username=admin password=<новый_пароль>

Проверить работоспособность foreman-proxy:

Foreman + Puppet


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

Перейти в "Узлы" - "All hosts" ("Hosts" -> "All Hosts" в английском варианте), где должен появится список доступных узлов:


Если узлы отсутствуют, то подождать, пока информация обновится, или на нужных узлах (на клиенте) выполнить команду:

sudo systemctl restart puppet

После чего обновить страницу web-интерфейса.

Убедиться, что в "Инфраструктура" - "Капсулы" ( в английском варианте "Infrastructure" -> "Smart Proxies") имеется отображение созданного по умолчанию proxy. Если proxy не создан, то:

  • Перейти в "Администратор" - "Местоположения" ("Administer" - "Locations");
    • Выбрать Default location;
    • Нажать кнопку "Устранить несоответствия" ("Fix mismatches");
    • Нажать кнопку "Применить" ("Submit");
    • Выбрать Default organization;
    • Нажать кнопку "Устранить несоответствия" ("Fix mismatches");

    После выполнения этих шагов в "Инфраструктура" - "Капсулы" ( в английском варианте "Infrastructure" -> "Smart Proxies") появится отображение созданного по умолчанию proxy.

    Foreman + Ansible

    Установить необходимые плагины:

    для работы с Ansible: foreman-plugin-ansible, foreman-proxy-plugin-ansible;

    для запуска Ansible playbooks как запланированные задачи: foreman-plugin-remote-execution, foreman-proxy-plugin-remote-execution-ssh

    Создать и скопировать ключ для работы каждого клиента с сервера (команда выполняется на сервере от имени пользователя foreman-proxy):

    sudo -u foreman-proxy ssh-keygen -f

    foreman-proxy/.ssh/id_rsa_foreman_proxy -N ''
    sudo -u foreman-proxy ssh-copy-id -i

    Проверить работу связки можно запустив Ansible playbook. Запустить Ansible playbook можно несколькими способами (при этом нужно будет указать команду или сценарий для выпонения на удалённой машине):

    1. Через список узлов (хостов):
      1. открыть страницу "Узлы" ("Узлы" -> "All Hosts");
      2. выбрать необходимые узлы;
      3. нажать "Действия" -> "Scheduled Remote Job";
      1. открыть страницу "Узлы" ("Узлы" -> "All Hosts");
      2. перейти на страницу нужного узла и нажать "Scheduled Remote Job" -> "Run Ansible roles";
      1. открыть страницу "Шаблоны заданий"
      2. напротив нужного шаблона нажать "Выполнить"

      Ansible-роли могут быть импортированы из смарт-прокси. Для этого необходимо:

      1. Часть I: статья «Установка, настройка, начало эксплуатации». <— Вы здесь!
      2. Часть II: статья «Манифесты, синтаксис, команды».

      На чем было опробовано:

      1. CentOS Linux release 7.9.2009 (Core).
      2. Puppet 3.8.7 (master+agent).

      1. Введение.

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

      Хороший админ — ленивый админ. Он не любит делать что-то несколько раз.

      Первая мысль — написать пару скриптов:

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

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

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

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

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

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

      2. Что такое Puppet?

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

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

      Используется pull-модель работы: по умолчанию раз в полчаса клиенты обращаются к серверу за конфигурацией и применяют её. Если вы работали с Ansible, то там используется другая, push-модель: администратор инициирует процесс применения конфигурации, сами по себе клиенты ничего применять не будут.

      При сетевом взаимодействии используется двустороннее TLS-шифрование: у сервера и клиента есть свои закрытые ключи и соответствующие им сертификаты. Обычно сервер выпускает сертификаты для клиентов, но в принципе возможно использование и внешнего CA (Certificate Authority Server).

      Puppet позволяет просто настроить и впоследствии быстро управлять практически любой сетью на базе любой операционной системы. Система Puppet достаточно популярна в среде IT-компаний.

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

      2.1. Архитектура Agent / Master.

      В этой архитектуре один или несколько серверов запускают главное приложение Puppet, обычно как приложение Rack, управляемое web-сервером (например, Apache с Passenger), а приложение агента Puppet работает на клиентских серверах, обычно как фоновая служба.

      2.2. Автономная архитектура.

      В этой архитектуре клиентские серверы запускают приложение Puppet Apply (автономное сочетание приложений Puppet Master и Puppet Agent), обычно как запланированное задание или задание cron.

      3. Знакомство с манифестами.

      Puppet DSL — декларативный язык. На нём описывается желаемое состояние ноды в виде объявления отдельных ресурсов, например:

      • Файл существует, и у него определённое содержимое.
      • Пакет установлен.
      • Сервис запущен.

      Ресурсы могут быть взаимосвязаны:

      • Есть зависимости, они влияют на порядок применения ресурсов.
        • Например, «сначала установи пакет, затем поправь конфигурационный файл, после этого запусти сервис».
        • Например, если изменяется конфигурационный файл, можно автоматически перезапускать сервис.

        Кроме того, в Puppet DSL есть функции и переменные, а также условные операторы и селекторы.

        Puppet поддерживает шаблоны в формате EPP и ERB :

        Puppet написан на Ruby, поэтому многие конструкции и термины взяты оттуда. Ruby позволяет расширять Puppet — дописывать сложную логику, новые типы ресурсов, функции.

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

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

        4. Подготовка инфраструктуры.

        Для настройки архитектуры Agent/Master, потребуется подготовить свое рабочее окружение. Для демонстрации программного обеспечения Puppet создадим 4 виртуальных машины на базе операционной системы CentOS 7.


        Puppet master

        Puppet clients

        Operating system: CentOS 7 minimal

        IP Address: 192.168.0.17
        HostName: puppet-srv.hamsterden.locm

        Operating system: CentOS 7 minimal

        IP Address: 192.168.0.14
        HostName: puppet-cl14.hamsterden.loc

        IP Address: 192.168.0.15
        HostName: puppet-cl15.hamsterden.loc

        IP Address: 192.168.0.16
        HostName: puppet-cl16.hamsterden.loc

        5. Первые шаги на серверах.

        5.1. Как временно или навсегда отключить SELinux.

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

        Конечно в интернете имеется много способов настройки и эксплуатации этой системы, но в данной инструкции я, настраивать SELinux не буду.

        5.2. Настройка часового пояса и синхронизации времени.

        Внимание! Сервис Puppet крайне чувствителен к синхронизации времени между сервером и агентами. Рассинхронизация даже в несколько минут может приводить к отказу в обслуживании.

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

        Чтобы время на сервере CentOS 7 соответствовало вашему часовому поясу, его можно изменить вручную.

        Для корректной работы сервера требуется правильно настроить его синхронизацию времени по Network Time Protocol.

        5.3. Первичная настройка брандмауэра.

        По умолчанию в системе CentOS 7 нет сервиса Puppet, но мы можем открыть порт 8140 для работы Puppet master вручную.

        Для этого просто добавьте нужный порт 8140 к зоне:

        Чтобы удалить порт 8140 из зоны, выполните:

        Аналогично сервисам, чтобы открыть порт в firewall в CentOS 7 надо перезагрузить брандмауэр:

        Ответы:


        6. Настройка Puppet master сервера.

        Устанавливаем Midnight Commander:

        Puppet чувствителен к именам узлов, поэтому задаем имена сервера и тестового клиента в файле hosts:

        Модифицируем содержимое файла, добавим в конце файла:

        Также зададим имя нашего Puppet master сервера:

        Модифицируем содержимое файла:

        Сначала установим репозиторий для Puppet 3 версии на Puppet master:

        Устанавливаем Puppet:

        Разрешаем автозапуск puppet-сервера:

        По умолчанию, Puppet настроен для оптимальной работы.

        Единственное, что мы сделаем, включим автоматическое подтверждение сертификатов от клиентов:

        Модифицируем содержимое файла:

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

        Для этого отредактируем основной манифест-файл:

        Добавим в содержимое файла:

        Данная строчка означает, что мы будем подгружать все файлы с расширением *.pp из каталога /etc/puppet/manifests/nodes .

        Создаем каталог nodes :

        В качестве теста, создадим первый манифест-правило:

        Модифицируем содержимое файла files.pp :

        Правило создаст файл hello-file , если его нет, в каталоге /tmp . Задаст ему владельца root и группу-владельца wheel. Добавит в него текст «From Puppet» и задаст права 0644 .

        Запускаем службу Puppet:

        7. Настройка Puppet node / Puppet client (агентов).

        Заходим в каждую систему по списку клиент-серверов под root:

        Обновляем список пакетов:

        Устанавливаем Midnight Commander:

        Задаем имя сервера Puppet master в файле hosts :

        Просто добавьте в конце текста в файле эту строку:

        Также зададим имя Puppet клиента, соответствующего порядковому номеру из списка:

        Просто добавьте в файл эту строку, взамен старой информации:

        Чтобы все изменения вступили в силу желательно перезапустить службу (сервис) systemd-hostnamed:

        Чтобы увидеть имя хоста сервера в CentOS 7 воспользуйтесь командой hostnamectl:

        Устанавливаем Puppet:

        Редактируем конфигурационный файл Puppet:

        Просто добавьте эти строки по аналогии в соответствующий раздел файла:

        Запускаем Puppet:

        Проверяем подключение клиента puppet-cl14.hamsterden.loc к серверу puppet-srv.hamsterden.loc :

        Если вы все правильно настроили, результатом выполнения данной команды будет создание файла /tmp/hello-file .

        Проверяем на клиенте сработало ли правило с мастера?

        Должен быть создан файл hello-file , в каталоге /tmp , с владельцем root и группой-владельца wheel. Внутри файла должен быть текст «From Puppet» и заданы права 644 .



        Всё настроено исправно и программа выполняется!

        Или выскочит ошибка:


        8. Тестирование работы системы Puppet.

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

        Протестируем работу режима Puppet apply, напишем манифест самому себе, то есть для Puppet master сервера.

        В качестве теста, создадим манифест-правило:

        Модифицируем содержимое файла:

        И применим его в режиме автономной архитектуры:

        Ответ:


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


        Вы можете сказать, что можно было сделать echo "Hello, world!" > /tmp/helloworld , это было бы быстрее.

        На самом деле, необходимо было бы написать:

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

        8.2. Описание ноды и ресурса на ней.

        Установим Puppet agent на остальные виртуальные машины, по аналогии с текстом инструкции выше.

        На ноде puppet-cl14.hamsterden.loc должен быть создан файл /etc/issue.test с содержимым "CentOS 7 Hello" . Файл должен принадлежать пользователю и группе root , права доступа должны быть 0644 .

        В качестве теста, создадим манифест-правило:

        Права на файл заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано.

        Зайдем на puppet-cl14.hamsterden.loc :

        И запросим манифесты с Puppet master для puppet-cl14.hamsterden.loc :

        Агент запросит манифесты с сервера и выполнит их. В ответе несколько манифестов на выполнении, в том числе и тот, пример которого мы сейчас с вами сделали.

        Ответ:


        На puppet-cl14.hamsterden.loc что-то пошло не так.

        Ответ с puppet-cl14.hamsterden.loc :


        Зато puppet-cl15.hamsterden.loc цветет и пахнет.

        Ответ с puppet-cl15.hamsterden.loc :


        Так что если что-то работать не будет сразу или не на всех Puppet node, то смотрите логику манифестов и их алгоритм работы, возможно вы допустили ошибку.

        8.3. Взаимосвязи ресурсов на ноде.

        На ноде puppet-cl14.hamsterden.loc должен быть запущен nginx, работающий с подготовленной заранее конфигурацией.

        • Создать файл оригинального репозитория nginx.
        • Нужно, чтобы был установлен пакет nginx.
        • Нужно, чтобы был запущен сервис nginx.
        • В случае обновления конфигурации нужно перезапускать сервис.

        Создадим манифест-правило не для всех нод, а только для puppet-cl16.hamsterden.loc :

          -> Прямая стрелка ( -> ) говорит о том, что ресурс ниже должен создаваться после ресурса, описанного выше.

        Зайдем на puppet-cl14.hamsterden.loc :

        И запросим манифесты с Puppet master для puppet-cl16.hamsterden.loc :

        Ответ:


        Проверим стартанул ли сервис после автоустановки nginx без нашего участия?

        Ответ:


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

        Все остальные шаблоны легко можно найти на просторах интернета.

        9. Возможные ошибки или если что-то пошло не так.

        9.1. Удаление сертификатов.


        Иногда на Puppet master забыли пробросить порт 8140 или необходимо удалить битый сертификат.

        Будем считать, что порт 8140 проброшен и займёмся сертификатом.

        Для этого сначала выполняем команду на сервере:


        Затем, деликатно, на клиенте:

        Или, чтоб наверняка, бахнем всё:


        Если всё рано выскакивает ошибка, то уже точно на Puppet master не проброшен порт 8140 и его отсекает межсетевой экран. Отключите брандмауэр или настройте проброс порта.


        10. Как узнать версию Puppet.

        Более новые версии, отличные от версии Puppet 3, используют другую командную строку.

        Команда для Puppet 3 будет соответственно:

        Для версий до Puppet 4.0, если Puppet был установлен как пакет RPM, вы можете запросить базу данных RPM:

        Ответ:


        Для любителей Debian / Ubuntu / Mint, пакет запроса будет: dpkg -l | grep puppet .

        Puppetlabs изменили свою упаковку, и упакованная версия Puppet не указана номером версии пакета puppet-agent.

        11. Полезные команды.

        11.1. Проверка текущих параметров.

        Для проверки всех текущих параметров Puppet сервера есть полезная команда:

        Ответ: большой и длинный список параметров и их значений.

        11.2. Проверка состояния сертификатов.

        Для проверки списка сертификатов:

        Если с плюсом, значит подписан.

        Ответ:


        Если он без плюса, значит его надо подписать:

        Итог должен появиться в /var/lib/puppet/ssl . Если что то пошло не так всё там стираем и повторяем заново.

        Ответ:


        12. Готовые конфигурации из репозиториев.

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

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

        13. Примеры манифестов.

        Задает права и владельца для файла /etc/passwd :

        Устанавливает последнюю версию пакета samba:

        Содержание

        Как правило, пакеты puppet входят в стандартные репозитории операционных систем, и называются puppet и puppet-server. Их установка требует наличия ruby.

        Основными файлами конфигурации являются auth.conf, puppet.conf (англ.) и fileserver.conf, расположенные по умолчанию в /etc/puppet

        Для того, чтобы puppet работал:

        • у клиента должна быть возможность соединиться с мастером по IP адресу и имени компьютера (последнее особенно важно, так как SSL сертификаты подписываются с учётом указанного имени). Для этого может потребоваться у клиента в файле /etc/hosts прописать строку с IP адресом и именем host или корректная настройка dns-сервера:
        • должны быть открыты исходящие соединения для Puppet на порту 8140 для работы и 8139 для передачи обратных отчётов (или фаервол полностью отключен);
        • должны быть синхронизированы часы (из практических соображений, так как часть команд может задаваться с привязкой ко времени и используемое SSL шифрование тоже имеет привязку к времени существования сертификатов).

        Для того чтобы клиенту знать, где собственно искать мастера, необходимо в файле puppet.conf добавить строку:

        вы заставите клиента при аутентификации на мастере всегда представляться как workstation. Данная настройка упрощает управление, позволяя задавать имена, соответствующие определённой целевой группе клиентов.

        Запрос сертификата у сервера и тестовый запуск puppet (без активации службы), но при этом происходит подключение к серверу и применение всех доступных конфигураций можно выполнить как:

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

        Подписать сертификат и, соответственно, разрешить доступ клиенту можно командой:

        В версиях менее третьей надо было использовать эти команды в двух вариантах, заменив puppet cert = puppetca.

        Может содержать следующие настройки:

        Их иногда называют рецептами, представляют собой текстовые файлы с расширением .pp (По умолчанию выполняется $confdir/manifests/site.pp). В манифесте могут и должны содержаться:

        • Классы (class)
        • Узлы (node)
        • Ресурсы (то есть типы file, user и др.)
        • Ссылки на другие манифесты (import)

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

        При вызове класса freebsd для файлов атрибут group изменится на wheel, а вот атрибут owner не будет проверяться вообще. Значение атрибутов можно не заменять а добавлять:

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

        Позволяет управлять файлами и директориями.

        Позволяет управлять подключенными репозиториями, посредством изменения /etc/yum.conf. Большинство параметров аналогичны man yum.conf.

        Позволяет управлять системными службами.

        Позволяет выполнять консольные команды, скрипты непосредственно при запуске puppet.

        При этом onlyif может проверять массив команд и выполнить основную команду только тогда, когда все команды массива выполнятся:

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

        Позволяет управлять пользователями.

        Позволяет управлять группами пользователей.

        Обращение в коде puppet к классам будет выглядеть как:

        Для того, чтобы модуль вообще заработал достаточно иметь папку с именем модуля, папку с манифестами и начальным манифестом init.pp.
        По аналогии выстраиваем под_под_классы и под_под_…под_классы, пока не надоест.
        Требуется, чтобы в каждом из файлов «класс1» … «под_класс1» был один и только один класс с соответствующим именем: «имя_модуля::класс1» … «имя_модуля::класс1::под_класс1». При этом файл init.pp должен содержать класс с именем «имя_модуля».
        Получить доступ к файлам модуля можно, например, по адресу puppet:///modules/имя_модуля/.
        Из директории lib можно запускать исполняемые файлы с Ruby-кодом, чтобы расширить возможности Puppet и Facter (поставщика переменных).

        Окружения (environments) нужны для полного разделения конфигураций. У каждого окружения свои модули и манифесты. Это можно сравнить с использованием разных серверов puppet master.

        Если не указано, с версии 4.0 будет использоваться окружение production.

        В версиях 3.5, 3.6, 3.7 Open Source, 3.8 для использования «directory environments» прописываем в секцию [main] или [master] файла /etc/puppet/puppet.conf:

        В более новых версиях указывать ничего не нужно.

        В конфигурации агента (секция [agent] в файле /etc/puppet/puppet.conf) надо указать, какое окружение он будет использовать, например:

        После подключения, используются манифесты из каталога окружения, например, /etc/puppet/environments/production/manifests/.

        В манифестах можно использовать переменную $environment с именем текущего окружения.

        Система управления конфигурациями Puppet входит в состав дистрибутивов Astra Linux.
        По состоянию на декабрь 2018 в состав дистрибутивов входит версия 4.8.2.
        В Astra Linux Special Edition пакеты Puppet находятся на диске со средствами разработки.

        Сервер

        Для установки сервера:

        При установке серверного пакета puppet-master автоматически установится пакет агента puppet.
        После установки сервис puppet-master должен запуститься автоматически.
        Проверка установки с помощью стандартных команд:

        Проверка установки с помощью агента puppet:

        Клиентский компьютер

        Для установки агента на клиентском компьютере выполнить команду:

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

        Сервер

        Конфигурационные файлы сервера находятся в каталоге /etc/puppet/.
        К выполнению базовых действий и подключению агентов сервер puppet-master готов сразу после установки.

        Файл-сервер

        При установке сервера не включается автоматически сервис по передаче файлов на клиентские компьютеры.
        Для его включения нужно в каталоге конфигурационных файлов создать дополнительный файл с именем fileserver.conf и с указаниями, какие файлы где расположены, например:

        [kiosk]
        path /etc/puppet/kiosk
        allow *

        • kiosk - так называемая "точка монтирования", имя, по которому сценарии будут выбирать нужные пулы файлов;
        • path /etc/puppet/kiosk - путь в локальной файловой системе, указывающий каталог, который будет "примонтирован" в "точку монтирования";
        • allow * - разрешение на чтение для всех агентов;
        Подробные настройки правил доступа находятся в файле /etc/puppet/auth.conf

        Соответственно, нужно создать каталог /etc/puppet/kiosk/ и разместить в нём файлы для передачи.
        См. пример ниже.

        Клиентский компьютер

        Конфигурационные файлы агента находятся в каталоге /etc/puppet/ на клиентском компьютере.
        (Агент, установленный на сервере, имеет конфигурационный файл общий с сервером).

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

        Имя сервера также можно указать, добавив адрес сервера в файл /etc/hosts.
        Имя сервера по умолчанию puppet и задается в конфигурационном файле /etc/puppet/puppet.conf:

        Соответственно, в файл /etc/hosts можно добавить строчку с адресом сервера вида

        Агент после установки должен зарегистрироваться на сервере и получить сертификаты.
        Для этого на компьютере-клиенте выполнить команду:

        sudo puppet agent --test --waitforcert 60

        При первом запуске агент попытается связаться с сервером, получит отказ по причине отсутствия у агента сертификата доступа, и самостоятельно выпустит и отправит на сервер запрос на получение сертификата.
        Необязательный ключ --waitforcert указывает агенту ждать подписанный сертификат в течение определённого времени (в данном примере 60 секунд).
        Если ключ не указать, то агент попытается получить подписанный сертификат при следующем запуске.

        Подписание сертификата агента

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

        Проверить список полученных запросов и сертификатов:

        Копирование файла

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

        • Имена файлов будут состоять из доменного имени клиентского компьютера;.
        • Подготовленные для передачи файлы будем размещать в каталоге /etc/puppet/kiosk/ на сервере;
        • При получении файлы будем размещать в каталоге /tmp/ на клиентском компьютере в файле с одинаковым для всех компьютеров именем kiosk.conf, т.е. /tmp/kiosk.conf;
        • Файлы на клиентском компьютере будут иметь владельцев root:root и права доступа 600;

        Настройка файлового сервера (/etc/puppet/fileserver.conf) была приведена выше:

        Сценарий действий (в терминах puppet - манифест) поместим в каталог на сервере /etc/puppet/code/environments/production/manifests/site.pp.

        Подробно про размещение манифеста:

        • каталог /etc/puppet/code - общий каталог для размещения данных для клиентов;
        • каталог /etc/puppet/code/environments - каталог для размещения данных в зависимости от выбранного параметра "environment";
        • каталог /etc/puppet/code/environments/production - каталог для размещения данных для значения параметра "environment" равного "production" (значение по умолчанию);
        • каталог /etc/puppet/code/environments/production/manifests - каталог для размещения манифестов
        • файл /etc/puppet/code/environments/production/manifests/site.pp - манифест "по умолчанию";
        class passwd <
        file < "/tmp/kiosk.conf":
        owner => root,
        group => root,
        mode => "600",
        source => " puppet:///kiosk/$"
        >
        >
        node default <
        include passwd
        >
        • /tmp/kiosk.conf - целевой файл на компьютере клиента;
        • owner, group, mode - атрибуты целевого файла;
        • puppet:///kiosk/$ - путь к файлу-источнику, где
          • kiosk - "точка монтирования" (см. настройку файл-сервера);
          • $ - предопределённая переменная, вместо которой будет подставлено FQDN клиентского компьютера, приславшего запрос.

          И вызываем на клиентском компьютере агента для проверки (опции --verbose и --debug включают отладочную диагностику):

          puppet agent --test --verbose --debug

          Если всё в порядке - вызываем агента для исполнения (опция --onetime – разовый вызов):

          После чего в каталоге /tmp должен появиться файл /tmp/kiosk.conf

          Выполнение команды на клиентском компьютере

          Дополним предыдущий пример манифеста созданием архивной копии скопированного файла.

          Для этого с помощью puppet выполним на клиентском компьютере команду

          Команды выполняются агентом на клиентском компьютере с помощью клиентского shell-ла, соотвественно, в командах работают все подстановки.

          node default include passwd
          >

          Подробная документация по системе puppet доступна по ссылке: Документация Puppet 4.8

          Читайте также: