@kj2 @tudmin Gracias!! Creo que lo voy pillando pero me parece que no es lo que busco a no ser que lo esté entendiendo mal. Si para crear la imagen final debo de enumerar los comandos ejecutados, librerias instaladas, etc.. para que al instalarla de nuevo replique dichos pasos, entonces muy seguramente, para dentro de X años si se requiere migrar (o reinstalar) otra vez, no existan ni la mitad de repositorios 🤣 Creo que me voy a plantear hacer una imagen completa virtualizada con todo lo malo que eso conlleva....
Respecto a separar contenedores, creo que lo entiendo. Se crea un contenedor sólo de BD y así por muchas apps / contenedores que tengas, sólo estás corriendo 1 servidor de bd (o http) pero en mi caso, como mysql es tambíen del año catapum y utiliza apache con cientos de directrices y reglas, al final me obligaría a montar servidores exclusivos para esta app que no puedo aprovechar para otras apps...
de eso se trata los contenedores tratan de tener exactamente el BUILD/COMPILADO de ese instante. ojo, una vez que hace todo ese BUILD, docker lo almacena o crea una imagen DE uso , el cual es el usado es como agarrar tu maquina virtual, hacerle un SNAPSHOT y usarlo cada vez que se inicie / reinicie tu server. pero si tu server es formateado y tienes solo el archivo docker, entonces toda tu receta se creara de nuevo desde 0, para tener ese "SNAPSHOT" ojo que la gracia de esto es que lo puedes subir a algun repositorio. gratuito como Gitlab, o en el mismo "docker hub" (solo te permite 1 por cuenta de forma gratuita) . el tema de esto de las Imagenes/snapshot es que si de aqui a 20 años, todos los LINKS de librerias, que usaste originalmente mueren, y ya no se puede replicar esa instalacion en ningun server nuevo, pero cuentas con esa "imagen" entonces no necesitas instalar nada, solo es iniciar donde estaba ,
recuerda que las imagenes solo deben contener los ejecutables no la DATA, como tus sitios php, eso para evitar que cresca exageradamente.
ahora otro punto lo de separar en varios contenedores, el fragmentar los contenedores te da cierta libertad de mejora progresiva. imagina que ya tienes todo sistema con php5 y mysql. pero quiers migrar a php 7.
pues como tienes en un contenedor tu mysql 5, creas otro contenedor solo con php7, pero que apunte a la DATA de tu proyecto actual. y asi puedes ver si algun proyecto no se rompe o no hay cambios significativos que hacer. una vez llegues a ese punto ya empiezas a mover.
ahora con mysql mas o menos es lo mismo, preparar un contendor mysql-8 , y subes la DATA , para ver si se rompe. y si se rompe la copatiblidad puedes probar hacer un UPGRADE, te haces una copia de tu contenedor con mysql5 entrars a esa copia-mysql5, y usas tus archivos de upgrade que suelen brindar los de mysql y listo como resultado la DATA-copia esta lista para mysql8, ya en produccion significaria que detengas todos tus contenedores por unas horas y hagas ese proceso para que tu informacion mas actual no se vea afectada.
en resumen el tema de contenedores es mucho msa llevadero que hacer replicas con vmware o virtualbox. sin contar que el tamaños de las imagenes/snapshot resultantes son cientos de megas en coparacion a snapshot de vmware que son gigas
