“Instala uma máquina virtual Linux e recria exatamente o mesmo ambiente.”
Três meses depois de eu entrar na empresa, o clima no escritório estava estranho. O único sênior da equipe já tinha sido transferido para outro projeto e estava ocupado demais arrumando as próprias coisas para sequer pensar em repasse de conhecimento, enquanto o líder do time já estava há muito tempo longe do desenvolvimento prático e bem distante das tendências técnicas mais recentes.
Um dia, o líder me chamou. “Quando o seu sênior sair, você vai ser a única pessoa que ainda consegue cuidar dos servidores. Mesmo que o servidor caia, você precisa ser capaz de recuperá-lo sozinho. Instale Linux como uma máquina virtual, VM, no seu notebook atual de desenvolvimento, Windows, e tente montar exatamente o mesmo ambiente do servidor de produção.”
Foi aí que começou o meu sofrimento. Instalei o VMware, baixei o arquivo ISO do Ubuntu, e só essa instalação já levou meio dia. Fuçando na wiki da empresa, instalei Java, Node.js e PostgreSQL. Pensei: “Mais novo deve ser melhor”, então instalei Java 17, mas descobri depois que o código legado dependia de Java 8 e nem sequer compilava. Tive que apagar tudo e instalar de novo. Cada vez que eu mudava uma linha de código, precisava rodar mvn build, mover o arquivo jar para a VM e executá-lo lá. Era sofrimento puro.
Então me veio uma dúvida de repente. “Espera aí. Da última vez que fizemos deploy em produção, não tinha acabado só com uma única linha de docker service update?”
A minha máquina virtual local era tão pesada e exigia uma montanha de configuração, então o que exatamente era aquele tal de ‘Docker’ no servidor de produção que permitia atualizar tudo com um único comando?
A solução pesada: a máquina virtual
O método que meu líder mandou eu usar, isto é, instalar Linux em cima do Windows, é exatamente o que é uma máquina virtual, VM. É como construir uma ‘casa virtual’, um guest OS, inteira em cima de um computador físico, o host.
No fim, uma VM realmente isola o ambiente de forma confiável, mas para desenvolvimento ou deploy ela é simplesmente pesada e lenta demais para ficar sendo passada de um lado para o outro o tempo todo.
A revolução leve: Docker
Foi por isso que surgiu o Docker, isto é, a tecnologia de containers. O Docker não constrói uma casa inteira como a VM faz. Em vez disso, ele monta uma barraca.
O comando update que eu executei no servidor de produção não estava reinstalando um sistema operacional pesado. Ele só estava “desmontando a barraca antiga e montando outra nova com a nova versão do código dentro”. Então era inevitável que terminasse quase na mesma hora.
[Code Verification] O Docker é realmente tão leve?
Não vamos só dizer que o Docker é leve; vamos conferir isso de verdade. Quando o objetivo é rodar um ambiente Linux, Ubuntu, a diferença entre VM e Docker é gritante.
# Rodar Ubuntu via comando Docker (baixa a imagem se nao existir)
$ docker run -it ubuntu:latest /bin/bash
Resultado:
No momento em que apertei Enter, eu já estava dentro de um ambiente Ubuntu. Isso é possível porque um container Docker não é um sistema operacional de verdade. Ele é apenas “um espaço isolado que pega emprestado o kernel do host OS, isto é, do meu computador, enquanto finge ser um OS separado”.
Conselho prático: o motivo real para usar Docker
Depois que passamos a usar Docker no trabalho, a minha vida mudou completamente.
Encerrando: não entregamos um executável, e sim um “ambiente”
Com a chegada do Docker, o paradigma do desenvolvimento mudou. A gente não envia mais só o código-fonte, .java, para o servidor. Também congelamos a configuração do sistema operacional, as bibliotecas e as variáveis de ambiente que aquele código precisa em uma ‘imagem’ e enviamos o pacote inteiro.
Mas então como essa mágica ‘imagem Docker’ é construída de fato? É só um arquivo compactado? Surpreendentemente, dizem que uma imagem Docker é empilhada em várias camadas, como um bolo.
Na próxima, vamos destrinchar o segredo da eficiência do Docker: as imagens e sua estrutura em camadas.