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, 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ísicos 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 às outras alternativas. Veja abaixo uma imagem de como era o ambiente 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:

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 às necessidades que aparecerem. Outro ponto positivo nesse ambiente é o fato das 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 tem-se a certeza de que a migração está sendo realizada, e em que etapa ela se encontra.

Por hoje era isso. Quer saber mais ou conversar sobre como foi o processo de mudança? Deixe seu comentário abaixo.

Abraço!