Skip to content

Latest commit

 

History

History
65 lines (53 loc) · 2.65 KB

File metadata and controls

65 lines (53 loc) · 2.65 KB

Passo 2 - Operar a aplicação com balanceamento de carga em 3 instâncias distintas

Para realizar o procedimento de balanceamento de carga em 3 instâncias distintas utilizamos o servidor nginx-proxy

PS > docker run -d -p 80:80 -e DEFAULT_HOST=proxy.apilivraria -v /var/run/docker.sock:/tmp/docker.sock:ro --name nginx jwilder/nginx-proxy

Após rodar o container do nginx, executamos o comando de curl apenas para verificar se realmente estava funcionando conforme o esperado:

PS > curl http://localhost

O retorno foi:

curl : <html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body bgcolor="white">
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.14.0</center>
</body>
</html>
No linha:1 caractere:1
+ curl http://localhost
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Como é possível verificar NGINX respondeu com o erro 503, indicando que está ativo.

Para este cenário eu precisei criar um novo método publico na minha API que não exigisse uma autenticação, uma vez que os demais métodos exigiam, para mostrar qual o ID do container que havia executado a requisição. alt text

O código é bem básico, apenas o suficiente para retornar o id do container.

namespace Livraria.Api.Controllers.v1.pbl
{
    [Route("v1/public/[controller]")]
    public class ContainerController : Controller
    {
        [HttpGet]
        public IActionResult Get()
        {
            return new OkObjectResult("Request processado pelo container id: " + System.Environment.MachineName);
        }
    }
}

Após criado o método repeti todo o procedimento para criar a imagem e então iniciei os containers apontando para o proxy criado.

PS > docker run -d -p 5000 -e VIRTUAL_HOST=proxy.apilivraria --name teste apilivraria
PS > docker run -d -p 5000 -e VIRTUAL_HOST=proxy.apilivraria --name teste2 apilivraria
PS > docker run -d -p 5000 -e VIRTUAL_HOST=proxy.apilivraria --name teste3 apilivraria

Feito isso eu consegui acessar o endereço http://localhost/v1/public/Container e verifiquei que a cada requisição um container era o responsável pela resposta efetuando o (round-robin), conforme imagens abaixo: alt text alt text alt text