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

> Docker: o que é, que problema resolve e quando Kubernetes é exagero. Containers explicados sem código, com analogias de negócio, para quem decide.

Fonte: https://pervian.tech/blog/docker-e-containers-para-gestores · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/node-dotnet-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.

| Aspecto | Máquina virtual | Container |
|---|---|---|
| O que carrega | Sistema operacional completo + aplicação | Só a aplicação e suas dependências |
| Tempo para subir | Minutos, em geral | Segundos, em geral |
| Uso de recursos | Maior, cada VM tem seu próprio sistema | Menor, compartilha o sistema do servidor |
| Isolamento | Mais forte | Bom, mas compartilha o núcleo do sistema |
| Uso típico | Separar ambientes inteiros, rodar sistemas operacionais diferentes | Empacotar e publicar aplicações |

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](https://pervian.tech/blog/ci-cd-para-gestores):** 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](https://pervian.tech/blog/migrar-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](https://pervian.tech/blog/alta-disponibilidade-de-sistemas) 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](https://pervian.tech/blog/monolito-ou-microsservicos): 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](https://pervian.tech/blog/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](https://pervian.tech/blog/onde-hospedar-sistema-web) 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](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato).**

## 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](https://pervian.tech/servicos/cloud-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](https://pervian.tech/blog/categoria/cloud-e-infraestrutura). Se publicar uma versão nova ainda é motivo de tensão na sua empresa, [conte como funciona hoje](https://pervian.tech/#contato).