Предупреждение: до сих пор я только узнал, как использовать nginx для обслуживания приложений с их собственным доменом и серверным блоком. Но я думаю, что пора погрузиться глубже.
Чтобы уменьшить необходимость в нескольких сертификатах SSL или дорогих сертификатах с подстановочными знаками, я хотел бы обслуживать несколько приложений (например, приложения rails, приложения php, приложения node.js) с одного nginx server_name. например rooturl / railsapp rooturl / nodejsapp rooturl / phpshop rooturl / phpblog
Я не уверен в идеальной стратегии. Некоторые примеры, которые я видел или о которых думал:
Множественные правила местоположения, это, кажется, вызывает конфликты между требованиями конфигурации отдельных приложений, например различные требования к перезаписи и доступу
Возможно ли изолированное приложение по внутреннему внутреннему порту? Маршрутизация каждого порта на свой конфиг? Таким образом, конфигурация изолирована и может быть адаптирована к требованиям приложения.
Обратный прокси, я немного не знаю, как это работает, это то, что мне нужно исследовать? это на самом деле 2 выше? Помощь в Интернете, кажется, всегда прокси на другой сервер, например apache
Каков эффективный способ изолировать требования к конфигурации для приложений, обслуживаемых из одного домена через sub uris?
Nginx может многое, в том числе обратное проксирование, кэширование и обслуживание контента, но в больших средах отдельные функции разделены, чтобы сделать их более удобными в обслуживании или специализированными с более подходящими альтернативами (например, Stud для большого объема https: //).
Обратный прокси просто означает нечто, что находится между клиентом и фактическим приложением; на самом деле это неправильное название, и его следует называть «прокси-сервером».
Чтобы обслуживать все из одного сертификата в одном домене, начните с чего-то вроде этого:
(Проверено на Ubuntu LTS 12.04)
#proxy_set_header Host $proxy_host; # instead of standard $host
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# note: must disable the built-in
# /etc/nginx/sites-enabled/default by removing it (it's a symlink)
server {
# redirects all http:// requests to https://
# critically, passes the original host the client was trying to connect to.
rewrite ^ https://$host$request_uri? permanent;
# combined redirect access and error logs for easier correlation
error_log '/var/log/nginx/global_redirects';
access_log '/var/log/nginx/global_redirects';
}
# This serves all enabled-locations over ssl only.
# If there's no match, it shows the default site.
include /etc/nginx/upstreams-enabled/*; # include enabled upstream proxies
server {
listen 443 ssl;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
keepalive_timeout 70;
root /usr/share/nginx/www;
index index.html index.htm;
access_log '/var/log/nginx/global_ssl';
error_log '/var/log/nginx/global_ssl';
include /etc/nginx/locations-enabled/*;
}
# points to hackernews but
# it could be http://10.2.4.5:401/app495 instead
location ~ ^/bar(/.*)?$ {
include proxy_params;
include apps/node;
proxy_pass http://news.ycombinator.com/$1;
access_log '/var/log/nginx/bar';
error_log '/var/log/nginx/bar';
}
location ~ ^/foo(/.*)?$ {
include proxy_params;
include apps/ruby;
proxy_pass http://www.linode.com/$1;
access_log '/var/log/nginx/foo';
error_log '/var/log/nginx/foo';
}
upstream news.ycombinator.com {
server news.ycombinator.com;
}
upstream www.linode.com {
server www.linode.com;
}
# Place ruby specific directives here
# Place node specific directives here
Помните, что это не перезаписывает URL-адреса на страницах, потому что они генерируются каждым приложением. Вместо этого каждое приложение должно знать свою внешнюю схему, хост, порт и базу URL-адресов и соответствующим образом создавать ссылки (большинство реальных приложений это поддерживают).
Ссылки: