Artigo original: https://www.freecodecamp.org/news/7-cases-when-not-to-use-docker/
O Docker é um divisor de águas. Mas não é uma solução para todos os problemas.
Há muitas coisas boas sobre o Docker. Ele empacota, envia e executa aplicativos como uma ferramenta de conteinerização leve, portátil e autossuficiente. O Docker é ótimo para empresas de todos os tamanhos. Quando você está trabalhando em um trecho de código em uma equipe pequena, ele elimina o problema do "mas funciona na minha máquina". Enquanto isso, as empresas podem usar o Docker para criar pipelines de entrega de software Agile para enviar novos recursos com mais rapidez e segurança.
Com seu sistema de conteinerização integrado, o Docker é uma excelente ferramenta para computação em nuvem. Por sua vez, o Docker Swarm avança na clusterização e no design descentralizado. Parece bom demais para ser verdade, certo? Bem, ainda existem vários casos em que não se deve usar o Docker. Aqui estão sete deles.
Vamos passar por eles um por um.
Não use o Docker se você precisa de mais velocidade
Os contêineres do Docker são menores e exigem menos recursos do que uma máquina virtual com um servidor e um banco de dados. Ao mesmo tempo, o Docker usará tantos recursos do sistema quanto o agendador do kernel do host permitir. Você não deve esperar que o Docker acelere um aplicativo de forma alguma.
Mais do que isso, o Docker pode até torná-lo mais lento. Se estiver trabalhando com ele, você deve definir limites de memória, CPU ou bloco de E/S o contêiner pode usar. Caso contrário, se o kernel detectar que a máquina host está com pouca memória para executar funções importantes do sistema, ele poderá começar a matar processos importantes. Se o processo errado for eliminado (incluindo o próprio Docker), o sistema ficará instável.
Infelizmente, os ajustes de memória do Docker – a prioridade de falta de memória no daemon do Docker – não resolvem esse problema. Por outro lado, uma camada adicional entre um aplicativo e o sistema operacional também pode resultar em redução de velocidade. No entanto, essa diminuição será insignificante. Os contêineres do Docker não são totalmente isolados e não contêm um sistema operacional completo como qualquer máquina virtual.
Não use o Docker se você prioriza a segurança
A maior vantagem de segurança do Docker é que ele divide o aplicativo em partes menores. Se a segurança de uma parte for comprometida, as demais não serão afetadas.
No entanto, enquanto processos isolados em contêineres prometem segurança aprimorada, todos os contêineres compartilham acesso a um único sistema operacional de host. Você corre o risco de executar contêineres do Docker com isolamento incompleto. Qualquer código malicioso pode ter acesso à memória do seu computador.
Existe uma prática popular de executar muitos contêineres em um único ambiente. É assim que você deixa seu aplicativo exposto a ataques do tipo Abuso de Recursos, a menos que você limite os recursos do contêiner de recursos. Para máxima eficiência e isolamento, cada contêiner deve tratar de uma área específica de preocupação.
Outro problema é a configuração padrão do Docker – os usuários não têm espaços de nome (namespace, em inglês). Os espaços de nome permitem que os recursos de software usem outros recursos somente se eles pertencerem a um espaço de nome específico.
A execução de aplicativos com o Docker implica a execução do daemon do Docker com privilégios de root. Todos os processos que saem do contêiner do Docker terão os mesmos privilégios no host que tinham no contêiner. Executar seus processos dentro dos contêineres como um usuário sem privilégios não garante a segurança. Depende dos recursos que você adiciona ou remove. Para mitigar os riscos de rompimento de contêineres do Docker, você não deve baixar contêineres prontos para uso de fontes não confiáveis.
Não use o Docker se você desenvolve um aplicativo de interface gráfica para desktops
O Docker não é adequado para aplicativos que exigem interface do usuário avançada. O Docker destina-se principalmente a contêineres isolados com aplicativos baseados em console. Os aplicativos baseados em GUI (abreviação em inglês de interface gráfica de usuário) não são uma prioridade. Seu suporte dependerá do caso e da aplicação específicos. Os contêineres do Windows são baseados em Nano ou Core Server – ele não permite que os usuários iniciem uma interface baseada em GUI ou um servidor Docker RDP no contêiner Docker.
No entanto, você ainda pode executar aplicativos baseados em GUI desenvolvidos com Python e a estrutura QT em um contêiner Linux. Além disso, você pode usar o encaminhamento X11, mas essa solução é um pouco estranha.
Não use o Docker se você deseja facilitar o desenvolvimento e depuração
O Docker foi criado por desenvolvedores e para desenvolvedores. Ele fornece estabilidade ao ambiente: um contêiner na máquina de desenvolvimento funcionará exatamente da mesma forma no teste, na produção ou em qualquer outro ambiente. Isso elimina o problema de várias versões de programas em diferentes ambientes.
Com a ajuda do Docker, você pode adicionar facilmente uma nova dependência ao seu aplicativo. Nenhum desenvolvedor em sua equipe precisará repetir essa manipulação em sua máquina. Tudo estará funcionando no contêiner e será distribuído para toda a equipe.
Ao mesmo tempo, você precisa fazer algumas configurações extras para codificar seu aplicativo no Docker. Além disso, com a depuração do Docker, você precisa configurar a saída de logs e as portas de depuração. Você também pode precisar mapear portas para seus aplicativos e serviços em contêineres. Portanto, se você tiver um processo de implantação complicado e tedioso, o Docker o ajudará muito. Se você tem um aplicativo simples, ele apenas adiciona complexidade desnecessária.
Não use o Docker se você precisa usar sistemas operacionais e kernels diferentes
Com máquinas virtuais, o hipervisor pode abstrair um dispositivo inteiro. Você pode usar o Microsoft Azure para executar as duas instâncias do Windows Server e do Linux Server ao mesmo tempo. A imagem do Docker, no entanto, requer o mesmo sistema operacional para o qual foi criada.
Há um grande banco de dados de imagens de contêiner do Docker – o Docker Hub. No entanto, se uma imagem foi criada no Linux Ubuntu, ela será executada apenas no mesmo Ubuntu.
Se um aplicativo for desenvolvido no Windows, mas a produção for executada no Linux, você não poderá usar o Docker de maneira eficaz. Às vezes, é mais fácil configurar um servidor se você tiver vários aplicativos estáticos.
Não use o Docker se você tem muitos dados valiosos para armazenar
Por design, todos os arquivos do Docker são criados dentro de um contêiner e armazenados em uma camada de contêiner gravável. Pode ser difícil recuperar os dados do contêiner se um processo diferente precisar deles. Além disso, a camada gravável de um contêiner é conectada à máquina host na qual o contêiner está sendo executado. Se você precisar mover os dados para outro lugar, não poderá fazê-lo facilmente. Mais do que isso, todos os dados armazenados dentro de um contêiner serão perdidos para sempre quando o contêiner for encerrado.
Você precisa pensar em maneiras de salvar seus dados em outro lugar primeiro. Para manter os dados seguros no Docker, você precisa empregar uma ferramenta adicional – o Docker Data Volumes. No entanto, esta solução ainda é bastante desajeitada e precisa ser melhorada.
Não use o Docker se você busca a tecnologia mais fácil de gerenciar
Tendo sido introduzido em 2012, o Docker ainda é uma tecnologia nova. Como desenvolvedor, talvez seja necessário atualizar as versões do Docker regularmente. Infelizmente, a compatibilidade com versões anteriores não é garantida. Além disso, a documentação está ficando para atrás em relação ao avanço da tecnologia. Como desenvolvedor, você terá que descobrir algumas coisas sozinho.
As opções de monitoramento que o Docker oferece também são bastante ruins. Você pode obter uma visão rápida de algumas estatísticas simples. No entanto, se você quiser ver alguns recursos avançados de monitoramento, o Docker não tem nada a oferecer.
No caso de um aplicativo grande e complexo, a implementação do Docker tem um custo. Construir e manter a comunicação entre vários contêineres em vários servidores exigirá muito tempo e esforço. No entanto, existe uma ferramenta útil, que facilita o trabalho com aplicativos Docker de vários contêineres – o Docker Compose. Ele define serviços, redes e volumes em um único arquivo YAML.
No entanto, o ecossistema do Docker é bastante fragmentado – nem todos os produtos de contêiner de suporte funcionam bem uns com os outros. Cada produto é apoiado por uma determinada empresa ou comunidade. A competição acirrada entre elas resulta na incompatibilidade do produto.
Para resumir
Os profissionais da KeenEthics gostam de trabalhar com o Docker e costumam usá-lo para o desenvolvimento de aplicativos. Apesar de algumas desvantagens, você pode usá-lo facilmente para executar e gerenciar aplicativos lado a lado em contêineres isolados.
Instalar um aplicativo pode ser tão simples quanto executar um único comando – <docker run>. O Docker também fornece um ambiente de isolamento limpo e original para cada teste, tornando-o uma ferramenta importante e útil para testes de automação.
Os recursos do Docker oferecem benefícios em termos de gerenciamento de dependência e segurança. Aprimorado com ferramentas úteis como o Docker Hub, o Docker Swarm e o Docker Compose, o Docker é uma solução popular e fácil de usar.
Apesar de todos os benefícios do Docker, você não deve usá-lo para conteinerizar todo e qualquer aplicativo que você desenvolver.
Lembre-se: o Docker é um divisor de águas, mas não é uma solução para todos os problemas.
O Docker também não é a única ferramenta desse tipo no mercado. As alternativas ao Docker são o rkt (que se pronuncia como "rocket"), o Linux Containers ou o OpenVZ. Todos têm suas vantagens e desvantagens e são bastante semelhantes ao Docker. A crescente popularidade e as taxas de uso do Docker são causadas apenas pela decisão das empresas de adotá-lo.
Antes de tirar conclusões precipitadas sobre usar ou não o Docker, pesquise os requisitos do projeto. Converse com seus colegas de equipe ou colegas e deixe-os ajudá-lo a decidir quando usar o Docker, quando não usar contêineres e se é um desses casos de uso do Docker.
Quer você goste ou não, essa tecnologia tem futuro. Existem alguns desenvolvedores e agências de desenvolvimento que odeiam o Docker e tentam eliminá-lo de todos os seus projetos em andamento. Ao mesmo tempo, existem especialistas que colocam em contêiner tudo o que podem porque veem o Docker como uma panaceia. Talvez você não deva se juntar a nenhum dos lados. Mantenha-se imparcial, seja objetivo e tome uma decisão que dependa de sua situação específica.
Você tem uma ideia para um projeto do Docker?
A empresa do autor, a KeenEthics, é uma equipe de desenvolvedores de aplicativos da web experientes. Caso precise de um orçamento gratuito de um projeto semelhante, sinta-se à vontade para entrar em contato.
Você pode ler mais artigos semelhantes no blog do autor, o Keen Blog. Permita-me sugerir que você leia Why to Refactor Your Code? (em inglês) ou Software Development Models Explained: Outsourcing vs Outstaffing, Fixed Price vs Time & Material? (também em inglês)
Nota final
Por fim, o autor original gostaria de registrar seu "obrigado" a Alex Pletnov, por ser o coautor do artigo original, bem como aos leitores por chegarem até o final do texto!
O artigo original, postado no blog da KeenEthics, pode ser encontrado aqui: 7 Cases When Not to Use Docker (em inglês).