Esta es una muy buena pregunta que describe un principio que he enfrentado varias veces, en realidad dos problemas separados pero relacionados:

1.) Cómo manejar mejor los archivos transitorios en Docker

Docker es excelente para encapsular la recreación total y absoluta de un entorno. Si maneja parte del proceso 'fuera' del contenedor, es decir, ejecuta la composer install fuera del proceso de compilación de la docker build , entonces tiene un proceso de compilación menos portátil porque es posible que haya introducido dependencias de máquina/entorno de las que no está al tanto.

Si siempre reconstruye el entorno completo dentro de Docker, está garantizando que sus dependencias siempre estén satisfechas y que podría darle el dockerfile a cualquier otra persona y ellos también tendrán una gran confianza de poder reconstruir localmente sin problemas.

¡Los archivos transitorios son ideales para construir dentro de Docker! Así que intentaría construirlos dentro del contenedor siempre que sea posible.

2.) Cómo desacoplar la autorización del proceso de compilación de Docker

Lo que nos lleva al segundo problema, ¿cómo desvincular la autorización de la compilación?

Opción 1 : Bake In composer auth.json con credenciales para un usuario de compilación dedicado:

Como han dicho otras respuestas, puede 'hornear' las credenciales y luego eliminarlas nuevamente. Sin embargo, no querría 'hornear' algo tan sensible como sus claves ssh. Composer admite un archivo auth.json , entonces, ¿por qué no crear un usuario de compilación dedicado y almacenar sus credenciales (en lugar de las suyas) en el archivo auth.json? Si alguna vez se ve comprometida, puede cambiar la contraseña. Una vez que la instalación del compositor haya terminado, elimine o sobrescriba el archivo.

 COPY . ./ RUN composer install --no-dev --no-interaction -o RUN rm -f ./auth.json

Opción 2 : haga que las credenciales sean transitorias y páselas al contenedor de Docker mediante docker exec:

No he probado completamente este enfoque, pero no puedo ver por qué algo como esto no funcionaría.

1.) Construye un contenedor PHP base que es capaz de ejecutar la 'instalación del compositor' (o usa uno de Docker Hub)

2.) Giras este contenedor base para que se ejecute

3.) Utiliza docker exec para pasar sus credenciales a un script de contenedor que ya está integrado en su contenedor. Los scripts de envoltura ejecutarán la instalación del compositor utilizando la autenticación básica HTTP; ya tendrá el nombre de usuario incorporado, por lo que solo deberá proporcionar la contraseña según la técnica básica de http.

 docker exec -d my_base_php_container php -f /my_wrapper_script.php ${PASSWORD}

4.) Confirmas este contenedor como una nueva imagen

 docker commit --change "composer install" ${CONTAINER_ID} my_installed_image:1.0

Gracioso. Solo unos días después de publicar esta pregunta, se lanzó Docker 17.05 y trajo una solución para eso: compilaciones de varias etapas . Simplemente coloque sus cosas de compositor dentro de su dockerfile y cree su aplicación. luego, inicie una segunda etapa y copie su aplicación como el artefacto de compilación de la primera etapa.

Creo que, en el caso que está describiendo, tiene sentido instalar el compositor fuera de la compilación de la ventana acoplable.

Normalmente tendría un proceso de compilación inicial que crea el código de su aplicación. Esta compilación podría ejecutar algunas pruebas automatizadas o de linting, y luego generar un artefacto que contenga todo el código necesario para ejecutar su aplicación. Esto comprendería su código fuente, más su carpeta de proveedor y cualquier código generado automáticamente (clases ORM, cachés, etc.). Estos artefactos suelen ser archivos tar.

Luego, copiaría ese artefacto de código en su contenedor de ventana acoplable en su compilación de ventana acoplable posterior.