Puppet для управления и автоматизации Linux часть 5.

Введение.

В этой части мы будем устанавливать базу данных платформы. База Puppetdb является одной из трёх составляющих ядра платформы в которую входят: мастер-сервер, puppet-agent и puppetdb.

Подготовка puppetdb.

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

  • При подключении к PuppetDB, мастер сервер осуществляет:
    • отправку данные каждого узла в PuppetDB
    • посылает запрос PuppetDB для составлении каталогов узлов

Но прежде чем приступить к установке связки Puppetdb+PostgreSQL, попробуем организовать работу сервера без них. В этом случае мы получаем простую в установке систему автоматизации выполнения кода различного характера. Надо отметить, что при этом не будут доступна система контроля в виде графического интерфейса и сбора информации. Проконтролировать выполнение задач можно будет другими штатными средствами которых достаточно в Linux. К вопросу установки базы данных Puppet вернёмся позднее в другой части нашей повести.

Работа Puppet без puppetdb.

В качестве примера работы платформы без использования puppetdb установим, с помощью кода, на рабочею станцию lin-sl пакет notepad. Многим пользователям пришедшим в Linux из Windows эта программа хорошо знакома и они без неё скучают… В репозитории ALT Linux программа звучить как notepadqq.

Подготовка манифеста.

Под манифестом мы понимаем небольшую программу содержащею описание для выполнения последовательности кода. В нашем случае этим кодом является установка утилиты notepad с помощью агента на клиентском ПК. Сам манифест хранится(объявляется) в хранилище мастер сервера1. Агент на клиенте через равные промежутки времени осуществляет соединение(синхронизация) с мастер-сервером, проверяя наличие новых манифестов и выполнение кода указанного в них. Запуск агента можно выполнить и в ручном режиме.

Манифест notepad2.

Создадим в каталоге vim /etc/puppet/code/environments/production/manifests/soft.pp сценарий для установки программы MS Windows notepad.

node 'lin-sl' {
       Package { ensure => installed }
       package { 'notepadqq': }
 }

Если несколько узлов (node)3 — перечислить через запятую. Поместим манифест в каталог показанный в начале.

Выполнение манифеста.

На рабочей станции запускаем команду.

# puppet agent --test --verbose

Контроль выполнения манифеста.

Проконтролировать выполнение кода можно несколькими способами. 1.Запустить в «ручную» агента, как показано выше или подождать выполнение обращения агента к серверу ~30 мин. В любом случае появится сообщение, если успешно, как показано ниже.

# .... Notice: /Stage[main]/Main/Node[lin-sl]/Package[notepadqq]/ensure: created (corrective) Notice: Applied catalog in 12.74 seconds

2.Непосредственно на рабочей станции, проверить лоток «Стандартные».

Программа notepad установлена в папке «Стандартные «.

3. Смотреть журнал мастер-сервера, отчёты о своих действиях агенты отправляет на сервер.

Заключение.

В этой части мы рассмотрели работу Puppet без установки базы данных Puppetdb + PostgreSQL. Этим мы сократили время для перехода к практическому использованию платформы и наглядному показу, как это всё работает. Конечно такая тонкая работа, как сбор статистических данных, например серийных номеров или параметров HDD, ОЗУ… требуют наличие хранилища в виде БД. Но нам же не терпится, а с установкой и настройкой PostgreSQL и puppetdb можно «завязнуть», после чего махнув рукой и послав… бросить эту затею. В том состоянии Puppet, которое было описано выше, многие администраторы найдут полезное для своей организации и для себя, освобождая от рутины своё рабочее время. Мониторинг и сбор сведений можно поручить Zabbix.

Полезные ссылки.

Сноски.

  1. Путь хранилища /etc/puppet/code/environments/production/manifests ↩︎
  2. Созданию манифестов будет посвящена отдельная статья ↩︎
  3. Если указать defoult, выполнять код сможет любая станция где есть агент ↩︎

Puppet для управления и автоматизации Linux часть 4.

Введение.

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

