Introdução

Rapaz, se eu ganhasse um real para cada vez que ouvi "mas no meu notebook estava rodando liso", eu já estava aposentado em Jericoacoara. O grande problema do TI tradicional nunca foi o código em si, mas o ambiente. É aquela versão do Python que é 3.8 no dev e 3.10 no server, ou aquela biblioteca de PDF que ninguém lembrava que precisava instalar no SO.

O Docker entrou no meu fluxo de trabalho para matar essa variação. Ele não é apenas uma ferramenta de "modinha"; é o que garante que o que você testou às 14h é exatamente o que vai rodar no deploy das 18h.

A "Receita" que garante o sono do Sysadmin

Muita gente confunde Docker com Máquina Virtual, mas o buraco é mais embaixo. Enquanto uma VM carrega o peso de um sistema operacional inteiro, o Docker compartilha o kernel do hospedeiro. Ele é leve porque é focado no processo.

Para a gente que está no dia a dia da infra, o segredo está no Dockerfile. Ele é a nossa documentação viva. Se não está no Dockerfile, não existe na aplicação.

Bash

# Exemplo de uma receita (Dockerfile) simples e real
FROM node:18-slim

# Definimos onde o código vai morar
WORKDIR /app

# Copiamos as dependências primeiro para aproveitar o cache de camadas
COPY package*.json ./
RUN npm install --production

# Só então levamos o código
COPY . .

# O container sobe pronto para o combate
CMD ["npm", "start"]

O que realmente importa: Imagens e Containers

Na prática, eu gosto de pensar assim:

  • Imagem: É o "print" do seu sistema. Ela é imutável. Depois que você gerou a minha-app:v1, ela nunca mais muda. Isso é segurança pura para o deploy.

  • Container: É a imagem em movimento. Deu problema? Você não "conserta" o container. Você mata ele, corrige a imagem e sobe um novo.

Por que você deveria começar hoje?

Se você ainda instala banco de dados, Redis ou RabbitMQ direto no seu sistema operacional, você está criando um "servidor de estimação". Amanhã você precisa formatar a máquina e perde meio dia configurando tudo de novo.

No mundo real, a gente usa o Docker Hub para baixar o que já está pronto. Precisa de um Postgres?

Bash

# Sobe um banco de dados prontinho em segundos
docker run --name meu-postgres -e POSTGRES_PASSWORD=minhasenha -d postgres:15

Conclusão

O Docker mudou o jeito que eu entrego software porque ele trouxe previsibilidade. Se você quer subir na carreira de DevOps ou ser um Dev que não dá dor de cabeça para o pessoal da infra, dominar o fluxo de Build, Ship and Run é o primeiro passo.

O próximo nível? Aprender a orquestrar esses containers, mas isso é conversa para outro café.

Dúvidas? Me chama no LinkedIn ou deixa um comentário.