Play Framework – Transferencia de arguments de la aplicación a través de Docker Container

Antes de hacer docker mi aplicación web para jugar, pude hacer lo siguiente al ejecutar:

Joes-Macbook:project-1 joe$ sbt -Dconfig.env=dev run 

Donde puedo usar uno de los siguientes dev, qa, prod al argumento config.env y mi aplicación se ejecutará utilizando la correspondiente application.dev.conf o application.qa.conf en consecuencia.

Ahora tengo mi aplicación como contenedor acoplable, lo que significa que necesito una forma de inyectar mi file de configuration. ¿Cómo podría hacerlo?

Una forma de lo que estoy pensando es tener un script de shell y usarlo como el Entrypoint. Pero no estoy seguro de cómo podría funcionar esto? ¿Alguna sugerencia?

Entonces cuando lo hago

sbt docker: publishLocal

Obtengo el siguiente file Dockerfile

 FROM anapsix/alpine-java:8_server-jre_unlimited MAINTAINER Joesan <myemail@email.com> WORKDIR /opt/docker ADD opt /opt RUN ["chown", "-R", "daemon:daemon", "."] USER daemon ENTRYPOINT ["sh", "-c", "bin/project-1", "-Denv=$configEnv"] CMD [] ENV configEnv default 

No pude resolver $ configEnv en mi aplicación Scala. Así es como ejecuto la image del acoplador producido:

 docker run -e "configEnv=crap" --rm --name play-8080 -p 8080:9000 joesan/project-1:1.0-SNAPSHOT 

Puede establecer una variable de entorno cuando usa la docker run (o en la docker compose )

 docker run -e "deep=purple" ... 

Eso significa que su file Docker puede declarar esa misma variable como ENV y ser utilizado por su CMD pnetworkingeterminado.

 ENV configEnv CMD sbt -Dconfig.env=${configEnv} run 

Sin embargo, el OP está trabajando con sbt-native-packager , que genera un file Docker .
El Issue 861 muestra cómo agregar commands al Dockefile generado:

 dockerCommands ++= Seq ( // setting the run script executable ExecCmd("RUN", "chmod", "u+x", s"${(defaultLinuxInstallLocation in Docker).value}/bin/${executableScriptName.value}") ) 

Eso significa que puedes declarar ENV de esa manera.

Y el problema 927 muestra cómo anular el ENTRYPOINT pnetworkingeterminado:

 dockerEntrypoint := Seq("bin/my-app", "-Dconfig.resource=application-prod.conf") 

La combinación de los dos debería permitir implementar la solución que propuse anteriormente.


En realidad, después de la discusión , anular no es bueno, porque el Dcokerfile generado tendría ENTRYPOINT seguido de la statement ENV , lo cual no es bueno.

Solo al agregar tanto ENV como ENTRYPOINT , uno puede generar el Dockerfile correcto, como se ilustra con la chispa OP que se muestra a continuación.

Entonces, con la ayuda de VonC y algunos cambios en mi build.sbt, lo hice funcionar:

Esto es lo que tengo en mi build.sbt:

 dockerCommands ++= Seq( Cmd("ENV", "configEnv", "default"), // This will be overridden when running! // This is the entrypoint where we can run the application against different environments ExecCmd("ENTRYPOINT", "sh", "-c", "bin/" + s"${executableScriptName.value}" + " -Denv=$configEnv") ) 

Entonces cuando ejecuto mi command de docker:

 docker run -e "configEnv=test" --rm --name play-8080 -p 8080:9000 joesan/project-1:1.0-SNAPSHOT 

El application.test.conf apropiado se recoge, se carga y mi aplicación de reproducción se ejecuta en su contra.