Lectura recomendada:
Después de la implementación de la arquitectura de microservicios, la estructura original del sistema único se ha convertido en una gran cantidad de aplicaciones de microservicios, y el desarrollo, las pruebas, la operación y la implementación de mantenimiento se enfrentarán a muchos desafíos. Cómo mejorar la eficiencia de la investigación y el desarrollo de ingeniería bajo la arquitectura de microservicios y garantizar la fluidez del desarrollo, las pruebas, la implementación de operaciones y mantenimiento y otros procesos es la clave para la implementación real del sistema de tecnología de microservicios para generar beneficios.
Para lograr los objetivos anteriores, es necesario construir un sistema de lanzamiento altamente automatizado basado en la idea de DevOps (desarrollo, operación y mantenimiento), en el que los desarrolladores pueden construir código en cualquier momento y en cualquier lugar y lanzarlo a un entorno operativo específico. Este proceso es nuestro. Comúnmente conocido como proceso CI / CD (Integración continua / Entrega continua).
Con respecto a la práctica específica de DevOps, las diferentes empresas generalmente eligen un plan de implementación específico de acuerdo con su propia etapa de desarrollo y sus necesidades reales. Las empresas calificadas pueden desarrollar un sistema de publicación visual rico en funciones, mientras que las nuevas empresas con condiciones limitadas pueden usar componentes de tecnología de código abierto o existentes (como GitLab, Jenkins, etc.) para implementar un sistema de publicación automatizado relativamente simple pero completamente funcional.
En este artículo, utilizaré el sistema de tecnología de microservicio Spring Cloud como fondo para implementar un sistema de publicación automatizado de proceso CI / CD relativamente completo a través del mecanismo CI / CD propio de GitLab y basado en la tecnología de contenedorización de Kubernetes.
Descripción general del proceso de CI / CD
De hecho, DevOps no es un concepto que surgió después de la popularidad de la arquitectura de microservicios, sino una colección de teorías y herramientas acumuladas por la industria en años de práctica de desarrollo de software. El sistema de publicación automatizado que se discutirá en este artículo es en realidad para establecer un conjunto de métodos automatizados eficientes para la construcción, prueba, empaquetado y publicación de aplicaciones mediante la construcción de un canal de CI / CD. El concepto de CI (Integración continua) / CD (Entrega continua) no se refiere a una tecnología específica, sino a una colección de cultura de ingeniería de software más una serie de principios operativos y prácticas específicas.
El objetivo principal de CI (Integración continua) es empaquetar el código del programa mediante el establecimiento de un método de construcción automatizado consistente, de modo que los miembros del equipo puedan enviar código con más frecuencia, integrar código antes y encontrar y resolver problemas en el código de manera oportuna. , Mejorar la eficiencia del desarrollo colaborativo y la calidad de la entrega de software. El proceso básico de integración sostenible (CI) se muestra en la figura:
Desde la perspectiva del proceso de implementación, el proceso principal de CI es empaquetar el código enviado por el desarrollador en un paquete que se puede ejecutar en un entorno de infraestructura específico (como una imagen de Docker) de una manera altamente automatizada. Y este proceso se puede completar con un conjunto de herramientas como GitLab Runner (CI Pipeline), Sonar (herramienta de inspección de código), etc., y el proceso CI específico se puede integrar y usar de acuerdo con las necesidades reales.
La lógica principal de la entrega continua (CD) es publicar automáticamente la imagen del programa integrada en el proceso de CI desde el almacén espejo al entorno de infraestructura específico (como el clúster de Kubernetes de prueba / producción). Las herramientas para implementar CD incluyen principalmente GitLab Runner (CD Pipeline) , Helm (herramienta de gestión de paquetes de Kubernetes), etc.
De hecho, el núcleo del CD es generar automáticamente instrucciones de lanzamiento específicas (como las instrucciones de Helm) a través de varios parámetros de entrada de usuario (como archivos yaml, parámetros de configuración ambiental, etc.) y configurar el funcionamiento específico del programa de acuerdo con la información correspondiente establecida en los parámetros. alrededores. El proceso operativo básico de entrega sostenible (CD) se muestra en la siguiente figura:
Lo anterior es el concepto y proceso básico de CI / CD, y también es la base para la realización del sistema de publicación automatizado. El siguiente contenido se centrará principalmente en estas dos etapas para realizar la lógica de flujo básica del sistema de publicación automatizado.
Componentes básicos del sistema
El sistema de publicación automatizado descrito en este artículo utiliza principalmente el mecanismo de CI de GitLab proporcionado por GitLab para activar automáticamente el proceso de CI / CD preestablecido cuando el código se envía o se fusiona. El proceso de CI incluye principalmente las etapas básicas de compilación, construcción y empaquetado del código, y después de completar los pasos anteriores, la imagen de Docker de la aplicación empaquetada se envía al almacén espejo.
La fase de CD extrae la imagen de Docker de la aplicación del almacén espejo y publica la aplicación en el clúster de Kubernetes especificado de acuerdo con el proceso de CD establecido. La estructura específica del sistema se muestra en la siguiente figura:
Como se muestra en la figura anterior, el sistema de publicación automatizado se compone principalmente de GitLab, el almacén espejo de Harbour y el clúster de Kubernetes. Entre ellos, GitLab es el principal responsable de la gestión de las versiones de código, así como de la definición y activación del proceso de CI / CD. Harbour es responsable del almacenamiento y distribución de las imágenes de Docker de aplicaciones, y el clúster de Kubernetes es el entorno de infraestructura para la operación del contenedor de aplicaciones.
La realización clave del sistema de publicación automática GitLab-CI
Anteriormente describimos los componentes básicos de un sistema de publicación automatizado basado en el mecanismo GitLab-CI. Para implementar este sistema, debe instalar e implementar el servidor GitLab y configurar la función GitLab Runner, el servicio de almacén espejo privado (Harbour o JFrog) y el clúster de Kubernetes (disponible específicamente Ver otros artículos en esta columna).
Dado que el servidor GitLab es el principal punto de transporte para la ejecución del proceso CI / CD, si su servicio es un servicio Java construido en Maven, también debe instalar el cliente Maven en el servidor GitLab y configurar la dirección del servidor privado Maven para mejorar la velocidad de compilación. Además, el servidor de GitLab también ejecutará el empaquetado y la construcción de imágenes de Docker durante la ejecución del proceso de CI / CD, enviará la imagen al almacén de imágenes de Docker y publicará la imagen de Docker desde el almacén privado en el clúster de Kubernetes. Por lo tanto, el servidor de GitLab también necesita instalar el entorno de Docker y los clientes de kubelet. final.
Si el entorno es correcto, entonces podemos crear el archivo ".gitlab-ci.yml" en el código del directorio raíz del proyecto Gitlab y definir el proceso CI / CD específico. Pero antes de la definición específica, debemos agregar la configuración del complemento y la definición del archivo Dockerfile del empaquetado de la imagen Docker de la aplicación en el proyecto Maven, de la siguiente manera:
<!--添加Docker镜像Maven打包插件-->
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>1.4.13</version>
<executions>
<execution>
<id>build-image</id>
<phase>package</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
<configuration>
<!--指定Dockerfile文件位置-->
<dockerfile>docker/Dockerfile</dockerfile>
<!--指定Docker镜像仓库路径-->
<repository>${docker.repository}/springcloud-action/${app.name}</repository>
<buildArgs>
<!--提供参数向Dockerfile传递-->
<JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
</buildArgs>
</configuration>
</plugin>
Agrega el complemento "dockerfile-maven-plugin" al archivo pom.xml del proyecto del proyecto. Este complemento es un reemplazo del complemento "docker-maven-plugin" anterior y admite el empaquetado de compilaciones de proyectos Maven como imágenes de Docker. En la configuración anterior, el método de construcción específico de la imagen de Docker se logra especificando el archivo Dockerfile en la etiqueta. Específicamente, puede crear un directorio de Docker en el proyecto del proyecto y crear un archivo Dockerfile con el siguiente contenido:
FROM openjdk:8u191-jre-alpine3.9
ENTRYPOINT ["/usr/bin/java", "-jar", "/app.jar"]
ARG JAR_FILE
ADD ${JAR_FILE} /app.jar
EXPOSE 8080
Después de configurar el complemento de empaquetado de Maven, puede admitir el comando de empaquetado de Maven para empaquetar el código de la aplicación en una imagen de Docker. En este punto, definimos las Etapas de construcción de CI / CD específicas en el archivo ".gitlab-ci.yml", un ejemplo es el siguiente:
#环境参数信息
variables:
#Docker镜像仓库地址&账号密码信息
DOCKER_REPO_URL: "10.211.55.11:8088"
DOCKER_REPO_USERNAME: admin
DOCKER_REPO_PASSWORD: Harbor12345
#Kubernetes相关信息配置(空间与服务端口)
K8S_NAMESPACE: "wudimanong"
PORT: "8080"
#定义CI/CD阶段
stages:
- test
- build
- push
- deploy
#执行单元测试阶段
maven-test:
stage: test
script:
- mvn clean test
#代码编译打包镜像阶段
maven-build:
stage: build
script:
- mvn clean package -DskipTests
#将打包的Docker镜像上传至私有镜像仓库
docker-push:
stage: push
script:
#对打包的镜像进行tag
- docker tag $DOCKER_REPO_URL/$CI_PROJECT_PATH $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
#登录私有镜像仓库
- docker login $DOCKER_REPO_URL -u $DOCKER_REPO_USERNAME -p $DOCKER_REPO_PASSWORD
#上传应用镜像至镜像仓库
- docker push $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
- docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
- docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH
#将应用发布至Kubernetes测试集群（这里指定为手动确认方式）
deploy-test:
stage: deploy
when: manual
script:
- kubectl config use-context kubernetes-admin@kubernetes
- sed -e "s/__REPLICAS__/1/; s/__PORT__/$PORT/; s/__APP_NAME__/$CI_PROJECT_NAME/; s/__PROFILE__/test/; s/__IMAGE__/$DOCKER_REPO_URL\/${CI_PROJECT_PATH//\//\\/}\/${CI_BUILD_REF_NAME//\//\\/}:${CI_COMMIT_SHA:0:8}/" kubernetes/deploy.yaml | kubectl -n ${K8S_NAMESPACE} apply -f -
Como se mencionó anteriormente, hemos definido 4 etapas de "prueba, compilación, inserción e implementación" en el archivo ".gitlab-ci.yml". Las descripciones específicas de estas etapas son las siguientes:
-
prueba: ejecuta el código de prueba de la unidad;
-
build: ejecute las instrucciones de empaquetado de compilación y empaquete la compilación de la aplicación como una imagen de Docker;
-
Empujar: esta etapa es principalmente para cargar la imagen de Docker local creada por la compilación en el almacén de réplicas de Harbour después del procesamiento de la etiqueta, y limpiar el archivo de imagen local después del éxito;
-
Implementar: esta etapa es principalmente para ejecutar las instrucciones de Kubernetes e implementar la imagen del contenedor en el clúster de Kubernetes de acuerdo con la configuración del archivo de implementación de la versión de Kubernetes;
En la fase de implementación, la imagen de Docker se publica y se ejecuta en el clúster de Kubernetes, lo que implica escribir archivos yaml de implementación y publicación de Kubernetes. Los ejemplos específicos son los siguientes:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: __APP_NAME__
spec:
replicas: __REPLICAS__
selector:
matchLabels:
app: __APP_NAME__
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: __APP_NAME__
spec:
imagePullSecrets:
- name: wudimanong-ecr
containers:
- name: __APP_NAME__
image: __IMAGE__
resources:
requests:
memory: "1000M"
limits:
memory: "1000M"
volumeMounts:
- name: time-zone
mountPath: /etc/localtime
- name: java-logs
mountPath: /opt/logs
ports:
- containerPort: __PORT__
env:
- name: SPRING_PROFILES_ACTIVE
value: __PROFILE__
- name: JAVA_OPTS
value: -Xms1G -Xmx1G -Dapp.home=/opt/
volumes:
- name: time-zone
hostPath:
path: /etc/localtime
- name: java-logs
hostPath:
path: /data/app/deployment/logs
Si todo está listo, enviar el código al almacén de GitLab activará automáticamente la construcción de la tubería, y la tubería ejecutará automáticamente la lógica de la tubería de CI / CD específica definida en el archivo ".gitlab-ci.yml", realizando así la automatización de la aplicación. Efecto posterior.
El sistema de publicación automatizado basado en el mecanismo GitLab-CI no requiere demasiado trabajo de desarrollo debido a su método de construcción relativamente simple, por lo que muchas empresas emergentes actualmente adoptan este tipo de solución para lograr la construcción y entrega automatizadas de microservicios.