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.