Лялечка насправді досить добре піддається багатокористувацькому середовищу, з застереженнями. Основна? Багато частин лялечки люблять бути централізованими. Орган сертифікації, служби інвентаризації та інформаційної панелі / звітів, файлові пакети та збережені конфігурації - всі вони найкраще підходять (або просто вимагають) налаштування, де є лише одне місце для них.
Однак цілком реально отримати багато тих рухомих частин, які працюють у мультимайстерному середовищі, якщо ви добре з витонченою втратою частини функціональних можливостей, коли ви втратили свій основний сайт.
Почнемо з базової функціональності, щоб отримати вузол, який звітує майстру:
Модулі та маніфести
Ця частина проста. Версія контролює їх. Якщо це система управління версіями розподілених версій, тоді просто централізуйте та синхронізуйте та змініть потік "push / pull" за потребою на веб-сайті з відмовою. Якщо це Subversion, то, ймовірно, ви захочете svnsyncперенести репо на ваш аварийний сайт.
Орган сертифікації
Один з варіантів тут - це просто синхронізувати файли авторизованих сертифікатів між ведучими, щоб усі мали спільний кореневий сертифікат і могли підписувати сертифікати. Це завжди вражало мене, як "роблю це неправильно";
- Чи повинен один майстер дійсно бачити свій власний сертифікат, представлений у клієнті auth для вхідного з'єднання від іншого ведучого, як дійсний?
- Чи надійно це буде працювати для служби інвентаризації, інформаційної панелі тощо?
- Як додати додаткові дійсні імена DNS alt у дорозі?
Я не можу чесно сказати, що я пройшов ретельне тестування цього варіанту, оскільки це здається жахливим. Однак, схоже, що Лялькові лабораторії не хочуть заохочувати цей варіант, зазначається тут .
Отже, те, що залишається, - це мати центрального господаря ЦА. Усі довірчі відносини продовжують працювати, коли ЦС знижується, оскільки всі клієнти та інші майстри кешують сертифікат CA та CRL (хоча вони не оновлюють CRL так часто, як слід), але ви не зможете підписувати нові сертифікати, поки ви отримуєте резервну копію основного сайту або відновлюєте головний центр CA із резервних копій на відмовному сайті.
Виберете одного майстра, який буде діяти як КА, а всі інші майстри відключать його:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Потім вам потрібно, щоб центральна система отримувала весь трафік, пов’язаний із сертифікатом. Для цього є кілька варіантів;
- Використовуйте нову
SRVпідтримку запису в 3.0, щоб спрямувати всі вузли агентів у потрібне місце для CA -_x-puppet-ca._tcp.example.com
- Встановіть параметр
ca_serverconfig у puppet.confвсіх агентів
Проксі весь трафік для запитів, пов'язаних з CA, від агентів до правильного майстра. Наприклад, якщо ви працюєте з усіма своїми майстрами в Apache за допомогою Пасажира, то налаштуйте це на не-CA:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
І це повинно це робити.
Перш ніж ми перейдемо до допоміжних служб, бічна примітка;
Імена DNS для основних сертифікатів
Я думаю, що саме тут є найбільш вагомою причиною переходу на 3.0. Скажіть, що ви хочете вказати вузол на "будь-якого робочого майстра".
У розділі 2.7 вам знадобиться загальне ім'я DNS на зразок puppet.example.com, і всі майстри потребують цього у своєму сертифікаті. Це означає, що встановити dns_alt_namesїх конфігурацію, повторно видавати сертифікат, який вони мали до того, як вони були налаштовані як майстер, повторно видали cert знову, коли вам потрібно додати нове ім'я DNS до списку (наприклад, якщо ви хотіли, щоб кілька імен DNS до агенти віддають перевагу майстрам на своєму сайті) .. потворно.
З 3.0 ви можете використовувати SRVзаписи. Віддайте це своїм клієнтам;
[main]
use_srv_records = true
srv_domain = example.com
Тоді ніякі спеціальні сертифікати не потрібні для майстрів - просто додайте новий запис у свій SRVRR на _x-puppet._tcp.example.comі ви налаштовані, це живий майстер у групі. А ще краще, ви можете легко зробити логіку вибору майстра більш складною; "будь-який ol 'робочий майстер, але віддайте перевагу тому, що знаходиться на вашому сайті", встановивши різні набори SRVзаписів для різних сайтів; не dns_alt_namesпотрібно.
Звіти / Інформаційна панель
Цей варіант найкраще працює централізовано, але якщо ви можете жити без нього, коли ваш основний сайт знижений, то жодних проблем. Просто налаштуйте всіх своїх господарів на правильне місце для розміщення звітів.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..і все налаштовано. Не завантаження звіту не є фатальним для запуску конфігурації; він просто загубиться, якщо тост сервера приладної панелі.
Інвентаризація фактів
Ще одна приємна річ, яку вклеїли у вашу приладову панель - служба інвентаризації. З facts_terminusнабором, restяк рекомендовано в документації, це фактично порушить конфігурацію, коли вона працює, коли центральна служба інвентаризації працює. Хитрість тут полягає у використанні inventory_serviceтерміналу на не центральних майстрах, що дозволяє витончено вийти з ладу ..
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Встановіть центральний сервер інвентаризації для зберігання даних інвентаризації через ActiveRecord або PuppetDB, і він повинен бути в курсі кожного разу, коли послуга буде доступна.
Так що - якщо ви все в порядку з обмеженою обстановкою для управління конфігурацією barebones, де ви навіть не можете використовувати CA для підписання нової вершини вузла до його відновлення, то це може працювати чудово - хоча це було б дуже добре якби деякі з цих компонентів були трохи привітнішими до розповсюдження .