Existem desvantagens em usar um pacote deb como se fosse um contêiner para implantar um aplicativo?

Atualmente, minha equipe está tentando decidir se devemos implantar nosso aplicativo Nodejs como um pacote deb em vez de tentar executá-lo em um contêiner como o Docker.

Eu tive essa idéia lendo este blog aqui, que apresenta alguns bons argumentos para usar um pacote deb para um aplicativo python pré-existente. O ponto principal deste blog que é atraente para nós é a questão da manutenção do ecossistema do Docker (compartilhamento de porta, permissões, hospedagem de imagens do Docker etc.)

Parece que "dep-packages como os contêineres originais" faz muito sentido para pequenos serviços onde não há preocupação com conflitos de portas e onde todas as dependências são mantidas em um ambiente virtual.

Meu instinto, no entanto, está me dizendo que, se os pacotes deb fossem adequados, seria mais comum e o docker seria anunciado como uma solução mais específica para o idioma. Existem desvantagens em usar algo como pacotes deb para implantar nossos serviços, em vez de usar um sistema completo, como o docker?

Primeiro, embora o Docker às vezes seja visto e usado como um sistema de empacotamento ad hoc , ele realmente resolve um problema totalmente diferente: o Docker trata da execução de programas. O sistema Docker permite descrever serviços que podem ser dimensionados à vontade e controlar enxames de contêineres. Os pacotes Debian são para instalação de programas e são capazes de lidar com dependências entre versões de software. Docker certamente não se qualifica como um sistema de empacotamento descendente: cada "pacote" pode ter apenas uma dependência, o sistema não possui a opção "compilação recursiva" e não suporta restrições de versão complexas!

Uma resposta possível seria que, se você estiver disposto a escrever um pacote Debian para seu aplicativo, também poderá usar o Docker para implantar seu aplicativo. Isso pode ser alcançado com um script de configuração apt_setup.shque se pareceria com

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

e um Dockerfileao longo das linhas de

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Na sua situação específica, apt_setup.shseria mais complicado adicionar os repositórios nodesource e alguns pacotes auxiliares, como apt-transport-https .)

Portanto, é realmente possível usar pacotes Debian e Docker simultaneamente, no entanto…

Meu instinto […] está me dizendo que, se os pacotes deb se encaixassem, seria mais comum

Esse é um problema correto que nos leva a nos perguntar por que o Docker se mostra popular como um sistema de empacotamento ad hoc , embora não pretenda ser um. (Veja acima.)

O sistema de empacotamento "oficial" de uma determinada distribuição é apenas uma possibilidade entre muitos outros de instalar software em algum ambiente de computação. Existem muitas outras fontes disponíveis, como gerenciadores de pacotes específicos da comunidade, como npm ou opam, árvores de portas como pkgsrc e distribuição simples de código-fonte. Nessa perspectiva, é fácil entender o sucesso do Docker como um sistema de empacotamento ad hoc :

• As especificações do Docker estão muito próximas de um script de shell e, independentemente da origem, instalamos o software usando o shell.

• O Docker possui um serviço " interno " (pago) para hospedar artefatos produzidos, o Docker Hub .

Agora, qual é a força dos pacotes Debian sobre as imagens do Docker como um sistema de pacotes? O controle rígido sobre as dependências na instalação. (A possibilidade de atualizar e fazer o downgrade também existe, mas não tem importância prática se estivermos implementando o padrão de servidor imutável .) Isso leva ao

Conclusão

Se você tiver apenas um único produto implantado em uma única versão (típica do SaaS), suas necessidades de gerenciamento de versões serão muito simples e o uso do Docker como um gerenciador de pacotes ad hoc não deve ter desvantagens. Assim que você trabalha com várias versões de um único produto ou vários produtos, a complexidade do problema de restrições de versão que você precisa resolver aumenta e você precisa de uma ferramenta apropriada para isso, que pode ser pacotes Debian ou algum sistema de gerenciamento de configuração, se você estiver software de mixagem de diferentes origens.

Sim, há desvantagens.

Com um pacote .deb, você não poderá ter duas versões do mesmo aplicativo no mesmo host. Você precisará confiar nos pacotes disponíveis de distribuição; se seu aplicativo depender de nodejs, por exemplo, você ficará preso à versão de distribuição ou precisará instalar o seu próprio.

Agora, quando você deseja hospedar vários aplicativos no mesmo host, estará atingindo um muro muito rapidamente quando eles dependerem da mesma coisa (vamos manter o nodejs aqui) em duas versões diferentes.

O principal objetivo do docker é isolar cada aplicativo do sistema de hospedagem e outros aplicativos no mesmo host. há duas razões para fazer esse isolamento: 1. evitar o comprometimento do aplicativo para poder assumir o controle do host ou impactar outro aplicativo 2. fornecer ao aplicativo suas dependências exatas e impedir que seja afetado por uma atualização do sistema ou outro aplicativo dependência.

Um pacote Debian (ou RedHat) para instalar aplicativos tem sido uma boa prática quando feito corretamente. Os pacotes são usados ​​com a finalidade de implantar aplicativos que são alterados com pouca frequência. Os pacotes Debian envolvem alguma sobrecarga, como gerenciamento de versões, gerenciamento de dependências, scripts de pré e pós-instalação, etc ...

Em muitos casos, a atualização de uma versão mais antiga para uma nova versão requer a escrita cuidadosa dos scripts, atenção aos detalhes na versão etc. Porque a modificação do estado existente é difícil. Seria muito mais fácil substituir o estado atual por um novo, sem alterar nada.

Depois de decidir substituir completamente sua configuração, dependências ou aplicativo em cada implantação, é mais fácil e menos propenso a erros. A maioria das organizações (costumava) mudar para uma nova instância de VM ou nuvem. O que significa que a instalação do pacote seria feita em um servidor "limpo" e a alteração dos arquivos e da configuração no servidor não é mais um problema.

Os desenvolvedores que criaram pacotes e não entenderam a falácia e a complexidade das mutações sofreram muitas dificuldades como resultado.

A substituição de VMs fica abaixo do ideal quando tudo o que você precisa é substituir um aplicativo, e é por isso que os contêineres leves foram introduzidos como resposta. Usando o Docker (ou outro LWC), você pode substituir a base de usuários, incluindo todas as dependências, sem substituir o próprio servidor. Você também pode hospedar várias versões do mesmo aplicativo, com dependências diferentes, no mesmo servidor e alternar apenas o tráfego de rede recebido na atualização. Além de alternar o tráfego de rede de volta à reversão (azul esverdeado), algo que foi notavelmente difícil no caso de gerenciar implantações por meio de pacotes.

Os contêineres apresentam uma maneira de agrupar todo o código do aplicativo, dependências e configuração em uma imagem. Essa imagem possui várias propriedades que a tornam muito melhor que os pacotes do sistema operacional tradicional. Por exemplo, ele possui tags que permitem o controle de versão, mas também possui camadas, que permitem economizar espaço. Ele permite uma maneira fácil de enviar essas imagens para servidores e ambientes de desenvolvimento, usando um registro. E essas imagens podem ser executadas como contêineres em qualquer ambiente e servidor, quase de forma idêntica. Isso inclui o laptop do desenvolvedor, bem como o ambiente de produção. Novamente, algo que era muito mais difícil de fazer com VMs e / ou com versões do software baseadas em pacotes. Testar a mesma imagem no laptop do desenvolvedor e manter os mesmos bits e bytes na produção remove muitos "

Falando especificamente sobre a parte de empacotamento de imagem do Docker, não o tempo de execução do contêiner, existem alguns bits menores. O maior é que uma imagem do Docker se parece mais com um chroot, o que significa que você é impedido de depender acidentalmente do estado do sistema compartilhado, pois todos os arquivos em uso devem ser explicitamente incluídos na imagem, enquanto um pacote do sistema pode pegar links dinâmicos que você não fez espere ou fique mais interligado com outros pacotes. Isso pode gerar dependências C complexas sendo carregadas sem o seu conhecimento, por exemplo, OpenSSL. Além disso, o uso de pacotes deb não desduplica os bits compartilhados no sistema de armazenamento do Docker, por exemplo. Para alguns, isso pode ser uma coisa boa, melhor desempenho de E / S e menos peças móveis, mas para outros, pode ser um problema.