Por que não usar a ferramenta de gerenciamento de configuração em vez do Dockerfile?

Sou bastante novo no Docker e nas ferramentas de gerenciamento de configuração.

No começo, comecei a escrever scripts bash para provisionar minhas caixas do Vagrant para minhas máquinas de desenvolvimento, mas agora mudei para o Chef, para que eu possa usar a mesma fonte para provisionar ambientes de desenvolvimento e produção e tentar obtê-los como semelhantes que possível.

Desde que comecei a usar o Chef, aproveitei o aspecto DRY de não ter que copiar e colar linhas de script do shell de projeto para projeto, a capacidade de provisionar máquinas executando uma variedade de distribuições linux usando uma fonte consolidada e a conveniência de usar livros de receitas fornecidos pela comunidade.

Agora que estou usando o Chef para provisionar minhas vm, parece que estou dando um passo atrás quando adiciono comandos RUN seguidos por comandos shell a um Dockerfile para alcançar o que poderia ser alcançado executando apenas uma receita do Chef.

Pesquisei no Google e não encontrei nada (mas talvez tenha perdido), mas parece que não há uma maneira fácil de usar as receitas do Chef para criar contêineres do Docker. Por que é que?

Entendo que os contêineres são imutáveis ​​e as ferramentas de gerenciamento de configuração são geralmente usadas para reconfigurar as máquinas durante toda a vida útil, mas elas ainda não oferecem muitos benefícios se usadas durante a construção inicial do contêiner?

A ferramenta necessária é o Packer, usando o Docker como o "construtor" e o Chef como o "provisionador". Em seguida, você pode adicionar a imagem resultante ao seu repositório e reutilizá-la sem precisar embalar novamente, até que suas receitas mudem.

Essas estratégias não têm nada a ver uma com a outra.

Contêineres (como o Docker) são uma metodologia para implantar e isolar aplicativos. Os contêineres são muito apreciados porque são transportáveis. Eles podem ser desenvolvidos e visualizados localmente na maioria dos casos, portanto, colocar aplicativos neles faz sentido.

Quanto ao motivo pelo qual o Docker usa scripts de shell : Uma imagem do docker é literalmente uma imagem do contêiner linux. É um sistema operacional linux e o objetivo desse contêiner é o mais leve e eficiente possível. Se você começou a adicionar Chef, Ruby, Erlang e todas as outras bibliotecas necessárias para ter o Chef como provisionador em um arquivo Docker, você eliminaria o ponto de usar contêineres.

O Gerenciamento de configuração é para provisionar um nó de computação. O estado final da configuração geralmente é refletido no código e possui um servidor central para manter o estado. Ferramentas como o vagrant permitem que você use o chef para configurar as máquinas Vagrant, em grande parte por conveniência para os desenvolvedores. Embora você possa usar a maioria dessas ferramentas em um modo somente local , a manutenção delas se torna bastante onerosa. Esses servidores centrais destinam-se a classificar automaticamente o controle de versão e o gerenciamento de dependências.

Bash não é inerentemente um passo atrás. Por exemplo, muitas organizações que constroem pipelines de imagens totalmente imutáveis criam suas imagens usando o Bash. Isso garante estabilidade e previsibilidade, além de um idioma comum entre os engenheiros (muitos engenheiros podem ter diferentes origens de gerenciamento de configurações).

Imutável vs Gerenciamento de configuração . A infraestrutura imutável não muda e deve ser totalmente substituída para ser atualizada. O Gerenciamento de configuração implica que o estado de uma máquina é mantido por um agente ou conexão externa (como no Ansible).

Os contêineres do Docker são inerentemente imutáveis. Você não persiste os dados neles e eles devem ser rolados para serem atualizados.