Docker é chato, mas é legal: entenda por que você precisa dele
Já fazem 5 anos quando comecei a trabalhar com Docker. Eu entrei em um projeto onde ele era usado, opcionalmente, para desenvolvimento.
Logo em seguida entrei em outro projeto utilizando Kubernetes, e aí tive que entender de verdade ou ia ficar nadando em alto mar.
Bom, minha primeira impressão foi:
“Poxa, mais uma coisa aqui pra aprender que não vai fazer diferença nenhuma para minhas entregas.”
A segunda foi:
“Interessante pra caraio, é tipo uma distro linux criada especialmente pro projeto com tudo que preciso nele!”
A terceira:
“Essa merda está ocupando todo espaço da minha máquina e só faz o tempo de deploy ficar gigantesco buildando toda a imagem toda vez.”.
Depois de passar por essas fases, quero dizer:
Docker é muito legal, mas você precisa entender!
Por que um desenvolvedor deve aprender Docker?
Vejo que para nós, desenvolvedores, o Docker tem duas grandes utilidades:
Primeiro ele permite que o desenvolvimento do software seja feito em um ambiente muito similar ao de produção. Ou seja, desde a versão do sistema operacional que vai rodar o projeto até as bibliotecas do sistema que são dependências do projeto, podem ser as mesmas tanto para o desenvolvimento como para o ambiente de produção.
O segunda utilidade é que, fica muito mais fácil fazer o setup do projeto, pois todas as dependências ficam descritas em um arquivo que “roda”.
Para ficar mais claro, imagina que:
- Você usa seu querido Ubuntu 20.04;
- Você tem a versão do Ruby 3.0.0 na sua máquina;
- Você instalou o PostgreSQL 11.
E aí, em ambiente de produção, a máquina rode:
- Debian 12.4, bem atualizado;
- O último Ruby até o momento: 3.1.2;
- Uma versão do PostgreSQL 15.
Consegue imaginar a quantidade de B.O e de tempo que você pode perder porque essas versões estão diferentes?
Solução sem docker
Uma solução de equiparar esses ambientes seria você atualizar as versões do Ruby, talvez usando um gerenciador de versões como o rvm, e do seu banco de dados PostgreSQL. Ainda assim, haveria uma mudança do sistema operacional, que pode impactar em algum nível o seu projeto, mas não vamos pensar nisso agora.
Seguindo essa solução, o que aconteceria se em outro projeto você utilizasse o PostgreSQL 10?
Você teria que instalar a outra versão do banco, e manter essas duas instalações, e infelizmente haveriam incompatibilidade entre elas, como o pg_dump.
Observe que, na medida que você for se envolvendo em novos projetos, vai ficando mais difícil manter tudo isso alinhado.
Se ligue que nesse cenário costumamos escrever no arquivo README do projeto tudo que é necessário instalar para rodar o projeto, para que quando outro desenvolvedor, ou eu mesmo depois de um tempo, tiver for configurar o ambiente para desenvolvimento, pudesse seguir os passos.
Solução com Docker
Cada projeto carrega consigo alguns arquivos que descrevem, exatamente, todo o ambiente que você precisa, desde a versão do sistema operacional, passando pelas dependências, até serviços extras como o sistema de banco de dados da sua aplicação.
Para ficar mais didático, é como se dentro no seu projeto tivesse um arquivo chamado “ambiente.txt”, mais ou menos assim:
SISTEMA: “Ubuntu 20.04” VERSÃO DO RUBY: “2.3.4” BANCO DE DADOS: “Postgresql 10.23”
Então, rodando um script “preparar_ambiente.sh” você teria tudo preparado: o Ubuntu com o Ruby e o PostgreSQL nessas versões, e o seu projeto lá dentro para garantir que tudo está no ponto para desenvolver.
Pois é, com Docker é mais ou menos assim!
E mais: esse mesmo arquivo “ambiente.txt” é usado em produção, para deixar tudo preparado por lá e assim manter os dois ambientes (desenvolvimento e produção) alinhados.
E por que eu achei chato? Querendo ou não, é mais uma ferramenta para estudar.
Para você configurar o Docker, em um projeto, você precisa ser mais específico do que descrito no exemplo acima com o arquivo “ambiente.txt”.
Você precisa entender de:
- Linux: afinal de contas, na grande maioria das vezes, você estará usando imagens baseadas no linux, e às vezes em distribuições diferentes (como Ubuntu, Debian, CentOs).
- Segurança: pois a ideia é que o mesmo ambiente de desenvolvimento seja usado em produção, e aberturas
- Docker: parece óbvio, mas muitos devs ignoram isso e passam a usar o Docker em um nível muito superficial, sem entender o que está fazendo, o que leva a problemas que não vai saber resolver e atrasar todo o projeto.
Outros desafios também vão aparecendo:
- Consumo de espaço em disco: em especial se você utilizar o Windows com WSL, pois existe um bug miserável que faz com que o Docker fique ocupando espaço e não libere automaticamente.
- Memória: pois a gente começa a subir vários containers (por enquanto imagiem que cada container é um “Linux” rodando em sua máquina) simultaneamente. Como qualquer dev, você também deve gostar de estudar novas ferramentas, mas enquanto a necessidade não bater na porta ou a solução do Docker não fizer sentido, você vai ficar achando um saco pois pode virar um gargalo no projeto, uma coisa que vai levar tempo pra configurar e que o cliente final não vai ver valor.
Pra fechar
Para quem estava acostumado a ter sempre projetos com a mesma stack, versões simimlares e compatíveis, isso pode não fazer muito sentido.
Já, se você começa a trabalhar com stacks e versões diferentes, a solução do Docker começa a parecer interessante. Exige um aprendizado a mais, mas a médio e longo prazo vai te ajudar pra caramba.
Ficou mais claro pra você? Comenta aí que isso me motiva a seguir criando conteúdos como esse.
Chato é ficar subindo as coisas na mão, uso muito o Docker no meu workflow de desenvolvimento, para subir serviços como Postgres, Grafana, Prometheus, etc. Antes de conhecer o Docker e tirar um tempo para estudá-lo, ficava muito tempo tendo que sempre que subir tudo que ia usar na mão, executando de um por um, antes de realmente começar a desenvolver. Não tive essa ideia do script "preparar_ambiente.sh" antes kkkk.
Inclusive, parabéns pelo blog, comecei o meu também recentemente (divulguei em um post aqui), mas ao contrário de você, 20 anos eu tenho é de idade 😅, então, o blog é mais para compartilhar o que estou aprendendo, criando ou qualquer outra coisa que eu acho legal, até porque, um blog tem muito do "pessoal" de quem escreve.
Simplesmente pulei a primeira fase, lembro de estar fazendo um projeto e precisa rodar o kafka e ainda não sabia trabalhar com Docker. Gastei algumas boas horas configurando o ambiente e o java pra rodar aquilo.
Depois de um tempo aprendi o docker e foi questão de minutos e já tinha o kafka funcionando, aquilo pra mim foi uma maravilha.
Atualmente troquei de stack no trabalho, de JS pra C#, a primeira coisa que fiz foi configurar o ambiente pra rodar com docker. Hoje não me vejo trabalhando sem ele
Dá para traçar uma limha no antes e depois do Docker... Antes eu recorria a VM's, agora consigo ter muitos ambientes no meu note com poucos arquivos e alguns comandos. Sem falar nos ambientes de fábrica, homologação, a entrega ficou mais simples.
Muito obrigado por compartilhar conosco sua experiencia, eu tambem tinha muito preconceito com o docker antigamente mas depois que comecei a entender melhor como funciona e seus beneficios hoje valorizo bastante.
Eu não cheguei na fase do legal.
Claro que tem casos que precisa mesmo, mas eu faço as cosias simples, eu não uso coisas que tem trocentas dependências, que viram uma atração de equilíbrio em circo. Portanto eu não adota uma ferramenta para consertar os problemas causados pelas decisçies errdas anteriores.
Novamente, tem cenérios que você tem menos controle mesmo, e pode ser útil, mas na maioria a pessoa escolhe ter o problema.
Agredeço pela postagem. Espero que todos reflitam que existem lados diferentes, e o apresentado tem várias desvantagens também, não é só vantagem.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).
Aqui no meu Fedora, MongoDB e Postgres são docker. Uma mão na roda.
Doscker de fato é muito top, mas tem algo que não consegui entender/resolver é como montar o ambiente de desenvolvimento de maneira como eu consiga debbugar, isso no frontend. No backend como no c# o proprio Visual Studio já ger ência as imagens e dá para debbugar e tudo mais, mas e no frontend como faria?
Você recomenda a um desenvolvedor com foco no front-end? Aprender a usar o docker e criar um docker file no front-end para projetos pequenos envolvendo apenas um back e um front?