Установка puppet agent.

  • Стенд
    • Cервер ALT Linux , имя lin-pup; ip-10.0.2.33
      • CPU Intel Core 5
      • HDD >50Gb
      • ОЗУ > 8Gb
      • ALT Simply Linux, имя lin-sl; ip-10.0.2.32

Как установить puppet agent см. часть 3. Для понимания технологии взаимодействия цепочки сертификатов между мастер-сервером и агентом клиентского устройства ниже приводится пошаговая инструкция.

Договоримся, мастер-сервер установлен и проверен. Запись DNS на клиентском устройстве и сервере присутствует, всё готово для работы. Контролировать наши действия будем с двух консолей — сервера и клиента.

Puppet agent Шаг 1.

После установки на «чистой» клиентской станции агента, выполняем действия по инициализации сертификата.

Под «чистой» понимают, что никаких действий с агентом до этого не проводилось…

Генерируем пару ключей: private1 и public, формат pem2.

# puppet ssl bootstrap …: csr_attributes file loading from /etc/puppet/csr_attributes.yaml …: Creating a new SSL certificate request for lin-sl …: Certificate Request fingerprint (SHA256): A0:45:71:65:C8:BE:75:A0:70:F9:3B:9A:DE:E5:69:CD:7E:36:EC:01:1F:BA:4F:4F:4E:88:10:6F:96:4A:BA:E7 …: Certificate for lin-sl has not been signed yet Couldn’t fetch certificate from CA server; you might still need to sign this agent’s certificate (lin-sl). …: Will try again in 120 seconds.

На консоли сервера наблюдаем такую картину.

# puppetserver ca list --all Requested Certificates: lin-sl (SHA256) A0:45:71:65:C8:BE:75:A0:70:F9:3B:9A:DE:E5:69:CD:7E:36:EC:01:1F:BA:4F:4F:4E:88:10:6F:96:4A:BA:E7 Signed Certificates: lin-pup (SHA256) 2A:3E:66:AD:3F:35:05:60:45:3A:C1:3A:37:58:5C:72:32:57:E8:D2:82:54:76:A6:95:43:10:C9:BC:93:6A:1A alt names: ["DNS:puppet", "DNS:lin-pup"] authorization extensions: [pp_cli_auth: true]

Из приведённого листинга видно, что ключ сертификата агента клиентского устройства «встал» в очередь для подписи CA мастер-сервера.

Puppet agent Шаг 2.

Теперь нам необходимо подписать полученный сертификат на сервере.

# puppetserver ca sign --certname lin-sl
Successfully signed certificate request for lin-pup

Смотрим общею картину показную CA мастер-сервера.

# puppetserver ca list --all ... Signed Certificates: lin-sl (SHA256) 82:F7:8D:05:0C:72:FA:5F:3A:2B:11:34:9C:2C:CB:A8:3B:64:86:2D:70:7C:D1:E7:E1:0C:89:D3:1E:53:6A:A3 lin-pup (SHA256) C5:C4:11:4A:2D:EC:C8:2F:22:31:A3:F5:8C:91:BD:B6:E9:05:FB:AF:FD:80:63:48:31:31:2C:8B:5A:55:BA:E0 alt names: ["DNS:puppet", "DNS:lin-pup"] authorization extensions: [pp_cli_auth: true]

Из предыдущей текста видно — все сертификаты имеют подпись.

Puppet agent Шаг 3.

На агенте клиентской станции проверяем работу сертификата.

# puppet ssl bootstrap Notice: Completed SSL initialization
# puppet agent —test … Using environment ‘production’ …: Retrieving pluginfacts …: Retrieving plugin …: Caching catalog for lin-sl …: Applying configuration version ‘1702707510’ Notice: Applied catalog in 0.02 seconds

Выводимая информация указывает на доверительные отношения между клиент-сервер с помощью SSL шифрования.

Troubleshooting Puppet agent.

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

Замена ключей SSL агента.

Мы установили ключи на рабочей станции, у нас всё работает можно двигаться дальше. Но вот нам потребовалось пересоздать сертификат, причин может быть много, изменилось имя ПК, IP… Для новой генерации ключей, сначала необходимо удалить старые сертификаты на клиенте, предварительно остановив агент.

