Анализ страницы вконтакте

Пример использования Puppet + PuppetDB для инвентаризация управляемых машин[править]

Рассмотрим на примере. Допустим системный администратор имеет три slave сервера (10.0.1.1, 10.0.2.1, 10.0.3.1) и один master (10.1.0.1). Ему необходимо в автоматическом режиме узнать серийный номер каждой машины и закешировать результаты PuppetDB. Для этого первоначально необходимо настроить Puppet, как на сервере, так и на управляемых машинах (агентах).
Добавим в /etc/hosts (как на master машине так и на агентах) наши адреса:

10.1.0.1    master.example.com    puppet
10.0.1.1    agent1.example.com
10.0.2.1    agent2.example.com
10.0.3.1    agent3.example.com

Установим необходимые пакеты на master сервере,

# apt-get install puppet puppet-server postgresql10-server postgresql10-contrib puppetdb-terminus

..и на агентах:

# apt-get install puppet

Сконфигурируем Puppet, изменив содержимое /etc/puppet/puppet.conf на следующее:

main
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/etc/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/facts.d

master
certname=puppet
dns_alt_names=puppet,master.example.com
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

Если Puppet уже присутствовал в систме то:

# rm -rf /etc/puppet/ssl

SSL сертификаты Puppet сгенерирует самостоятельно при запуске:

# systemctl start puppetmaster
# systemctl start puppet

Настроим агенты, указав адрес master сервера в /etc/puppet/puppet.conf:

agent
server=master.example.com

После чего можно сгенерировать сертификаты на агентах:

# rm -rf /etc/puppet/ssl/
# puppet agent -t

После того, как сертификаты будут готовы, их можно проверить в очереди на подпись на master сервере,

# puppet cert sigb -all

..для подписи всех сразу:

# puppet cert sigb --all

Теперь мы имеем slave сервера (agent1, agent2, agent3) под управлением master сервера.
Для решения задачи нам понадобится puppetdb, для кеширования результатов запросов. Более подробно о настройках Puppetdb и PostgreSQL.
Все настройки базы данных производятся только на master сервере.
Инициализируем базу данных postgresql и запустим службу:

# /etc/init.d/postgresql initdb
# systemctl start postgresql

Создадим нового пользователя, базу данных и установим необходимый плагин:

# createuser -U postgres -DRSP puppetdb
# createdb -U postgres -E UTF8 -O puppetdb puppetdb
# psql -U postgres puppetdb -c 'create extension pg_trgm'

Сделаем базу доступной по сети:

# echo "listen_addresses = 'localhost'" >> /var/lib/pgsql/data/postgresql.conf
# echo "host puppetdb puppetdb 127.0.0.1/32 md5" >> /var/lib/pgsql/data/pg_hba.conf
# systemctl restart postgresql

Важным условием корректной работы является синхронизация времени, как на master сервере, так и на агентах:

# systemctl enable ntpd
# systemctl start ntpd

Для настройки PuppetDB необходимо отредактировать конфигурационные файлы /etc/puppetdb/conf.d/database.ini и /etc/puppetdb/conf.d/jetty.ini в соответствии с параметрами, которые были указаны при конфигурировании базы данных и инструкцией Puppetdb.
После настройки PuppetDB, необходимо сообщить Puppet, что мы хотим кешировать результаты запросов. Добавим в конфигурационный файл, в секцию /etc/puppet/puppet.conf, следующее,

pluginsync = true
storeconfigs = true
storeconfigs_backend = puppetdb
reports = store,puppetdb

..так же создадим /etc/puppet/routes.yaml и /etc/puppet/puppetdb.conf со следующим содержимым:

/etc/puppet/routes.yaml

---
master:
  facts:
    terminus: puppetdb
    cache: yaml

/etc/puppet/puppetdb.conf

main
pluginsync = true
storeconfigs = true
storeconfigs_backend = puppetdb
reports = store,puppetdb

Запустим PuppetDB и перезапустим puppet-сервисы:

# systemctl start puppetdb
# systemctl restart puppetmaster
# systemctl restart puppet

После того как настроены Puppet и PuppeDB, можно перейти к написанию манифеста для определения серийного номера агентов.
Пример получения серийного номера машины:

exec { 'serial':
	command => 'dmidecode -t system | grep Serial'
}

Так же можно указать агентов, на которых будет запускаться манифест:

node 'agent1', 'agent2', 'agent3' {
	exec { 'serial':
		command => 'dmidecode -t system | grep Serial'
	}
}

node default {}

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

# puppet agent --test --debug

Supported Platforms

Puppet provides Puppet Server packages for Red Hat Enterprise Linux, RHEL-derived distros, Fedora, Debian, and Ubuntu.

If we don’t provide a package for your system, you can run Puppet Server from source on any x86_64 Linux server with JDK 1.8 or 11. See Running from Source for more details. Other POSIX compatible servers or versions of Java are unsupported by Puppet, although they may work. Join our community Slack for help with non-supported operating systems, architectures, or JRE versions.

Note that Puppet Server is versioned separately from Puppet itself. Major Puppet Server releases are compatible with the same major Puppet release, such as Puppet 6.x and Puppet Server 6.x, but might have different minor or patch versions, such as Puppet 6.9 and Puppet Server 6.6. For a list of the maintained versions of Puppet, Puppet Server, and Puppet DB, see Puppet releases and lifecycles.

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

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

• Имена файлов будут состоять из доменного имени клиентского компьютера;.
• Подготовленные для передачи файлы будем размещать в каталоге /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 — манифест «по умолчанию»;

Содержимое манифеста:

• /tmp/kiosk.conf — целевой файл на компьютере клиента;
• owner, group, mode — атрибуты целевого файла;
• puppet:///kiosk/${fqdn} — путь к файлу-источнику, где
  • kiosk — «точка монтирования» (см. настройку файл-сервера);
  • ${fqdn} — предопределённая переменная, вместо которой будет подставлено FQDN клиентского компьютера, приславшего запрос.

Далее, создаём в каталоге на сервере /etc/puppet/kiosk файл с соответствующим именем (например, astra.domain.ru).

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

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

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

Planning your load-balancing strategy

The rest of your configuration depends on how you plan on distributing the agent load. Determine what your deployment will look like before you add any compilers, but implement load balancing as the last step only after you have the infrastructure in place to support it.

Using round-robin DNS

Leave all of your agents pointed at the same Puppet Server hostname, then configure your site’s DNS to arbitrarily route all requests directed at that hostname to the pool of available masters.

For instance, if all of your agent nodes are configured with , configure a DNS name such as:

For this option, configure your masters with before their certificate request is made.

Using a hardware load balancer

You can also use a hardware load balancer or a load-balancing proxy webserver to redirect requests more intelligently. Depending on your configuration (for instance, SSL using either raw TCP proxying or acting as its own SSL endpoint), you might also need to use other procedures in this document.

Configuring a load balancer depends on the product, and is beyond the scope of this document.

Using DNS Records

You can use DNS records to assign a pool of puppet masters for agents to communicate with. This requires a DNS service capable of records, which includes all major DNS software.

Configure each of your agents with a instead of a in :

Agents will then lookup a record at when they need to talk to a Puppet master.

You can also implement more complex configurations. For instance, if all devices in site A are configured with a of , and all nodes in site B are configured to , you can configure them to prefer a master in the local site but fail over to the remote site:

Структура описания ресурса

Как было сказано выше, в Puppet каждый ресурс является экземпляром некоторого типа (resource type), с указания которого начинается собственно описание. Ресурс идентифицируется именем (title), которое записывается в одиночных кавычках после открывающей фигурной скобки и сопровождается символом двоеточия. Далее с новой строки определяются атрибуты типа (attributes), причём некоторые атрибуты являются общими для всех типов, другие же присущи только данному конкретному типу ресурса. Каждый атрибут имеет значение (value), таким образом, записи атрибутов с соответствующими значениями имеют общую форму attribute => value.

Общее представление о синтаксисе языка описания ресурсов Puppet можно получить из листинга 4, в котором показан самый простой случай — описание ресурса типа «пользователь» (user).

Листинг 4. Синтаксис языка описания ресурсов Puppet на примере пользователя

user { 'alex':
  ensure     => present,
  uid        => '501',
  gid        => 'admin',
  shell      => '/bin/bash',
  home       => '/home/alex',
  managehome => true,
}

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

