Compile, empaquete e implemente proyectos Spring Boot en Dockerfile

1、Archivo Docker

1.1 ¿Qué es Dockerfile?

        Dockerfile es un archivo de configuración que crea automáticamente una imagen de Docker. El proceso de creación de la imagen se define en Dockerfile a través de instrucciones. Con la línea de comando de Docker Build, se puede lograr la creación automatizada de imágenes de Docker.

1.2 Análisis de sintaxis de Dockerfile

        Cuando aprendemos un idioma o la gramática de un documento, la forma más rápida de aprender es ver cómo lo escriben los demás. Quién es este "otro" aquí es muy importante: cuanto más juegas al ajedrez con la apestosa canasta de ajedrez, más apestoso te vuelves.

        Por lo tanto, para aprender la sintaxis de Dockerfile, necesitamos encontrar un modelo: puede ir a Dockerhub para ver las imágenes proporcionadas oficialmente por el software de código abierto, y puede encontrar el Dockerfile correspondiente y ver cómo otros lo escriben. Tomemos el Dockerfile de la imagen acoplable de la versión nginx:1.20.2 mencionada anteriormente (proporcionada oficialmente) y analicemos su sintaxis y proceso de construcción línea por línea. Los scripts involucrados en este artículo se pueden obtener en el canal oficial de github:docker-nginx.

1.3 Comando Dockerfile

DE

        Generalmente, cuando construimos una imagen, necesitamos una imagen de versión básica del sistema operativo Linux y, sobre esta base, construimos nuestra propia imagen.
        Por lo tanto, la función de la instrucción FROM es especificar la imagen base. La imagen base de Linux utilizada por nginx aquí es debian:bullseye-slim. Entre ellos, debian:bullseye es una versión del sistema operativo de distribución Linux de Debian y el nombre de la versión es bullseye. Slim generalmente significa que esta imagen es la versión de instalación más pequeña en la versión de lanzamiento. Debido a que la imagen que construimos se propagará en el proceso de integración continua posterior y la red entre el almacén y el servidor Docker, debemos construir la imagen como lo más fácil posible El tamaño del resultado se minimiza. "A la hora de elegir una imagen base, debes centrarte en el tamaño. Cuanto más pequeña sea la imagen, mejor si cumple con las funciones básicas de Linux y la ejecución de tu programa " .

FROM debian:bullseye-slim

ETIQUETA

        LABEL se utiliza para agregar alguna descripción e información explicativa a la imagen actual , como el mantenedor y la información de contacto de la imagen actual. Utilice pares clave-valor para personalizar y podrá definir varios en una línea.

LABEL <key>=<value> <key>=<value> <key>=<value> ...

mantenedor, descripción

        También puede definir varias líneas, como información del mantenedor e información de descripción de la imagen de descripción. Si la información de descripción no se puede escribir en una línea, puede utilizar "\" para dividir la línea.

LABEL maintainer="NGINX Docker Maintainers "
LABEL description="This is a Docker image \
for nginx 1.20.2. "

        Hay una instrucción en la sintaxis de Dockerfile llamada MAINTAINER, que se usa para describir la información del mantenedor de la imagen, sin embargo, ya no se recomienda usarla, LABEL se usa de manera uniforme.

ENV

        La función de ENV es establecer variables de entorno. Una vez configuradas las variables de entorno, se pueden utilizar en scripts de shell.

        El método de uso es: ${NGINX_VERSION}. Estudiantes que han estudiado JAVA, ¿piensan en cómo configuran y utilizan su variable de entorno JAVA_HOME? ENV es lo mismo. Es solo que la sintaxis ha cambiado cuando se coloca en la ventana acoplable. El formato de sintaxis es: ENV variable de entorno KEY variable de entorno Valor.

ENV NGINX_VERSION 1.20.2
ENV NJS_VERSION 0.7.0
ENV PKG_RELEASE 1~bullseye

CORRER

        La función de la instrucción RUN es ejecutar el script de shell de Linux. Como puede ver en la figura siguiente, las variables de entorno definidas por ENV se pueden usar en el script de shell.
        Para imágenes de nginx, la función del comando RUN es ejecutar una serie de líneas de comando de shell (scripts) para completar la instalación de nginx. Por lo tanto, la clave para dominar la instrucción RUN no es la instrucción RUN en sí, la clave radica en:

