4.1 Introdução
No Capítulo 3 fizemos o deploy de nossas aplicações no ambiente de produção. Para isso foram criados vários contêineres, e em várias configurações diferentes:
Na Seção 3.2, criamos um contêiner para executar uma tarefa offline, ou seja, um script que começa e termina assim que seu trabalho é concluído.
Na Seção 3.3, fizemos de duas maneiras diferentes:
Primeiro subimos um servidor web (nginx) e um servidor WSGI (gunicorn + Flask) em um mesmo contêiner.
Depois subimos dois contêineres: um para o nginx e outro para o servidor WSGI. Colocamos os dois na mesma rede Docker para que eles pudessem se comunicar entre si.
Na Seção 3.4, criamos três contêineres:
Um para o zookeeper, que controla os brokers do Kafka
Um broker, responsável por lidar com a fila de eventos
Um consumidor, que faz a tarefa de analisar o sentimentos das mensagens enviadas pelo usuário do chatbot.
Em qualquer um dos casos, os serviços devem estar operacionais o tempo todo, ou pelo menos na maior parte do tempo. Isso se refere à qualidade de serviço ou QoS (Quality of Service) e, em geral, é representada por uma notação do tipo 24x7, que significa que desejamos a aplicação operacional 24 horas por dia nos 7 dias da semana.
Nesse ponto é que entra em ação a equipe de Operação, na garantia da qualidade do serviço a ser prestado.
Para saber se há algo errado com nossa aplicação ou com os serviços e servidores que viabilizam sua execução é necessário um monitoramento constante dos mesmos para que, na ocorrência de algum evento que impossibilite a operação dos serviços, ações sejam tomadas para colocá-la no ar novamente.
Retomando a figura que apresentamos no início deste livro, estamos falando do item 6. Ou seja, conseguimos colocar a aplicação em ambiente de produção, e agora queremos saber se é necessário alguma ação para retomar o ciclo DevOps.
Claramente, realizar esse monitoramento de forma manual é praticamente impossível e, desse modo, são necessárias ferramentas que realizam esse monitoramento de forma automatizada e, havendo ocorrências que mereçam a ação humana, elas comunicarão a equipe de operações para intervir e corrigir o problema, restaurando o serviço e colocando a aplicação no ar novamente, no menor tempo possível.
O Nagios é uma dessas ferramentas de monitoramento que temos disponível. Tal ferramenta possui uma versão paga, com uma interface de configuração gráfica, e uma versão gratuita, denominada Nagios Core, que pode ser configurada por arquivos de configuração. Trata-se de uma ferramenta que está há um bom tempo no mercado, é bastante robusta e, apesar de não ter uma interface muito amigável, faz o trabalho que se propõe.
A título de ilustração, no restante deste capítulo vamos instanciar o Nagios Core para oferecer o suporte de monitoramento ao nossos ambiente de produção e, posteriormente, aos demais ambientes conteinerizados que forem criados. Para isso, vamos subir todos esses contêineres que mencionamos no início da seção. Faça download de todas as pastas desse link aqui. Você deve ter os seguintes diretórios (entre outros que não iremos utilizar):
http-api-classificacao-produtos-container-unico:Tarefa online para classificação de produtos via API HTTP (contêiner único)
http-api-classificacao-produtos-dois-containers:Tarefa online para classificação de produtos via API HTTP (dois contêineres)
analise-sentimentos:Consumidor Kafka que analisa sentimentos
chatbot:Produtor Kafka que produz conversas com um chatbot
Estando no diretório anterior a todos estes, basta executar os seguintes comandos para construir todas as imagens necessárias:
Os seguintes comandos instanciam todos os contêineres. Não iremos executar o classificador offline, pois ele irá rodar e encerrar sozinho, portanto não faz sentido monitorar sua execução neste momento. Além disso, iremos executar o consumidor Kafka em modo desacoplado, apenas para não ocupar o terminal. Não veremos as mensagens sendo consumidas, mas não importa, pois já vimos isso rodando no capítulo anterior. E iremos colocar todos os contêineres na mesma rede, chamada minharede. Os comandos a seguir executam as ações descritas.
Se tudo rodar corretamente, devemos ter as seguintes imagens sendo exibidas após um comando docker image ls:
Exceto pela primeira tarefa, que é offline, todas essas imagens estarão rodando em contêineres, como mostra a saída do comando docker container ps:
Alguns desses têm portas abertas para o host, outros tem portas internas, disponíveis apenas para outros contêineres que rodam na mesma rede. A figura abaixo ilustra o ambiente de produção onde será incluído o Servidor de Monitoramento.
Animados para mais esse desafio? Então vamos iniciar a configuração dessa ferramenta.
Ao longo deste capítulo, iremos aos poucos construir a solução que se encontra pronta aqui. Mas tente construi-la aos poucos, compreendendo cada etapa cuidadosamente. Use esse repositório apenas como uma referência.
Last updated
