Docker é um brinquedo ou não? Ou ainda é verdade?

Olá a todos!

Quero muito ir direto ao assunto, mas seria mais correto contar um pouco da minha história:

Entrada

Sou programador com experiência em desenvolvimento de aplicações frontend single page, scala/java e nodejs no servidor.

Por muito tempo (definitivamente alguns ou três anos), fui da opinião de que o Docker é um maná do céu e, em geral, uma ferramenta muito legal e que absolutamente todo desenvolvedor deveria ser capaz de usá-lo. E a partir disso segue-se que todo desenvolvedor deve ter o Docker instalado em sua máquina local. E na minha opinião, dê uma olhada nas vagas que estão postadas no mesmo hh. Cada segundo contém uma menção ao docker e, se você o possui, essa será sua vantagem competitiva 😉

No caminho, conheci muitas pessoas, com suas diferentes atitudes em relação ao Docker e seu ecossistema. Alguns disseram que isso é algo conveniente que garante funcionalidade multiplataforma. Os segundos não entendiam porque deveriam rodar em containers e que lucro adviria disso, os terceiros não se importaram nem um pouco (eles apenas escreveram o código e foram para casa - eu os invejo, pelo menos caminho :)

Razões para uso

Por que usei o docker? Provavelmente pelos seguintes motivos:

• lançamento de banco de dados, 99% dos aplicativos os utilizam
• lançando o nginx para distribuição frontend e proxy para backend
• você pode empacotar o aplicativo em uma imagem do docker, dessa forma meu aplicativo funcionará onde quer que o docker exista, o problema de distribuição será resolvido imediatamente
• descoberta de serviço pronta para uso, você pode criar microsserviços, cada contêiner (conectado a uma rede comum) pode facilmente acessar outro por meio de um alias, muito conveniente
• É divertido criar um contêiner e “brincar” nele.

O que eu sempre NÃO gosto no docker:

• Para que meu aplicativo funcione, preciso do próprio Docker no servidor. Por que preciso disso se meus aplicativos são executados em jre ou nodejs e o ambiente para eles já está no servidor?
• se eu quiser executar minha imagem (privada) construída localmente em um servidor remoto, preciso do meu próprio repositório docker, preciso que o registro funcione em algum lugar e também preciso configurar o https, porque o docker cli só funciona em https. Caramba... existem opções, é claro, para salvar a imagem localmente via docker save e é só enviar a imagem via scp... Mas são muitos movimentos corporais. E além disso, parece uma solução de “muleta” até que apareça seu próprio repositório
• docker-compose. É necessário apenas para executar contêineres. Isso é tudo. Ele não pode fazer mais nada. Docker-compose tem várias versões de seus arquivos, sua própria sintaxe. Não importa o quão declarativo seja, não quero ler a documentação deles. Não vou precisar disso em nenhum outro lugar.
• ao trabalhar em equipe, a maioria das pessoas escreve um Dockerfile muito torto, não entende como ele é armazenado em cache, adiciona tudo o que precisa e não precisa à imagem, herda de imagens que não estão no Dockerhub ou em um repositório privado, cria alguns docker-compose arquivos com bancos de dados e nada persiste. Ao mesmo tempo, os desenvolvedores declaram com orgulho que o Docker é legal, tudo funciona localmente para eles, e o RH escreve na vaga: “Usamos o Docker e precisamos de um candidato com essa experiência de trabalho”.
• Sou constantemente assombrado por pensamentos sobre como criar tudo no Docker: postgresql, kafka, redis. É uma pena que nem tudo funcione em containers, nem tudo seja fácil de configurar e executar. Isso é suportado por desenvolvedores terceirizados e não pelos próprios fornecedores. E por falar nisso, surge imediatamente a pergunta: os fornecedores não se preocupam em manter seus produtos no Docker, por que isso acontece, talvez eles saibam de alguma coisa?
• Sempre surge a questão sobre a persistência dos dados do contêiner. e então você pensa, devo apenas montar o diretório host ou criar um volume docker ou fazer um contêiner de dados que agora é deprecated? Se eu montar um diretório, preciso ter certeza de que o uid e o gid do usuário no contêiner correspondem ao id do usuário que iniciou o contêiner, caso contrário, os arquivos criados pelo contêiner serão criados com direitos de root. Se eu usar volume então os dados serão simplesmente criados em algum /usr/* e haverá a mesma história com uid e gid como no primeiro caso. Se você estiver lançando um componente de terceiros, precisará ler a documentação e procurar a resposta para a pergunta: “em quais diretórios de contêiner o componente grava arquivos?”

Eu sempre não gostei do fato de ter que mexer no Docker por muito tempo na fase inicial: descobri como iniciar contêineres, de quais imagens iniciar, criei Makefiles que continham aliases para comandos longos do Docker. Eu odiava o docker-compose porque não queria aprender outra ferramenta no ecossistema docker. E docker-compose up Isso me incomodava, principalmente se eles ainda se encontravam lá build construções, em vez de imagens já montadas. Tudo o que eu realmente queria era fazer um produto com eficiência e rapidez. Mas não consegui descobrir como usar o docker.

Apresentando o Ansible

Recentemente (há três meses), trabalhei com uma equipe de DevOps, onde quase todos os membros tinham uma atitude negativa em relação ao Docker. Por razões:

• docker regras iptables (embora você possa desativá-lo em daemon.json)
• docker tem bugs e não vamos executá-lo em produção
• se o daemon do docker travar, todos os contêineres com infraestrutura travarão de acordo
• não há necessidade de docker
• por que docker se existe Ansible e máquinas virtuais

No mesmo trabalho, conheci outra ferramenta - Ansible. Ouvi falar disso uma vez, mas não tentei escrever meus próprios manuais. E agora comecei a escrever minhas tarefas e então minha visão mudou completamente! Porque percebi: o Ansible possui módulos para executar os mesmos contêineres docker, construções de imagens, redes, etc., e os contêineres podem ser executados não apenas localmente, mas também em servidores remotos! Minha alegria não tinha limites - encontrei uma ferramenta NORMAL e joguei fora meus arquivos Makefile e docker-compose, eles foram substituídos por tarefas yaml. O código foi reduzido usando construções como loop, when, etc.

Docker para executar componentes de terceiros, como bancos de dados

Recentemente, conheci túneis ssh. Descobriu-se que é muito fácil “encaminhar” a porta de um servidor remoto para uma porta local. O servidor remoto pode ser uma máquina na nuvem ou uma máquina virtual rodando no VirtualBox. Se meu colega ou eu precisarmos de um banco de dados (ou algum outro componente de terceiros), podemos simplesmente iniciar o servidor com este componente e desligá-lo quando o servidor não for necessário. O encaminhamento de porta dá o mesmo efeito que um banco de dados em execução em um contêiner docker.

Este comando encaminha minha porta local para um servidor remoto executando o postgresql:

ssh -L 9000:localhost:5432 [email protegido]

Usar um servidor remoto resolve o problema de desenvolvimento da equipe. Esse servidor pode ser usado por vários desenvolvedores ao mesmo tempo; eles não precisam ser capazes de configurar o postgresql, entender o Docker e outras complexidades. Em um servidor remoto, você pode instalar o mesmo banco de dados no próprio Docker, caso seja difícil instalar uma versão específica. Tudo o que os desenvolvedores precisam é fornecer acesso ssh!

Li recentemente que os túneis SSH são uma funcionalidade limitada de uma VPN normal! Você pode simplesmente instalar o OpenVPN ou outras implementações de VPN, configurar a infraestrutura e fornecê-la aos desenvolvedores para uso. Isso é tão legal!

Felizmente, AWS, GoogleCloud e outros oferecem um ano de uso gratuito, então use-os! Eles são baratos se você desligá-los quando não estiverem em uso. Sempre me perguntei por que precisaria de um servidor remoto como o gcloud, parece que os encontrei.

Como máquina virtual local, você pode usar o mesmo Alpine, que é usado ativamente em contêineres docker. Bem, ou alguma outra distribuição leve para tornar a inicialização da máquina mais rápida.

Resumindo: você pode e deve executar bancos de dados e outros recursos de infraestrutura em servidores remotos ou em caixa virtual. Não preciso do docker para esses fins.

Um pouco sobre imagens e distribuição do Docker

Eu já escrevi статью no qual eu queria transmitir que o uso de imagens do Docker não oferece nenhuma garantia. As imagens do Docker são necessárias apenas para criar um contêiner do Docker. Se você estiver atualizando para uma imagem docker, estará atualizando para usar contêineres docker e só os usará.

Você já viu algum lugar onde os desenvolvedores de software portam seus produtos apenas em uma imagem docker?
O resultado da maioria dos produtos são arquivos binários para uma plataforma específica; eles são simplesmente adicionados à imagem do docker, que é herdada da plataforma desejada. Você já se perguntou por que existem tantas imagens semelhantes no dockerhub? Entre no nginx, por exemplo, você verá 100500 imagens de pessoas diferentes. Essas pessoas não desenvolveram o nginx em si, elas simplesmente adicionaram o nginx oficial à sua imagem do docker e temperaram-no com suas próprias configurações para a conveniência de lançar contêineres.

Em geral, você pode simplesmente armazená-lo em tgz, se alguém precisar executá-lo no docker, deixe-o adicionar tgz ao Dockerfile, herdar do ambiente desejado e criar pães adicionais que não alteram o próprio aplicativo em tgz. Qualquer pessoa que criar uma imagem docker saberá o que é tgz e o que ele precisa para funcionar. É assim que eu uso o docker aqui

Resumindo: não preciso do registro do docker, usarei algum tipo de S3 ou apenas armazenamento de arquivos como google drive/dropbox

Docker em CI

Todas as empresas em que trabalhei são semelhantes. Geralmente são mercearias. Ou seja, eles têm um aplicativo, uma pilha de tecnologia (bem, talvez algumas ou três linguagens de programação).

Essas empresas usam o docker em seus servidores onde o processo de CI é executado. Pergunta: Por que você precisa construir projetos em um contêiner docker em seus servidores? Por que não apenas preparar um ambiente para a construção, por exemplo, escrever um playbook Ansible que instalará as versões necessárias de nodejs, php, jdk, copiará chaves ssh, etc.

Agora entendo que isso é um tiro no pé, pois o docker não traz lucro com seu isolamento. Problemas que encontrei com CI no docker:

• novamente, você precisa de uma imagem docker para construir. você precisa procurar uma imagem ou escrever seu próprio dockerfile.
• 90% que você precisa encaminhar algumas chaves ssh, dados secretos que você não deseja gravar na imagem do docker.
• o contêiner é criado e morre, todos os caches são perdidos junto com ele. a próxima compilação baixará novamente todas as dependências do projeto, o que é demorado e ineficaz, e tempo é dinheiro.

Os desenvolvedores não constroem projetos em contêineres docker (eu já fui um grande fã, na verdade, sinto pena de mim mesmo no passado xD). Em java é possível ter várias versões e alterá-las com um comando para aquela que você precisa agora. É a mesma coisa no nodejs, existe o nvm.

Jogar aviator online grátis: hack aviator funciona

Acredito que o docker seja uma ferramenta muito poderosa e flexível, essa é a sua desvantagem (parece estranho, sim). Com sua ajuda, as empresas podem facilmente se apegar a ele e usá-lo onde for necessário ou não. Os desenvolvedores lançam seus contêineres, alguns de seus ambientes e, em seguida, tudo flui suavemente para CI e produção. A equipe DevOps está escrevendo algum tipo de código para executar esses contêineres.

Use o docker apenas em o mais recente estágio em seu fluxo de trabalho, não o arraste para o projeto no início. Isso não resolverá seus problemas de negócios. Ele apenas moverá os problemas para OUTRO nível e oferecerá suas próprias soluções, você fará um trabalho duplo.

Quando o docker é necessário: Cheguei à conclusão de que o docker é muito bom para otimizar um determinado processo, mas não para construir funcionalidades básicas

Se você ainda decidir usar o docker, então:

• seja extremamente cuidadoso
• não force os desenvolvedores a usar o docker
• localize seu uso em um só lugar, não o espalhe por todos os repositórios Dockefile e docker-compose

PS:

• Recentemente me deparei empacotador e dizem que funciona muito bem com Ansible e permite unificar o processo de construção de imagens (incluindo imagem docker)
• também sobre docker, artigo interessante

Obrigado pela leitura, desejo decisões transparentes em seus negócios e dias de trabalho produtivos!

Fonte: habr.com