• ¿Sabes cómo instalar nginx manualmente?
• ¿Conoce la sintaxis del script de shell de Linux?
• ¿Puedes escribir el proceso de instalación de nginx como un script de shell?

        Si las respuestas a las tres preguntas anteriores son afirmativas, utilice el comando EJECUTAR para ejecutar el script de shell para completar la instalación del software. Este es también el núcleo del contenido escrito de Dockerfile. El shell de Linux no es lo que le explicará este artículo.

COPIAR

        La función de la instrucción COPY es copiar el archivo local (el servidor donde se realiza la construcción de la imagen) al archivo de imagen.

        La sintaxis es: COPY <ruta del archivo local>:<ruta del archivo de imagen> La ruta del archivo de imagen también es la ruta del sistema de archivos cuando el contenedor se está ejecutando.

COPY docker-entrypoint.sh /
COPY 10-listen-on-ipv6-by-default.sh /docker-entrypoint.d
COPY 20-envsubst-on-templates.sh /docker-entrypoint.d
COPY 30-tune-worker-processes.sh /docker-entrypoint.d

        Si la ruta del archivo local solo tiene el nombre del archivo, significa que el archivo y el Dockerfile están en el mismo directorio (sintaxis de ruta relativa). Es decir: los siguientes archivos están en el mismo directorio y estos archivos se pueden ver en la conexión Dockerfile oficial de nginx que proporcioné anteriormente.

        Nota: Si <ruta del archivo local> es un directorio, solo los archivos dentro del directorio se copian en la imagen, no el directorio.

DIRTRABAJO

        Además, puede utilizar la directiva WORKDIR para configurar el directorio de trabajo local para cualquier instrucción RUN, CMD, ENTRYPOINT, COPY y ADD que le siguen en el Dockerfile.

        De esta manera, la ruta relativa mencionada anteriormente es la ruta relativa a la ruta especificada por WORKDIR. "Pero, en general, no se recomienda utilizar WORKDIR porque es difícil garantizar que la ruta de trabajo del host de trabajo del desarrollador que ejecuta la compilación y la ruta de trabajo del escritor Dockerfile sean consistentes".

WORKDIR  /root

EXPONER

Los contenedores Docker exponen puertos de red específicos cuando se ejecutan, que se pueden usar para el mapeo de puertos del contenedor. El protocolo predeterminado es TCP. El formato es el siguiente:

EXPOSE <端口号>
EXPOSE <端口号>/<协议>

        Una vez expuesto el puerto del contenedor, se puede establecer una relación de mapeo con el puerto del host, de modo que se pueda acceder a los servicios dentro del contenedor accediendo al puerto del host. Por ejemplo, el puerto 80 del contenedor está expuesto en TCP y UDP al mismo tiempo.

EXPOSE 80/tcp
EXPOSE 80/udp

SEÑAL DE PARADA

        Este comando no es comúnmente utilizado por el autor. Revisé los problemas de docker-nginx en github y la respuesta es que el propósito de agregar la señal STOPSIGNAL es evitar el proceso zombie causado por el servicio nginx que no finaliza correctamente después de la ventana acoplable. El contenedor está detenido La presencia.

STOPSIGNAL SIGQUIT

CMD

        La instrucción CMD también se utiliza para ejecutar comandos o scripts de Linux, lo cual es coherente con la instrucción RUN. La diferencia entre los dos es:

1. El comando RUN se ejecuta cuando se construye la imagen, es decir, cuando se construye Docker .
2. La instrucción CMD se ejecuta cuando se ejecuta la instrucción docker run, es decir, cuando se crea el contenedor ;

        Precisamente porque los períodos de ejecución de las instrucciones son diferentes, las operaciones de escritura ejecutadas por el nombre RUN se escriben en la capa espejo. El resultado de la ejecución de la instrucción CMD incluye una operación de escritura y se escribe en la capa contenedora. (Puede consultar mi artículo anterior "Principio de capas de espejos" para aprender y comprender).
        Entonces, las instrucciones CMD y ENTRYPOINT son algo similares, ambas se ejecutan al crear un contenedor.

        Lo que hay que tener en cuenta es: "Una vez que la instrucción ENTRYPOINT se incluye en el Dockerfile, la instrucción CMD existe como un parámetro del script especificado por ENTRYPOINT".

Consulte la sintaxis del formato a continuación.

CMD contiene tres formatos:

