Docker me cativou

Uma das mais proeminentes invenções da década anterior no mundo da tecnologia da informação é uma ferramenta de infraestrutura (infra), chamada Docker. Particularmente parece-me muito novo, pois o descobri há pouco tempo. Faz apenas 2 anos que comecei com ele e não consigo mais trabalhar sem.

Surpreende-me ainda ver desenvolvedores, que não fazem uso e outros que não sabem nem do que se trata. Alguns amigos me perguntaram: “Por que eu preciso usar Docker?”, Esta é uma daquelas perguntas difíceis de responder. “Eu sei que é bom, mas não sei explicar o porquê”. Porém é uma pergunta justa, uma vez que a curva de aprendizagem da ferramenta é lenta, pelo menos pra mim foi. Se a pessoa vai empreender um grande esforço nisso, é compreensível que ela queira saber dos seus benefícios. Talvez eu não tenha respostas concretas, mas vou contar minha experiência e será possível que eu convença alguém.

Antes do Docker aparecer na minha vida, eu trabalhava como qualquer outro “ dev.” Tinha toda minha stack de desenvolvimento instalada no sistema operacional. Como eu já usava Linux nessa época, eu criava algum “shell script” “para me servir, instalando e configurando coisas. Não configurava tudo, uma parte era manual, porque eu não era um expert em “shell script.” O script poderia ser distribuído para equipe para que os programadores fizessem usufruto.

Então surgiu o primeiro problema. Nem todos os programadores usavam Linux. Então meu “ shell script” não iria funcionar no windows. Era preciso ter muita coragem para formatar um sistema defeituoso e a gente sabe que não é tão difícil isso acontecer com o Windows. O sofrimento dos programadores Windows era bem maior, eles levavam em torno de 1 dia de trabalho para instalar todo o ambiente. Eu me gabava de usar Linux e do meu maravilhoso programinha que fazia tudo para mim, ou pelo menos quase tudo. Ainda assim eu levava de 2 a 3 horas.

Nessa época eu trabalhava com PHP e o meu chefe trouxe uma aplicação, que não funcionava na versão do PHP7, porque era feito em PHP 4. Este seria o nosso segundo problema. Nós tínhamos uma “infra” que rodava uma versão do PHP diferente. Era normal usar a pasta “www” do Apache e empurrar todos os projetos lá dentro, separados por pastas. Ao meu ver, hoje, uma bagunça total. Os aplicativos precisavam utilizar a mesma versão da linguagem e do SGBD. Imagina só, neste contexto, entrando um projeto que usa uma infra diferente da nossa. É claro que nós resolvemos, na época, mas era uma situação bem desagradavel, desgastante e cheia de configurações extras, coisa que meu “ shell script” não ia dar conta. Além de que, replicar isso para outros computadores, seria um desafio. Nós também precisamos começar a anotar no readme, a versão do PHP e do SGBD.

Pense comigo numa situação hipotética. Uma equipe de 9 programadores. 3 usam Windows, 3 usam Linux e 3 usam MacOs. Imagine 4 projetos nas mãos desta equipe. Um projeto é um App feito em PHP com Laravel e Mysql, outro projeto em Ruby on Rails com Postgres, outro em Java com Oracle, e ainda outro em Python com Mysql. Fui abusado em misturar bem os projetos, mas a ideia é que percebamos como lidar com uma infraestrutura variada pode ser bem sinistra. Adicione nesta hipótese que alguns dos programadores usam 2 ou mais computadores, pois estes às vezes levam trabalho para casa. Agora pense na hora de concatenar tudo isso no git e fazer o deploy para um servidor de produção. Será que você consegue enxergar a confusão, a dificuldade de alinhamento desta “infra”. Imagine o líder de equipe tendo que ouvir: “No meu computador não funciona”, ou “instalei tudo, mas o java está dando problema”, ou ainda, “tá dando conflito de porta”, ou ainda mais, “O arquivo json não grava, tá sem permissões no Linux”. Serão muitas as queixas e os problemas. O líder de equipe vai precisar ter problemas de ansiedade e a equipe pode até desmotivar porque não consegue harmonizar o trabalho.

