В этой статье будет рассмотрена установка и настройка связки Puppet + Foreman для централизованного управления конфигурациями.
Для сервера, на котором будет установлена связка Puppet + Foreman, будет использоваться виртуальная машина (1 CPU, 2 Gb RAM, 20Gb HDD), в качестве клиентов будут физические ПК на которых установлена Ubuntu. Конфигурация моего виртуального сервера с указанными выше характеристиками позволяет без проблем обслуживать 500 клиентов (можно и больше).
Установка Puppet довольно простая (все последующие команды выполняются от root):
Этими командами мы скачиваем deb пакет с сайта разработчиков puppet и устанавливаем его. Данный пакет puppetlabs-release-trusty.deb при установке создает файл /etc/apt/sources.list.d/puppetlabs.list в котором прописаны репозитории puppet, а также импортируется gpg ключ которым подписан репозиторий puppet. Сам puppetmaster мы не устанавливаем, он будет установлен автоматически при установке Foreman.
На этом установка Puppet закончена, приступим к установке веб-интерфейса Foreman:
Здесь мы добавили файл /etc/apt/sources.list.d/foreman.list в который вписали репозитории от Foreman, а также добавили ключ от данного репозитория. После добавления репозитория мы обновили список пакетов и установили foreman-installer — это пакет который позволяет установить Foreman.
Далее нам нужно настроить правильное имя компьютера. Прописываем в /etc/hosts и /etc/hostname
Перезагружаем наш сервер.
Запускаем наш установщик коммандой foreman-installer -i.
Нас спрашивают — готовы ли мы к установке, отвечаем «y», далее следует меню в котором можно выбрать дополнительные конфигурации Foreman и дополнительные модули. Мы же устанавливаем стандартную конфигурацию, поэтому выбираем пункт «Save and run» и у нас начинается установка (можно было ставить командой foreman-installer без опции -i, тогда у нас поставится базовая установка, -i подразумевает интерактивный режим).
У меня установка заняла примерно 5 минут, после установки мы видим сообщение об успешно установке, в этом сообщении находятся наши параметры доступа к Foreman.
Переходим по адресу srv.co.com и заходим в веб-интерфейс используя параметры доступа которые мы получили при установке (их желательно сохранить в файлик, а после первого входа в панель управления — поменять пароль). После входа мы видим страницу с множеством текстовой информации на английском языке, можно перейти в настройки аккаунта и сменить язык на русский. Переходим в правый верхний угол, жмем Admin User, My account, вибираем нужный нам язык и сохраняем настройки.
При последующем входе в Foreman мы получим другой интерфейс:
Здесь в списке будут отображаться наши клиенты.
Вот мы и завершили установку связки Puppet + Foreman. Давайте попробуем добавить клиента puppet и посмотреть что поменяется в веб-интерфейсе.
Для установки Puppet агентов на клиентские ПК я использую следующий скрипт:
Этот скрипт устанавливает puppet agent, настраивает автозапуск агента при старте системы, указывает адрес Puppet сервера и запускает агента. Также мы закомментируем в конфиге /etc/puppet/puppet.conf строку templatedir, если не закомеентировать — сыпятся ошибки (как фиксить без комментирования я не разобрался,хотя оно меня не раздражает).
После установки агента у нас на сервере будет запрос на подпись сертификата, если мы не подпишем данный сертификат, тогда агент не будет подключен в серверу.
Для просмотра сертификатов на сервере можно использовать комманду puppet cert --list --all:
Здесь мы видим что у нас 2 сертификата, один не подписан с именем zeppelin и другой подписан (+) с именем srv.co.com. Не подписаный сертификат — это сертификат от нашего новоустановленого клиента.
Для подписи сертификата можно использовать комманду puppet cert --sign $client_name. Также для подписи сертификатов мы можем использовать веб-интерфейс от Foreman, для этого нам нужно перейти в меню «Инфраструктура» — «Капсули» — «Сертификаты» и здесь можно подписать или удалить сертификат.
Жмем «Подписать», в результате при просмотре списка сертификатов в консоли у нас будет 2 подписаных сертификата:
Переходим в меню «Узлы» — «Все узлы» — здесь мы видим 2 сервера (новый сервер может появиться не сразу, а через некоторое время, для того чтобы он появился сразу, нужно после подписи сертификата выполнить на клиенте команду puppet agent -t).
Поумолчанию Foreman берет манифесты из папки /etc/puppet/environments далее в записимоти от окружения. Сейчас мы добавим манифест в Foreman и попробуем применить его для одного из наших клиентов. Создаем папку mkdir -p /etc/puppet/environments/production/modules/vsftpd/manifests, в эту папку закидаем файл init.pp:
Теперь для того чтобы наш модуль с манифестом появился в Foreman нужно зайти в меню «Настройки» — «Классы Puppet» и нажать «Импорт из srv.co.com».
Отметить птичкой нужное нам окружение и нажать «Обновить».
В результате мы получим список доступных классов Puppet с указанием окружений, узлов к которым они применены и т.д.
Давайте добавим наш манифест в одному из клиентов. Для этого переходим в «Узлы» — «Все узлы», жмем на имени нужного нам узла и у нас открывается страница с детальной характеристикой узла.
Жмем кнопу «Изменить», попадаем на другую страницу с настройками указанного узла, тут жмем на вторую вкладку «Классы Puppet» и видим наш класс «vsftpd».
Выбираем наш клас (значок +), он перемещается в левую сторону с «Доступных классов» в «Включенные классы», подтверждаем изменения.
Все — наш манифест добавлен для выбраного сервера, остается подождать пока он будет применен на клиенте. Если мы не хотим ждать, можно зайти на клиент и выполнить комманду puppet agent -t, сразу после ее выполнения манифест будет применен к клиенту и на нем будет установлення vsftpd (в нашем случае).
Foreman также имеет множество дополнительного функционала, хосты можно группировать, манифесты можно применять на группы, также можно настроить автоподпись клиентских сертификатов, права на клиентские машины для разных администраторов, аудит оборудования и многое другое, о чем я расскажу в следующей статье.
Использованные ресурсы:
docs.puppetlabs.com/puppet/latest/reference/install_pre.html
theforeman.org/manuals/1.9
Для сервера, на котором будет установлена связка Puppet + Foreman, будет использоваться виртуальная машина (1 CPU, 2 Gb RAM, 20Gb HDD), в качестве клиентов будут физические ПК на которых установлена Ubuntu. Конфигурация моего виртуального сервера с указанными выше характеристиками позволяет без проблем обслуживать 500 клиентов (можно и больше).
Установка Puppet довольно простая (все последующие команды выполняются от root):
Установка Puppet
Этими командами мы скачиваем deb пакет с сайта разработчиков puppet и устанавливаем его. Данный пакет puppetlabs-release-trusty.deb при установке создает файл /etc/apt/sources.list.d/puppetlabs.list в котором прописаны репозитории puppet, а также импортируется gpg ключ которым подписан репозиторий puppet. Сам puppetmaster мы не устанавливаем, он будет установлен автоматически при установке Foreman.
На этом установка Puppet закончена, приступим к установке веб-интерфейса Foreman:
Установка Foreman
echo «deb deb.theforeman.org trusty 1.9» > /etc/apt/sources.list.d/foreman.list
echo «deb deb.theforeman.org plugins 1.9» >> /etc/apt/sources.list.d/foreman.list
wget -q deb.theforeman.org/pubkey.gpg -O- | apt-key add — apt-get update && apt-get -y install foreman-installer
echo «deb deb.theforeman.org plugins 1.9» >> /etc/apt/sources.list.d/foreman.list
wget -q deb.theforeman.org/pubkey.gpg -O- | apt-key add — apt-get update && apt-get -y install foreman-installer
Здесь мы добавили файл /etc/apt/sources.list.d/foreman.list в который вписали репозитории от Foreman, а также добавили ключ от данного репозитория. После добавления репозитория мы обновили список пакетов и установили foreman-installer — это пакет который позволяет установить Foreman.
Далее нам нужно настроить правильное имя компьютера. Прописываем в /etc/hosts и /etc/hostname
/etc/hosts
127.0.0.1 localhost
172.16.185.148 srv.co.com srv
172.16.185.148 srv.co.com srv
/etc/hostname
srv
Перезагружаем наш сервер.
Запускаем наш установщик коммандой foreman-installer -i.
Нас спрашивают — готовы ли мы к установке, отвечаем «y», далее следует меню в котором можно выбрать дополнительные конфигурации Foreman и дополнительные модули. Мы же устанавливаем стандартную конфигурацию, поэтому выбираем пункт «Save and run» и у нас начинается установка (можно было ставить командой foreman-installer без опции -i, тогда у нас поставится базовая установка, -i подразумевает интерактивный режим).
У меня установка заняла примерно 5 минут, после установки мы видим сообщение об успешно установке, в этом сообщении находятся наши параметры доступа к Foreman.
Foreman параметры доступа
Success!
* Foreman is running at srv.co.com
Initial credentials are admin / AQgtYVSPXfNytRt6
* Foreman Proxy is running at srv.co.com:8443
* Puppetmaster is running at port 8140
The full log is at /var/log/foreman-installer/foreman-installer.log
* Foreman is running at srv.co.com
Initial credentials are admin / AQgtYVSPXfNytRt6
* Foreman Proxy is running at srv.co.com:8443
* Puppetmaster is running at port 8140
The full log is at /var/log/foreman-installer/foreman-installer.log
Переходим по адресу srv.co.com и заходим в веб-интерфейс используя параметры доступа которые мы получили при установке (их желательно сохранить в файлик, а после первого входа в панель управления — поменять пароль). После входа мы видим страницу с множеством текстовой информации на английском языке, можно перейти в настройки аккаунта и сменить язык на русский. Переходим в правый верхний угол, жмем Admin User, My account, вибираем нужный нам язык и сохраняем настройки.
При последующем входе в Foreman мы получим другой интерфейс:
Здесь в списке будут отображаться наши клиенты.
Вот мы и завершили установку связки Puppet + Foreman. Давайте попробуем добавить клиента puppet и посмотреть что поменяется в веб-интерфейсе.
Для установки Puppet агентов на клиентские ПК я использую следующий скрипт:
Установка Puppet на клиентское оборудование
#!/bin/bash
wget apt.puppetlabs.com/puppetlabs-release-trusty.deb
dpkg -i puppetlabs-release-trusty.deb
rm puppetlabs-release-trusty.deb
apt-get install -y puppet
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i '/\/var\/log\/puppet/a \server=srv.co.com' /etc/puppet/puppet.conf
sed -i 's/templatedir/#templatedir/' /etc/puppet/puppet.conf
puppet agent --test
wget apt.puppetlabs.com/puppetlabs-release-trusty.deb
dpkg -i puppetlabs-release-trusty.deb
rm puppetlabs-release-trusty.deb
apt-get install -y puppet
sed -i s/START=no/START=yes/g /etc/default/puppet
sed -i '/\/var\/log\/puppet/a \server=srv.co.com' /etc/puppet/puppet.conf
sed -i 's/templatedir/#templatedir/' /etc/puppet/puppet.conf
puppet agent --test
Этот скрипт устанавливает puppet agent, настраивает автозапуск агента при старте системы, указывает адрес Puppet сервера и запускает агента. Также мы закомментируем в конфиге /etc/puppet/puppet.conf строку templatedir, если не закомеентировать — сыпятся ошибки (как фиксить без комментирования я не разобрался,
После установки агента у нас на сервере будет запрос на подпись сертификата, если мы не подпишем данный сертификат, тогда агент не будет подключен в серверу.
Для просмотра сертификатов на сервере можно использовать комманду puppet cert --list --all:
puppet cert --list --all
root@srv:~# puppet cert --list --all
«zeppelin» (SHA256) 43:64:08:BF:DB:AF:7C:17:5B:DE:3C:CE:22:8B:40:6A:13:60:B7:F4:2C:38:B6:57:E5:FA:EA:CC:63:FB:87:EB
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)
«zeppelin» (SHA256) 43:64:08:BF:DB:AF:7C:17:5B:DE:3C:CE:22:8B:40:6A:13:60:B7:F4:2C:38:B6:57:E5:FA:EA:CC:63:FB:87:EB
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)
Здесь мы видим что у нас 2 сертификата, один не подписан с именем zeppelin и другой подписан (+) с именем srv.co.com. Не подписаный сертификат — это сертификат от нашего новоустановленого клиента.
Для подписи сертификата можно использовать комманду puppet cert --sign $client_name. Также для подписи сертификатов мы можем использовать веб-интерфейс от Foreman, для этого нам нужно перейти в меню «Инфраструктура» — «Капсули» — «Сертификаты» и здесь можно подписать или удалить сертификат.
Жмем «Подписать», в результате при просмотре списка сертификатов в консоли у нас будет 2 подписаных сертификата:
puppet cert --list --all
root@srv:~# puppet cert --list --all
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)
+ «zeppelin» (SHA256) 03:C6:FF:F9:4D:10:7C:7D:6C:32:A7:E8:0C:9F:DA:FB:DD:43:B6:E5:36:79:DD:E3:04:41:D3:58:9F:6A:C4:8F
+ «srv.co.com» (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (alt names: «DNS:puppet», «DNS:puppet.co.com», «DNS:srv.co.com»)
+ «zeppelin» (SHA256) 03:C6:FF:F9:4D:10:7C:7D:6C:32:A7:E8:0C:9F:DA:FB:DD:43:B6:E5:36:79:DD:E3:04:41:D3:58:9F:6A:C4:8F
Переходим в меню «Узлы» — «Все узлы» — здесь мы видим 2 сервера (новый сервер может появиться не сразу, а через некоторое время, для того чтобы он появился сразу, нужно после подписи сертификата выполнить на клиенте команду puppet agent -t).
Поумолчанию Foreman берет манифесты из папки /etc/puppet/environments далее в записимоти от окружения. Сейчас мы добавим манифест в Foreman и попробуем применить его для одного из наших клиентов. Создаем папку mkdir -p /etc/puppet/environments/production/modules/vsftpd/manifests, в эту папку закидаем файл init.pp:
init.pp от vsftpd
class vsftpd {
package { 'vsftpd':
ensure => installed,
}
}
package { 'vsftpd':
ensure => installed,
}
}
Теперь для того чтобы наш модуль с манифестом появился в Foreman нужно зайти в меню «Настройки» — «Классы Puppet» и нажать «Импорт из srv.co.com».
Отметить птичкой нужное нам окружение и нажать «Обновить».
В результате мы получим список доступных классов Puppet с указанием окружений, узлов к которым они применены и т.д.
Давайте добавим наш манифест в одному из клиентов. Для этого переходим в «Узлы» — «Все узлы», жмем на имени нужного нам узла и у нас открывается страница с детальной характеристикой узла.
Жмем кнопу «Изменить», попадаем на другую страницу с настройками указанного узла, тут жмем на вторую вкладку «Классы Puppet» и видим наш класс «vsftpd».
Выбираем наш клас (значок +), он перемещается в левую сторону с «Доступных классов» в «Включенные классы», подтверждаем изменения.
Все — наш манифест добавлен для выбраного сервера, остается подождать пока он будет применен на клиенте. Если мы не хотим ждать, можно зайти на клиент и выполнить комманду puppet agent -t, сразу после ее выполнения манифест будет применен к клиенту и на нем будет установлення vsftpd (в нашем случае).
Результат выполнения puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for srv.co.com
Info: Applying configuration version '1443086109'
Notice: /Stage[main]/Vsftpd/Package[vsftpd]/ensure: ensure changed 'purged' to 'present'
Notice: Finished catalog run in 2.90 seconds
Info: Retrieving plugin
Info: Caching catalog for srv.co.com
Info: Applying configuration version '1443086109'
Notice: /Stage[main]/Vsftpd/Package[vsftpd]/ensure: ensure changed 'purged' to 'present'
Notice: Finished catalog run in 2.90 seconds
Foreman также имеет множество дополнительного функционала, хосты можно группировать, манифесты можно применять на группы, также можно настроить автоподпись клиентских сертификатов, права на клиентские машины для разных администраторов, аудит оборудования и многое другое, о чем я расскажу в следующей статье.
Использованные ресурсы:
docs.puppetlabs.com/puppet/latest/reference/install_pre.html
theforeman.org/manuals/1.9
Комментарии (34)
miwa
24.09.2015 14:17+2В скрипте установки вместо строчки
wget apt.puppetlabs.com/puppetlabs-release-trusty.deb
лучше написать
wget apt.puppetlabs.com/puppetlabs-release-`lsb_release -cs`.deb
Тогда во-первых не надо будет менять скрипт после перехода на другую версию ОС, а во-вторых скрипт будет работать и на классическом debian.petro25
24.09.2015 14:23+1Спасибо за замечание. Просто у меня везде используется Ubuntu 14.04 и не возникало потребности в массовой установке на другие ОС(только для тестирования).
miwa
24.09.2015 14:34Да не за что.
Рано или поздно все равно надо будет переходить на следующую LTS, тогда разбор таких вот мелочей занимает слишком много времени и нервов.
gto
24.09.2015 14:18+1Да, за туториал спасибо. Вещь полезная, связка рабочая. Думаю для многих снизит порог входа.
gto
С активным агентом?
petro25
Да. Агенты обращаются к puppet серверу по умолчанию раз в пол часа. В результате мы имеем примерно 16 обращений в минуту.
gto
Тогда понятно. У нас агенты с 5 минутным интервалом вешали такую же связку, на похожей конфигурации напрочь когда их становилось чуть больше 200.
miwa
А зачем вам настолько частое обновление конфигурации?
Я не ерничаю, мне действительно интерессно.
gto
Больная тема, просто у нас девы вовлечены в процес конфигурации своих стейджей + все локальные вагранты через паппет. Сначала хотели их заставить ручками запускать агентов. Но волевым решением начальства всё было автоматизировано.
miwa
Понятно, спасибо.
baldr
Раз в полчаса — они размазаны по времени или все в одно и то же время?
Вот в этом, на мой взгляд, одна из главных опасных особенностей использования систем с самостоятельным агентом.
Например, мы имеем базу и несколько веб-серверов. Самый простой вариант…
База обновляется миграциями, все по-уму. Пусть даже руками, хотя это тоже хочется автоматически.
Но вот база обновилась, но код на веб серверах обновится хз в какой момент, но в течение получаса.
То есть все эти 30 минут мы не будем точно знать насколько консистентна система? А пользователи идут и получают ошибки либо в базу пишется что-то не то.
Это еще самый простой вариант, когда у вас нет сложной связки сервисов, которые нужно обновлять один-за-другим строго по очереди или обновлять кластер.
Прошу прощения, но у меня зуб на Puppet и Chef — я могу много недостатков перечислить :)
petro25
У меня через Puppet управляются обычные Ubuntu 14.04 Desktop и нет необходимости в том чтобы запускать чаще agent или же как-то синхронизировать обновления между машинами.
Агенты на них запускаются в разное время(так как все ПК в один момент не включаются, а включаются рандомно).
Интервал в 30 минут меня в данном случае устраивает, так как через Puppet у меня в основном производится установка обновлений ОС, установка софта, проверка работы сервисов, настройки прокси, установка сертификатов и т.д.(ничего такого что не может подождать 30 минут).
Если делаются изменения на серверах, то у меня тоже пока что нет таких сервисов(управляемых через Puppet) которые б зависели один от другого.
Когда появятся, думаю к тому времени я найду решение.
baldr
Согласен, для обновления независимых друг от друга компьютеров — решение может подойти.
Но, опять же, в своей практике я встречал слишком много случаев когда сервер, поднятый из стандартного образа, лез не на тот master-сервер из-за разных причин. Зашитый на ноде адрес мастера — очередная проблема.
petro25
А можно узнать какое у Вас решение для этой проблемы?
baldr
Я предпочитаю использовать push-схему, когда есть центральный сервер, который обладает знаниями о всей топологии и может принимать решения о порядке запуска обновлений на серверах.
Первоначальное решение «в лоб» мы делали следующим образом — центральный сервер выбирает группу серверов для обновления, пишет в chef-сервер необходимые параметры (роли), затем удаленно коннектится к каждой ноде (параллельно, распределенно) и насильно запускает на них chef-агент с заданным именем chef-сервера. Остальное — стандартно. После завершения работ ноды рапортуют на главный сервер и он выбирает следующую группу.
Позже мы ушли от Chef совсем, написав своего агента и немного упростив-улучшив схему.
gto
Мне кажется, что паппет не совсем для описанных вами целей разрабатывался. Это больше выглядит как деплой. А паппетно-шефные системы больше подходят для задач вроде сконфигурировать сервер (пул серверов) с нуля (кстати фореман можно настроить на полный провижн, с PXE, dhcp и пр.) и держать конфигурацию консистентной, переписывая ручные измения.
baldr
Соглашусь, но даже для этих целей меня, как администратора, напрягали бы следующие моменты:
* В нагруженной сети из 1000 (или больше машин) время от времени (в случайные моменты времени) сервера тратят время/трафик на бесполезные обращения к мастер-серверу. Два раза в месяц они находят обновления, но в остальное время они работают вхолостую.
* Из этих 1000 серверов внезапно на три не дошли обновления. Неизвестно почему. Агент не запросил. В Foreman мы увидим, конечно, что какие-то агенты долго не отвечали, но, поверьте, в большой сети у вас там скопится достаточное количество старых записей и вы не сразу отловите эти необновленные конфигурации.
* внезапно количество серверов резко возрастает и приходится придумывать схемы с балансированием нагрузки, поскольку сервер начинает трещать даже если не делает ничего.
* обновления накатываются фактически бесконтрольно. Когда-то в течение этих N минут что-то накатится. Если нода была выключена месяц, а потом включилась — она будет тянуть все эти манифесты и применять, даже если сейчас не время…
* адрес мастер-сервера может смениться. Вот полетел raid в ESXi-кластере, мастер паппета недоступен, бэкап есть, но с тем же именем в сети его поднять не получается по каким-то причинам.
В серьезных сетях я предпочел бы контролировать такие вещи более строго.
petro25
1. Они делают изменения не 2 раза в месяц(обновления 2 раза в месяц), но есть еще и другие процедуры которые проделываются чаще. Но да, больше половины запросов проходят впустую.
2. Работу агентов контролируют локальные системные администраторы, если определенные клиенты почему-то не получили обновления, это сразу проверяется(также каждые сутки приходят отчеты в почту).
3. Пока есть запас по увеличению мощности виртуального сервера, когда не будет хватать мощности, буду думать как сделать балансировку.
4. Обновления накатываются не бесконтрольно, вначале обновления тестируются на тестовой группе, потом накатываются по всем остальным ПК.
5. В EXSi настроена отказоустойчивость и живая миграция(отдельный сторедж для виртуалок), есть суточные бэкапы мастер-сервера. Я не вижу причин почему нельзя поднять бэкап с тем же именем.
baldr
Ну, опять же, у вас просто еще не те масштабы. И не задача полноценного деплоя.
Что касается «с тем же именем» — не совсем в тему, но вспомнил несколько случаев когда доблестные сетевые инженеры случайно косячили и в сети появлялось устройство с не совсем уникальным IP-адресом. Поскольку использовать DHCP считалось не совсем безопасным, а так же часто требовались статические адреса — все адреса в сети выдавались руками. И коллизии случались.
Иногда проще и быстрее переименовать свой сервер, чем писать заявку на смену IP-адреса у свича, которая будет запланирована через неделю.
Еще вполне может отвалиться вся подсеть, в которой стоит ваш мастер-сервер.
Случиться может что угодно, а статически зашитый адрес мастера на нескольких тысячах устройств, на мой взгляд, не гибко.
petro25
Где Вы увидели статически зашитый IP адрес? Во всех клиентах прописано DNS имя(в данном примере srv.co.com) для Puppet Master.
В случае проблем — поднимаем виртуалку(
хоть на VmWare Player) в любой видимой для клиентов сети, нужно только изменить DNS запись.baldr
IP-адрес — это просто пример из жизни. Случиться может что угодно.
DNS-адреса могут кэшироваться, а задача «поднимем виртуалку» имеет смысл только если у вас есть полный образ всего сервера. Либо бэкапы всех сертификатов нод, чтобы заново их не регистрировать.
petro25
В моем случае меня вполне устраивает возможность в любой момент поднять бекап суточной давности.
petro25
Puppet — у меня не в качестве деплоя, он именно для держания конфигурации консистентной. Для деплоя я использую iPXE с набором seed файлов. Puppet же не позволяет пользователям изменять определенные конфиги(точнее позволяет, но потом назад возвращает все), с помощью puppet я могу централизовано внести любые изменения в уже установленную систему.
Foreman был избран мной потому что он бесплатный и имеет лучший функционал чем другие альтернативы.
Также не последним была возможность развертывания ОС по РХЕ и прочее. В будущем я опишу детальнее функционал Foreman в особенности его работу с гипервизорами.
baldr
Не подумайте что я вас критикую — наоборот, я вам даже плюс поставил.
Моя мысль всегда — для определенных случаев Puppet/Chef вполне подходят.
Но как «silver bullet» надо использовать их с осторожностью.
petro25
Я ничего плохого не подумал. К критике отношусь положительно, ведь тогда можно узнать о минусах(которых сам не замечал) своего решения.
Использую я данное решение потому оно мне показалось удачным(
а вообще время покажет).miwa
Да-да, мы в курсе о вашем зубе и даже помним что вы обещали продолжение вашей статьи. Неплохо бы выполнить обещание. Без этого… Скажем так, приведенный вами пример я разрулю. При том что опыта работы с паппетом у меня, скажем так, ровно столько, сколько можно научиться самому управляя несколькими десятками не особо сложных серверов.
baldr
Виноват, со статьей все-таки соберусь. Этот топик лишний раз будет стимулом.
А как бы вы разрулили мой пример (плюс остальные, если есть мысли)? Чисто для статистики — хочется знать мнения коллег.
miwa
Ну, боюсь, что я вашу статистику не сильно улучшу и ничего нового не расскажу. Во-первых, chef/puppet действительно не умеют оркестрацию, насколько мне известно — они просто не для того создавались. Из этого следует, что ни кластер ни просто несколько взаимосвязанных серверов они обновить не смогут. Во-вторых, puppet — не предназначен для деплоя приложений. Да, из-за того что он может управлять конфигурацией пакетного менеджера (и по ряду других причин) с его помощью очень удобно установить или обновить много-много пакетов, в том числе в определенном порядке. Но — это все будет делать не шеф/паппет, а пакетный менеджер.
Вы все это, конечно, и без меня знаете; я просто не хочу потерять контекст беседы.
Так вот. При всем при этом чтобы обновить в определенном порядке взаимосвязанные сервисы на разных нодах, надо все равно изобретать велосипед. Либо как вы описали выше — отдельным процессом менять конфигурацию SCM и потом принудительно дергать агента. Мы склонились к идее пакетировать (deb/msi) разрабатываемый софт и писать его (софт) с учетом возможных неконсистентных состояний. При том новые пакеты викладываются либо во время технологичных окон, либо в периоды минимальной нагрузки на систему.
P.S. Беглый гуглеж говорит, что puppet enterprise умеет какой-то orchestration. В жизни не видел РЕ, так что ничего по этому поводу сказать не могу.
baldr
Большой плюс вам за пакеты — не все так делают, а если не делают, то при деплое очень много веселого геморроя с удалением.
PE я тоже не трогал руками, но, судя по документации, не так уж много он умеет — просто может объединять задачи в несколько этапов (например, процент одновременно обновляемых серверов). Тем более в командной строке — половина работы руками.
Меня тут все правильно поправляют что puppet/chef — не для полноценного деплоя. Хорошо когда это понимают, потому что он позиционируется именно как инструмент для руления всей инфраструктурой.
lexore
Сейчас в puppet есть MCollective
puppetlabs.com/mcollective
Кроме всего прочего, он умеет делать «push» сразу на все сервера.
baldr
А, вот, кстати, спасибо. Это что-то новое, я еще не видел этой фичи.
Похоже что оно использует промежуточные сервера, связанные через ActiveMQ для одновременной посылки broadcast-сообщений на сервера.
Однако вот это примечание сразу настраивает меня против:
Когда я все-таки допишу статью, я объясню что я еще и против принятия решений нодами. :)
lexore
Эт необязательно.
Можно использовать вот так:
И он выгрузит только для тех нод, у которых имя попадает под регулярку.