• La primera es pasar parámetros al script especificado por ENTRYPOINT. El ejecutivo "$@" en la última línea del script ENTRYPOINT anterior está ejecutando el comando y los parámetros pasados ​​por CMD. Para completar el inicio del servicio nginx. ** Este uso es comúnmente utilizado por Dockerfiles oficiales (como: nginx, redis) **, que consiste en realizar un trabajo de preparación de configuración en el script especificado por ENTRYPOINT y luego llamar a CMD a través del exec "$@" en la última línea. del comando de script ENTRYPOINT para iniciar el servicio de contenedor.

CMD ["nginx", "-g", "daemon off;"]

• El segundo método consiste en ejecutar un comando o un script de shell y puede pasar parámetros. Tenga en cuenta las comillas dobles. La sintaxis es la misma que la del primer formato, excepto que no hay ningún script especificado por ENTRYPOINT, por lo que no existe como parámetro del script especificado por ENTRYPOINT.

CMD ["ejecutable","param1","param2"]

• El tercer tipo es la sintaxis común para ejecutar scripts de shell, como ejecutar echo "Esto es una prueba" | wc -cshell línea de comando. El autor dijo: "No utilice este método en Dockerfile, no es necesario saber por qué".

CMD echo "Esto es una prueba". | baño -c
 

PUNTO DE ENTRADA

        Si se definen varios ENTRYPOINT en un Dockerfile, solo tendrá efecto el último ENTRYPOINT y cada vez que se inicie el contenedor acoplable, se ejecutará el script especificado por ENTRYPOINT.

        Para nginx:1.20.2, el script "/docker-entrypoint.sh" define la verificación de la configuración de nginx y las instrucciones de inicio del servicio nginx. Por lo general, "el script especificado por ENTRYPOINT suele ser el script de inicio del servicio principal en la imagen".

ENTRYPOINT ["/docker-entrypoint.sh"]

        Este script finalmente ejecuta el inicio del servicio nginx, que debe completarse con el comando CMD. Consulte el comando CMD a continuación.

1.4 operación de la ventana acoplable

Para obtener más información, consulte: Comandos de operación básica de 3-Docker · Operación y mantenimiento de Linux · Kanyun

1. Generar imagen

# ventana acoplable build -t springboot-docker.
# docker build -f ./Dockerfile -t springboot-docker.
# docker build -f ./Dockerfile -t springboot-docker:0.1.

[root@ip-100 dockerfile]# imágenes acoplables ETIQUETA
DEL REPOSITORIO ID DE IMAGEN TAMAÑO CREADO
springboot-docker 0.1 54dcc83613d7 Hace aproximadamente un minuto 682 MB
springboot-docker último 54dcc83613d7 Hace aproximadamente un minuto 682 MB

# Nota:
# 1. El comando se ejecuta en el directorio donde se encuentra el Dockerfile
# 2. Asegúrese de no olvidar lo siguiente: Springboot-docker aquí es el nombre real de la imagen generada.

• --tag -t: el nombre y la etiqueta de la imagen, generalmente en formato nombre:etiqueta o nombre; se pueden configurar varias etiquetas para una imagen en una compilación.
• -f: especifica la ruta del Dockerfile que se utilizará

Referencia: https://www.runoob.com/docker/docker-build-command.html

2. Ejecute la imagen

• -d: indica que el contenedor se está ejecutando en segundo plano.
• --name: le da un nombre al contenedor
• -p: mapeo de puertos, el formato es puerto de host: puerto del contenedor, el significado anterior es asignar el puerto 80 en el contenedor al puerto 80 del host para proporcionar servicios de acceso externo.

El último campo es el nombre de la imagen.

# ejecución de ventana acoplable --nombre springboot-docker01 -d -p 8080:8080 springboot-docker

[root@ip-100 dockerfile]# docker ps 
ID DEL CONTENEDOR IMAGEN COMANDO ESTADO CREADO PUERTOS NOMBRES
65bb62a54e55 springboot-docker "java -Djava.securit..." Hace 33 segundos Subir 31 segundos 0.0.0.0:8080->8080/tcp, :: :8080->8080/tcp springboot-docker01

Navegador de host: http://192.168.192.128:8080/getIpAndPort

3. Ver el registro de inicio

registros de la ventana acoplable xxx
registros de la ventana acoplable -f springboot-docker01

2. Construcción de varias etapas de Dockerfile

