Recommended reading:
After the implementation of the microservice architecture, the original single system structure has become a large number of microservice applications, and development, testing, operation and maintenance deployment will face many challenges. How to improve the efficiency of engineering research and development under the microservice architecture and ensure the smoothness of development, testing, operation and maintenance deployment and other processes is the key to the real implementation of the microservice technology system to generate benefits.
To achieve the above goals, it is necessary to build a highly automated release system based on the idea of DevOps (development, operation and maintenance), in which developers can build code anytime and anywhere and release it to a specified operating environment. This process is ours Commonly referred to as CI/CD (Continuous Integration/Continuous Delivery) process.
Regarding the specific practice of DevOps, different companies generally choose a specific implementation plan according to their own development stage and actual needs. Qualified companies can develop a feature-rich visual publishing system, while startups with limited conditions can use open source or existing technology components (such as GitLab, Jenkins, etc.) to implement a relatively simple but fully functional automated publishing system.
In this article, I will use the Spring Cloud microservice technology system as the background to implement a relatively complete CI/CD process automated publishing system through GitLab's own CI/CD mechanism and based on Kubernetes containerization technology.
CI/CD process overview
In fact, DevOps is not a concept that emerged after the popularity of microservice architecture, but a collection of theories and tools accumulated by the industry in years of software development practice. The automated publishing system to be discussed in this article is actually to establish a set of efficient automated methods for application construction, testing, packaging and publishing by building a CI/CD pipeline. The concept of CI (Continuous Integration)/CD (Continuous Delivery) does not refer to a specific technology, but a collection of software engineering culture plus a series of operating principles and specific practices.
The main goal of CI (Continuous Integration) is to package program code by establishing a consistent automated construction method, so that team members can submit code more frequently, integrate code earlier, and find and solve problems in code in a timely manner , Improve the efficiency of collaborative development and the quality of software delivery. The basic process of sustainable integration (CI) is shown in the figure:
From the perspective of the implementation process, the main process of CI is to package the code submitted by the developer into a package that can run in a specific infrastructure environment (such as a Docker image) in a highly automated manner. And this process can be completed by a set of tools such as GitLab Runner (CI Pipeline), Sonar (code inspection tool), etc., and the specific CI process can be integrated and used according to actual needs.
The main logic of continuous delivery (CD) is to automatically publish the program image built in the CI process from the mirror warehouse to the specific infrastructure environment (such as test/production Kubernetes cluster). The tools to implement CD mainly include GitLab Runner (CD Pipeline) , Helm (Kubernetes package management tool), etc.
In fact, the core of CD is to automatically generate specific release instructions (such as Helm instructions) through various input user parameters (such as yaml files, environmental configuration parameters, etc.), and configure the specific operation of the program according to the corresponding information set in the parameters surroundings. The basic operation process of sustainable delivery (CD) is shown in the figure below:
The above is the basic concept and process of CI/CD, and it is also the basis for the realization of the automated publishing system. The following content will mainly focus on these two stages to realize the basic flow logic of the automated publishing system.
Basic components of the system
The automated publishing system described in this article mainly uses the GitLab CI mechanism provided by GitLab to automatically trigger the preset CI/CD process when the code is submitted or merged. The CI process mainly includes the basic code compilation, construction, and packaging stages, and after completing the above steps, the packaged application Docker image is released to the mirror warehouse.
The CD phase pulls the application Docker image from the mirror warehouse and publishes the application to the specified Kubernetes cluster according to the set CD process. The specific system structure is shown in the figure below:
As shown in the figure above, the automated publishing system is mainly composed of GitLab, Harbor mirror warehouse and Kubernetes cluster. Among them, GitLab is mainly responsible for the management of code versions, as well as CI/CD process definition and triggering. Harbor is responsible for the storage and distribution of application Docker images, and the Kubernetes cluster is the infrastructure environment for application container operation.
The key realization of GitLab-CI automatic publishing system
Earlier we described the basic components of an automated publishing system based on the GitLab-CI mechanism. To implement this system, you need to install and deploy the GitLab server and configure the GitLab Runner function, private mirror warehouse service (Harbor or JFrog), and Kubernetes cluster (specifically available See other articles in this column).
Since the GitLab server is the main carrying point for the execution of the CI/CD process, if your service is a Java service built on Maven, you also need to install the Maven client in the GitLab server and configure the address of the Maven private server to improve the build speed. In addition, the GitLab server will also run Docker image packaging and construction during the execution of the CI/CD process, push the image to the Docker image warehouse, and publish the Docker image from the private warehouse to the Kubernetes cluster. Therefore, the GitLab server also needs to install the Docker environment and kubelet customers. end.
If the environment is OK, then we can create the ".gitlab-ci.yml" file in the Gitlab project root directory code and define the specific CI/CD process. But before the specific definition, we need to add the plug-in configuration and Dockerfile file definition of the application Docker image packaging in the Maven project, as follows:
<!--添加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>
Add the "dockerfile-maven-plugin" plug-in to the project project pom.xml file. This plug-in is a replacement for the early "docker-maven-plugin" plug-in and supports packaging Maven project builds as Docker images. In the above configuration, the specific construction method of the Docker image is achieved by specifying the Dockerfile file in the tag. Specifically, you can create a docker directory in the project project and create a Dockerfile file with the following content:
FROM openjdk:8u191-jre-alpine3.9
ENTRYPOINT ["/usr/bin/java", "-jar", "/app.jar"]
ARG JAR_FILE
ADD ${JAR_FILE} /app.jar
EXPOSE 8080
After configuring the Maven packaging plugin, you can support the Maven packaging command to package the application code into a Docker image. At this point, we define the specific CI/CD construction Stages in the ".gitlab-ci.yml" file, an example is as follows:
#环境参数信息
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 -
As mentioned above, we have defined 4 stages of "test, build, push, and deploy" in the ".gitlab-ci.yml" file. The specific descriptions of these stages are as follows:
-
test: execute unit test code;
-
build: Execute build packaging instructions, and package the application build as a Docker image;
-
Push: This stage is mainly to upload the local Docker image built by the build to the Harbor mirror warehouse after tag processing, and clean up the local image file after success;
-
Deploy: This stage is mainly to execute Kubernetes instructions, and deploy the container image to the Kubernetes cluster according to the configuration of the Kubernetes release deployment file;
In the deploy phase, the Docker image is released and run to the Kubernetes cluster, which involves writing Kubernetes deployment and release yaml files. Specific examples are as follows:
---
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
If everything is ready, submitting the code to the GitLab warehouse will automatically trigger the construction of the Pipeline, and the Pipeline will automatically run the specific CI/CD pipeline logic defined in the ".gitlab-ci.yml" file, thereby realizing application automation Post effect.
The automated publishing system based on the GitLab-CI mechanism does not require too much development work due to its relatively simple construction method, so many startup companies currently adopt this type of solution to achieve the automated construction and delivery of microservices.