Доброго времени суток, жителям Хабра!Когда число управляемых серверов достигает нескольких десятков, а то и сотен, приходится искать решение по автоматической настройке и управлению таким парком. Тут на помощь приходит Puppet. Почему Puppet? Puppet кроссплатформенный, имеет богатое сообщество, имеет множество готовых модулей (4800+), имеет Enterprise версии. Все эти плюсы не дают усомнится в мощи данного продукта. Но управлять из консоли таким «комбайном» не так просто. Потому для удобного управления и настройки Puppet был разработан Foreman. Далее установка и настройка этой связки на примере задачи управления SSH-ключами.
Требования:
- чистый сервер для puppet-мастер;
- команды на сервере puppet-мастер выполняются как root;
- команды на серверах puppet-агент выполняются через sudo.
Используемое ПО:
- ОС Ubuntu 14.04.5 LTS;
- Puppet 3.8.7;
- Foreman 1.11.4.
Цели:
- получить удобный способ автоматизированного управления инфраструктурой сети;
- получить удобный способ управления ssh-ключами.
Примечание
Все скриншоты и кусок конфигурации скрыты спойлерами. Для лучшего понимания, где выполняются команды, перед каждой командой добавил тип сервера (master или agent).
1. Установка Foreman + Puppet на puppet-мастера
Добавим репозиторий установщика Foreman/Puppet и установим его в систему:
master ~ $ apt-get -y install ca-certificates
master ~ $ cd ~ && wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
master ~ $ dpkg -i puppetlabs-release-trusty.deb
master ~ $ sh -c 'echo "deb http://deb.theforeman.org/ trusty 1.11" > /etc/apt/sources.list.d/foreman.list'
master ~ $ sh -c 'echo "deb http://deb.theforeman.org/ plugins 1.11" >> /etc/apt/sources.list.d/foreman.list'
master ~ $ cd ~ && wget -q http://deb.theforeman.org/pubkey.gpg -O- | apt-key add -
master ~ $ apt-get update && apt-get -y install foreman-installer
Запустим установщик:
master ~ $ foreman-installer
Результат должен быть похож на следующий:
Ссылка вида puppet.<domain.com> и логином с паролем нам пригодятся дальше.
Настроим конфигурацию для просмотра в Foreman различий изменений файлов:
master ~ $ nano /etc/puppet/puppet.conf
> show_diff = true
Откроем в браузере ссылку, рекомендованную в предыдущем шаге: puppet.<domain.com>
И введём логин: admin и пароль, который мы видели в консоли после установки.
Если авторизация прошла успешно, значит Foreman установлен и работает должным образом. Теперь можно переходить к следующей главе.
2. Настройка Foreman
По умолчанию Foreman использует свой SSL-сертификат, сгенерированный Puppet и ваш браузер не будет принимать его. Вы можете добавить корневой сертификат (
/var/lib/puppet/ssl/certs/ca.pem) в свой браузер, чтобы исчезли предупреждения небезопасного соединения (для Chromium добавлять сюда: Настройки/SSL/Центры сертификации).При первом входе вы увидите страницу Dashboard, где будет показана общая статистика по всем узлам сети. При добавления узлов сети, здесь будет полезная статистическая информация.
При последующих входах вы будете перенаправляться на страницу списка узлов сети.
2.1. Смена пароля
Первым делом необходимо изменить пароль пользователя:
Пароль по умолчанию и так сложный, но лучше сделать свой.
2.2. Добавление модуля на примере NTP
Время должно быть точно установлено на главном сервере puppet-мастер. Для этого необходимо использовать NTP. Если время неверно, puppet-мастер может ошибочно выдавать сертификаты агентов из далекого прошлого или будущего, которые другие узлы будут считать устаревшими.
Иногда, чтобы иметь возможность управлять модулями Puppet через Foreman, необходимо установить модули, разработчиками которых являются не Puppet-Labs, а разработчики сообщества Puppet. Это вытекает из того факта, что Foreman использует HTTP-запросы Restful API для Puppet, но не во всех модулях определено управление с помощью такого API.
Установим модуль saz/ntp на puppet master:
master ~ $ puppet module install saz/ntpПримечание
Модуль saz/ntp прекрасно работает на версии Foreman 1.11. Для других версий Foreman, можно использовать модули с сайта forge.puppetlabs.com по поиску ntp.
Вы должны увидеть следующее:
Сейчас модуль был установлен только для puppet-мастер. Теперь необходимо войти в веб интерфейс и добавить его к Foreman. Перейдите в меню Configure > Classes и нажмите Import from puppet.<domain.com>:
В результате вы увидите список доступных классов, отметьте нужные и нажмите Update:
Для того, чтобы использовать ближние к вам ntp-серверы, перейдем на сайт www.pool.ntp.org. Там в правом блоке выберем нужный нам пул (Африка, Азия и т.д.) и заберём список серверов в буфер обмена.
Далее идём в настройки класса ntp, кликнув по его названию. Переходим во вкладку Smart Class Parameter и ищем в левом списке вкладку server list:
Отмечаем пункт Override и в Default value по примеру предыдущего значения, добавляем сервера из шага выше. Я добавил такое значение:
["0.asia.pool.ntp.org","1.asia.pool.ntp.org","2.asia.pool.ntp.org","3.asia.pool.ntp.org"]
Нажимаем Submit внизу страницы, тем самым мы переопределили параметр класса.
2.3. Добавление модуля accounts и ssh
На примере предыдущего модуля установим модуль accounts:
master ~ $ puppet module install camptocamp-accounts
Если установка прошла успешно, то вы увидите следующее:
Установим модуль ssh:
master ~ $ puppet module install saz/ssh
После этого идём в Foreman и импортируем новые классы. Позже, после создания групп узлов сети, мы настроим классы accounts и ssh.
2.4. Добавление модуля mysql и apache
Для объяснения последующих названий групп database и web добавим модули apache и mysql. Добавляем модули по примеру предыдущих. Загрузить их можно командами:
master ~ $ puppet module install puppetlabs-apache
master ~ $ puppet module install puppetlabs-mysql
3. Добавление узлов сети
Чтобы добавить узел сети в Puppet, необходимо установить puppet-агент на этот узел. Для установки puppet-агента скачаем и установим репозиторий puppet-labs:
agent ~ $ cd ~ && wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
agent ~ $ sudo dpkg -i puppetlabs-release-trusty.deb
agent ~ $ sudo apt-get update
Затем установим puppet-агент:
agent ~ $ sudo apt-get -y install puppet
Чтобы запустить Puppet в роли агента, необходимо закомментировать настройки зоны puppet-мастера. Также добавьте конфигурацию для агента, которая установит адрес нашего puppet-мастера. Приведём файл конфигурации
/etc/puppet/puppet.conf в вид:[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
#templatedir=$confdir/templates
#[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
#ssl_client_header = SSL_CLIENT_S_DN
#ssl_client_verify_header = SSL_CLIENT_VERIFY
[agent]
server = puppet.domain.com
# где puppet.domain.com - hostname или IP-адрес вашего master-сервера
Заменим значение переменной START с no на yes, чтобы запустить puppet-агент после перезагрузки ОС. А также запустим puppet-агент:
agent ~ $ sudo sed -i s/START=no/START=yes/g /etc/default/puppet
agent ~ $ sudo service puppet start
При небольшой инфраструктуре puppet-агент можно запускать в виде демона. Есть также способ запуска через CRON: docs.puppet.com/puppet/3.6/services_agent_unix.html#running-puppet-agent-as-a-cron-job.
Примечание
Puppet-агент по умолчанию ищет домен puppet-мастера в своей зоне, если явно не указан параметр server (в файле puppet.conf). Например: server.domain.com будет искать сервер puppet.domain.com. Потому, если вы ещё идёте по инструкции, то у вас всё должно работать.
После этого идём на Foreman в Infrastructure > Smart Proxies > Certificates:
Там должен появится узел сети, на который мы только что установили puppet-агент. Можно использовать фильтр (вверху слева), чтобы увидеть только неподписанные сертификаты. Чтобы подписать, необходимо нажать кнопку Sign:
В течение нескольких минут сервер server.<domain.com> (сервер, на котором мы только что установили агент) появится в списке Hosts > All hosts.
4. Добавление групп узлов сети
Перейдём в пункт меню Configure > Host Groups. Нажмём New Host Group. Вкладка Host Group должна получится следующей:
Группа root будет корневой. Она будет родителем всех остальных групп. У ней будет полный доступ ко всему. И в неё будут включены основные классы.
Далее перейдем во вкладку Puppet Classes и добавим необходимые классы нажав на +:
Нажимаем Submit.
Добавим по этому же принципу ещё две группы. Только теперь мы выберем в качестве Parent группу root, потому классы accounts, ntp и ssh наследуются и добавлять их повторно не нужно. Добавим только для группы database класс mysql::server, а для группы web класс apache.
5. Добавление узла в группу
Чтобы включить узел в группу, необходимо перейти в его настройки.
После этого в первой вкладке добавляем группу, как на скриншоте ниже:
После этого нажимаем Submit и в течение нескольких минут на узле сети появится mysql. Таким же образом можно присвоить остальным двум серверам группу web:
Вся конфигурация распространяется на puppet-агенты автоматически в течение нетокоротого времени.
Если не хочется ждать, то можно на клиентах выполнить команду
puppet agent --test и увидеть своими глазами, как создаётся конфигурация.6. Настройка прав доступа с помощью модуля accounts
Собственно сейчас можно ещё раз посмотреть на схему, которую мы привели в начале и на основе её создать логику.
Перейдём в пункт меню Configure > Classes. Нажмём на accounts, чтобы перейти в настройки модуля. Из всех настроек нам будут нужны вкладки accounts, ssh keys, users.
Примечание
Вкладка accounts — в ней содержаться хэши «пользователь сервера > названия публичных ключей из вкладки ssh keys». Вкладка ssh keys — в ней содержаться хэши «название ключа > тип и значение». Вкладка users — в ней содержаться пользователи, которых необходимо создать или указать для уже существующих некоторые параметры.
Откроем последнюю вкладку users и установим её как на скриншоте:
Этот параметр настраивает домашний каталог пользователя. Здесь мы задействовали Merge overrides и Merge default параметры, которые позволят объединить конфигурацию для конечного узла сети.
Вкладку ssh keys заполним следующим образом:
В поле Default value необходимо вписать все публичные ключи аккаунтов, которые будут использоваться во вкладке accounts. Эти публичные ключи пользователей, которые будут иметь доступ на те или иные сервера. Отступ в два пробела перед параметрами type и public обязателен.
Пример того, как выглядит один публичный ключ (остальные добавляются друг за другом ниже):
admin:
type: ssh-rsa
public: AAAAB3NzaC1yc2EAAAADAQABAAABAQDXibuyi2MFzERps7mD2J38mhd4phXQlOEZrmui9rDdcYD0XeEnvdRTZPcsMOw6DRT1ERpzbcFehj+G29YxoiXZ541gVjVvsATAqojN3zEkMz5b0AgBNcKDFi9h/qwlK9YDv2trKEcRHQ4kBN332Z6oqdBFerUMys5dvc3RVlE+x2kVmYNmGIlma5twC9w/wRNoD+nUK+3bk+I+Og40f//uFAKFeY4DMoCrdOsHJrPak5nD9vL6a2m/Fe3jfgmpBCcnV3LS2mr+PdRYbtju7nzfu8WT0ugMAUi+dDMRFh3DmfCzXbOi2TPi+mP//L/A19thXffd/QzW7wmAgxlj+km1
Самую верхнюю вкладку accounts заполним следующим образом:
Из этого параметра следует: root имеет доступ везде с аккаунта root (аккаунт root — это элемент из вкладки ssh keys), аккаунт dbadmin имеет root-доступ только к серверам из группы database, а пользователь admin есть только у группы web и аккаунт admin может подключаться только под пользователя admin.
На вкладке users добавим пользователя admin в группу www-data.
6.1 Настройка класса ssh
В классе accounts мы настроили ssh-доступ по ключам. Потому для более полной безопасности необходимо запретить доступ по паролю. Делается это с помощью класса ssh. Переходим в его настройки и открываем вкладку Smart Class Parameter. Далее client options приводим к следующему виду:
Вкладку server options приводим к следующему виду:
И вкладку storeconfigs enabled заполняем так:
В storeconfigs хранятся все факты о клиентах, поэтому вы можете запросить базу данных и получить списки узлов сети, соответствующие определенным критериям. Для большей безопасности мы это отключили.
7. Результаты
В процессе выполнения данного руководства ваша инфраструктура добавленная под управление Puppet станет быстро-конфигурируемой и масштабируемой. А главная цель — управления публичными ssh ключами будет максимально удобной.
Скриншот списка ключей пользователя admin на одной из машин группы root/web:
Помните, при настройке класса accounts для параметра ssh keys мы включали Merge overrides и Merge default. Это нужно для того, чтобы в конце для определённого узла сети собирался один структурированный файл с ssh-ключами.
Проверим, действительно ли можно авторизоваться под пользователем “admin” с помощью добавленного ключа:
Если у вас также тест прошёл успешно, то инфраструктура готова и можно постепенно подключать остальные ваши сервера к puppet-мастеру и настраивать другие сервисы через Puppet.
Использованные ресурсы: документация Puppet, документация Foreman.
Комментарии (26)
tgz
12.03.2017 14:58+1пупет ужасен
— стандартная библиотека просто нищая
— модули, их много, ни одного рабочего
— миграция с пупет 3 на пупет 4 — это невозможно, проще засетапить по новой
— внутри руби
— последовательность исполнения надо указывать явно, есть целыз 3 способа это сделать
— нет возможности просто выполнить команду, тащите mcollective
— ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
— очень сложно выполнить на одном хосте код из отдельного бранча
— все пути прибиты гвоздями, нельзя положить файлик никуда кроме files
— не понятно куда пихать прослойки profiles/roles, то ли в модули (но это не модули), то ли в манифесты (но к хостам это тоже не относится напрямую), положить в отдельный каталог нельзя, все прибито гвоздями.
— и еще много чего
Ipeacocks
12.03.2017 18:48+1Согласен. Но это очевидно сейчас, когда есть ансибл. Папет же старенький и тянет за собой кучу легаси. Примером нельзя вызвать дважды функцию с тем же именем, оно должно быть для каждого вызова уникальной… и такого куча.
Да, действительно стандартная библиотека многого простого не умеет или же это простое нужно делать какими-то костылями. И помню, например, замену строки в файле и как это нелегко делалось…
Последовательность исполнения — это тот еще ад, особенно когда много кода понаписывали.
В конфингурациях master-client прекомпиляция почему-то делается на мастере и только на нем и это достаточно быстро приводит к проблемам масштабирования мастера.
Среди плюсов — это наверное то, что есть Фореман. Ну я не совсем о том, что он очень плох, я о том, что если есть выбор — то лучше попробовать Ансибл.
skywalk7
13.03.2017 03:03+1— стандартная библиотека просто нищая
Хотелось бы конкретный пример того, что нужно и чего нет в puppetlabs/stdlib?
— внутри руби
Наоборот, проблема в том, что нельзя напрямую использовать inline ruby, в отличие от Chef, например
— последовательность исполнения надо указывать явно
Да, внутри файла можно было бы добавить зависимость по умолчанию
— нет возможности просто выполнить команду, тащите mcollective
Ну это нормально для pull системы конфигурации
— очень сложно выполнить на одном хосте код из отдельного бранча
Гм… environments? Работает нормально, была пара багов, но их поправили
— ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
Ну конечно ресурс с одним именем уникален — было бы странно иметь неоднозначную систему конфигурации
— не понятно куда пихать прослойки profiles/roles
Ну так для этого Foreman и создан — там очень гибкая система smart variables — позволяет задавать разные конфигурации в зависимости от множества факторов — имени хоста, домена, группы, региона и т.д.
Я думаю, что основная проблема в том, что для понимания построения масштабной системы управления конфигурациями на основе Puppet надо обладать серьезными знаниями — отличиями в push/pull системах конфигураций, понятие об external node classifier, compile master, cvs и прочая. Ansible конечно проще для начального освоения.tgz
13.03.2017 09:01-1— debconf, модули для сетевого железа и еще миллион всего
— руби — это ужас, читать чужой код невозможно, писать свой тяжело, в итоге если в модуле банальная бага, ее правка выливается в тонны потраченного времени
— если бы у бабушки были яйца…
— push система легко превращется в pull, наоборот нет. Зачем делать только pull?
— environments решают другую проблему, да даже таскать хост по разным env — это куча телодвижений
— это все приводит к боли, добавил роль, а там уже что-то есть и начинается, убрать из роли нельзя, так как у других сломается, оставить как есть тоже. Можно же не выдавать ошибку если ресурс определен дважды, но одинаково?
— а без форемана? Его для пупет4 так и не портировали. Как жить?Ipeacocks
13.03.2017 12:58> а без форемана? Его для пупет4 так и не портировали. Как жить?
Та вроде как портировали.
Кстати, Ансибл вроде тоже как-то умеет работать с Фореманом. Если это кому-то нужно.
Ipeacocks
17.03.2017 21:11-1> нельзя напрямую использовать inline ruby, в отличие от Chef, например
а inline_template, или вы не об этом? http://blog.abhijeetr.com/2012/11/execute-ruby-code-from-puppet.htmlskywalk7
17.03.2017 23:58-1Chef позволяет использовать код напрямую, без извращений. Вот пример из документации:
if platform?('windows') ruby_block 'copy libmysql.dll into ruby path' do block do require 'fileutils' FileUtils.cp "#{node['mysql']['client']['lib_dir']}\\libmysql.dll", node['mysql']['client']['ruby_dir'] end not_if { File.exist?("#{node['mysql']['client']['ruby_dir']}\\libmysql.dll") } end end
Ipeacocks
12.03.2017 19:35И почему 14.04?
rebirther23
13.03.2017 08:09Писал статью одновременно с выполнением задачи по работе.
Ubuntu 14.04 — «хотелка» заказчика.
JuriM
12.03.2017 21:36Есть работающий фореман-1.10 на дебиан 7, решил обновить до фореман-1.14 и на дебиан 8.
Так как рекомендуют обновлять в пределах одной версии (10 -> 11 ->12), то решил не мучаться и поставить с нуля сразу 1.14 версию (руками перенес только группы), используя foreman-install
После установки, паппет агенты на хостах автоматом начали региться через фореман-прокси, тк использовался старый сертификат, отрабатывали тоже корректно, но через пару часов апач+мод_пассенджер переставал отвечать по достижении лимита сессий в очереди.
Что только не пробовал, увеличивал все лимиты, убирал их совсем, тюнил апач — ничего не помогало, через час passenger (причем последняя версия 5.1.2, где все-все исправили) перестает работать,(паппет агент на амазоновских хостах вообще отваливался по Net::Timeout)
На дебиан 7 фореман любой версии работает без проблем с дефолтными настройками, мистика просто.
past
13.03.2017 11:20+1Небольшой комментарий по поводу ntp серверов. Для России удобно использовать 0.ru.pool.ntp.org, 1.ru.pool.ntp.org, 2.ru.pool.ntp.org...
luckyap
14.03.2017 02:08+1@tgz, "паппет ужасен", в чистом его виде — согласен. С использованием встроенной hiera, все описание на YAML достаточно просто и элегантно.
Из текущего в небольшой конторе:
- Puppet 4.9.4 на Debian 8
- 2 окружения (environments): corporate & production
> ls -l /etc/puppetlabs/code/environments/corporate/hieradata/nodes/ | wc -l— 60 (и физ. сервера и виртуалки)- в проде хостов по-меньше
- общее кол-во модулей — 61
- кол-во модулей от 3их разработчиков (т.е. не от Puppetlabs) — 36
При использовании hiera, ruby манифест сокращается от 1 до 6 строчек:
/etc/puppetlabs/code/environments/corporate/manifests/site.pp
(устаревший вариант, но еще работающий)
hiera_include('classes')
либо
include lookup('classes', { 'merge' => 'unique' })
или такой, в зависимости от того какое слитие данных необходимо:
lookup({ 'name' => 'classes', 'merge' => { 'strategy' => 'deep', 'merge_hash_arrays' => true, }, })
Иерархия описывается на уровне системного hiera конфига; задатается как угодно; нам хватает вот этого:
hierarchy: - name: "Nodes" path: "nodes/%{::trusted.certname}.yaml" - name: "Roles" path: "roles/%{::role}.yaml" - name: "Vurtual" path: "virtual_%{::is_virtual}.yaml" - name: "OS" path: "os_%{::operatingsystem}.yaml" - name: "Environment" path: "env_%{environment}.yaml" - name: "Common Defaults" path: "common.yaml"
Последовательность вызова задается в hiera очередностью описания классов, например:
--- classes: - apt - sudo - nslcd - package
ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
совсем нет, есть knockout_prefix'ы; есть использование alias'ов и переменных, например:
> hieradata/node/devvm01.yaml dev_username: "username" > hieradata/role/dev_vm.yaml sudo::configs: "%{alias('dev_username')}": 'content' : "%{alias('dev_username')} ALL=(ALL:ALL) APTGET, APACHECTL....
все пути прибиты гвоздями, нельзя положить файлик никуда кроме files
смотрите в /etc/puppetlabs/puppet/fileserver.conf и /etc/puppetlabs/puppetserver/conf.d/auth.conf. По сути, Puppet Server — это web сервер, который можно настроить как угодно:
# access via puppet:///my_mount_point/ [my_mount_point] path /etc/puppetlabs/my_mount_point allow *
не понятно куда пихать прослойки profiles/roles
окружения (environments), когда недостаточно:
> cat /etc/puppetlabs/facter/facts.d/role.json { "role": "dev_vm" }
Плюс подобных подролей может быть сколько угодно. В hiera они просто будут как переменные и легко отслеживаются (см выше).
push система легко превращется в pull, наоборот нет. Зачем делать только pull
хм, нежеланием вешать Puppet Agent на порт, и связанным с этим геммороем в виде дыр, настройкой firewall'а, проброской NAT'а и прочими радостями...
К чему я это все, Puppet очень гибкая система, если есть желание с этим разбираться. Зато когда разберешься, то все летает.
Другой вопрос, что документация у них оставляет желать лучшего.Ipeacocks
14.03.2017 16:49Опять же, Папит достаточно актуален. Но попробуйте Ансибл и скажите после этого, что Папитом удобно пользоваться.
saamich
16.03.2017 10:21Года 1,5 приходилось писать на папете, правда еще 3 версии, задачи и условия были специфические(сначала у нас был свой орекстратор на питоне который запускал агенты на нодах в заданном порядке, потом на другом проекте писал плагин под fuel)- после него на ansible местами плеваться хочется — очень не хватает некоторых функций- вот пример:
- Как вы будете переиспользовать handler какой-то роли из другого плейбука, при условии что саму роль исполнять не надо? Если сделать include в handlers -то оно не будет реагировать на notify в версии 2,2(написано в доках)- тут только финт ушами в виде include файла с описанием handler как таски или делать отдельную роль со всеми нужными handler(что, как мне кажется, через пятую точку). По аналогии с папетом- в модуле можно сделать отдельный клас для рестарта и дергать только его(без дублирования описания ресусра)
- Как сказать через ansible что вот такой сервис при изменении конфига должен быть перезапущен и должен всегда быть запущен в системе? Тут только отдельный handler на перезапуск и таска на старт(иначе когда кто-то ручками остановит сервис и никаких изменений в конфиге не было- сервис так и не запустится). На папаете это будет один ресурс, который можно «обновлять» из других
Вообще такое чувство что ansible все еще сырой, в 2.2 завезли баг в yum модуле- при использовании state=latest — не ообновлялся пакет, который стоит в списке от yum checkupdate первым. Вместо того, чтобы получать список пакетов через rpmconf (как им еще ранее советовали)- опять написали кучу регулярок для парсинга yum checkupdate.
Очень двойственное чувство от ansible, если бы не отсуствие выделенного сервера- оно бы «не взлетело».neumeika
17.03.2017 00:001. dependencies?
2. register и when? state: started? (в пупете тож не за раз всё опишется)
Пупет я не люблю больше ансибла :) Но на текущей работе нет salt, зато есть и foreman, и ansible, и puppet :(saamich
17.03.2017 01:591) dependencies чего- ролей? Судя по докам при этом выполнится сама роль- чего не нужно (о чем выше написано)
2) Вот тут вообще не понял причем здесь и зачем «register и when? state: started? » даже если рассматривать вариант с таской на запуск и handler на рестарт оно не надо. Почему в папете «не за раз» опишется? ресурс запускающий сервис и рестартующий ровно один, остальные его обновляют(аналог notify).
И эти примеры только-то — на что недавно наступил…
Sovigod
Осталось пара практических вопросов.
1. Например есть у нас в группе web два аккаунта — developer1 и developer2. И все работает. В какой-то момент developer1 уходит с этого проекта и нам нужно удалить все его ключи со всех серверов. Пупет это сможет?
2. Частность от первого варианта. developer1 во время работы добавил ключ своего ноутбука, ручками в authorized_keys. Что будет с ними?
rebirther23
1. Да, это его прямая обязанность. Достаточно в модуле accounts параметр purge ssh keys перевести в true. Но при этом будут так же удалены ключи, добавленные вручную.
2. Если параметр purge ssh keys = false, что правильнее оставлять по умолчанию, то все ключи добавленные вручную будут пропускаться при обновлении.
foxmuldercp