# systemctl stop puppet
# rm -rf /etc/puppet/ssl/ ‘/etc/puppet/ssl/’? y rm: спуститься в каталог ‘/etc/puppet/ssl/private_keys’? y rm: удалить обычный файл ‘/etc/puppet/ssl/private_keys/sl.dom.pem’? y rm: удалить обычный файл ‘/etc/puppet/ssl/private_keys/sl.pem’? y rm: удалить каталог ‘/etc/puppet/ssl/private_keys’? y rm: спуститься в каталог ‘/etc/puppet/ssl/certs’? y rm: удалить обычный файл ‘/etc/puppet/ssl/certs/ca.pem’? y rm: удалить каталог ‘/etc/puppet/ssl/certs’? y rm: удалить каталог ‘/etc/puppet/ssl/public_keys’? y rm: удалить каталог ‘/etc/puppet/ssl/certificate_requests’? y rm: удалить каталог ‘/etc/puppet/ssl/private’? y rm: удалить обычный файл ‘/etc/puppet/ssl/crl.pem’? y rm: удалить каталог ‘/etc/puppet/ssl/’? y
# systemctl start puppet

Приведённый листинг показывает подробности удаления каталога ключей. В действительности при использовании дополнительного ключа "f" — всё удаляется без предупреждения.

Теперь необходимо проделать манипуляции как в шаге 1.

# puppet ssl bootstrap Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for lin-sl Info: Certificate Request fingerprint (SHA256): 74:78:39:FF:2B:E8:89:9C:31:27:11:55:5C:47:B9:27:8D:51:26:7D:EC:C9:AD:70:41:55:0A:CC:68:E0:54:FF Info: Downloaded certificate for sl.dom from https://lin-pup:8140/puppet-ca/v1 Error: The certificate for ‘CN=lin-sl’ does not match its private key Info: Will try again in 120 seconds.

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

Удаляем старый сертификат на CA мастер-сервере.

# puppetserver ca list --all
Signed Certificates: lin-sl (SHA256) 82:F7:8D:05:0C:72:FA:5F:3A:2B:11:34:9C:2C:CB:A8:3B:64:86:2D:70:7C:D1:E7:E1:0C:89:D3:1E:53:6A:A3 lin-pup (SHA256) C5:C4:11:4A:2D:EC:C8:2F:22:31:A3:F5:8C:91:BD:B6:E9:05:FB:AF:FD:80:63:48:31:31:2C:8B:5A:55:BA:E0 alt names: ["DNS:puppet", "DNS:test"] authorization extensions: [pp_cli_auth: true]
# puppetserver ca clean --certname lin-sl ... Certificate for lin-sl has been revoked Cleaned files related to lin-sl
# puppetserver ca list --all ... Signed Certificates: test (SHA256) C5:C4:11:4A:2D:EC:C8:2F:22:31:A3:F5:8C:91:BD:B6:E9:05:FB:AF:FD:80:63:48:31:31:2C:8B:5A:55:BA:E0 alt names: ["DNS:puppet", "DNS:test"] authorization extensions: [pp_cli_auth: true]

Снова возвращаемся на консоль клиента и запускаем команду.

# puppet ssl bootstrap Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for lin-sl Info: Certificate Request fingerprint (SHA256): 74:78:39:FF:2B:E8:89:9C:31:27:11:55:5C:47:B9:27:8D:51:26:7D:EC:C9:AD:70:41:55:0A:CC:68:E0:54:FF Info: Certificate for lin-sl has not been signed yet Couldn’t fetch certificate from CA server; you might still need to sign this agent’s certificate (lin-sl). Info: Will try again in 120 seconds.

Контролируем свои действия.

