Я перенес свою настройку мастера марионетки для работы в тонком режиме с файлами, обслуживаемыми из nginx.
Файлы модулей обслуживаются отлично, но файлы подключаемых модулей не работают. Журналы думают, что агенты запрашивают URL-адреса, например /production/file_content/plugins/puppet/provider/exec/powershell.rb и поэтому nginx выдает ошибку 404, потому что такого пути не существует. Это отлично работает на WEBrick.
Теоретически это должен быть простой случай написания правила перезаписи, аналогичного приведенному ниже правилу модулей. Однако многие из этих провайдеров находятся внутри модулей, поэтому этот конкретный провайдер находится в /etc/puppet/modules/powershell/lib/puppet/provider/exec/powershell.rb.
Как мне сопоставить URL-адрес запроса с фактическим плагином, когда они могут быть разбросаны по различным каталогам модулей?
Моя конфигурация nginx выглядит так:
upstream puppetmaster-thin {
server unix:/var/run/puppet/puppetmasterd.0.sock;
server unix:/var/run/puppet/puppetmasterd.1.sock;
server unix:/var/run/puppet/puppetmasterd.2.sock;
}
server {
listen 8140;
root /etc/puppet/rack;
ssl on;
ssl_session_timeout 5m;
ssl_certificate /var/lib/puppet/ssl/certs/gcspuppet01.pem;
ssl_certificate_key /var/lib/puppet/ssl/private_keys/gcspuppet01.pem;
ssl_client_certificate /var/lib/puppet/ssl/ca/ca_crt.pem;
ssl_crl /var/lib/puppet/ssl/ca/ca_crl.pem;
ssl_verify_client optional;
ssl_ciphers SSLv2:-LOW:-EXPORT:RC4+RSA;
proxy_read_timeout 120;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client_DN $ssl_client_s_dn;
proxy_set_header X-SSL-Subject $ssl_client_s_dn;
proxy_set_header X-SSL-Issuer $ssl_client_i_dn;
location /production/file_content/ {
location /production/file_content/extra_files/ {
alias /etc/puppet/files/;
}
rewrite ^/production/file_content/modules/([^/]+)/(.*) /$1/files/$2;
break;
root /etc/puppet/modules/;
}
location / {
proxy_pass http://puppetmaster-thin;
}
}
Я понял. Проблема заключалась в том, что nginx эффективно пытался обрабатывать статический любой запрос к /production/file_content/. Проблема в том, что, хотя это полезно для обслуживания файлов из модулей под /production/file_content/modules/, он угоняет /production/file_content/plugins.
Поскольку пути к плагинам являются «волшебными», их должен обрабатывать демон-мастер марионеток, а не nginx. Решение состоит в том, чтобы написать лучший конфигурационный файл nginx:
location /production/file_content/extra_files/ {
alias /etc/puppet/files/;
}
location /production/file_content/modules/ {
rewrite ^/production/file_content/modules/([^/]+)/(.*) /$1/files/$2;
break;
root /etc/puppet/modules/;
}