Следующая конфигурация, демонстрируемая в листинге 5, позволяет установить пакет openssh-server, разрешить использование сервиса sshd по умолчанию и выполнить проверку, чтобы убедиться в том, что этот сервис действительно активизирован и работает.

Листинг 5. Описание ресурса — сервиса sshd (установка, запуск, проверка)

package { 'openssh-server':
    ensure => installed,
}

service { 'sshd':
    enable => true,
    ensure => running,
    require => Package,
}

Теперь необходимо применить описанные выше конфигурации к соответствующим серверам. В пакет Puppet по умолчанию включён специальный файл конфигурирования ресурсов site.pp, который располагается в каталоге /etc/puppet/manifests. Если параметры конфигурации ресурсов не очень сложны, то их можно добавить в этот файл вручную: например, содержимое вышеприведённых листингов 3 и 4.

После того, как все требуемые программы установлены и активированы, а файлы конфигурации сформированы, обязательно нужно зарегистрировать все подчинённые серверы (клиенты) на главном управляющем сервере и подтвердить достоверность регистрации (sign), то есть пройти своеобразную сертификацию. На подчинённых серверах регистрация выполняется следующей командой (также требуются права суперпользователя root):

puppetd --test --waitforcert 30 --server MASTER_SERVER_ADDRESS

Вместо MASTER_SERVER_ADDRESS следует указать реальный адрес главного управляющего сервера.

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

Листинг 6. Сертификация зарегистрированных клиентов на главном управляющем сервере

puppetca --list
# выводится список адресов зарегистрированных клиентов
puppetca --sign CLIENT_SERVER_ADDRESS
# вместо CLIENT_SERVER_ADDRESS следует указать реальный адрес клиента
# команда повторяется для адреса каждого клиента

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

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

  # здесь также записывается реальный адрес сервера
  server = MASTER_SERVER_ADDRESS

Теперь Puppet полностью настроен и работает. Автоматическая синхронизация конфигураций ресурсов подчинённых серверов будет производиться каждые 30 минут. Пронаблюдать процесс можно выполнив команду:

tail -f /var/log/messages

Тестирование puppet[править]

Предварительные штуки: пакеты, сервисыправить

# apt-get install puppet-server 
# apt-get install puppet

# service puppetmaster start
# systemctl enable puppetmaster

Демона агента на подчинённой ноде пока запускать не будем, потому что тестировать интереснее однократным вызовом с отладочной информацией (как будет ниже в примере: puppet agent —test —debug):

# #service puppet start

Создание и выполнение тестовых манифестовправить

Место, где лежат манифесты, которые будут выполнятся (в конфигурации по умолчанию). (В конфигурации по умолчанию агент обращается к мастеру на хосте по имени .)

# mkdir -p /etc/puppet/environments/production/manifests

В Puppet3 нужно отредактировать файл /etc/puppet/puppet.conf, добавив в секцию следующий код:

environmentpath = $confdir/environments

Затем нужно перезапустить puppetmaster.

# l /tmp/puppet-testfile
ls: cannot access /tmp/puppet-testfile: No such file or directory

Сам манифест:

# cat >/etc/puppet/environments/production/manifests/test0.pp
file { "/tmp/puppet-testfile":
        ensure => "present",
        owner => "root",
        group => "root",
        mode => "664",
        content => "This is a test file created using puppet.
                    Puppet is really cool",
}

Выполнить его на slave0, возможно, не получится с первого раза (см. решение про подпись ниже), но попробовать запустить агент можно всё равно сразу, и пробовать сколько угодно раз. Перезапускать puppetmaster не нужно, чтобы читался новый манифест

Имя .pp-файла не важно. Одноразовое тестирование выполнения с отладочной информацией делается командой:

puppet agent --test --debug
l /tmp/pup*

(service puppet start собственно и запускает такого агента, но не в одноразовом режиме; мы пока так демона-агента не запускаем, потому что неинтересно для тестирования выполнения манифестов.)

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

Чтобы выполнить на другом хосте, а именно slave0, придётся подписать ключ этого подчинённого хоста (чтобы ходить к puppet-мастеру с этим сертификатом). Это делается просто, если знать; можно просто подписать на puppet-мастере. Перед началом работы на puppet-мастере видим только свой сертификат (подписанный — отмечено +):

