O Docker é adequado para o meu caso de uso?

Minha empresa possui um sistema que vendemos que consiste basicamente em um mini computador "Smartbox" que está executando o Ubuntu 12.04. Esta caixa executa um aplicativo Django, além de vários processos iniciantes diferentes relacionados a ele. Não há muito mais. Temos milhares dessas caixas no campo. Gerenciamos as dependências do pacote, o registro do processo etc. por meio de um pacote deb com diferentes graus de sucesso.

Precisamos de uma maneira eficiente e robusta de enviar atualizações para nossos usuários no campo. Também precisamos de algo que, à medida que atualizamos o sistema operacional (estamos muito atrasados ​​para uma atualização do Ubuntu, como você pode ver), podemos nos sentir relativamente seguros sobre nossos pacotes "apenas funcionando".

Não sei muito sobre o Docker, mas quando soube do nosso problema (sou um novo contratado), Docker foi meu primeiro pensamento. Mas quanto mais eu pensava sobre isso, talvez não fosse, já que essas caixas são nossas, controlamos o sistema operacional, o que é uma grande parte da proposta de valor do Docker, pelo que entendi. Portanto, se SABEMOS que nossas caixas sempre serão o Ubuntu e basicamente temos apenas um aplicativo Django mais alguns processos para executar, o Docker é melhor do que um pacote deb?

TL; DR: pacotes Docker vs deb para um dispositivo distribuído que sempre executará o Ubuntu, portanto a independência da plataforma não é tão importante.

Não estou 100% certo de que entendi da pergunta, mas parece que a solução Docker seria deixar de ter um dispositivo (físico?) Com um sistema operacional e seu aplicativo instalado nele, ter um dispositivo com sistema operacional e Docker, executando um único contêiner com seu aplicativo. Isso não elimina a necessidade de atualizar o sistema operacional no host e adiciona uma camada de complexidade (e mais atualizações a serem enfrentadas, pois agora você terá que manter o Docker e o SO corrigidos) sem nenhum benefício aparente no que diz respeito às áreas específicas mencionadas na pergunta.

No entanto, se você está pensando em ir de um dispositivo virtual para um contêiner do Docker, isso pode potencialmente facilitar as coisas para você, mas também adiciona o Docker como uma dependência do seu produto; você está excluindo quem não está usando o Docker e não deseja adicioná-lo à pilha deles apenas para usar seu produto. Você pode continuar dando suporte àqueles que não usam / não usarão o Docker, continuando a enviar o dispositivo virtual (agora "herdado") como antes, mas agora apenas dobrou sua carga de trabalho porque possui duas distribuições para oferecer suporte, em vez de 1.

Eu trabalho com o Docker há muito tempo. A independência da plataforma é boa, mas não é o que considero mais útil no Docker.

Em primeiro lugar, você obtém repetibilidade. Você pode criar um Dockerfile, depurar em um contêiner na máquina do desenvolvedor, executar testes em um servidor de integração contínuo e, em seguida, no seu produto final, e sabe que ele se comportará da mesma maneira em todos esses ambientes. Não há como esquecer uma dependência que um desenvolvedor instalou em sua máquina. Além disso, seus desenvolvedores não precisam usar o Ubuntu em suas mesas. Importante para nos manter felizes usuários do Arch Linux :-)

Segundo, para o seu cenário de atualização, você pode ter várias versões puxadas para uma máquina ao mesmo tempo. Se você faz um docker pull myapp:2.0tempo em 1.0execução, pode trocar para 2.0extremamente rapidamente. Muito mais rápido do que normalmente seria necessário fazer uma atualização completa do sistema operacional. Se você usar um orquestrador com várias instâncias de microsserviços, poderá fazer atualizações contínuas que não interrompem o serviço.

Se você usar um modelo de microsserviços, o Docker também fornecerá caixas de proteção que podem limitar a quantidade de danos que os invasores podem causar no caso de uma exploração. Em vez de ganhar controle sobre uma máquina inteira, eles estão apenas ganhando controle sobre um contêiner.

A principal desvantagem é que você precisa do sistema operacional host e de algum tipo de orquestração. Existem muitas opções para isso, mas não subestime a quantidade de trabalho necessário para avaliar um, colocá-lo em prática e mantê-lo.

Embora exista uma pequena região sobreposta, o Docker e os sistemas de empacotamento Debian resolvem essencialmente dois problemas muito diferentes :

• O sistema de empacotamento Debian foi criado para instalar o software em um host e atualizá-lo da maneira mais fácil possível. Ele é capaz de lidar com padrões complexos de dependência e restrição entre componentes de software, como “o software X versão A requer o software Y com a versão B ou mais recente instalado” ou “o software X nunca deve ser instalado com o software Z versão C”.

• O sistema Docker foi concebido para descrever e implantar facilmente serviços, especialmente microsserviços, possivelmente em vários hosts - por exemplo, um enxame Docker ou um cluster Kubernetes.

Esses dois problemas são essencialmente ortogonais, o que significa que, dado o problema de implantação a ser resolvido, é possível usar um deles, ambos, ou talvez nenhum deles, como parte da solução. Ao usar os dois, o pacote Debian é usado na produção da imagem do Docker, e seu Dockerfile (as receitas usadas para preparar a imagem do Docker descrevendo o “sistema virtualizado” executado em um contêiner) basicamente registraria seu repositório Debian no diretório fontes do sistema de empacotamento Debian e instale seu pacote.

