Docker: o que é, para que serve e quando Kubernetes é exagero

O sistema funcionava perfeitamente no notebook do desenvolvedor. Na sexta à noite, foi publicado no servidor da empresa e o módulo de emissão de boletos parou. Depois de horas de investigação, a causa: o servidor tinha uma versão diferente de uma biblioteca, instalada por alguém há dois anos para outro sistema. Ninguém lembrava. Ninguém tinha anotado.

Em muitas empresas, o servidor de produção é uma peça única, montada à mão ao longo dos anos. Cada atualização é um risco, cada nova pessoa no time leva dias para conseguir rodar o sistema na própria máquina e a frase "na minha máquina funciona" virou piada interna. Quando o servidor precisa ser trocado, ninguém sabe exatamente o que estava instalado nele.

Docker e containers existem para resolver esse tipo de problema. O termo aparece em propostas, em conversas com fornecedores e em vagas de emprego, mas raramente alguém explica para quem decide o que ele muda na prática. Este texto faz isso, sem código, e mostra também onde está o exagero.

Docker: o que é, em uma resposta curta

Docker é uma ferramenta que empacota um sistema junto com tudo de que ele precisa para rodar (versão da linguagem, bibliotecas, configurações, arquivos de apoio) num pacote padronizado chamado imagem. Quando essa imagem é executada, ela vira um container: um processo isolado que se comporta da mesma forma em qualquer máquina compatível com o Docker, seja o notebook do desenvolvedor, o servidor da empresa ou um servidor na nuvem.

A analogia mais útil é a do contêiner de navio. Antes da padronização, cada carga era embarcada de um jeito: sacos, caixas, barris, cada um exigindo manuseio próprio no porto. O contêiner padronizou a caixa. O guindaste não precisa saber se dentro há café ou peças de motor; ele só precisa saber levantar a caixa. O container de software faz o mesmo: o servidor não precisa saber se o sistema é em Python, Java, Node ou PHP. Ele só precisa saber rodar containers. Isso não tira a importância de escolher bem entre Node.js, .NET ou Java.

Alguns termos que aparecem nas conversas:

• Imagem: o sistema já montado e congelado, com tudo de que precisa. É como um prato pronto congelado: sai igual toda vez que vai ao forno.
• Container: a imagem em execução. Da mesma imagem podem sair vários containers idênticos.
• Dockerfile: a receita, um arquivo de texto que descreve como a imagem é montada. Fica junto do código, versionado, e qualquer pessoa consegue ler o que foi instalado.
• Registro de imagens: o "almoxarifado" onde as imagens prontas ficam guardadas, cada uma com uma versão, para serem baixadas pelos servidores.

Docker é a ferramenta mais conhecida, mas o formato de imagem segue um padrão aberto (OCI). Existem outras ferramentas compatíveis com esse padrão, como Podman e containerd, e uma imagem bem construída roda nelas também. Uma ressalva: a imagem precisa ser gerada para o tipo de processador e de sistema do servidor (a grande maioria roda em Linux), o que o time define na hora de montá-la.

O problema que os containers resolvem

Os ganhos aparecem em três dores que quase toda empresa com sistema próprio já sentiu.

"Na minha máquina funciona." Sem container, o ambiente do desenvolvedor, o de testes e o de produção divergem com o tempo. Uma versão de biblioteca aqui, uma configuração ali. Com container, o que foi testado é exatamente o que vai para produção, porque é a mesma imagem.

Servidores frágeis, montados à mão. O servidor que acumula anos de instalações manuais é o equivalente a uma planilha que só uma pessoa entende. Com containers, o servidor fica "limpo": ele roda o Docker e os containers, e toda a configuração de cada sistema está descrita em arquivos versionados. Se o servidor morrer, outro é montado a partir desses arquivos, sem arqueologia.

Implantação lenta e arriscada. Publicar uma versão nova deixa de ser um roteiro manual de vinte passos executado de madrugada. Vira "baixar a imagem nova e trocar o container", um processo que pode ser automatizado e repetido sempre do mesmo jeito.

Há ainda um ganho de convivência: dois sistemas que exigem versões diferentes da mesma linguagem podem rodar no mesmo servidor, cada um no seu container, sem um quebrar o outro.

Container x máquina virtual

A pergunta comum é: "isso não é a mesma coisa que máquina virtual?". Não é, e a diferença importa para custo e velocidade.

Uma máquina virtual simula um computador inteiro, com sistema operacional próprio. É como alugar uma casa inteira para cada morador. Um container compartilha o sistema operacional do servidor e isola apenas o que é do sistema. É como um prédio de apartamentos: cada um tem a sua porta e os seus móveis, mas a estrutura, a água e a energia são compartilhadas.

Na prática, as duas coisas convivem. É comum ter máquinas virtuais na nuvem e, dentro delas, vários containers. A escolha não é "um ou outro", é qual camada resolve qual problema.

Docker na rotina da equipe de desenvolvimento