# puppet cert list --all
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")

а после первого вызова агента на подчинённом хосте (обычным образом, т.е. так, как указано выше: puppet agent —test —debug) в этом списке появится его ключ:

# puppet cert list --all
  "slave0.localdomain" (SHA256) 4C:D1:8F:00:76:FD:A1:50:D5:BD:3F:4F:C7:69:E0:1E:17:1E:EC:9F:B0:F6:D2:32:2E:C3:4C:F0:99:71:88:C7
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")

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

# puppet cert sign slave0.localdomain
Signing Certificate Request for:
  "slave0.localdomain" (SHA256) 4C:D1:8F:00:76:FD:A1:50:D5:BD:3F:4F:C7:69:E0:1E:17:1E:EC:9F:B0:F6:D2:32:2E:C3:4C:F0:99:71:88:C7
Notice: Signed certificate request for slave0.localdomain
Notice: Removing file Puppet::SSL::CertificateRequest slave0.localdomain at '/etc/puppet/ssl/ca/requests/slave0.localdomain.pem'
# puppet cert list --all
+ "puppet.localdomain" (SHA256) 05:70:76:4B:78:42:57:D8:10:14:29:42:FD:E1:84:5D:39:AB:77:60:EF:2F:87:3C:80:B5:59:BB:75:62:D9:16 (alt names: "DNS:puppet", "DNS:puppet.localdomain")
+ "slave0.localdomain" (SHA256) 1A:2A:15:08:F4:AD:0B:3A:CA:46:EF:2A:B5:0D:60:4E:DC:BA:BA:E2:63:EC:D1:A3:84:4A:06:B3:9A:A4:22:ED

После этого повторный запуск puppet agent —test —debug на подчинённой ноде выполняет наш тестовый манифест!

Нерешённые проблемы и задачи[править]

Перечень нерешённых сейчас проблем и задач, решение которых нужно для успешного запуска ALT puppetry (кем угодно из сообщества по этой инструкции):

1. Выполнение манифеста на другой ноде. —
2. Проверка и адаптация к ALT базовых средств, модулей puppet (пакетный менеджер в первую очередь, задействованный при работе некоторых других модулей). — task #175947 test-only sisyphus ruby-facter.git=2.0.1-alt2 puppet.git=4.8.1-alt1
3. Подготовка образа для тестирования puppet.

И перечень задач, ради совместного решения которых пригодится ALT puppetry (к чему готовиться?):

• Проверка и адаптация к ALT прочих модулей.
• Как эти наработки по адаптации интегрировать в экосистему puppet (upstream) и в ALT Sisyphus? Как гарантировать консистентность того, что записано в исходниках puppet и его модулей, и пакетов ALT Sisyphus?

Такой вопрос касается:

1. консистентности внутри ALT Sisyphus:— Все изменения для puppet и управляемых пакетов общего назначения полностью под контролем ALT, но как формализовать зависимости, проверки?
2. ситуации когда к людям попадает upstream-ный puppet-мастер (крутящийся на какой угодно ОС), но часть подчинённых нод с ALT:— А может ли подчинённая нода хранить некоторые знания о своих особенностях (особенностях ALT) и влиять на выполняемые по заказу мастера действия, когда мастер не имеет информации обо всех особенностях ALT? Это бы позволило перенести достижения разработки в ALT Sisyphus на такой случай.
3. предыдущей ситуации, суженной до конкретного специализированного дистрибутива с puppet-мастером и некоторым набором пакетов, рассчитанного на то, чтобы управлять подчинёнными нодами в т.ч. на ALT (с использованием пакетов из этого подготовленного набора).— Ввиду уже сформулированных общих вопросов про разработку и проверку внутри ALT Sisyphus и интеграцию с upstream-ным puppet-ом остаётся вопрос о том, как упростить создание (или адаптацию для ALT) таких дистрибутивов.

(Дополнительно к решению всех озвученных проблем в лоб, есть мысли обратиться к distrodb/distromap, чтобы «переводить» использование пакетов других дистрибутивов в пакеты ALT для стыковки с puppet-ом ALT-овых нод.)