> Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть II. Настройка Puppet Masters
> Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть III. Настройка puppet-db с помощью Puppet
Мой опыт использования puppet. До написания настоящей статьи, я работал с Open Source Puppet версии 3 в stand alone конфигурации, и использовал его для управления несколькими сотнями хостов. Но пришло время расти: количество управляемых хостов вышло за тысячу, и грозит в ближайшем будущем перевалить за несколько тысяч. Было принято решение для распределения нагрузки и повышения отказоустойчивости развернуть Open Source Puppet версии 4 с несколькими серверами Puppet Master и отдельным сервером PuppetDB с postgresql. А также использовать для хранения окружений с конфигурациями конечных хостов git-репозиторий на git-сервере.
Вначале хотел бы предложить краткий обзор уже имеющийся статей на habrahabr.
Настройка современного Puppet сервера с нуля
Перевод статьи «Setup of modern Puppet of the server from scratch» выполненный grundic, оригинал которой мне удалось найти только в кэше гугла. Эта статья была взята мной за основу при подготовке публикации. Детали, описанные в оригинале статьи «Setup of modern Puppet of the server from scratch», как и дополнения переводчика в ее переводе, уже успели немного устареть. Это, а также желание поделиться описанием дополнительных тонкостей, побудило меня к написанию собственной статьи.
Вариант развёртывания Linux систем на базе Puppet 4. Часть III: установка Puppet Server (cfpuppetserver)
Статья является частью цикла, где автор andvgal описывает развертывание целой инфраструктуры. В статье автор предлагает автоматизировать процесс установки puppet с помощью пакета cfpuppetserver, разработанного самим автором статьи. Очень интересно, но сложно для начинающего кукловода.
Puppet под нагрузкой
Интересная статья от компании Badoo, содержащая большое количество схем, раскрывающих механизмы работы Puppet 3.
Как стать кукловодом или Puppet для начинающих
Статья хорошо начинается, даются базовые понятия о Puppet. В конце статьи автор Aecktann обещает продолжение, которое, к сожалению, за 4 года так и не появилось.
Puppet, система управления конфигурациями. Статья в двух частях: Часть I, Часть II
Автор spanasik дает базовые понятия о Puppet, а также описывает установку stand alone puppet master без других компонентов.
Общие сведения о Puppet. Puppet-агенты установлены на управляемых узлах, которые называются нодами (node). Через определенные интервалы времени (по умолчанию 30 минут) puppet-агенты подключаются к серверам Puppet, передают данные о нодах (факты), на которых они установлены; получают от серверов описания конфигураций для управляемых нод, а также необходимые данные и инструменты для настройки конфигураций.
Конфигурации для управляемых нод хранятся на серверах puppet в виде текстовых файлов. Такие файлы называются манифестами. Манифесты объединяются в окружения. Каждое окружение puppet содержит свой набор манифестов. Окружение по умолчанию называется production. Для тестирования обычно используют окружение developmement. Каждый управляемый узел может одновременно находится только в одном окружении.
Окружения, содержащие текстовые файлы с манифестами puppet, принято хранить в git-репозитории, который можно разместить на git-сервере. Каждому окружению будет соответствовать ветка (branch) в git-репозитории.
Для синхронизации окружений на каждом puppet-сервере используется робот R10k, который запускается с помощью post-receive хука в git-репозитории. Подробнее об этом роботе в блоге его создателя.
Данные, передаваемые puppet-агентами на серверы puppet, можно хранить локально на серверах в виде текстовых файлов, или в базе данных PuppetDB. PuppetDB позволяет использовать продвинутые возможности puppet, а также может использоваться в сторонних приложениях.
Для расширения базовых возможностей Puppet используются различные модули, которые можно загрузить с Puppet Forge, GitHub, или другого источника, а также создать самостоятельно.
puppetmaster.example.com – имя кластера.
puppet-master01.example.com – Puppet Master нода 1, также на нем будет работать Certificate Authority Service.
puppet-master02.example.com – Puppet Master нода 2.
Соответственно можно продолжить puppet-masterN.example.com – Puppet Master нода N. Все настройки, сделанные для puppet-master02.example.com подойдут для последующих нод.
puppet-db.example.com – сервер PuppetDB, сервер postgresql.
sgl-git.example.com – git-сервер для хранения git-репозитория, который содержит окружения с манифестами puppet.
На всех серверах установлена ОС Ubuntu 16.04.
aspetrenko — пользователь-администратор с правами для выполнения sudo (присутсвует на всех серверах).
gitolite3 – пользователь от имени которого работает git-сервер gitolite3 (на сервере sgl-git).
r10k – пользователь от имени которого работает робот r10k (на серверах puppet-master).
Варианты настройки DNS серверов описаны в соответствующем разделе документации Puppet. В моем случае используется подход описанный в разделе про Round-Robin DNS. Хотя это не имеет принципиального значения.
aspetrenko, aspetrenko.pub – приватный и публичный ключ администратора.
gitolite3, gitolite3.pub – ключи пользователя gitolite3. Публичный ключ gitolite3.pub нужно разместить в списке авторизованных ключей (~/ssh/authorized_keys) пользователя r10k на каждом сервере puppet-master, чтобы пользователь gitolite3 мог авторизоваться и запустить обновление окружений.
r10k, r10k.pub – ключи пользователя r10k. Публичный ключ r10k.pub нужно разместить в административном репозитории gitolite3 (каталог keydir в репозитории gitolite-admin) для того, чтобы робот r10k мог авторизоваться на git-сервере, и забрать окружения из git-репозитория для обновления окружений в локальной файловой системе. Ключи можно создать на любом компьютере, где есть ssh-keygen. Ключи нужно создавать без защиты паролем, чтобы авторизация могла происходить без участия человека. Создадим ключи администратора, и скопируем публичный ключ на sgl-git:
Он будет выполнять роль ключа администратора gitolite3. Создадим пользователя для r10k на серверах puppet-master01 и puppet-master02:
И зададим пользователю r10k пароль:
С паролем будет удобнее в процессе установки. Потом вход по паролю можно будет отключить, и оставить авторизацию только по ключу.
Создадим ключи пользователя r10k на puppet-master01, и скопируем приватный ключ на сервер puppet-master02:
В процессе установки git-сервера gitolite3, автоматически будет создан пользователь с аналогичным именем gitolite3. Нужно будет добавить публичный ключ этого пользователя в список доверенных ключей пользователя r10k на серверах puppet-master01 и puppet-master02, чтобы gitolite3 мог с помощью post-receive хука в репозитории puppet-environments запустить робота R10k.
Подробнее об автоизации с использованием ключей можно прочитать, например здесь. В итоге должно получиться как на схеме ниже.
Подробнее о gitolite можно почитать в официальной документации или на хабре.
Установим git и perl:
Запустим установку gitolite из репозитория Ubuntu:
В процессе установки укажем абсолютный путь к публичному ключу администратора aspetrenko.pub. Если вы ошиблись, то путь к ключу администратора можно указать следующим образом от системного пользователя gitolite3:
Ключ будет сохранен в административном репозитории gitolite-admin в каталоге keydir под именем admin.pub.
Gitolite3 хранит репозитории в своем домашнем каталоге /var/lib/gitolite3/repositories/. Если вы хотите хранить репозитории в другом месте, как я, то можно перенести их следующим образом:
Добавить в файл /etc/gitolite3/gitolite.rc в раздел "%RC = ("
И перенести репозитории в новое расположение:
Напрямую редактировать git-репозитории в каталоге /var/lib/gitolite3/repositories нельзя. На компьютере aspetrenko-pc, откуда будем работать с репозиториями на нашем сервере, укажем настройки авторизации по ssh для sgl-git в файле ~/.ssh/config:
где aspetrenko — приватный ключ администратора. Cклонируем административный репозиторий себе в домашний каталог:
Если сервер просит пароль, значит доступ с помощью ssh-ключей был настроен неправильно. В результате получим:
Настройки доступа к репозиториям находятся в файле gitolite-admin/conf/gitolite.conf
admin – это пользователь, ключ которого был указан при настройке gitolite3:
Поместим публичный ключ пользователя r10k в административный репозиторий gitolite3:
Добавим ключ r10k.pub в git:
Создадим репозиторий для хранения окружений puppet, для этого на aspetrenko-pc добавим в файл gitolite-admin/conf/gitolite.conf следующие строки:
Зафиксируем изменения в git:
И отправим все это на sgl-git:
Gitolite3 с помощью хуков создаст новый пустой репозиторий на sgl-git:
Не забудьте создать ключи для пользователя gitolite3, и добавить публичный ключ в в список доверенных ключей пользователя r10k на каждом сервере puppet-master01 и puppet-master02:
Приватный ключ gitolite3 должен оказаться в директории /var/lib/gitolite3/.ssh.
Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть II. Настройка Puppet Masters
> Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть III. Настройка puppet-db с помощью Puppet
Предисловие
Мой опыт использования puppet. До написания настоящей статьи, я работал с Open Source Puppet версии 3 в stand alone конфигурации, и использовал его для управления несколькими сотнями хостов. Но пришло время расти: количество управляемых хостов вышло за тысячу, и грозит в ближайшем будущем перевалить за несколько тысяч. Было принято решение для распределения нагрузки и повышения отказоустойчивости развернуть Open Source Puppet версии 4 с несколькими серверами Puppet Master и отдельным сервером PuppetDB с postgresql. А также использовать для хранения окружений с конфигурациями конечных хостов git-репозиторий на git-сервере.
Краткий обзор статей на habrahabr по развертыванию Puppet
Вначале хотел бы предложить краткий обзор уже имеющийся статей на habrahabr.
Настройка современного Puppet сервера с нуля
Перевод статьи «Setup of modern Puppet of the server from scratch» выполненный grundic, оригинал которой мне удалось найти только в кэше гугла. Эта статья была взята мной за основу при подготовке публикации. Детали, описанные в оригинале статьи «Setup of modern Puppet of the server from scratch», как и дополнения переводчика в ее переводе, уже успели немного устареть. Это, а также желание поделиться описанием дополнительных тонкостей, побудило меня к написанию собственной статьи.
Вариант развёртывания Linux систем на базе Puppet 4. Часть III: установка Puppet Server (cfpuppetserver)
Статья является частью цикла, где автор andvgal описывает развертывание целой инфраструктуры. В статье автор предлагает автоматизировать процесс установки puppet с помощью пакета cfpuppetserver, разработанного самим автором статьи. Очень интересно, но сложно для начинающего кукловода.
Puppet под нагрузкой
Интересная статья от компании Badoo, содержащая большое количество схем, раскрывающих механизмы работы Puppet 3.
Как стать кукловодом или Puppet для начинающих
Статья хорошо начинается, даются базовые понятия о Puppet. В конце статьи автор Aecktann обещает продолжение, которое, к сожалению, за 4 года так и не появилось.
Puppet, система управления конфигурациями. Статья в двух частях: Часть I, Часть II
Автор spanasik дает базовые понятия о Puppet, а также описывает установку stand alone puppet master без других компонентов.
Введение
Общие сведения о Puppet. Puppet-агенты установлены на управляемых узлах, которые называются нодами (node). Через определенные интервалы времени (по умолчанию 30 минут) puppet-агенты подключаются к серверам Puppet, передают данные о нодах (факты), на которых они установлены; получают от серверов описания конфигураций для управляемых нод, а также необходимые данные и инструменты для настройки конфигураций.
Конфигурации для управляемых нод хранятся на серверах puppet в виде текстовых файлов. Такие файлы называются манифестами. Манифесты объединяются в окружения. Каждое окружение puppet содержит свой набор манифестов. Окружение по умолчанию называется production. Для тестирования обычно используют окружение developmement. Каждый управляемый узел может одновременно находится только в одном окружении.
Окружения, содержащие текстовые файлы с манифестами puppet, принято хранить в git-репозитории, который можно разместить на git-сервере. Каждому окружению будет соответствовать ветка (branch) в git-репозитории.
Для синхронизации окружений на каждом puppet-сервере используется робот R10k, который запускается с помощью post-receive хука в git-репозитории. Подробнее об этом роботе в блоге его создателя.
Данные, передаваемые puppet-агентами на серверы puppet, можно хранить локально на серверах в виде текстовых файлов, или в базе данных PuppetDB. PuppetDB позволяет использовать продвинутые возможности puppet, а также может использоваться в сторонних приложениях.
Для расширения базовых возможностей Puppet используются различные модули, которые можно загрузить с Puppet Forge, GitHub, или другого источника, а также создать самостоятельно.
Имена серверов
puppetmaster.example.com – имя кластера.
puppet-master01.example.com – Puppet Master нода 1, также на нем будет работать Certificate Authority Service.
puppet-master02.example.com – Puppet Master нода 2.
Соответственно можно продолжить puppet-masterN.example.com – Puppet Master нода N. Все настройки, сделанные для puppet-master02.example.com подойдут для последующих нод.
puppet-db.example.com – сервер PuppetDB, сервер postgresql.
sgl-git.example.com – git-сервер для хранения git-репозитория, который содержит окружения с манифестами puppet.
Об ОС на серверах
На всех серверах установлена ОС Ubuntu 16.04.
Пользователи
aspetrenko — пользователь-администратор с правами для выполнения sudo (присутсвует на всех серверах).
gitolite3 – пользователь от имени которого работает git-сервер gitolite3 (на сервере sgl-git).
r10k – пользователь от имени которого работает робот r10k (на серверах puppet-master).
Настройка DNS
Варианты настройки DNS серверов описаны в соответствующем разделе документации Puppet. В моем случае используется подход описанный в разделе про Round-Robin DNS. Хотя это не имеет принципиального значения.
Авторизация по ssh с помощью ключей
aspetrenko, aspetrenko.pub – приватный и публичный ключ администратора.
gitolite3, gitolite3.pub – ключи пользователя gitolite3. Публичный ключ gitolite3.pub нужно разместить в списке авторизованных ключей (~/ssh/authorized_keys) пользователя r10k на каждом сервере puppet-master, чтобы пользователь gitolite3 мог авторизоваться и запустить обновление окружений.
r10k, r10k.pub – ключи пользователя r10k. Публичный ключ r10k.pub нужно разместить в административном репозитории gitolite3 (каталог keydir в репозитории gitolite-admin) для того, чтобы робот r10k мог авторизоваться на git-сервере, и забрать окружения из git-репозитория для обновления окружений в локальной файловой системе. Ключи можно создать на любом компьютере, где есть ssh-keygen. Ключи нужно создавать без защиты паролем, чтобы авторизация могла происходить без участия человека. Создадим ключи администратора, и скопируем публичный ключ на sgl-git:
aspetrenko@aspetrenko-pc:~$ ssh-keygen -t rsa -f ~/.ssh/aspetrenko
aspetrenko@aspetrenko-pc:~$ scp ~/.ssh/aspetrenko.pub aspetrenko@sgl-git:/home/aspetrenko/.ssh/Он будет выполнять роль ключа администратора gitolite3. Создадим пользователя для r10k на серверах puppet-master01 и puppet-master02:
sudo useradd -m -s /bin/bash r10kИ зададим пользователю r10k пароль:
sudo passwd r10kС паролем будет удобнее в процессе установки. Потом вход по паролю можно будет отключить, и оставить авторизацию только по ключу.
Создадим ключи пользователя r10k на puppet-master01, и скопируем приватный ключ на сервер puppet-master02:
aspetrenko@puppet-master01:~$ sudo su - r10k
r10k@puppet-master01:~$ ssh-keygen -t rsa -f ~/.ssh/r10k
r10k@puppet-master01:~$ scp /home/r10k/.ssh/r10k r10k@puppet-master02:/home/r10k/.ssh/В процессе установки git-сервера gitolite3, автоматически будет создан пользователь с аналогичным именем gitolite3. Нужно будет добавить публичный ключ этого пользователя в список доверенных ключей пользователя r10k на серверах puppet-master01 и puppet-master02, чтобы gitolite3 мог с помощью post-receive хука в репозитории puppet-environments запустить робота R10k.
Подробнее об автоизации с использованием ключей можно прочитать, например здесь. В итоге должно получиться как на схеме ниже.
Установка и настройка git-сервера
Подробнее о gitolite можно почитать в официальной документации или на хабре.
Установим gitolite3 на sgl-git
Установим git и perl:
aspetrenko@sgl-git:~$ sudo apt install git perlЗапустим установку gitolite из репозитория Ubuntu:
aspetrenko@sgl-git:~$ sudo apt install gitolite3В процессе установки укажем абсолютный путь к публичному ключу администратора aspetrenko.pub. Если вы ошиблись, то путь к ключу администратора можно указать следующим образом от системного пользователя gitolite3:
aspetrenko@sgl-git:~$ sudo su - gitolite3
gitolite3@sgl-git:~$ $HOME/bin/gitolite setup -pk /home/aspetrenko/.ssh/aspetrenko.pubКлюч будет сохранен в административном репозитории gitolite-admin в каталоге keydir под именем admin.pub.
Gitolite3 хранит репозитории в своем домашнем каталоге /var/lib/gitolite3/repositories/. Если вы хотите хранить репозитории в другом месте, как я, то можно перенести их следующим образом:
Добавить в файл /etc/gitolite3/gitolite.rc в раздел "%RC = ("
# Custom path for repos
GL_REPO_BASE => "/media/data/repositories",И перенести репозитории в новое расположение:
sudo mv /var/lib/gitolite3/repositories /media/data/Настроим gitolite3
Напрямую редактировать git-репозитории в каталоге /var/lib/gitolite3/repositories нельзя. На компьютере aspetrenko-pc, откуда будем работать с репозиториями на нашем сервере, укажем настройки авторизации по ssh для sgl-git в файле ~/.ssh/config:
host sgl-git
HostName sgl-git.example.com
IdentityFile ~/.ssh/aspetrenko
User gitolite3где aspetrenko — приватный ключ администратора. Cклонируем административный репозиторий себе в домашний каталог:
aspetrenko@aspetrenko-pc:~$ mkdir sgl-git
aspetrenko@aspetrenko-pc:~$ cd sgl-git
aspetrenko@aspetrenko-pc:~/sgl-git$ git clone gitolite3@sgl-git:gitolite-adminЕсли сервер просит пароль, значит доступ с помощью ssh-ключей был настроен неправильно. В результате получим:
aspetrenko@aspetrenko-pc:~/sgl-git/gitolite-admin$ tree
.
+-- conf
¦ L-- gitolite.conf
L-- keydir
L-- admin.pub
2 directories, 2 filesНастройки доступа к репозиториям находятся в файле gitolite-admin/conf/gitolite.conf
aspetrenko@aspetrenko-pc:~/sgl-git/gitolite-admin$ cat conf/gitolite.conf
repo gitolite-admin
RW+ = admin
repo testing
RW+ = @alladmin – это пользователь, ключ которого был указан при настройке gitolite3:
aspetrenko@aspetrenko-pc:~/sgl-git$ cat gitolite-admin/keydir/admin.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIFC/2v1S4WvvITHAXCuVle7dLZz0zL7z4dAWXvmMcqCLepfGI1suDBby6PW04tVwHvniAW5B/5HbZ2Fr7zCoeMrhGE5Z76/DBfidhO15CZbAMPOcs3X7aP4aZFK2GfiXCt7/yunP6f3zp3i6KbsZhcSeeUmmkeQFwccJsstVJbj9ciWHrLN/UDHwT5OTBVFKBpRZGM5pT6xzvWaPNN4IRlk5AN4ClrhWf13 aspetrenko@aspetrenko-pcПоместим публичный ключ пользователя r10k в административный репозиторий gitolite3:
r10k@puppet-master01:~$ scp /home/r10k/.ssh/r10k.pub aspetrenko@aspetrenko-pc:/home/aspetrenko/sgl-git/gitolite-admin/keydirДобавим ключ r10k.pub в git:
aspetrenko@aspetrenko-pc:~/sgl-git/gitolite-admin$ git add keydir/r10k.pubСоздадим репозиторий для хранения окружений puppet, для этого на aspetrenko-pc добавим в файл gitolite-admin/conf/gitolite.conf следующие строки:
repo puppet-environments
RW+ = admin
R = r10k Зафиксируем изменения в git:
aspetrenko@aspetrenko-pc:~/sgl-git/gitolite-admin$ git commit -a -m "Add puppet-environments repo"
[master 585326d] Add puppet-environments repo
1 file changed, 3 insertions(+)И отправим все это на sgl-git:
aspetrenko@aspetrenko-pc:~/sgl-git/gitolite-admin$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 411 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Initialized empty Git repository in /media/data/repositories/puppet-environments.git/
To gitolite3@sgl-git:gitolite-admin
7946dea..585326d master -> masterGitolite3 с помощью хуков создаст новый пустой репозиторий на sgl-git:
aspetrenko@sgl-git:~$ sudo ls /media/data/repositories/puppet-environments.git
branches config gl-conf HEAD hooks info objects refsНе забудьте создать ключи для пользователя gitolite3, и добавить публичный ключ в в список доверенных ключей пользователя r10k на каждом сервере puppet-master01 и puppet-master02:
aspetrenko@sgl-git:~$ sudo su - gitolite3
gitolite3@sgl-git:~$ ssh-keygen -t rsa -f ~/.ssh/gitolite3
gitolite3@sgl-git:~$ ssh-copy-id -i ~/.ssh/gitolite3.pub r10k@puppet-master01
gitolite3@sgl-git:~$ ssh-copy-id -i ~/.ssh/gitolite3.pub r10k@puppet-master02Приватный ключ gitolite3 должен оказаться в директории /var/lib/gitolite3/.ssh.
Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть II. Настройка Puppet Masters
Поделиться с друзьями