Para o gestor, o efeito mais visível dos containers está no dia a dia do time.

• Chegada de gente nova mais rápida. Uma pessoa nova clona o projeto, roda um comando e tem o sistema, o banco de dados e os serviços de apoio funcionando na máquina dela. O que antes era um documento desatualizado de instalação vira um arquivo que sempre funciona.
• Ambiente de testes fiel. O time consegue subir uma cópia do sistema parecida com a produção para testar uma mudança antes de publicar.
• Menos dependência de pessoas. A configuração do ambiente deixa de morar na cabeça de alguém e passa a estar escrita, revisada e versionada junto com o código.
• Ferramenta para vários serviços juntos. Com o Docker Compose, um único arquivo descreve o sistema, o banco, a fila e o cache, e todos sobem juntos. Para muitas empresas, isso já é toda a orquestração necessária.

Implantação mais previsível e reversível

O ganho que mais interessa à diretoria costuma ser este: publicar fica previsível, e voltar atrás fica simples.

Cada versão do sistema vira uma imagem com número. Se a versão nova apresentar um problema, o time volta a rodar a imagem anterior, que continua guardada no registro. Não é preciso desfazer instalações nem torcer para lembrar o que mudou.

Isso abre espaço para práticas que reduzem o risco de cada entrega:

• Pipeline automatizado: a cada mudança aprovada, a imagem é montada, testada e publicada pelo mesmo processo, sem passo manual.
• Publicações menores e mais frequentes: quando publicar é barato e reversível, o time entrega em lotes pequenos, e cada lote carrega menos risco.
• Troca sem parar o sistema: sobe o container novo, confirma que ele responde e só então desliga o antigo. Isso exige alguma configuração extra, mas fica muito mais simples com containers.

Um cuidado importante: o que é gravado dentro do container some quando ele é substituído. Banco de dados, arquivos enviados por clientes e documentos fiscais precisam estar em volumes ou serviços próprios, com backup. Um projeto que ignora isso perde dados na primeira troca de versão.

Se a sua empresa está pensando em tirar o sistema do servidor da sala e levar para a nuvem, containerizar costuma ser um passo natural dessa jornada, como mostramos em migrar o servidor local para a nuvem.

Kubernetes: quando faz sentido e quando é exagero

Kubernetes é um orquestrador de containers: um sistema que decide em quais servidores cada container roda, reinicia os que caem, distribui a carga e aumenta ou diminui a quantidade de cópias conforme a demanda. Se o Docker é o contêiner de navio, o Kubernetes é a gestão automatizada de um porto inteiro.

É uma ferramenta poderosa e também uma fonte frequente de complexidade desnecessária em empresas pequenas e médias. Ele traz conceitos próprios, exige conhecimento especializado para operar com segurança e cria uma camada a mais para monitorar, atualizar e pagar.

Kubernetes tende a fazer sentido quando:

• a empresa tem muitos serviços independentes, mantidos por times diferentes;
• a carga varia muito ao longo do dia ou do mês e precisa escalar automaticamente;
• a disponibilidade exigida não tolera a queda de um servidor;
• existe gente com conhecimento para operar, ou um serviço gerenciado com suporte adequado.

Kubernetes tende a ser exagero quando:

• o sistema é um ERP interno, um portal ou uma aplicação com poucos serviços;
• um ou dois servidores dão conta da carga com folga;
• ninguém no time sabe operar e a ideia é "aprender em produção";
• a motivação é "todo mundo usa" ou "fica bem no currículo".

Para grande parte das empresas pequenas e médias, containers com Docker Compose num servidor bem configurado, ou um serviço gerenciado de containers do provedor de nuvem, entregam quase todos os benefícios com uma fração da complexidade. É a mesma lógica da discussão entre monolito ou microsserviços: a arquitetura deve acompanhar o tamanho do problema, não a moda.

Complexidade sem necessidade também pesa na fatura. Clusters superdimensionados e ambientes esquecidos ligados são causas frequentes de conta alta, e o tema é tratado em como reduzir custos de nuvem.

Containers e independência de fornecedor

Um benefício pouco comentado: containers reduzem a dependência de um provedor de nuvem específico e também de um fornecedor de software.

Como a imagem é um formato padrão, o mesmo sistema roda em qualquer grande provedor de nuvem, num servidor dedicado ou num servidor dentro da empresa. Trocar de provedor continua dando trabalho (rede, banco de dados, armazenamento, permissões), mas a aplicação em si não precisa ser reescrita.

O mesmo vale para a relação com quem desenvolve o sistema. Se o Dockerfile, os arquivos de configuração e o pipeline estão no repositório da sua empresa, outro time consegue assumir o sistema sem depender de um servidor que só o fornecedor anterior sabia montar. Na hora de contratar, vale exigir isso por escrito: o código e a receita de implantação pertencem à empresa.

Os riscos que os containers não resolvem sozinhos

Container não é solução mágica. Alguns pontos precisam de atenção:

• Segurança das imagens. Uma imagem montada a partir de uma base desatualizada carrega as vulnerabilidades dela. Imagens precisam ser atualizadas e verificadas com regularidade.
• Senhas e chaves. Credenciais não podem ficar gravadas dentro da imagem. Elas devem ser injetadas no momento da execução, por um mecanismo próprio para segredos.
• Dados pessoais. Containers não mudam as obrigações da LGPD. Onde os dados ficam, quem acessa e como é feito o backup continuam sendo decisões que precisam estar documentadas.
• Monitoramento. Containers sobem e descem rápido. Sem registro centralizado de logs e alertas, um erro pode passar despercebido.
• Sistemas antigos. Nem todo sistema legado é fácil de containerizar. Alguns dependem de configurações do servidor ou de licenças amarradas à máquina, e exigem análise antes.

Perguntas para fazer ao seu time técnico

Você não precisa entender os comandos para avaliar se a infraestrutura está saudável. Estas perguntas ajudam a conduzir a conversa:

1. Se o servidor de produção sumisse hoje, quanto tempo levaríamos para montar outro? E isso está documentado ou depende de alguém lembrar?
2. Uma pessoa nova consegue rodar o sistema na própria máquina no primeiro dia?
3. Como publicamos uma versão nova? É automatizado ou é um roteiro manual?
4. Se a versão nova der problema, como voltamos para a anterior, e quanto isso leva?
5. Onde ficam os dados permanentes, e quando foi testada a restauração do backup?
6. As imagens e suas bases são atualizadas com que frequência?
7. Precisamos mesmo de Kubernetes, ou um ambiente mais simples atende?
8. O Dockerfile, a configuração e o pipeline estão num repositório da empresa?

Se as respostas para as quatro primeiras forem vagas, containers provavelmente trariam ganho real. Se a resposta para a sétima for "porque é o padrão do mercado", vale uma segunda opinião.

Um roteiro para adotar containers sem trauma

1. Inventarie o que roda hoje: sistemas, versões, dependências, tarefas agendadas e onde ficam os dados.
2. Comece por um sistema de risco moderado, que tenha uso real mas cuja queda não pare a empresa.
3. Escreva o Dockerfile e o Compose e faça o time inteiro usar o mesmo ambiente no desenvolvimento.
4. Separe os dados permanentes em volumes ou serviços gerenciados, com backup testado.
5. Monte o pipeline que constrói, testa e publica a imagem automaticamente.
6. Rode em paralelo com o ambiente atual antes de desligar o antigo.
7. Defina monitoramento e o procedimento de volta para a versão anterior.
8. Só depois avalie orquestração, se a carga e o número de serviços justificarem.

O prazo depende do número de sistemas, do estado do código e de quanto da configuração atual está documentada. Por isso ele só faz sentido depois do inventário.

Perguntas frequentes

Qual a diferença entre Docker e Kubernetes?

Docker empacota e executa um sistema dentro de containers padronizados, enquanto Kubernetes orquestra muitos containers ao mesmo tempo, decidindo em quais servidores cada um roda, reiniciando os que caem e ajustando a quantidade de cópias conforme a demanda. Muitas empresas usam Docker sem Kubernetes, com Docker Compose ou um serviço gerenciado de containers.

Preciso de Docker para rodar meu sistema na nuvem?

Não necessariamente. Um sistema pode rodar na nuvem sem Docker, em máquinas virtuais configuradas diretamente. Os containers, porém, tornam a implantação mais previsível, facilitam voltar para a versão anterior e reduzem a dependência de um provedor específico, por isso costumam ser um passo natural para quem está levando o sistema para a nuvem.

Todo sistema legado pode ser colocado em container?

Nem sempre. Muitos sistemas legados podem ser containerizados, mas alguns dependem de configurações específicas do servidor, de licenças amarradas à máquina ou de componentes antigos difíceis de empacotar. Antes de levar um sistema legado para containers, vale uma análise técnica que identifique essas dependências e mostre se o ganho compensa o esforço.

Containers deixam o sistema mais seguro?

Containers ajudam a organizar e isolar os sistemas, mas não garantem segurança sozinhos. As imagens precisam ser atualizadas para não carregar vulnerabilidades da base, senhas e chaves devem ser injetadas por um mecanismo próprio de segredos, e logs e alertas precisam ser centralizados. As obrigações da LGPD continuam valendo da mesma forma.

Como a Pervian Tech trabalha containers

Na Pervian Tech, containers fazem parte do trabalho de cloud e DevOps. Começamos pelo diagnóstico: o que roda hoje, onde estão os dados, como as versões são publicadas e onde estão os riscos. A partir daí propomos a infraestrutura do tamanho do problema, com Docker e Compose quando isso basta e orquestração só quando a operação pede, sempre com a receita de implantação no repositório da sua empresa.

O plano é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Outros temas de infraestrutura estão em cloud e infraestrutura. Se publicar uma versão nova ainda é motivo de tensão na sua empresa, conte como funciona hoje.