Estratégia para isolar vários aplicativos ssl nginx com domínio único via suburi?

Question

Estratégia para isolar vários aplicativos ssl nginx com domínio único via suburi?

#1 resposta do (2 votos)

4

Aviso: até agora só aprendi a usar o nginx para exibir aplicativos com domínio e bloqueio de servidor próprios. Mas acho que é hora de mergulhar um pouco mais.

Para atenuar a necessidade de vários certificados SSL ou certificados wildcard caros, gostaria de exibir vários aplicativos (por exemplo, aplicativos rails, aplicativos php, aplicativos node.js) de um nginx server_name. por exemplo. rooturl / railsapp rooturl / nodejsapp rooturl / phpshop rooturl / phpblog

Não tenho certeza da estratégia ideal. Alguns exemplos que tenho visto e pensado:

Várias regras de localização, isso parece causar conflitos entre os requisitos individuais de configuração do aplicativo, por exemplo, requisitos diferentes de reescrita e acesso
Aplicativos isolados por porta interna de back-end, isso é possível? Cada porta de roteamento para sua própria configuração? Então, a configuração é isolada e pode ser feita sob medida para os requisitos do aplicativo.
Proxy reverso, eu sou pouco ignorante de como isso funciona, é isso que eu preciso pesquisar? Isso é realmente 2 acima? A ajuda on-line parece sempre ser proxy para outro servidor, por exemplo, apache

Qual é uma maneira eficaz de isolar requisitos de configuração para aplicativos veiculados em um único domínio por meio de sub-URLs?

directory configuration ssl nginx application

por icpu 06.10.2012 / 19:49

1 resposta

Tags directory configuration ssl nginx application

Script de shell para notificar quando o uso da CPU atingir 100% Estou procurando uma maneira robusta de determinar se um serviço pode ser interrompido ou morto

score 2 · Accepted Answer

O Nginx pode fazer um pouco, incluindo proxy reverso, cache e conteúdo de serviço, mas em grandes ambientes, funções individuais são divididas para torná-las mais fáceis de manter ou especializadas com alternativas mais adequadas (como o stud para https de alto volume: / /).

Um proxy reverso significa apenas algo que fica entre o cliente e o aplicativo real; Na verdade, é um equívoco e deve ser chamado de "proxy do servidor".

Para veicular tudo, desde um certificado em um domínio, comece com algo assim:

(testado no Ubuntu LTS 12.04)

/ etc / nginx / proxy_params

#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;

/ etc / nginx / sites-enabled / global_redirects

# 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';

}

/ etc / nginx / sites-enabled / global_ssl

# 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/*;

}

/ etc / nginx / locations-enabled / bar

# 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';

}

/ etc / nginx / locations-enabled / foo

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';

}

/etc/nginx/upstreams-enabled/news.ycombinator.com

upstream news.ycombinator.com {
  server news.ycombinator.com;
}

/etc/nginx/upstreams-enabled/www.linode.com

upstream www.linode.com {
  server www.linode.com;
}

/ etc / nginx / apps / ruby

# Place ruby specific directives here

/ etc / nginx / apps / node

# Place node specific directives here

Lembre-se de que isso não reescreve URLs nas páginas, porque elas são geradas por cada aplicativo. Em vez disso, cada aplicativo deve conhecer seu esquema externo, host, porta e base de URL e produzir links de maneira adequada (a maioria dos aplicativos reais oferece suporte a isso).

Referências:

link
link