Todas essas histórias tristes, eram e ainda são a realidade de muitos. Alguns programadores, à semelhança de mim, não têm muita aptidão ou se interessam por infraestrutura. Porém nós trabalhamos sobre uma “infra” e utilizamos servidores para executar os nossos códigos. Não tem como fugir. Dificilmente uma empresa vai pagar um profissional de “infra” para ficar instalando PHP, Ruby, Java nas máquinas dos desenvolvedores. Até hoje nunca trabalhei em nenhuma empresa que fizesse isso. Então o jeito é aprender alguma coisa de infra para resolver os próprios problemas.

A primeira solução que eu cheguei a usar, foi o Vagrant. Na época foi uma solução viável. Dava para fazer alguns padrões de infra, virtualizado no Virtualbox. Parecia uma solução perfeita. Era criado uma “maquinazona” virtual com tudo que tinha direito e depois replicava ela para os coleguinhas.

No nosso exemplo hipotético era só criar uma VM para cada stack e distribuir entre os programadores, que deveriam ter o Vagrant e o Virtualbox instalado nos seus respectivos SO. A equipe toda poderia trabalhar sem muita burocracia e as aplicações igualmente funcionando para a alegria de todos.

Então fim… Só que não.

Se eu estava tão satisfeito com o Vagrant então porque mudar para o Docker? Porque na verdade eu não estava tão satisfeito assim. O Vagrant era muito, digamos, “Pesado”. Transferir a máquina virtual para outros não era tão fácil. Havia muita resistência dos programadores. Também não era viável ter uma infra específica para cada aplicação, caso houvessem muitas.

Por isso que o Docker resolveu o meu problema. Fazendo uma analogia grotesca, o Docker é uma Ferrari e o Vagrant um Fusca. O que mais me foi caro “cair para dentro” do Docker foi que ele exige muito mais para aprender a usá-lo. Depois que entende o funcionamento e aprende os comandos, é só ser feliz.

O Docker funciona com containers. Cada container container é uma máquina virtual, que tem um sistema operacional e os programas necessários para funcionar. Mas diferente do Vagrant, essa VM não contém todo ambiente de desenvolvimento, apenas um pedaço dele. Esses containers se unem para formar uma doca, ou seja a stack completa de desenvolvimento. Eu quero comparar o Vagrant com uma arquitetura de software monolítica e o Docker com a arquitetura de microservices. Outra analogia que eu poderia fazer é a do Jaspion e Power Rangers. Se você viveu nos anos 90 vai lembrar que o robozão do Jaspion era uma peça única, comparamos com o Vagrant, enquanto o Megazord dos Power Rangers eram vários animais robôs que se juntavam para formar uma peça, comparamos com o Docker.

O Docker é como um lego. Você monta um carro e depois aproveita as mesmas peças para montar uma casa. Isso é bom porque economiza espaço em disco. O Vagrant era bem espaçoso nesse aspecto. Outra questão é que o Docker se integra ao sistema operacional de tal forma que ele não precisa separar espaço exclusivo na memória ram, pois ele usa a memória da própria máquina hospedeira. Essa tática, faz como que você nem sinta que está usando uma virtualização.

Na nossa hipótese supracitada, nós iríamos apenas criar dois arquivos, dockerfile e docker-compose.yml, com tudo que precisamos para rodar a aplicação e subir junto no git. Depois era só cada programador fazer um PULL no seu computador e dar um comando docker-compose up e “voilá”, sua aplicação estará rodando.

No Docker-compose vocẽ pode fazer diversos arranjos para atender cada aplicação. O arquivo docker-compose.yml tem os services, que irão criar uma instância de container. Desta forma, o compositor me permite ter uma infraestrutura específica por aplicação.

Por essas tantas outras vantagens, comodidade e padrão, é que eu me sinto cativo do Docker. Meu caro, se você ainda não está convencido de que o Docker é uma boa opção para você, eu peço que você apenas experimente uma vez em um projeto. Que melhor que longas palavras é a sua própria experiência. Estou certo de que você será um consumidor ativo desta fantástica ferramenta.

Originally published at http://thiagolimadev.wordpress.com on March 10, 2021.