# puppetserver ca list --all ... Requested Certificates: lin-sl (SHA256) 74:78:39:FF:2B:E8:89:9C:31:27:11:55:5C:47:B9:27:8D:51:26:7D:EC:C9:AD:70:41:55:0A:CC:68:E0:54:FF Signed Certificates: lin-pup (SHA256) C5:C4:11:4A:2D:EC:C8:2F:22:31:A3:F5:8C:91:BD:B6:E9:05:FB:AF:FD:80:63:48:31:31:2C:8B:5A:55:BA:E0 alt names: ["DNS:puppet", "DNS:lin-pup"] authorization extensions: [pp_cli_auth: true] [root@test ~]# puppetserver ca sign --certname lin-sl ... Successfully signed certificate request for lin-sl # puppetserver ca list --all ... lin-sl (SHA256) 6E:2F:EA:93:61:39:40:7F:E2:9B:96:4A:2D:5F:16:10:47:50:67:20:1B:ED:17:BC:49:AC:A5:DF:7C:CF:F4:AD lin-pup (SHA256) C5:C4:11:4A:2D:EC:C8:2F:22:31:A3:F5:8C:91:BD:B6:E9:05:FB:AF:FD:80:63:48:31:31:2C:8B:5A:55:BA:E0 alt names: ["DNS:puppet", "DNS:lin-pup"] authorization extensions: [pp_cli_auth: true]

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

У мастер-сервера существует режим автоматизации подписи клиентских устройств, но он не рекомендован по соображениям безопасности.

Error 500.

Ошибка типа Error 500 on SERVER звучащая как…

# Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Could not find node statement with name 'default' or 'lin-sl' on node lin-pup Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run

…лечится редактированием файла манифеста site.pp3 в каталоге /etc/puppet/code/environments/production/manifests. Необходимо указать имя клиента на котором производится задача установки4 программы, после чего перезапустить мастер-сервер.

node 'lin-sl' {
       Package { ensure => installed }
       package { 'notepadqq': }
 } 

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

Печатать цифровой отпечаток подписи агента.

# puppet agent —fingerprint (SHA256) 6E:2F:EA:93:61:39:40:7F:E2:9B:96:4A:2D:5F:16:10:47:50:67:20:1B:ED:17:BC:49:AC:A5:DF:7C:CF:F4:AD

Включить режим отладки работы агента.

# puppet agent —debug

Проверка соединения клиента с портом мастер-сервера.

# puppet agent —test —serverport 8140

Подробный журнал работы агента.

# journalctl -u puppet

Заключение.

Рассмотрев некоторые особенности работы агента, пользователь получает более широкое представление об установке доверительных SSL отношений клиен-сервер. К этой части мы будем возвращаться ещё не раз, по мере продвижения обучения методики работы с Puppet. В пятой части мы переёдём к основной теме — практическое использования платфы в среде Linux.

Полезные ссылки.

Сноски.

  1. используется два ключа: один для шифрования (передается по открытому каналу public), другой для расшифровки хранится у владельца (закрытый ключ private): ↩︎
  2. метод кодирования двоичных данных ↩︎
  3. site.pp — стендовое название файла манифеста ↩︎
  4. Подробности работы манифеста site.pp смотри часть 6. ↩︎

Puppet для управления и автоматизации Linux часть 3.

Введение.

Рассмотрев в части 2 вопрос развёртывания Мастер-сервера Puppet, переходим к установке Puppet-agent (ов). Требования к Puppet-agent не особенно строгие, это небольшая программа не представляющая особых трудностей в установке. Вопрос в другом — настройка доверительных отношений между Puppet-agent и сервером с помощью SSL сертификата. Здесь обычно сталкиваются с проблемами от которых зависть работа всей платформы или дальнейшая её эксплуатация. В этой части мы сделаем первое приближение к вопросу настройки агента, подробности рассмотрим в часть 4.

Установка Puppet-agent.

  • Стенд
    • Cервер ALT Linux , имя lin-pup; ip-10.0.2.33
    • CPU Intel Core 5
    • HDD >100Gb
    • ОЗУ > 8Gb
    • ALT Simply Linux, имя lin-sl; ip-10.0.2.32
CPUsGHzGiB memoryOS
12.40.5Linux
Минимальные требования к клиенту Puppet.

