Container
Container empacota a aplicação junto com tudo o que ela precisa para rodar: bibliotecas, versões e configuração. O mesmo pacote roda igual na máquina do desenvolvedor, na homologação e em produção.
O problema que ele resolve tem nome conhecido: "na minha máquina funciona". A aplicação depende de uma versão de biblioteca que existe num lugar e não em outro, e a diferença só aparece na hora da publicação.
O container elimina isso porque o ambiente vai junto com a aplicação, no mesmo pacote. O servidor precisa saber executar containers, e não precisa mais ter a versão certa de cada dependência instalada.
Há um ganho secundário relevante: isolamento. Duas aplicações que exigem versões conflitantes da mesma biblioteca convivem no mesmo servidor sem se atrapalhar, o que antes exigia servidor separado.
A dependência nova é a imagem. Ela congela as versões no dia em que foi construída, incluindo as falhas de segurança conhecidas depois. Container criado e nunca reconstruído acumula vulnerabilidade em silêncio, e esse é o custo que a maioria dos projetos esquece de orçar.
Quando se aplica
- A aplicação se comporta diferente entre ambientes e ninguém sabe explicar por quê.
- Subir ambiente novo depende de uma lista de instalações feita à mão.
- Aplicações diferentes precisam de versões conflitantes da mesma dependência.
- A equipe quer publicar com mais frequência e a preparação do servidor é o gargalo.
Quando não se aplica
- A aplicação é única, estável e roda num servidor que ninguém mexe há anos.
- Sem processo de reconstrução periódica da imagem. Container esquecido vira dívida de segurança.
- Só para seguir tendência. O ganho aparece quando há mais de um ambiente ou mais de uma aplicação.
Empacotamento, esteira de publicação e reconstrução periódica da imagem.
Termos relacionados
Container que nunca é reconstruído acumula vulnerabilidade em silêncio.
O diagnóstico olha como a sua aplicação é empacotada hoje e o que falta para publicar sem surpresa.
Agendar diagnóstico