Я в настоящее время пытаюсь установить сбалансированную марионеточную инфраструктуру загрузки. Я использую puppetserver для марионеточного сервера (серверов) и марионеточного агента 3.7.3 для клиентов.
В настоящее время у меня есть четыре установки серверов в локальном сервере DNS, и определение имен работает правильно (я не показал FDQN's для краткости),
vmhgmaasdns01 IN A 192.168.207.208
vmhgmaasmgmt01 IN A 192.168.207.210
vmhgmaasproxy01 IN A 192.168.207.209
vmhgmaaspuppetdb01 IN A 192.168.207.206
mgmt IN CNAME vmhgmaasproxy01
Все серверы могут соединиться с марионеточным сервером vmhgmaasmgmt01 при выполнении марионеточного выполненного использования - server=vmhgmaasmgmt01
Однако при попытке использовать - server=mgmt я получаю ошибки
puppet agent --no-daemonize --no-splay --verbose --onetime --server=mgmt
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: end of file reached
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional resources using 'eval_generate': Broken pipe - SSL_connect
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet://mgmt/pluginfacts: Broken pipe - SSL_connect
Wrapped exception:
Broken pipe - SSL_connect
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': Broken pipe - SSL_connect
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve file metadata for puppet://mgmt/plugins: Broken pipe - SSL_connect
Wrapped exception:
Broken pipe - SSL_connect
Info: Loading facts
Error: Could not retrieve catalog from remote server: Broken pipe
Я могу работать
openssl s_client -connect mgmt:8140 -cert /etc/puppet/ssl/certs/vmhgmaasproxy01.pem -key ssl/private_keys/vmhgmaasproxy01.pem -CAfile ssl/certs/ca.pem
Который показывает, что я могу успешно проверить соединение SSL через подсистему балансировки нагрузки
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-SHA256
Session-ID: 54C623F7CC73B6CEDFC8C6BF1366FE96049030E60667FE170113D30EA2221F06
Session-ID-ctx:
Master-Key: B19715E32AE17A2C7D501D80A9D695C476A99CFB5441D07142650689CD554418C193505A5468364A7E0F482304F32C1E
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1422271478
Timeout : 300 (sec)
Verify return code: 0 (ok)
У меня есть установка/etc/puppet/puppet.conf опции указать на сертификаты и ключи, используемые в вышеупомянутом примере.
В HAProxy у меня есть фронтенд и набор бэкендов в режиме TCP и когда я пытаюсь работать, марионетка работает I, видят, что сессии увеличиваются во фронтенде и бэкенде на странице статистики. Я могу также видеть, что запросы получаются марионеточным сервером с помощью tcpdump.
puppetserver сертификат был сгенерирован с dns_alt_names для менеджмента loadbalancer, а также названия DNS хоста.
Я ничего не вижу в файлах журнала в /var/log/puppetserver/puppetserver.log с набором уровня журнала для ОТЛАДКИ для неудавшихся соединений.
Все серверы выполняют CentOS 6.6, и я превратил SELinux в разрешающий режим.
Любая справка значительно ценила, поскольку я попробовал и заменил прошлые три дня для следования за деталями из редкой официальной документации
Мне удалось решить проблему, настроив прокси-сервер для использования завершения SSL, чтобы включить балансировку нагрузки уровня 7 и режим http.
# This file managed by Puppet
global
daemon
group haproxy
log 192.168.*.* local1
maxconn 4000
nbproc 1
pidfile /var/run/haproxy.pid
user haproxy
defaults
maxconn 8000
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
frontend puppet-frontend
bind 192.168.*.*:8140 ssl crt /etc/haproxy/ssl/cert.pem ca-file /etc/haproxy/ssl/ca.pem verify none
mode http
acl ca path -m sub certificate
default_backend puppet-backend
use_backend puppet-ca-backend if ca
backend puppet-backend
balance roundrobin
mode http
stick on src
stick-table type ip size 1m expire 1m
server vmhgmaasmgmt01 192.168.*.*:8140 check
server vmhgmaasmgmt02 192.168.*.*:8140 check
backend puppet-ca-backend
mode http
server vmhgmaasmgmt01 192.168.*.*:8140 check
Это позволяет каталогам переходить на любой из двух марионеточных серверов, но запросы сертификатов маршрутизируются в CA. Мне пришлось изменить webserver.conf, чтобы использовать порт и хост вместо ssl-host и ssl-port и добавьте следующее в master.conf
master: {
allow-header-cert-info: true
}
. Крупнейший PITA не осознавал, что мне пришлось объединить ключ и сертификаты для HAproxy в файл PEM. (не во всем вышеперечисленном я добавил . , чтобы скрыть реальные IP-адреса)