2.1 Ejemplo 1 de uso de Dockerfile

FROM openjdk:8-jdk-alpine as build
WORKDIR /workspace/app

COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src

RUN ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)

FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]

2.2 Ejemplo 2 del uso de Dockerfile

Cree un Dockerfile en el directorio raíz del proyecto:

# 拉取编译环境
FROM maven:3.6.1 as builder

#拷贝源码到固定的目录，注意前面有个 '.'
COPY . /project

# 切换到源码目录
WORKDIR /project

# 使用maven进行编译
RUN mvn clean package -Dmaven.test.skip=true

# 拉取运行环境，这个镜像打包出的镜像比较小，如需要可换成oracle的jre
FROM fabric8/java-alpine-openjdk8-jre

# 从编译好的镜像中将jar拷贝到运行时容器
COPY --from=builder /project/target/your-jar-name.jar /

# 容器启动时执行的命令，这里可加jvm参数
ENTRYPOINT ["java","-jar","/mqtt-rule-engine.jar"]

# 开放端口，根据自己的配置进行开放
EXPOSE 8080

2.3 Ejemplo 3 de uso de Dockerfile

# First stage: complete build environment
FROM maven:3.5.0-jdk-8-alpine AS builder

# add pom.xml and source code
ADD ./pom.xml pom.xml
ADD ./src src/

# package jar
RUN mvn clean package

# Second stage: minimal runtime environment
From openjdk:8-jre-alpine

# copy jar from the first stage
COPY --from=builder target/my-app-1.0-SNAPSHOT.jar my-app-1.0-SNAPSHOT.jar

EXPOSE 8080

CMD ["java", "-jar", "my-app-1.0-SNAPSHOT.jar"]

FROM maven:3.6.3-openjdk-8 AS builder
 #  AS builder 起别名

RUN mkdir /build
# 创建临时文件

ADD src /build/src
#将 src目录复制到临时目录

ADD pom.xml /build
# 将 pom文件复制到临时目录

RUN cd /build && mvn -B -ntp package
# 打包

FROM adoptopenjdk/openjdk8:alpine-jre
# 获取jre

COPY --from=builder /build/target/ems-0.0.1-SNAPSHOT.jar /ems.jar
#从标记点 拷贝jar包 并改名

CMD ["java", "-jar", "/ems.jar"]

# 声明运行方式

 Ejecute el siguiente comando en el directorio raíz del proyecto

Docker build -t nombre: etiqueta.
 

3. Embalaje enchufable

3.1 Empaquetado del complemento spring-boot-maven-plugin

SpringBoot tiene su propia herramienta de empaquetado de imágenes incorporada Docker, por lo que spring-boot-starter-parentno necesitamos configuraciones adicionales. Ventajas: No es necesario escribir DockerFiley no hay necesidad de preocuparse por la seguridad, la memoria, el rendimiento y otros problemas recomendados por Spring.

3.2 Complemento jib-maven-plugin

GoogleUn complemento empaquetado de . DockerVentajas: No se requiere instalación ni escritura local DockerFiley Jibse puede enviar directamente al Dockeralmacén especificado.

3.3 Complemento dockerfle-maven-plugin

Necesita estar escrito DockerFiley necesita un entorno local Docker, pero es el más útil, estable y libremente controlable. Ventajas: Estable, no sujeto a restricciones de red, DockerFile lo escribe uno mismo y tiene un alto grado de libertad. Puedes cambiarlo como quieras. Personalmente lo recomiendo.

Empaquetado de complementos, para ejemplos específicos, consulte: Varias formas de empaquetar (construir) proyectos Java (SpringBoot) en imágenes de Docker - Comunidad de desarrolladores de Tencent Cloud - Tencent Cloud

4, referencia:

docker compila Dockerfile para implementar automáticamente el paquete jar del proyecto springboot_dockerfile compila el paquete jar_blog-CSDN de blog de xixiyuguang

La última construcción de varias etapas de dockerfile en 2021 implementa la compilación del código fuente de Java, el paquete jar y la duplicación - Alibaba Cloud Developer Community

Varias formas de empaquetar (construir) proyectos Java (SpringBoot) en imágenes de Docker - Comunidad de desarrolladores de Tencent Cloud - Tencent Cloud

Compile, empaquete e implemente proyectos Spring Boot en las compilaciones de docker_docker durante el blog-CSDN de implementación_csdn_meng