Комментарии 14
ssl_certificate /home/CERT.crt;
ssl_certificate_key /home/CERT.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_protocols TLSV1.1 TLSV1.2 TLSV1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
и
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
можно вынести в файлы типа ssl.conf и proxy.conf и подключить через include. Значительно улучшится читаемость и снизится вероятность ошибки при переконфигурировании. Настройки конкретных серверов проще вынести в отдельные файлы как это сделано в дебиане/убунте - так проще выключить более ненужный сервер/подключить нужный без ошибок удалив/создав симлинк.
Да, всё верно. Я как раз и описал в статье что это можно разделить. Как для быстрого решения конечно подойдет и монолитный конфиг, который в дальнейшем можно будет оптимизировать.
В процессе эксплуатации такой системы я бы даже настоятельно советовал использовать подход с разделенными конфигами. Уже были прецеденты с участием неопытных админов когда были забыты закрывающие знаки.
"Но важно понимать что если у вас раздельные конфиги как в Ubuntu это так же будет работать. Главное поместить нужный код в нужные места ;)"
А Nginx выполняеться непосредственно на сервере виртуализации?
Подсткажите, если не трудно, как быть в ситуации когда есть веб-сервер с N доменами, и один из доменов надо перенаправить на другой сервер?
server {
listen 168.119.???.???:80;
listen 168.119.???.???:443 ssl;
server_name clamav.xxx.ru;
root /var/www/clamav;
access_log /var/log/nginx/clamav__access.log;
index index.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}для домена и
server {
listen 168.119.???.???:80;
listen 168.119.???.???:443 ssl;
server_name ns0.xxx.ru;
root /var/www/html/ns0;
access_log /var/log/nginx/ns0__access.log;
index index.html;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme https;
proxy_set_header X-Forwarded-Proto https;
proxy_buffering off;
proxy_ssl_verify off;
proxy_redirect https://127.0.0.1:443/ /;
proxy_pass https://127.0.0.1:443;
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
#try_files $uri $uri/ =404;
}
}для реверс-прокси. Обе могут быть в одном блоке http{}.
Не пойму, зачем nginx перед istio ставить? вроде и то и другое — прокси-серверы в этой схеме, причем istio ещё и маршрутизирует запросы по урлам.
Объясню почему в этом случает так.
Мы разрабатываем коробочное решение и в это коробочное решение входит вся инфраструктура (проще говоря мы передаём ВМ). По этому не трогаем "коробочную" инфру
Решение из статьи - быстрый выход из ситуации когда необходимо держать какое то множество пред-прод серверов в своей инфраструктуре с внешним доступом. Специфично но имеет место быть :)
Зачем указывать полные имена URL?
Достаточно server_name *.xxx.ru
Istio сам разберётся какой запрос куда.
Единственное, сертификат с *. xxx.ru не распространяется на *. yyy.xxx.ru - только на *. xxx.ru
Если конечно все сайты в пределах одного домена.
Почему сделан такой акцент на proxy_cache_bypass, когда в статье приведен конфиг без кэшей и даже нет упоминания, что настроено кэширование? Разве nginx по умолчанию что-то кэширует?
Ответа однозначного в силу отсутствия достаточного опыта по nginx не смогу дать, НО!
Во время настройки взаимосвязи nginx -> istio я получал ошибки от istio "426 Upgrade Required" . На просторах интернета нашел единственное подходящее объяснение где предлагалось добавлять proxy_cache_bypass $http_upgrade;
Однако сейчас, для того что бы сделать скрин ошибки и показать вам, я закоммитил эти строки в конфиге и не получил 426 ошибки.
Настройка Nginx multiple reverse proxy для k3s+istio