В предыдущей части мы развернули мастер-сервер. Вместе с серверным пакетом был установлен Puppet-agent. Роль агента является важной составляющей для успешной работы платформы в целом. Проверить работу серверного агента можно командой:

# puppet agent --test
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for lin-pup
Info: Applying configuration version '1701625263'
Info: Creating state file /var/cache/puppet/state/state.yaml
Notice: Applied catalog in 0.01 seconds

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

Создание сертификата CA.

На стороне сервере необходимо выполнить манипуляции, позволяющие создать доверительные отношения с Puppet-agent на клиентских станциях. Доверительные отношения Puppit строит с помощью сертификатов SSL, центра сертификации (CA), развёрнутого при установке Мастер-сервера.

Если мы откроем консоль и посмотрит, какие сертификаты уже присутствуют после установки, то увидим, один подписанный ключ принадлежащий Puppet-agent сервера.

# puppetserver ca list --all ... Signed Certificates: lin-pup (SHA256) A8:C5:50:EF:EA:13:1F:C3:A1:DA:AC:4A:72:41:72:A6:A6:54:6E:92:50:4B:F7:00:E3:0D:F0:94:30:CD:18:DE
alt names: ["DNS:puppet", "DNS:lin-pup"] authorization extensions: [pp_cli_auth: true]

Правильную работу Puppet-agent на сервере проверяют командой.

# puppet agent --test

Из сказанного выше становится видно — работа и настройка Puppet-agent на мастер сервере не требует особых усилий. Это не относится к агентам работающих на клиентских устройствах, здесь, как правило, возникают трудности..

Создание сертификата на клиенте.

Под клиентом мы понимаем рабочею станцию или иное устройство обслуживаемое Puppit. У нас имеется стендовая рабочая станция lin-sl, развернём на ней puppet-агент, после чего выполним запрос к CA мастер-сервера для получения подписи.

Как puppet-agent работает?.

После установке клиента Puppet, при запуске командного сценария puppet ssl bootstrap, генерируются ключи (сертификаты) открытый и закрытий. После чего один из ключей, этой сладкой парочки, ставится в очередь на подпись СА мастер-сервера. Специально обученный пользователь с помощью консольной команды осуществляет подпись сертификатов. PS. Puppet имеет возможность включения режима автоподписи ключей.

Подпись CA подтверждает подлинность подключенного устройства по защищённому каналу.

Развёртывание Puppet-agent.

Установим свежею версию агента на клиентской станции.

# apt-get update
# apt-get install puppet
# systemctl start puppet
# systemctl enable puppet

В библиотеке Puppt имеется сценарий, который вносит изменения в конфигурацию агента puppet.conf для соединения с сервером.

# puppet config set server lin-pup --section main

Эту операцию можно произвести в ручную, отредактировав файл /etc/puppet/puppet.conf, секции [main], на server — lin-pup.

Узнать путь к каталогу SSL агента можно запустив сценарий:

# puppet config print ssldir --section agent

Остаётся проверить состояние сертификатов.

# puppet ssl bootstrap
Notice: Completed SSL initialization

Листинг печатает сообщение «запрос на создание SSL создан».

Дерево каталогов puppet-агент.

  • /etc/puppet — базовый каталог агента
    • /code — каталог кода и данных
      • /enviroment…
        • /production…
          • /manifests — каталог манифестов
      • /modules — каталог модулей
  • /devices — каталог устройств
  • /ssl — каталог сертификатов
    • /cetificate_requests — сертификаты для подписи (CSR)
    • cert
    • /private
    • /private_keys — закрытый ключ
    • /public_keys — открытый ключ
    • crl.pem…
  • auto.conf …
  • autosign.conf — настройки автоподписи для сервера CA
  • fileserver.conf…
  • puppet.conf…

Заключение.

В этой части рассмотрены общие вопросы технологического процесса установки Puppet-agent и проверки соединения SSL с мастер сервером. Агент начинает работать сразу на сервере и как правило вопросов не возникает. Другое дело клиентские устройства, здесь возникают трудности, ответы на которые мы рассмотрим в следующей, четвертой части нашего романа.

Полезные ссылки.

