Bienvenido a mi GitHub
https://github.com/zq2599/blog_demos
content: resumen de clasificación de todos los artículos originales y código fuente de apoyo, que involucran Java, Docker, Kubernetes, DevOPS, etc .;
Acerca de GitLab CI
En el artículo "Experimentar la aplicación SpringBoot (2.3) haciendo una imagen de Docker (solución oficial)" , dominamos la solución de construcción de imágenes recomendada oficialmente por SpringBoot. Lo siguiente que experimentamos es la capacidad de CI de GitLab, que es responsable de convertir el código en un almacén privado La imagen especular de, podemos concentrarnos en la codificación;
La función de GitLab CI se muestra en la siguiente figura. Una vez que el desarrollador envía el código a GitLab, activará la compilación, la construcción, la duplicación y el envío al almacén. Luego, el entorno K8S puede usar la última duplicación:
El contenido de este artículo
Este artículo continúa adhiriéndose al estilo de combate real y completa las siguientes operaciones con todos:
- Prepare una aplicación SpringBoot-2.3;
- Escriba el script de canalización de GitLab;
- Envíe el código para activar el trabajo del script de canalización;
- El entorno K8S utiliza la última imagen;
- Experimente cómo GitLab implementa automáticamente la última imagen en el entorno K8S;
Informacion ambiental
- GitLab: Community Edition 13.0.6
- GilLab Runner: 13.1.0
- gobernadores: 1.15.3
- SpringBoot: 2.3.0.RELEASE
- JDK: 1.8.0_121
- Maven: 3.3.9
- Docker: 19.03.8
- Sistema operativo: CentOS Linux versión 7.8.2003
Listo
Antes del combate real, debes preparar el siguiente entorno:
- GitLab, consulte "Synology DS218 + Implementación de GitLab"
- Almacén espejo privado, consulte "Synology DS218 + Deployment Harbour (1.10.3)"
- GitLab Runner, consulte "Implementación de GitLab Runner (entorno de kubernetes)"
- Kubernetes, consulte "kubespray2.11 instalar kubernetes1.15"
Código fuente de la aplicación SpringBoot
Este combate real usa el proyecto SpringBoot ordinario. Si no planeas escribir código, también puedes descargar el código fuente de este combate real desde GitHub. La dirección y la información del enlace se muestran en la siguiente tabla:
| nombre | enlace | Observaciones |
|---|---|---|
| Página de inicio del proyecto | https://github.com/zq2599/blog_demos | La página de inicio del proyecto en GitHub |
| dirección del almacén de git (https) | https://github.com/zq2599/blog_demos.git | La dirección del almacén del código fuente del proyecto, protocolo https |
| dirección del almacén de git (ssh) | [email protected]: zq2599 / blog_demos.git | La dirección del almacén del código fuente del proyecto, protocolo ssh |
Hay varias carpetas en este proyecto git. La aplicación de este capítulo se encuentra en la carpeta dockerlayerdemo , como se muestra en la siguiente figura:
Operación real
- Cree un proyecto SpringBoot llamado dockerlayerdemo , el número de versión de SpringBoot es 2.3.0.RELEASE y el contenido de pom.xml es el siguiente:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.0.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.bolingcavalry</groupId>
<artifactId>dockerlayerdemo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>dockerlayerdemo</name>
<description>Demo project for Spring Boot layer docker image</description>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.0.RELEASE</version>
<configuration>
<layers>
<enabled>true</enabled>
</layers>
</configuration>
</plugin>
</plugins>
</build>
</project>
- El código java no es el punto. Se agrega una interfaz http a la clase de aplicación:
package com.bolingcavalry.dockerlayerdemo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Date;
@SpringBootApplication
@RestController
public class DockerlayerdemoApplication {
public static void main(String[] args) {
SpringApplication.run(DockerlayerdemoApplication.class, args);
}
@RequestMapping(value = "/hello")
public String hello(){
return "hello " + new Date();
}
}
- Agregue la carpeta .m2 al directorio donde se encuentra pom.xml y coloque settings.xml en él. Este es el archivo de configuración de maven y puede establecer su información especial de maven;
- Agregue un archivo Dockerfile al directorio donde se encuentra pom.xml para hacer un espejo:
# 指定基础镜像，这是分阶段构建的前期阶段
FROM openjdk:8u212-jdk-stretch as builder
# 执行工作目录
WORKDIR application
# 配置参数
ARG JAR_FILE=target/*.jar
# 将编译构建得到的jar文件复制到镜像空间中
COPY ${JAR_FILE} application.jar
# 通过工具spring-boot-jarmode-layertools从application.jar中提取拆分后的构建结果
RUN java -Djarmode=layertools -jar application.jar extract
# 正式构建镜像
FROM openjdk:8u212-jdk-stretch
WORKDIR application
# 前一阶段从jar中提取除了多个文件，这里分别执行COPY命令复制到镜像空间中，每次COPY都是一个layer
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
- Agregue un archivo .gitlab-ci.yml al directorio donde se encuentra pom.xml . Este es el script de canalización para CI:
image: maven:3.6.3-jdk-8
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
# 定义缓存
# 如果gitlab runner是shell或者docker，此缓存功能没有问题
# 如果是k8s环境，要确保已经设置了分布式文件服务作为缓存
cache:
key: dockerlayerdemo-ci-cache
paths:
- .m2/repository/
- target/*.jar
# 本次构建的阶段：build package
stages:
- package
- build
# 生产jar的job
make_jar:
image: maven:3.6.3-jdk-8
stage: package
tags:
- k8s
script:
- echo "=============== 开始编译源码，在target目录生成jar文件 ==============="
- mvn $MAVEN_CLI_OPTS clean compile package -Dmaven.test.skip=true
- echo "target文件夹" `ls target/`
# 生产镜像的job
make_image:
image: docker:latest
stage: build
tags:
- k8s
script:
- echo "从缓存中恢复的target文件夹" `ls target/`
- echo "=============== 登录Harbor ==============="
- docker login 192.168.50.43:5888 -u admin -p Harbor12345
- echo "=============== 打包Docker镜像 ： " gitlabci-java-demo:$CI_COMMIT_SHORT_SHA "==============="
- docker build -t 192.168.50.43:5888/common/gitlabci-java-demo:$CI_COMMIT_SHORT_SHA .
- echo "=============== 推送到镜像仓库 ==============="
- docker push 192.168.50.43:5888/common/gitlabci-java-demo:$CI_COMMIT_SHORT_SHA
- echo "=============== 登出 ==============="
- docker logout
- echo "清理掉本次构建的jar文件"
- rm -rf target/*.jar
Con respecto al script de canalización anterior, hay cinco puntos a tener en cuenta:
Primero: con respecto al caché, si tu gitlab runner es de tipo shell o docker, no necesitas prestar atención. El caché es directamente efectivo, pero si tu gitlab runner es K8S, debes prestarle atención . Debes completar la configuración relacionada con el caché en el gitlab runner. , Deje que el servicio de archivos distribuidos sea la capa inferior de la caché;
Segundo: se definen un total de dos etapas: empaquetar y compilar. El orden es empaquetar primero y luego compilar. Tenga en cuenta que el trabajo que genera el jar debe ser empaquetado, y el trabajo que usa jar para compilar la imagen debe ser compilado, de modo que pueda eliminarse sin problemas del caché cuando se compile la imagen. Coge el frasco;
Tercero: la secuencia de comandos de trabajo de make_image ejecutará la operación de inicio de sesión en el almacén espejo privado. Para la comodidad de la operación, la cuenta de inicio de sesión y la contraseña están escritas directamente en la secuencia de comandos. No lo haga en el uso real. Se recomienda utilizar la cuenta de robot de Harbor. Contraseña y escríbala en la página de configuración de variables de entorno de GitLab CI en lugar de escribirla directamente en el script de canalización
Cuarto: El parámetro de etiquetas se usa para que coincida con el GitLab Runner existente, configúrelo de acuerdo con su propio corredor;
Quinto: La etiqueta de la imagen de la ventana acoplable generada es igual a $ CI_COMMIT_SHORT_SHA , que es el ID de confirmación de este envío. Por lo tanto, cada envío dará como resultado una imagen adicional en el almacén espejo, y su etiqueta es igual al ID de confirmación;
- El contenido final de todo el proyecto es el siguiente: Hasta el
momento, se ha completado todo el trabajo de desarrollo y luego se verifica la implementación;
Verificar CI
- Envíe todo el contenido a GitLab. Si la configuración del entorno de CI es correcta, la compilación se activará de inmediato. La siguiente figura muestra el efecto de una compilación exitosa:
- Primero observe la ejecución de make_jar, como se muestra en la siguiente figura, el proyecto SpringBoot construye exitosamente el archivo jar:
- Observe la ejecución de make_image, como se muestra a continuación:
- Una vez que la imagen se haya creado correctamente, se enviará a albergar:
- Finalmente complete el empuje y limpie los archivos restantes:
- Finalmente, observe la situación general de la tubería, como se muestra a continuación:
- En la figura anterior, podemos ver que el ID de confirmación es 02307851 , por lo que debería haber un espejo con etiqueta igual a 02307851 en Harbour. Inicie sesión en Harbour para verlo, como se muestra en el cuadro rojo en la siguiente figura:
Verificar en el entorno K8S
A continuación, verifique que la imagen anterior se pueda ejecutar normalmente en el entorno K8S:
- Inicie sesión en el entorno K8S a través de SSH, ejecute el siguiente comando para crear una implementación con la imagen más reciente:
kubectl create deployment dockerlayerdemo \
--image=192.168.50.43:5888/common/gitlabci-java-demo:02307851
- Ejecute el siguiente comando para crear un servicio de tipo NodePort:
kubectl create service nodeport \
dockerlayerdemo --tcp 8080:8080
- El navegador visita http://192.168.50.135:31685/hello , donde 192.168.50.135 es la dirección IP del host K8S, como se muestra en la siguiente figura, puede acceder al servicio SpringBoot normalmente:
El valor de GitLab CI
Como ve el artículo, nuestro script de canalización se ha escrito, la duplicación está disponible y los servicios implementados en K8S también se han verificado.
—Todavía no, experimentemos el proceso desde la modificación del código hasta su aplicación en el entorno K8S:
- Modifique el código Java como se muestra a continuación:
- Ingrese el código:
- La imagen se genera con éxito:
- Ejecute los siguientes comandos en el entorno K8S para completar la actualización del espejo:
kubectl set image deployment dockerlayerdemo \
gitlabci-java-demo=192.168.50.43:5888/common/gitlabci-java-demo:8735c78d
- El gitlabci-java-demo en el comando anterior proviene del nombre del contenedor que se muestra en el resultado de kubectl describe la implementación dockerlayerdemo , como se muestra en el cuadro rojo en la siguiente figura:
- El sistema le indica que la actualización se realizó correctamente:
- Use el navegador para visitar la misma dirección nuevamente, como se muestra en el cuadro rojo a continuación, el código modificado ha entrado en vigencia:
se puede ver que con la ayuda de GitLab CI, el proceso desde la codificación hasta la implementación se ha simplificado y la codificación puede ser más enfocada;
¿Experiencia CD?
Además de la integración continua (CI), la implementación continua (CD) también se puede agregar al script de canalización, de modo que solo necesitamos enviar el código, y la imagen correspondiente se implementará automáticamente en el entorno K8S;
- Abra .gitlab-ci.yml y agregue una etapa para definir la implementación , como se muestra a continuación, ahora hay tres etapas:
stages:
- package
- build
- deploy
- Luego agregue un trabajo al final , como se muestra a continuación, el nombre de la imagen es ictu / sshpass: último , la imagen tiene sshpass incorporado y se puede conectar al entorno K8S con SSH, ejecute el comando kubectl set image XXX para actualizar la imagen, preste atención al paquete kubectl set image comando es Comillas dobles , esto es muy importante, solo cuando se usan comillas dobles, el $ TAG dentro se reemplazará con el valor correspondiente:
# 生产镜像的job
deploy_k8s:
# 禁用cache，避免上传、下载、压缩、解压缩带来的开销
cache: {
}
image: ictu/sshpass:latest
stage: deploy
tags:
- k8s
script:
- export TAG=$CI_COMMIT_SHORT_SHA
- echo "TAG is "$TAG
- sshpass -p 888888 ssh -o "StrictHostKeyChecking no" [email protected] "kubectl set image deployment dockerlayerdemo gitlabci-java-demo=192.168.50.43:5888/common/gitlabci-java-demo:$TAG"
- Nuevamente, en el script anterior, la cuenta, la IP y la contraseña deben colocarse en la página de configuración de parámetros de GitLab y no deben escribirse directamente en el script de la canalización;
- Como se muestra en la figura siguiente, modifique el archivo java nuevamente y cambie el resultado de retorno de hola a abcdef :
- Después de enviar el código, puede observar el proceso de ejecución del nuevo trabajo en la página de CI;
- Una vez completado el script, abra el navegador y pruébelo. Realmente se ha actualizado: hasta
ahora, se han verificado CI y CD. Se puede ver que la capacidad de CI de GitLab ha aportado mucha comodidad a nuestro desarrollo diario. Espero que este artículo pueda traer algunas referencias. ；