@kj2 @tudmin Obrigado!! Acho que estou começando a entender, mas me parece que não é o que procuro, a não ser que eu esteja entendendo errado. Se para criar a imagem final eu tenho que listar os comandos executados, bibliotecas instaladas, etc.. para que ao instalá-la de novo ela replique esses passos, então muito provavelmente, daqui a X anos, se for preciso migrar (ou reinstalar) outra vez, não vai existir nem metade dos repositórios 🤣 Acho que vou pensar em fazer uma imagem completa virtualizada com tudo de ruim que isso implica....
Quanto a separar contêineres, acho que entendi. Cria-se um contêiner só de BD e assim, por mais apps / contêineres que você tenha, você só está rodando 1 servidor de bd (ou http), mas no meu caso, como o mysql também é do tempo do onça e usa apache com centenas de diretivas e regras, no fim eu seria obrigado a montar servidores exclusivos para este app que não posso aproveitar para outros apps...
é disso que se trata, os contêineres buscam ter exatamente o BUILD/COMPILADO daquele instante. olha, depois que faz todo esse BUILD, o docker armazena ou cria uma imagem DE uso , que é a usada, é como pegar sua máquina virtual, fazer um SNAPSHOT dela e usá-lo cada vez que seu server inicia / reinicia. mas se o seu server for formatado e você só tiver o arquivo docker, então toda a sua receita vai ser criada de novo do 0, para ter esse "SNAPSHOT". olha que a graça disso é que você pode subir para algum repositório. gratuito como Gitlab, ou no próprio "docker hub" (só permite 1 por conta de forma gratuita) . a questão dessas imagens/snapshots é que se daqui a 20 anos todos os LINKS de bibliotecas que você usou originalmente morrerem, e já não for possível replicar essa instalação em nenhum server novo, mas você tiver essa "imagem", então não precisa instalar nada, é só iniciar de onde estava ,
lembre-se de que as imagens só devem conter os executáveis, não os DADOS, como seus sites php, isso para evitar que cresça exageradamente.
agora outro ponto, isso de separar em vários contêineres, fragmentar os contêineres te dá certa liberdade de melhoria progressiva. imagine que você já tem todo o sistema com php5 e mysql. mas quer migrar para php 7.
pois como você tem seu mysql 5 em um contêiner, cria outro contêiner só com php7, mas que aponte para os DADOS do seu projeto atual. e assim você pode ver se algum projeto não quebra ou se não há mudanças significativas a fazer. quando chegar a esse ponto, aí você começa a mover.
agora com mysql é mais ou menos a mesma coisa, preparar um contêiner mysql-8 , e subir os DADOS , para ver se quebra. e se a compatibilidade quebrar, você pode tentar fazer um UPGRADE, faz uma cópia do seu contêiner com mysql5, entra nessa cópia-mysql5, e usa os arquivos de upgrade que o pessoal do mysql costuma fornecer e pronto, como resultado a DATA-cópia está pronta para mysql8, já em produção significaria parar todos os seus contêineres por algumas horas e fazer esse processo para que sua informação mais atual não seja afetada.
em resumo, o tema de contêineres é muito mais tranquilo do que fazer réplicas com vmware ou virtualbox. sem contar que o tamanho das imagens/snapshots resultantes é de centenas de megas em comparação aos snapshots do vmware, que são gigas