Puppet для управления и автоматизации Linux часть 2.

Введение.

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

Подготовка.

  • Стенд
    • Cервер ALT Linux , имя lin-pup; ip-10.0.2.33
      • CPU Intel Core 5
      • HDD >100Gb
      • ОЗУ > 8Gb
      • ALT Simply Linux, имя lin-sl; ip-10.0.2.32
Объем узловЯдраОЗУРазмер кэша
Средний офис21 GBn/a (not available)
1,0002-44 GB512m
Минимальные требования к серверу.

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

Настройка DNS — ntp сервера.

Возможность использования системы доменных имен для puppet server является одним из важных факторов успешного использования платформы. Далее приводится пример настройки файла /etc/hosts стендового сервера.

127.0.0.1    localhost.localdomain localhost
10.0.2.33    lin-pup
10.0.2.32    lin-sl

Проверяем разрешения DNS на puppet сервере и puppet клиенте.

# ping -c2 lin-pup
# nslookup lin-pup
# nslookup lin-sl

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

# systemctl status ntpd 

Установка Puppet server.

Серверная платформа Puppet состоит из трёх пакетов: puppetserver, puppet-agent(puppet) и puppetdb2.

Puppet-agent в ALT-Linux идёт под названием puppet

# apt-get update
# apt-get install puppetserver

Пакет агента puppet входит в состав сборки puppetserver

Для сервера Pupplet требуется Java Virtual Machine (JVM), определим последнею доступную версию jdk для установки.

# apt-cache search jdk
# apt-get install java-XX-openjdk
# rpm -qa|grep jdk

Запуск и проверка работы мастер-сервера осуществляем командами.

# systemctl start puppetserver
# systemctl enable puppetserver
# systemctl status puppetserver
# systemctl start puppet
# systemctl enable puppet
# systemctl status puppet

Проверка работы Puppet server.

Если всё выполнили правильно, то убедится в работоспособности платформы можно командой:

# puppetserver -v
puppetserver version: X.XX.X

В ответ сервер выведет версию программного обеспечения платформы.

Каталоги Puppet server.

Все настройки платформы Puppet хранятся в папках /etc и /var. При запуске сервер читает файлы каталога config.d

  • /etc/pupetserver
    • /config.d — основной каталог конфигурации Puppet
      • autch.conf — файл правил авторизации HTTP API Puppet Server
      • global.conf — файл глобальных параметров конфигурации
      • metrics.conf — файл настроек мониторинга метрики
      • web-routes.conf — файл службы точки монтирования для веб-приложений
      • webserver.conf — файл настроек службы веб-сервера для монтирования веб-приложений административного API Puppet,
      • puppetserver.conf — файл настроек для приложения Puppet Server
    • /services.d — каталог конфигурации CA
      • ca.cfg — файл конфигурации центра сертификации
    • bootstrap.cfg — файл загрузки при старте
    • logback.xml — файл управляющий журналами сервера
    • request-logging.xml — файл управления журнала трафика-HTTP, формат Apache

Каталоги puppet агента

  • /etc/puppet
    • /code — каталог кода и данных
      • /environments …
        • /production…
          • /manifests — каталог манифестов
      • /modules — каталог модулей
    • /ssl — каталог сертификатов узлов
    • puppet.conf — основной файл конфигурации
    • auth.conf — правила контроля доступа к серверу
    • fileserver.conf — настройки дополнительных точек монтирования файлового сервера
    • autosign.conf — список предварительно одобренных запросов на сертификаты
    • /device- каталог сетевых устройств управляемых сервером
    • device.conf — файл настроек сетевых устройств под управлением сервера

Журналы puppet.

  • /var/log
    • /pupet — журналы клиента
    • /pupetserver — журналы сервера

Каталог /etc/puppetlabs — создаётся при удалении /etc/puppet/ssl — рестарт сервер

Заключение.

В этой части приведены требования к оборудование для установки мастер-сервера Puppet server. Развёртывание платформы выполняется после того, как будет установлен базовый сервер ALT-Linux, настроен DNS — ntp и выполнены все требования для сервера, как описывалось выше. Мастер-сервер является базовым узлом всей архитектуры платформы. Изучение основ установочной конфигурации — основа успешной работы системы.

