Se você já ouviu diversas vezes o termo proxy reverso mas não sabe nem o que é, este artigo é para você! Mas primeiro, antes de entender o que é um proxy reverso, você sabe o que é um proxy?

Um servidor proxy nada mais é do que um servidor intermediário entre o dispositivo gerador de uma requisição e o servidor receptor da requisição.

Sabe quando você está em uma empresa com sérias restrições de internet, e você tenta dar aquela escapadinha para acessar o Facebook? E quando acessa o site, o Facebook está bloqueado?

Então, neste caso, o proxy funciona da seguinte maneira: a rede interna solicita para acessar um web site externo, e caso o acesso a este web site esteja mapeado como permitido, o request será redirecionado ao servidor externo, que devolverá uma resposta ao proxy, que por sua vez devolverá uma resposta ao dispositivo solicitante.

Já no caso do web site estar mapeado como não permitido, ao receber o request o proxy não o repassará para o servidor externo e o bloqueará.

Proxy Reverso

Agora que você já sabe o que é um proxy, explicar o que é um proxy reverso é muito mais fácil! Se o proxy é um servidor intermediário entre uma rede interna e a internet, um proxy reverso nada mais é do que um intermediário entre a internet e a rede interna.

Exemplo: vamos lá, você desenvolveu um software extremamente complexo que realiza a somatória de dois números inteiros! Sim, você é diferenciado. E você fez esse software para a empresa “Matemática na Veia”.

No processo tradicional, para que os usuários do mundo inteiro consigam acessar essa incrível feature disponibilizada, seria necessário apenas dois passos. Primeiro, hospedar a aplicação na infraestrutura da empresa, e segundo, expor o serviço na internet.

Agora imagine que a empresa não queira expor o endereço IP do servidor. O que você deve fazer, neste caso, é criar um servidor proxy – mais precisamente um servidor proxy reverso, e expôr o proxy reverso na internet, deixando o IP do servidor interno mascarado pelo IP do proxy reverso.

Resumo da Ópera: Proxy, intermediador de requests de dentro de casa (On premises) para internet. Proxy reverso, intermediador de requests da internet para dentro de casa (On premises).

Colocando a teoria na prática

Demonstrarei como utilizar um proxy reverso utilizando nginx em um container docker juntamente com um web api conteinerizada também, e tudo isso orquestrado pelo docker compose.

Se você não quiser criar um web api do zero, pode utilizar esta aqui.

Veja a simplicidade do Dockerfile do container de proxy reverso com nginx. Estou apenas deletando o arquivo padrão de configuração do nginx, e copiando os novos arquivos de configuração para dentro do container.

FROM nginx:latest
EXPOSE 80
RUN rm /etc/nginx/conf.d/default.conf
COPY Patterns.WebAPI/Nginx/*.conf /etc/nginx/conf.d/

Quer entender mais como funciona a configuração de proxy reverso com Nginx? Confira essa documentação.

Crie o arquivo reverse-proxy.conf conforme a seguir.

server {
    listen       80;
    location /   {
      proxy_pass        http://192.168.1.37:8080; #Your server/local IP
    }
 }

Nesse arquivo definimos as configurações do servidor de proxy reverso. Perceba que a sintaxe é muito simples e clean. Primeiramente está definido o objeto servidor e, dentro dele, suas configurações. Neste caso, porta e rota para “proxear”. A porta do servidor de proxy reverso é definida com a propriedade listen, a qual configurei a porta padrão 80.

Na sequência vem a definição de qual caminho será redirecionado para qual servidor, a partir do objeto location. Na frente de location temos uma barra, o que significa que todas as requisições ao endereço do servidor de proxy reverso deverão ser redirecionadas ao endereço do servidor configurado na propriedade proxy_pass.

Se a aplicação em questão também tiver um front-end web, você pode utilizar o mesmo servidor proxy. O arquivo reverse-proxy.conf ficaria assim:

server {
    listen       80;
    location ^~/api/v1/   {
      proxy_pass        http://{BACKEND-IP}/api/v1/; 
    }
    location ^~/   {
      proxy_pass        http://{FRONTEND-IP}/; 
    }
 }

Apenas mais um arquivo de configuração, proxy.conf.

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_buffers           32 4k;

Para finalizar, seguem os arquivos para orquestrar os contêineres, lembrando que esta parte é opcional, já que você pode subir os contêineres na mão.

docker-compose.yaml

version: '3.3'

networks:
        patterns-network:
                driver: 'bridge'

services:
        patterns-webapi:
                image: patterns-webapi
                container_name: patterns-webapi
                build:
                        context: /home/kenerry/workspace/Nginx/
                        dockerfile: Patterns.WebAPI/Dockerfile
                depends_on:
                       - reverse-proxy
                networks:
                        - patterns-network

        reverse-proxy:
                image: reverse-proxy
                container_name: reverse-proxy
                build:
                        context: /home/kenerry/workspace/Nginx/
                        dockerfile: Patterns.WebAPI/Nginx/Dockerfile
                networks:
                        - patterns-network

docker-compose.override.yaml

version: '3.3'

services:
        patterns-webapi:
                environment:
                        - ASPNETCORE_ENVIRONMENT=Development
                ports:
                        - 8080:80

        reverse-proxy:
                ports:
                        - 80:80

Como você pode ver na figura abaixo, o container patterns-webapi está rodando na porta 8080, enquanto o container reverse-proxy está rodando na porta 80.

O que deve acontecer é o seguinte: devemos conseguir acessar nossa web api através do endereço proxy.

Primeiro, vamos testar o acesso ao container patterns-webapi para garantir que esta de pé – porta 8080.

Veja agora o acesso ao container reverse-proxy, porta 80.

Mas veja agora o que acontece se ativarmos a rota /api/v1/swagger no container reverse-proxy. O swagger será renderizado normalmente. Por trás, o request foi redirecionado para o web api, mas na rota o endereço IP continua sendo o do proxy reverso. Confira!

Por hoje é só! Espero que tenham gostado! Se este artigo ajudou de alguma maneira, não deixem de compartilhar com os amigos!

Muito obrigado e um grande abraço!

• Código completo
• https://imasters.com.br/dotnet/asp-net-core-2-1-http-client-refit
• https://imasters.com.br/back-end/padroes-de-web-api-parte-02-middleware

Quer saber mais sobre boas práticas de web api, docker, docker compose, testes unitários e de integração? Baixe meu e-book free!