Demonstracao DevOPS na Pratica

Conforme conversado em outros artigos aqui escritos por mim, DevOPS é uma cultura onde visa integrar duas equipes, Infraestrutura e Desenvolvimento.

Grande parte desses processos de instalação e preparação, será feita por ambas as equipes, para atender suas necessidades. Lembrando que não existe uma receita pronta de sucesso, apenas exemplos que deram mais certo em outros lugares.

Aqui vou dar um exemplo de funcionamento da ferramenta Git, Zabbix, Ansible e Docker, para realização da tarefa de reconstruir um container.

A minha ideia neste exemplo, é que o Zabbix ( Ferramenta de monitoração ) ao perceber que o DNS está fora ( Ferramenta responsável por resolver nomes em ips ) irá tomar uma ação, lembrando que essas ações do Zabbix podem ser como, enviar email, enviar sms, enviar mensagem via Whatsapp, como também restartar aplicações, ou até mesmo reconstruir um ambiente, que é o que eu quero fazer neste exemplo.

Para que o artigo no Linkedin não fique grande, e cansativa a leitura, vou deixar aqui a parte mais teórica e exibicionista, e no meu blog e em outros lugares o HowTo de como fazer o passo a passo.

Zabbix - Monitoramento

Para quem não conhece a ferramenta Zabbix, ela é capaz de monitorar diversos objetos que tenham rede instalada, desde coleta de valores via SNMP, como também valores informados por um ShellScript.

Vamos supor então, que o Zabbix está monitorando a porta 53 protocolo udp, de um determinado servidor ( Container do Docker )

Claro que muitas pessoas, iriam imaginar que o Puppet Agent, é capaz de fazer isso, mas esquecem que ele é pesado para determinadas aplicações, mas enfim, não vou me aprofundar dessa forma, só quero dar exemplos, não fidelizar nenhuma ferramenta da cultura DevOPS.

Sendo assim o Zabbix ao perceber que os valores, da porta 53 estão diferentes, ele começa a contabilizar o tempo de DownTime daquela coleta. Sendo assim quando ultrapassar o limite estipulado em sua configuração, o Zabbix irá ativar uma Trigger, e que a mesma irá convocar uma Action. Essa Action está correlacionada a reconstrução do Container no Docker.

Se tiver interesse a 4Linux tem um curso prático sobre a ferramenta

Docker

O container que o Docker criar irá servir para nós recebermos o código, imagine que o container é uma máquina, fácil e rápida para ser criada. Em menos de 1 minuto você tem um ambiente com Ubuntu e todos os programas já inseridos dentro dele como, Apache, Php, FastCGI e seu código fonte.

O Docker foi feito para ser construído e morto, e ele utiliza os mesmos recursos da máquina, sendo bem semelhante da ideia de Virtualização.

Então neste momento, imagine que o Zabbix ativou a reconstrução de um novo container, sendo assim o Docker que já tem um Template pronto, pega esse template e cria uma nova máquina para receber seu código de configuração ( Lembrando que agora falamos de infra versionada ) sabendo que a configuração do DNS/Bind está dentro de um repositório, basta pegarmos a configuração do seu Git.

Informações sobre Docker

Git

O Git é um repositório de código, a ideia dele é que a gente sempre armazene códigos, podem ser "apache2.conf", "Um livro" conforme falei no outro artigo sobre o Git, ou mesmo o programa da sua empresa, quem lê as noticias viu que o git recebeu 300G de código da MicroSoft, então se alguém perguntar quem usa, você já sabe.

Bom sabendo que todo código está armazenado dentro de um lugar seguro, onde seus computadores, podem ir e coletar essas informações, com o comando git clone iremos pegar o código fonte do nosso DNS/Bind e dar ao Ansible.

Ansible

O Ansible é um provisionador de comandos remotos, rápido e leve, sem a necessidade de um Agent, do outro lado, claro que ele tem pré-reqs como o pacote Python e OpenSSH-Server instalado no cliente.

Eu gosto dele pelo fato de ser fácil o trabalho e leve, permitindo converter extensos códigos de ShellScript que realizavam tarefas com LoopFor, em apenas um comando conforme demonstrei no outro artigo sobre Ansible utilizando o modulo command.

Todos os processo que o Ansible irá executar, será convocado pelo Jenkins.

