Hola Tomas,
Algo asi… aunque no serian tus propias imagenes, sino que serian las imagenes de las aplicaciones.
Dicho de otra forma, la idea es que las aplicaciones/proyectos/modulos/comosellamen tengan su imagen docker de produccion y que para el desarrollo lo unico que se haga es montarle un volumen con el codigo y la instalacion de Toba realizada. La primera vez que arranca la imagen, haces la instalacion de Toba y la creacion del proyecto… luego de eso simplemente arrancas el contenedor y laburas.
Ese seria el workflow adecuado para el enfoque nuevo?
Basado en lo anterior, no reo que sume mucho que el framework tenga sus propias imagenes (con varios scripts extra de automatizacion), mas alla de la comodidad de uso si se quiere. Y la ofuscacion de todo lo que pasa detras va en detrimento del entendimiento de como funciona el mismo.
Si desarrollas en docker, lo logico seria que esa tecnologia se traslade al deploy tambien (via CI/CD) pero para eso no podes usar la imagen de Toba, sino que hay que construir una propia para la aplicacion completamente ajustada a su funcionamiento, sin cosas de mas instaladas.
Una vez tenes dicha imagen, tiene todo el sentido usarla para el desarrollo tambien y asi no tener 2 ambientes disjuntos o configurados de manera distinta.
Quizas simplemente migre dicho archivo a un esquema donde se use la imagen base del repo mencionado y modifique la documentacion para agregar un paso manual que instale composer y yarn, una vez tenes eso podes desarrollar tranquilamente y luego a partir de ahi generar el Dockerfile de la aplicacion y reemplazarlo como nueva base.
Fijate que mas alla del up inicial, una vez instalaste las cosas no hay mucho mas que el laburo diario (igual que en una VM o Host)… quizas lo mas extraño sea que arrancas creando una imagen propia (que solo es un FROM + build) y luego desarrollas con ella, pero te queda el camino allanado para llegar hasta el deploy y mayor automatizacion luego del commit.
Saludos