Oi Pessoal,

Hoje queremos trazer para você um exemplo prático de Docker em produção, e como ele pode ser útil quando você trabalha de forma correta com micro-serviços.

Há 6 meses atrás, quando o pessoal do https://goodbye.host lançou a V1 da plataforma de migração, tinham em mente apenas uma coisa: Fazer mudanças de forma fácil, e isso inclui  mudanças de arquitetura/código/tecnologia e no processo de migração de sites, e-mail e banco de dados, tornado-o mais fácil, rápido e seguro.

Tendo isso em mente, a opção mais lógica na época (e hoje prova-se como sendo a melhor e mais acertada) era projetar a plataforma para trabalhar com micro-serviços, de forma independente e modular, garantindo assim maior segurança  e eficiência na ferramenta. Mas afinal, por que mudar?

A primeira versão da plataforma foi projetada para trabalhar utilizando servidores (físico ou virtuais), de forma uma pouco engessada, tornando difícil o scale da aplicação e manutenção do ambiente como um todo, pois as modificações eram complexas e em alguns casos demoradas, para Cassio Bock, desenvolvedor da plataforma, era necessário tornar esse ambiente mais eficiente, autonomizável e simples. Depois de uma série de pesquisas, testes e conversas, o Docker se sobressaiu frente as outras alternativas. Veja abaixo uma imagem de como era o ambiente antes:

goodbye-antes

Antes, para cada processo de migração, havia um fluxo sequencial, que garantia a execução de cada migração. Dessa forma, criava-se uma fila de processamento, que em alguns casos atrasava as tarefas de outros usuários. O ambiente era dessa forma devido a dois fatores:

1 – As tecnologias utilizadas, em algumas das camadas, eram monolíticas, tendo que adaptar outras partes da plataforma para atender uma necessidade não suprida pelas demais.

2 – Necessidade de controle manual em cima de tarefas que poderiam ser auto-gerenciadas.

Depois de alguns desenhos, a arquitetura ideal encontrada foi essa:

goodbye-depois

Na nova arquitetura, quando uma migração é criada, um container é iniciado, isso feito tudo através da API do Swarm, sendo muito mais fácil adaptar a plataforma as necessidades que aparecerem. Outro ponto positivo nesse ambiente é  fato de as camadas serem independentes, então o site ou api não precisam ficar aguardando um retorno para seguirem com as tarefas, isso torna a plataforma escalável e claro, muito mais ágil.

Através do Swarm foi possível criar um cluster para a execução dos containers, então, quando uma migração é iniciada, não é necessário saber onde ela será realizada (passo que era necessário na arquitetura anterior), basta criar o container via API do próprio Swarm, e ele mesmo provisionará o container no melhor nó possível. Outra tecnologia utilizada é o Socket.io, responsável pelo acompanhamento da migração, com ele foi possível desenvolver um método onde o container que está realizando a migração, informe ao cliente sobre o andamento da mesma, dessa forma têm-se a certeza de que a migração está sendo realizada, e em que etapa ela encontra-se.

Por hoje era isso, quer saber mais ou conversar sobre como foi o processo de mudança? Mande e-mail para nós e vamos conversando. Gostou? Então nos ajude divulgando o Blog 😉

Abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.