Jenkins

O Jenkins é um programa para Contínuos Delivery, com ele você pode homologar diversas ações, como por exemplo testar, se o retorno de um comando é positivo, e baseado nesse retorno, você pode iniciar outra aplicação/job.

No nosso projeto, vamos usar ele para convocar o Playbook do Ansible, onde ele vai garantir nosso ambiente.

Toda as ferramentas que citei aqui, tirando Zabbix estão presentes no curso da Empresa 4Linux - 525 - Infraestrutura Agil com técnicas DevOPS

Fluxo Natural com DevOPS

Então vamos imaginar nosso Laboratório dentro de uma empresa, imagine que o SysAdmin, precisa fazer uma entrada no DNS, com o seguinte valor

www IN A 192.168.11 .100

Normalmente, ele teria que fazer isso dentro do servidor de Bind9, e depois rodar o comando "rndc reload"

Para quem quiser aprender a Empresa 4Linux, da esse curso focado na LPI, ensinando Bind9, Apache, Squid, Samba4 entre outras tecnologias OpenSource.

Bom feito isso, o DNS já estaria funcionando, porém como estamos falando de boas práticas DevOPS, vamos fazer de uma forma diferente.

O SysAdmin, baixa o arquivo para a máquina dele, com o comando :

git clone git@g192.168.11.101:/opt/git/bind.git

Esse comando iria trazer para a máquina do nosso SysAdmin, todo o código, para que o mesmo possa alterar o arquivo db.zona.exemplo.com.br, e depois enviar os dados, novos para o repositório de código.

Quando o servidor Git receber esses valores, será ativado o gatilho que se chama Git Hook, assim acionando o servidor Jenkins em sua API, que por sua vez, irá chamar o Ansible utilizando um módulo para isso, o playbook do Ansible, irá chamar o Docker.

O Docker receberá o código novo que está dentro do Git, e depois restartado, caso o Jenkins encontre algum problema, ele pode fazer um Git Revert e voltar o código caso necessário.

Perfeito, mas onde entra o Zabbix nessa situação ?

Vamos imaginar nosso cenário que não tem o Puppet para garantir um arquivo pelo seu MD5, logo então precisamos saber se o serviço de DNS está funcionando ou não, ai entra o Zabbix.

O Zabbix será o servidor responsável por isso, ele irá ficar ouvindo a porta 53, caso alguma coisa aconteça, o Zabbix irá ativar uma ação, essa ação, podera ser desde enviar um Email, SMS ou no nosso caso, invocar o Jenkins que irá reconstruir o Docker.

Na imagem abaixo podemos ver como será todo esse fluxo:

Cenário : Explicação de como está construído nosso laboratório

Seguindo a lógica de funcionamento do nosso cenário, toda empresa já estará em funcionamento, e sempre que houve uma alteração no código do Git o Bind será alterado.

Prática : Demonstração da integração de todas as ferramentas

Quem quiser esse cenário, poderá obter um laboratório que fiz no Vagrant, o arquivo está no meu GitHub, esse ambiente pode ser utilizado como referência para se criar um ambiente de produção, mas recomendo que conheça bem primeiro sua necessidade para depois adotar determinada ferramenta.

Projeto : devops-zabbix-dns.git

git clone git@github.com:tonnytg/devops-zabbix-dns.git

Você irá baixar o projeto, irá vir 4 pastas, e com 4 arquivos chamados Vagrantfile, cada arquivo é uma configuração de máquina, você tem que ter o VirtualBox e o Vagrant instalados como pré-req.

Quando terminar de baixar o código, acesse a pasta e dentro dela, execute o comando:

vagrant up --provision

Esse comando irá construir as máquinas permitindo que elas se comuniquem umas com as outras. Lembrando que o range de ips que utilizei neste laboratório é 192.168.11.10X

Dentro da pasta do projeto, tem uma chave de confiança, basta utilizar ela para fazer um ssh nos servidores.

O HowTo de como configurar vou deixar no Blog da 4Linux, sendo assim posso atender dois tipo de pessoas, as que querem somente ter uma noção teórica sobre o que é DevOPS e quem quer um HowTo prático para construir em seu ambiente de produção.

Segue abaixo o link do Blog, onde todos os analistas da 4Linux podem publicar seus artigos e projetos: