example - docker run java

Manera correcta de desplegar archivos WAR en imagen docker

Question

¿Cuál es la manera de desplegar proyectos java en un contenedor acoplable?

¿Copio la guerra en webapps?

FROM jetty:9.2.10
MAINTAINER Me "[email protected]"
ADD ./target/*.war /var/lib/jetty/webapps/ROOT.war

o tomo el archivo de guerra explotado:

FROM jetty:9.2.10
MAINTAINER Me "[email protected]"
ADD ./target/app-0.1.0.BUILD-SNAPSHOT /var/lib/jetty/webapps/ROOT

Normalmente, se implementaría el archivo war sellado si se tratara de un contenedor normal, pero con la ventana acoplable, eso significa presionar un archivo de 10-20MB cada vez que realice un pequeño cambio, mientras que agregar la guerra estallada solo empujaría la diferencia: el archivo .class ha cambiado.

¿Hay algún inconveniente en desplegar la guerra explotada en lugar del archivo de guerra?

Answer 1

Así es como lo hago:

FROM tomcat:8.0
MAINTAINER David Ford <[email protected]>
ENV DB_HOST mySqlServer
ENV DB_USER joeBlow
ENV DB_PASSWORD bla bla bla
EXPOSE 8080
RUN rm -fr /usr/local/tomcat/webapps/ROOT
COPY target/webapp /usr/local/tomcat/webapps/ROOT

En mi lista de tareas pendientes: separe el directorio WEB_INF / lib en su propio contenedor.

Answer 2

En realidad, SIEMPRE deberías implementar el .war explotado.

Hay dos elementos de velocidad para pensar aquí:

1. ¿Qué tan rápido es poder subir tu imagen a un repositorio de contenedores?

   y

2. ¿Qué tan rápido puede una nueva instancia de mi contenedor comenzar a servir solicitudes? (importante en un entorno de escalamiento elástico)

La respuesta para ambos es la misma: es mejor explotar el archivo .war al crear su contenedor y NO copiarlo en el archivo .war.

Esto tiene los siguientes dos efectos muy positivos:

1. Hace que las diferencias entre las versiones de contenedor sean mucho más pequeñas, por lo que su tiempo de carga es menor.
2. Esto significa que, al escalar dinámicamente para satisfacer la demanda de la aplicación, sus nuevas instancias de contenedor no tienen que descomprimir su archivo .war antes de que puedan comenzar a responder a las solicitudes.

Para aquellos de nosotros sobrecargados por las conexiones de carga lenta, también es una gran idea usar un servidor CI o incluso una máquina virtual alojada en la nube para construir y enviar sus imágenes de dockerhub u otro registro de contenedores. De esa manera usted puede aprovechar las velocidades de carga a escala gigabit.

Answer 3

Me pregunto cómo estás usando tus imágenes. Agregar un archivo de 20MB mientras se construye una imagen debería ser casi instantáneo. Puede que de alguna manera construya imágenes durante la implementación, como lo hace AWS cuando le da un archivo Docker.

En cualquier caso, creo que depende de cómo se está implementando. Si está moviendo las imágenes a su alrededor, no veo mucha diferencia entre AGREGAR un archivo .war y un directorio WAR explotado. Yo diría que haga lo que sea conveniente para usted. Sin embargo, si a veces ejecuta la aplicación desde Docker y otras veces desde un .war (que puede pasar por alto parte del punto de Docker), también puede utilizar el .war todo el tiempo.

Si está implementando en algo como AWS Elastic Beanstalk (algo que extrae la imagen de un repositorio), que quiere un archivo Dockerfile o Dockerrun.aws.json, entonces separar la imagen de lo que realmente implementa tiene sentido (o me ha dado sentido hasta ahora). Esto permite que el contenedor permanezca igual, mientras que la actualización de su aplicación puede estar simplemente copiando un archivo .jar / .war en la ubicación correcta (lo que también puede pasar por alto parte del punto de Docker;).

Lo que he estado haciendo es crear una imagen base en Docker Hub y luego usar el archivo Dockerrun.aws.json para mapear en mi aplicación. De esa manera, AWS no necesita construir mi imagen, solo tire de ella. Eso es mucho más rápido y menos costoso ($). Pero sí separa mi aplicación de la imagen, lo que podría complicar la implementación en algunas circunstancias. Sin embargo, debido a que mi imagen es muy estable, generalmente solo compilo un archivo .jar, un archivo Dockerrun.aws.json y un script de shell en un .zip y lo subo a AWS. Bastante fácil, creo.

Mi Dockerfile es bastante simple y realmente todo lo que necesito para mi aplicación Spring Boot:

FROM java:8
VOLUME /tmp
VOLUME /app
EXPOSE 8080
ENTRYPOINT ["sh","/app/app.sh"]

Podría hacer algo similar y usar la opción -v, etc., para asignar volúmenes a su aplicación, su configuración del entorno, etc. Por cierto, esta imagen está disponible en Docker Hub.

Answer 4

Puede intentar esto: Copie el archivo war en el contenedor utilizando COPY Copie el archivo jetty runner jar en el contenedor utilizando COPY y luego use el CMD para ejecutarlo de esta manera ["java -jar /path/to/jetty-runner.jar / ruta / a / app.war "]

http://www.eclipse.org/jetty/documentation/current/runner.html

NOTA: deberá tener java instalado en el contenedor.