Devo dividir um aplicativo em vários contêineres Docker vinculados ou combiná-los em um só?

Question

Antecedentes

Atualmente, estou trabalhando na criação de um aplicativo que desejo implantar em contêineres do Docker.

Os contêineres serão executados em um servidor meu. Eu quero ter a capacidade de executar outros aplicativos no mesmo servidor sem inchar a quantidade de imagens do Docker que são executadas.

As diferentes partes / contêineres a partir de agora são:

• Nginx (proxy reverso, recursos estáticos)
• Nó (frontend do aplicativo)
• Nó (back-end / API do aplicativo)
• Mongo (banco de dados)

Pensamentos

A idéia geral que tenho é que cada parte distinta deve ser executada como um contêiner. Minha preocupação é que, se eu executasse outro aplicativo na mesma máquina, acabaria inchando-o com uma quantidade indevassável de imagens vinculadas.

Isso pode ser resolvido fazendo uma imagem para cada aplicativo. De modo que os serviços acima mencionados farão parte de uma imagem. Isso está em conflito com a segurança geral ou a finalidade do Docker?

Esclarecimento

O fato de ter vários serviços em uma imagem do Docker está em conflito com o propósito do Docker?

Os benefícios gerais de segurança dos contêineres serão removidos ao executar os serviços de uma imagem?

    

Answer 1

O próprio Docker deixa isso claro: é esperado que você execute um único processo por contêiner .

Mas, suas ferramentas para lidar com contêineres vinculados deixam muito a desejar. Eles oferecem docker-compose (que costumava ser conhecido como figo), mas os meus desenvolvedores relatam que é mimado e, ocasionalmente, perde o controle de contêineres vinculados. Ele também não escala bem e é realmente adequado apenas para projetos muito pequenos.

Agora, acho que a melhor solução disponível é o Kubernetes , um projeto do Google. O Kubernetes também é a base da versão mais recente da Openshift Origin , uma plataforma de PaaS, bem como do Google Container Engine, e provavelmente de outras agora. Se você estiver usando o Kubernetes, poderá implementá-lo facilmente.

    

Answer 2

O Docker deixa claro que eles acreditam que um processo por contêiner é o caminho "certo", mas nunca dão justificativa. Minha resposta é, depende. Neste caso em particular, eu iria separá-los e gerenciar com o Kubernetes ou o OpenShift, porque isso é trivial e lhe dará a capacidade de dimensionar cada parte do seu aplicativo de forma independente.

Eu não diria que é uma regra que você precisa dividir seu aplicativo. Os contêineres em execução são essencialmente a chamada de sistema clone (), cgroups e selinux, o que significa que você pode executar absolutamente mais de um processo por contêiner. Docker, LXC, caseiro, realmente não importa quando estão rodando. O LXC incentiva múltiplos processos por contêineres, então eu diria que "um processo por contêiner" é filosofia não engenharia

link