Com isso em mente, parece-me que o que você realmente está procurando é implementar o padrão de servidor imutável. O recente desenvolvimento das tecnologias em nuvem tornou possível atualizar o software, não usando o sistema clássico de atualização de software de um sistema de pacotes de software (como o sistema de empacotamento Debian), mas simplesmente substituindo o servidor completo de uma só vez. (Algumas pessoas fizeram isso antes deste desenvolvimento, tendo três SOs em um servidor, dois usados ​​alternadamente para executar o dispositivo e um mini-SO dedicado à execução da substituição do dispositivo. Embora não seja excessivamente complexo, isso parece ter permanecido sempre um nicho.) Essa técnica pode ser interessante para você, porque se você é usado para atualizar o software em seu servidor usando o gerenciador de pacotes, o estado final do servidor depende do "histórico de atualização" do servidor - especialmente se ocorrerem erros no processo de atualização. Essa heterogeneidade é ruim,

Temos milhares dessas caixas no campo. Gerenciamos as dependências do pacote, o registro do processo etc. por meio de um pacote deb com diferentes graus de sucesso.

poderia se relacionar com isso. O padrão imutável do servidor limpa essa fonte de erros, basicamente destruindo a noção de "histórico de atualização" do problema.

Agora, existem várias opções para implementar o padrão imutável do servidor, duas opções populares são usar imagens, imagens do Docker ou usar "imagens de instância principal" do seu provedor de nuvem (chamadas AMIs na AWS e apenas imagens personalizadas no Google Compute Engine) . Seu caso de uso proíbe o uso de técnicas baseadas em nuvem; portanto, assumirei as imagens do Docker como a única opção qualificada. (Para fins de conclusão, certamente é possível usar outras abordagens, por exemplo, usando o Virtual Box ou uma solução de virtualização semelhante, como uma alternativa ao Docker.)

Ao usar a técnica de padrão de servidor imutável, você apresenta um novo artefato (a imagem do Docker) representando seu servidor e esse artefato também pode ser testado, e é muito fácil obter uma configuração replicando com sinceridade suas configurações de produção - além da carga de serviço.

Agora, para considerar o problema concreto que você descreveu, vamos assumir que a implementação do padrão imutável do servidor com o Docker é realmente o que você deseja. Como o sistema Docker e o sistema de empacotamento Debian são complementares e não mutuamente exclusivos (cf. introdução), ainda temos que resolver a questão se você deve preparar um pacote Debian para o seu software.

A pertinência de usar um pacote Debian para instalar seu software (na imagem do Docker ou em um host) está na complexidade do problema de versão que você precisa resolver. Se você executa ao mesmo tempo várias versões do seu software, ocasionalmente precisa fazer o downgrade e possui requisitos de versão complexos que você precisa documentar cuidadosamente, ter um pacote Debian é obrigatório. Caso contrário, essa etapa poderá ser ignorada - mas como você já se esforçou para produzir e implantar esses pacotes, não há valor real em abandonar seu trabalho. Eu sugeriria, portanto, continuar produzindo seus pacotes Debian.

O Docker me parece razoável, pois você pode fazer e testar alterações no contêiner internamente e, dependendo do processo de liberação, reinicie os contêineres sempre puxando: mais recentes ou algo semelhante que proporcionaria uma atualização testada.

As considerações com as quais você precisa lidar incluem o armazenamento de dados, pois os contêineres não retêm alterações na reinicialização; portanto, você deseja um volume de dados. Provavelmente há muito mais considerações que você teria assim que se aprofundar nela. O sistema com o qual estou trabalhando atualmente (todos baseados no docker) está em desenvolvimento há mais de um ano e ainda estamos encontrando áreas nas quais precisamos fazer alterações no contêiner, nas configurações etc.

Em geral, o docker oferece muitas vantagens para desenvolvedores e pessoal de operações. Uso o docker para alguns dos meus aplicativos e considero uma abordagem muito confiável e robusta.

Meu problema com a adoção do docker é que eu não ouço você fazer as perguntas certas e você pode tornar sua vida mais complicada sem abordar os requisitos mais importantes.

A primeira pergunta que você deve fazer (você disse que era nova) é como as atualizações do SO e do aplicativo são tratadas agora? A metodologia atual funciona para você (sua empresa)? O que funciona bem? O que poderia ser melhorado? Você pode fazer uma auditoria de configuração física em suas máquinas de destino no campo para verificar se elas possuem os patches, aplicativos e SO corretos, ou se houve alguma alteração não autorizada.

Adoro o docker, mas não pularia na onda do docker sem antes avaliar onde você está agora, incluindo o que funciona bem e o que precisa ser aprimorado.

Eu acho que poderia ser uma boa opção (mais testes são necessários)

Você pode fornecer uma URL com todas as tags / versão do contêiner criado e os clientes lerão essa URL para ver se há uma nova versão do contêiner.

Você pode armazenar arquivos / configurações pessoais no local e nunca perderá essas informações em atualizações e garantirá que o que você fez e testou funcionará para todos da mesma maneira.

Até você pode dar aos usuários a possibilidade de escolher qual versão do disponível eles desejam usar (se você quiser dar essa possibilidade).

Será como "" atualizar apenas um pacote "", falando apenas sobre recuperar uma nova versão do container, muito melhor do que lidar com pacotes debian;)