Configurando um balanceador HTTP usando Nginx e Apache2 com canal HTTPs para os usuários

Motivação

Nosso objetivo é construir um ambiente que seja capaz de responder a muitas requisições a websites na internet de forma balanceada (no processamento dos acessos aos sites) usando uma única entrada. Esta solução permite que o usuário tenha acesso a somente uma IP público, mas vários IPs privados podem responder as requisições. Neste exemplo vamos utilizar o Ubuntu Server 12.04LTS, mas funciona perfeitamente com o Debian Squeeze 6.0 também.

O ambiente vai ficar da seguinte forma:

  INTERNET --->  MASTER_NGINX ---> NÓS_BACKEND_APACHE2


É importante que todos os nós tenham as mesmas configurações nos serviços (Apache2, SSH) para tornar o ambiente mais prático de gerenciar. Diferente do modelo LVS que sugerimos em outro post, este modelo só serve para aplicações Web ou aplicações suportadas pelo Nginx (POP3, IMAP, etc).

O mais legal deste modelo é que é simples de configurar e o canal HTTPs vai ficar somente entre os usuários da Internet e o Nginx. A comunicação do Nginx com os nós que vão atender de fato as requisições pode ser HTTP, facilitando o gerenciamento dos certificados digitais para cada VirtualDomain.

Configuração

A configuração é muito simples. No nó que você elegeu como Master, basta instalar o Nginx e fazer a configuração de balanceamento:

Vamos instalar os pacotes necessários:

# apt-get install nginx


Com ele instalado basta criarmos uma configuração para um site como: www.exemplo.com.br:

# vim /etc/nginx/sites-available/exemplo
upstream webservers{
        #Este parâmetro é para dizer que quando um usuário se conectar a um nó-X, ele vai continuar nele até o final (resolve o problema de
        #sessões PHP por exemplo)
	ip_hash;

        #Aqui você deve trocar o nome NÓ-XX, pelo IP do servidor backend que está rodando o Apache2
	server NÓ-01;
        server NÓ-02;
        server NÓ-03;
        server NÓ-04;
}

server {
	listen 80;
	server_name www.exemplo.com.br;

        #Para redirecionar sempre para o HTTPs
	rewrite     ^(.*) https://$server_name$1 permanent;
}

# HTTPS server
#
server {
       listen 443 ssl;
       server_name www.exemplo.com.br;

       ssl on;
       ssl_certificate /etc/ssl/www_exemplo_com_br.crt;
       ssl_certificate_key /etc/ssl/www_exemplo_com_br.key;

       ssl_session_timeout 30m;

       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
       ssl_prefer_server_ciphers on;

       location / {
      		proxy_pass http://webservers/;

	        proxy_set_header   Host             $host;
       		proxy_set_header   X-Real-IP        $remote_addr;
	        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        	client_max_body_size       10m;
	        client_body_buffer_size    128k;

         	proxy_connect_timeout      90;
	        proxy_send_timeout         90;
        	proxy_read_timeout         90;

	        proxy_buffer_size          4k;
	        proxy_buffers              4 32k;
	        proxy_busy_buffers_size    64k;
        	proxy_temp_file_write_size 64k;
       }
}


E depois é só ativar o VirtualDomain criado:

# ln -s /etc/nginx/sites-available/exemplo /etc/nginx/sites-enabled/exemplo


Pronto, para a página www.exemplo.com.br você já tem 4 nós respondendo pelas conexões. Prático e eficiente. Você pode estar pensando que o Nginx pode virar o gargá-lo certo? o Nginx trata conexões HTTP de forma muito rápida.. e o serviço mais pesado que é o processamento das aplicações Web, como o PHP por exemplo, ficam nas mãos dos backends com Apache2, então o Nginx apenas controla as conexões e repassa o serviço pesado para os servidores por trás dele. É claro que tem um limite de eficiência aqui, mas para o nosso caso resolveu muito bem.

Usando certificados baratos da ComodoSSL ou PositiveSSL no Nginx

Com o ambiente já encaminhando as requisições, tivemos um problema. No Apache2 temos diretivas para o certificado principal e os certificados adicionais, além do certificado e chave da página em questão. No Nginx só temos 2 diretivas: ssl_certificate e ssl_certificate_key, por isso é complicado você adicionar mais de um nível de certificado para usar no Nginx. Desta forma é necessário fazer uma operação para “unir” estes certificados.

A grande sacada neste caso é unir na ordem correta:

# cat www_exemplo_com_br.crt AddTrustExternalCARoot.crt PositiveSSLCA2.crt >> bundled_exemplo_com_br.crt


Note que o primeiro é o certificado do seu site, o segundo é a autoridade certificadora externa (AddTrustExternalCARoot) e finalmente a autoridade que assinou o certificado (PositiveSSLCA2), ou seja, a ordem é a inversa da forma como foi assinada o seu certificado:

    PositiveSSLCA2 ---> AddTrustExternalCARoot ---> www_exemplo_com_br


Basta você prestar atenção na ordem que a sua autoridade certificadora assinou os certificados e montar a ordem inversa no certificado que você vai usar no Nginx. Talvez faça um vídeo sobre isso depois.

Até a próxima,
Brivaldo Jr