Полезные ссылки.

  1. Как настроить ntp смотри здесь ↩︎
  2. Разбор установки и работы puppetdb будет посвящена отдельная статья. ↩︎

Puppet для управления и автоматизации Linux часть 1.

Введение.

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

Что такое Puppet.

Прежде чем приступит к практическим действиям, см. следующею часть, определимся с философией платформы. Программа написана на языке Ruby и является кросс платформенным клиент-серверным приложением. Инструмент выпускается под двумя редакциями: платной — Puppet Enterprise, и бесплатной — Open source Puppet. К базовым пакетам выбранной редакции, в последствии, можно добавлять дополнения и расширения:

  • Continuous Delivery for PE
  • Bolt
  • Puppet Comply
  • Puppet Development Ki

Основная идея вложенная в платформу — желание установить систему в то состояние, которое вы считаете нужным для управления.

Это достигается через специальный Domain-Specific Language (DSL) код. Этот сценарий декларация, автоматизирует процесс перевода систем в определённое состояние, проводит мониторинг установленных режимов. Достигается это с помощью главного сервера и агентов, развёрнутых на устройствах, преобразующих код в команды для выполнения в указанных системах, как показано ниже.

Диаграмма работы архитектуры сервер-агент Puppet.
Диаграмма работы архитектуры сервер-агент Puppet.

Инструменты декларативной настройки, позволяют определить согласованность, автоматизацию, культуру и способ работы. В отличие от Zabbix, выполняющий сбор информации, Puppit, кроме инвентаризации, способен переводить систему (применять) установку программ и обновлений, получая отчёт о выполнении этих действий.

Архитектура Pupplet.

Перечисленные ниже концепции и практики являются ключом к успешному использованию Puppet.

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

DevOps — development & operations — методология автоматизации тех. процессов сборки настройки и развёртывания программного обеспечения.

Идемпотентность (не к ночи сказано — термин Pupplet ), ключевая особенность Puppet — возможность многократного применения кода для обеспечения желаемого состояния системы.

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

Возможность применять Git — отраслевой стандарт контроля версий, его использование поможет вашей команде воспользоваться преимуществами DevOps.

Структура Pupplet.

Структурная Pupplet состоит из нескольких базовых пакетов:

  • puppetserver — сервер
  • puppetdb — база данных
  • puppet-agent — агент
    • Facter — инструмент инвентаризации узла
    • Hiera — поиск ключевых данных узла

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

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

Все данные, созданные или собранные Puppet, хранятся (кэшируются) в базе данных PostgreSQL с помощью коннектора PuppetDB, выступающим посредником между Puppet сервером и PostgreSQL. Это позволяет платформе работать быстрее и предоставлять API другим приложениям для доступа к собранным данным.

Соединение происходит по защищённому SSL протоколу, для этого при развёртывании платформы создаются самоподписанные сертификаты для сервера и клиента.

Код создаваемый програмой для взаимодействия с агентами называется манифестом (manifest). Манифест — файл, содержащий сценарий написанный на языке Puppet. Файл имеет расширение .pp. и включает:

  • ресурсы и классы
  • переменные
  • функции
  • узлы

Большинство манифестов содержатся в модулях. Каждый манифест в модуле определяет один класс, функцию или определенный тип. На стороне сервера хранится основной (main manifest) манифест среды. В манифесте определяются узлы и уникальные каталоги.

Модуль — включает: классы, типы ресурсов, файлы, функции и шаблоны, нацеленных на выполнение определенной задачи. Например, с помощью модуля можно распространить установку демона SSH на клиентах. Большой выбор готовых модулей доступен в библиотеке Puppet Forge. Концепция инфраструктуры позволяет администратору писать свои собственные модульные и приемочные тесты.

Заключение.

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

Полезные ссылки

Copyright © 2011-2024
Все права защищены.
При перепечатке указать источник: kabtim.ru
Контакты