Um dos conceitos do Docker é ter o mesmo ambiente - se você tem um ambiente diferente em produção do que o dev, então você não sabe que ele realmente funcionará com total certeza quando o aplicativo é movido para produção.
Do docker.com:
Eliminate Environment Inconsistencies
By packaging up the application with its configs and dependencies together and shipping as a container, the application will always work as designed locally, on another machine, in test or production. No more worries about having to install the same configs into a different environment.
Dito isto, é claro que produção e desenvolvimento terão diferenças, mas isso deve ser principalmente em termos de configuração de aplicativo - por exemplo, a instância de desenvolvimento não envia e-mails para os clientes, mas sim para uma caixa de correio fictícia etc. / p>
Eu não acho que seria a coisa certa a fazer para ter tanta diferença entre produção e desenvolvimento quanto o que você passa no seu post.
Quanto à diferença entre o dev e a configuração de produção (como o exemplo que eu dei acima), eu pessoalmente vejo duas formas viáveis de fazê-lo.
-
No Dev, um Dockerfile que sobrescreve certas configurações de uma base comum para produção e desenvolvimento.
-
Seu contêiner executa algo - inicia o httpd, etc. O script que inicia o processo primeiro puxa a configuração do Git ou de qualquer repositório, com base em uma variável de ambiente (por exemplo,
docker run ... -e RUNAS=PROD ...) - isso é o que eu faço . No meu caso, rodando um container para o Tomcat, os scripts de inicialização do Tomcat simplesmente baixam a versão war file baseada em uma variável de ambiente (por exemplo,-e VERSION=current) e extrai dos arquivos de configuração baseados em uma variável que define se é produção ou desenvolvimento. (-e RUNAS=DEV).