Um texto (em inglês apenas) foi lançado na internet e isso causou um certo alvoroço na comunidade, pois já pelo título é bem impactante “Docker em produção: Uma história de fracasso”.

Pelo título eu imaginei que seria uma extensa e detalhada explicação sobre o que deu errado para eles, e apresentar os caminhos que eles seguiram para contornar, assim como demonstrar em qual momento foi impossível continuar.

Pra contextualizar, quero deixar claro que fui ler o texto realmente pensando em obter dados para me ajudar a trabalhar em projetos futuros. Coisas que eu poderia aprender previamente e ver se tinha soluções alternativas, mas infelizmente não foi isso que vi, ao menos não na maioria do texto.

Pra resumir bem, o texto tem um tom bem irônico e é claramente o desabafo de uma equipe frustada com o uso da tecnologia, que na minha opinião foi usada de forma equivocada e até mesmo sem uma pesquisa mais profunda sobre as possíveis soluções e contramedidas.

Pra organizar a minha argumentação, vou separar elas por tópicos do texto.

Docker Issue: Breaking changes and regressions

Nesse capítulo ele fala basicamente de problemas de retrocompatibilidade, que existe mesmo, mas não apresenta quais os problemas reais ele encontrou na regressão, apenas tocou superficialmente em redes, mas sequer mostrou um caso real.

No Bônus, faltou explicar que o Docker não foi removido do repositório do Debian, ele apenas não entrou na versão nova. Não achei o motivo ainda, mas arrisco dizer que a velocidade de lançamento do Docker não funciona bem com o esquema de empacotamento do repositório estável do Debian.

Aqui o link da situação do pacote no Debian: https://tracker.debian.org/pkg/docker.io.

O Docker oferece repositórios próprios com pacotes Debian, que aparentemente é seguro e a atualização é constante.

Docker Issue: Can’t clean old images

Isso é realmente chato e precisa ser corrigido, mas tem uma solução da Spotify que pode ajudar: https://github.com/spotify/docker-gc

Linux 3.x: Unstable storage drivers

Nesse capítulo ele fala de como os drives AUFS do kernel tem falhas e como causa kernel panic no sistema, ou seja, isso tem muito mais a ver com as versões do kernel que ele usa nas distribuições dele do que o Docker em sí.

Linux 4.x: The kernel officially dropped docker support

Ele explica que o AUFS não é mais suportado nos kernel 4.x e faz uma afirmação falsa:

“How does docker work without AUFS then? Well, it doesn’t.”

Funciona sim desde 2015, inclusive existem artigos falando para não usar mais AUFS. Achei esse no google na primeira página de busca: https://sthbrx.github.io/blog/2015/10/30/docker-just-stop-using-aufs/

The debacle of Overlay

Ele fala que para adotar o Docker você precisa constantemente modificar seu ambiente host, com atualização de kernel e afins. Infelizmente isso é verdade, mas acho que isso se dá mais por conta da velocidade como tudo foi construído nesse curto espaço de tempo. Em todo caso, não acredito que isso seja um problema, pois estamos em um momento de servidores descartáveis, ou seja, refazer um outro host com as configurações ideais, testar ele e então subir os containers nesse novo nó não deveria ser algo custoso para uma empresa moderna.

Bonus: The worldwide docker outage

Nesse capítulo ele fala sobre um grande downtime que o serviço do Docker gerou na instalação dos pacotes, pois a chave estava errada. Infelizmente isso é verdade e foi corrigido com uma certa lentidão. Ponto negativo total mesmo.

Docker Registry Issue: Abandon and Extinguish

Nesse capítulo ele fala como a v1 pra v2 do registry foi completamente reconstruída e ao abandonar a v1 o Docker não fez ofereceu mecanismos para uma migração, o que é mentira, pois existe ferramenta para auxiliar a migração: https://github.com/docker/migrator

Docker Registry Issue: Can’t clean images

Isso de fato é um problema, que tem bug aberto até hoje: https://github.com/docker/docker-registry/issues/1004

Docker Issue: The release cycle

O texto fala muito sobre falta de retrocompatibilidade, mas os poucos exemplos que ele apresentam são fracos ou inexistentes.

Banned from the core

Nesse capítulo ele descreve que aplicação erlang, que é core para o ambiente deles, não funcionou bem no Docker por alguns motivos e eles então concluíram que docker não está pronto para nada crítico. Constatação feita com base em uma única experiência.

Se você olhar esse comentário, verá que existe uma outra pessoa falando que roda erlang sem problemas no Docker.

Banned from the DBA

Nesse texto ele descreve o porque não usou Docker como banco de dados, mas novamente sem detalhar o suficiente para podermos inclusive aprender com a falha deles.

Eles provavelmente não usaram volumes para armazenar os dados, pois ele descreve o comportamento das camadas das imagens Docker, que de fato não foram pensadas para armazenar dados variáveis dentro dos containers.

É necessário utilizar volumes para esse tipo de ação.

Para quem quiser saber um pouco mais sobre MySQL no Docker, vejam esse artigo: http://mysqlserverteam.com/mysql-with-docker-performance-characteristics/

Outros capítulos

Ele repete um pouco o que já foi dito e deixar a ironia ficar ainda mais pesada, colocando gifs engraçados para reforçar o clima cômico da coisa.

Em resumo acho esperado que o Docker não funcione bem para a maioria dos casos, pois como já foi muito dito em vários espaços que o Docker NÃO É UMA BALA DE PRATA, ou seja, é possível sim que não será adequado para todos os casos, mas dai com base em uma experiência ruim, que muitas vezes foi fruto de uma má implementação inclusive, dizer que o Docker não está pronto para produção chega a ser hilária.

Novamente, juro que não tinha intenção de ler o texto para formular uma resposta para o artigo, mas foi inevitável dado a tantas pessoas que me marcaram para eu me posicionar sobre o ocorrido.

Agradecimentos

Quero agradecer a Somatório, que sempre me ajuda nas revisões dos artigos e Fukui por ter me marcado em uma postagem e assim me estimulou a de fato divulgar esse material.