Lecture recommandée:
Après la mise en œuvre de l'architecture de microservices, la structure de système unique d'origine est devenue un grand nombre d'applications de microservices, et le développement, les tests, l'exploitation et le déploiement de maintenance seront confrontés à de nombreux défis. Comment améliorer l'efficacité de la recherche et du développement en ingénierie dans le cadre de l'architecture de microservices et assurer la fluidité du déploiement de développement, de test, d'exploitation et de maintenance et d'autres processus est la clé de la mise en œuvre réelle du système technologique de microservice pour générer des avantages.
Pour atteindre les objectifs ci-dessus, il est nécessaire de créer un système de publication hautement automatisé basé sur l'idée de DevOps (développement, exploitation et maintenance), dans lequel les développeurs peuvent créer du code à tout moment et n'importe où et le publier dans un environnement d'exploitation spécifié. Ce processus est le nôtre. Communément appelé processus CI / CD (Continuous Integration / Continuous Delivery).
En ce qui concerne la pratique spécifique du DevOps, différentes entreprises choisissent généralement un plan de mise en œuvre spécifique en fonction de leur propre stade de développement et de leurs besoins réels. Les entreprises qualifiées peuvent développer un système de publication visuelle riche en fonctionnalités, tandis que les startups aux conditions limitées peuvent utiliser des composants technologiques open source ou existants (tels que GitLab, Jenkins, etc.) pour mettre en œuvre un système de publication automatisé relativement simple mais entièrement fonctionnel.
Dans cet article, j'utiliserai le système technologique de microservices Spring Cloud comme arrière-plan pour implémenter un système de publication automatisé de processus CI / CD relativement complet via le mécanisme CI / CD de GitLab et basé sur la technologie de conteneurisation Kubernetes.
Présentation du processus CI / CD
En fait, DevOps n'est pas un concept qui a émergé après la popularité de l'architecture de microservices, mais un ensemble de théories et d'outils accumulés par l'industrie au cours des années de pratique du développement logiciel. Le système de publication automatisé dont il est question dans cet article consiste en fait à établir un ensemble de méthodes automatisées efficaces pour la construction, le test, le conditionnement et la publication d'applications en créant un pipeline CI / CD. Le concept de CI (Continuous Integration) / CD (Continuous Delivery) ne fait pas référence à une technologie spécifique, mais à un ensemble de culture du génie logiciel ainsi qu'à une série de principes de fonctionnement et de pratiques spécifiques.
L'objectif principal de CI (intégration continue) est de conditionner le code du programme en établissant une méthode de construction automatisée cohérente, afin que les membres de l'équipe puissent soumettre le code plus fréquemment, intégrer le code plus tôt et trouver et résoudre les problèmes dans le code en temps opportun. , Améliorer l'efficacité du développement collaboratif et la qualité de la livraison de logiciels. Le processus de base de l'intégration durable (IC) est illustré dans la figure:
Du point de vue du processus de mise en œuvre, le processus principal de CI consiste à regrouper le code soumis par le développeur dans un package qui peut s'exécuter dans un environnement d'infrastructure spécifique (comme une image Docker) de manière hautement automatisée. Et ce processus peut être complété par un ensemble d'outils tels que GitLab Runner (CI Pipeline), Sonar (outil d'inspection de code), etc., et le processus CI spécifique peut être intégré et utilisé en fonction des besoins réels.
La logique principale de la livraison continue (CD) est de publier automatiquement l'image du programme construite dans le processus CI de l'entrepôt miroir vers l'environnement d'infrastructure spécifique (tel que le cluster Kubernetes de test / production). Les outils pour implémenter le CD incluent principalement GitLab Runner (CD Pipeline) , Helm (outil de gestion de packages Kubernetes), etc.
En fait, le cœur du CD est de générer automatiquement des instructions de publication spécifiques (telles que les instructions Helm) via divers paramètres utilisateur d'entrée (tels que les fichiers yaml, les paramètres de configuration environnementale, etc.), et de configurer le fonctionnement spécifique du programme en fonction des informations correspondantes définies dans les paramètres. alentours. Le processus de fonctionnement de base de la livraison durable (CD) est illustré dans la figure ci-dessous:
Ce qui précède est le concept et le processus de base de CI / CD, et c'est également la base pour la réalisation du système de publication automatisé. Le contenu suivant se concentrera principalement sur ces deux étapes pour réaliser la logique de flux de base du système de publication automatisé.
Composants de base du système
Le système de publication automatisé décrit dans cet article utilise principalement le mécanisme CI GitLab fourni par GitLab pour déclencher automatiquement le processus CI / CD prédéfini lorsque le code est soumis ou fusionné. Le processus CI comprend principalement les étapes de base de la compilation du code, de la construction et de l'empaquetage, et après avoir terminé les étapes ci-dessus, l'image Docker de l'application packagée est publiée dans l'entrepôt miroir.
La phase CD extrait l'image Docker de l'application de l'entrepôt miroir et publie l'application sur le cluster Kubernetes spécifié en fonction du processus CD défini. La structure spécifique du système est illustrée dans la figure ci-dessous:
Comme le montre la figure ci-dessus, le système de publication automatisé est principalement composé de GitLab, de l'entrepôt de miroir Harbor et du cluster Kubernetes. Parmi eux, GitLab est principalement responsable de la gestion des versions de code, ainsi que de la définition et du déclenchement des processus CI / CD. Harbour est responsable du stockage et de la distribution des images Docker des applications, et le cluster Kubernetes est l'environnement d'infrastructure pour le fonctionnement des conteneurs d'applications.
La réalisation clé du système de publication automatique GitLab-CI
Nous avons décrit précédemment les composants de base d'un système de publication automatisé basé sur le mécanisme GitLab-CI. Pour implémenter ce système, vous devez installer et déployer le serveur GitLab et configurer la fonction GItLab Runner, le service d'entrepôt de miroir privé (Harbor ou JFrog) et le cluster Kubernetes (spécifiquement disponible Voir les autres articles de cette colonne).
Étant donné que le serveur GitLab est le principal point de transport pour l'exécution du processus CI / CD, si votre service est un service Java basé sur Maven, vous devez également installer le client Maven sur le serveur GitLab et configurer l'adresse du serveur privé Maven pour améliorer la vitesse de construction. En outre, le serveur GitLab exécutera également l'empaquetage et la construction d'image Docker pendant l'exécution du processus CI / CD, poussera l'image vers l'entrepôt d'images Docker et publiera l'image Docker de l'entrepôt privé vers le cluster Kubernetes. Par conséquent, le serveur GitLab doit également installer l'environnement Docker et les clients kubelet. fin.
Si l'environnement est OK, nous pouvons créer le fichier ".gitlab-ci.yml" dans le code du répertoire racine du projet Gitlab et définir le processus CI / CD spécifique. Mais avant la définition spécifique, nous devons ajouter la configuration du plug-in et la définition du fichier Dockerfile de l'empaquetage d'image Docker de l'application dans le projet Maven, comme suit:
<!--添加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>
Ajoutez le plug-in "dockerfile-maven-plugin" au fichier pom.xml du projet de projet. Ce plug-in remplace l'ancien plug-in "docker-maven-plugin" et prend en charge l'empaquetage des builds de projet Maven sous forme d'images Docker. Dans la configuration ci-dessus, la méthode de construction spécifique de l'image Docker est obtenue en spécifiant le fichier Dockerfile dans la balise. Plus précisément, vous pouvez créer un répertoire Docker dans le projet de projet et créer un fichier Dockerfile avec le contenu suivant:
FROM openjdk:8u191-jre-alpine3.9
ENTRYPOINT ["/usr/bin/java", "-jar", "/app.jar"]
ARG JAR_FILE
ADD ${JAR_FILE} /app.jar
EXPOSE 8080
Après avoir configuré le plugin d'empaquetage Maven, vous pouvez prendre en charge la commande d'empaquetage Maven pour empaqueter le code d'application dans une image Docker. À ce stade, nous définissons les étapes de construction CI / CD spécifiques dans le fichier ".gitlab-ci.yml", un exemple est le suivant:
#环境参数信息
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 -
Comme mentionné ci-dessus, nous avons défini 4 étapes de "tester, construire, pousser et déployer" dans le fichier ".gitlab-ci.yml". Les descriptions spécifiques de ces étapes sont les suivantes:
-
test: exécuter le code de test unitaire;
-
build: exécutez les instructions d'empaquetage de build et empaquetez la build d'application en tant qu'image Docker;
-
Push: Cette étape consiste principalement à télécharger l'image Docker locale construite par la construction dans l'entrepôt de miroir Harbour après le traitement des balises, et à nettoyer le fichier image local après le succès;
-
Déployer: cette étape consiste principalement à exécuter les instructions Kubernetes et à déployer l'image du conteneur sur le cluster Kubernetes en fonction de la configuration du fichier de déploiement de la version Kubernetes;
Lors de la phase de déploiement, l'image Docker est publiée et exécutée sur le cluster Kubernetes, ce qui implique l'écriture de fichiers de déploiement Kubernetes et de publication de fichiers yaml. Des exemples spécifiques sont les suivants:
---
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 tout est prêt, la soumission du code à l'entrepôt GitLab déclenchera automatiquement la construction du Pipeline, et le Pipeline exécutera automatiquement la logique de pipeline CI / CD spécifique définie dans le fichier ".gitlab-ci.yml", réalisant ainsi l'automatisation de l'application Effet post.
Le système de publication automatisé basé sur le mécanisme GitLab-CI ne nécessite pas trop de travail de développement en raison de sa méthode de construction relativement simple, de sorte que de nombreuses startups adoptent actuellement ce type de solution pour réaliser la construction et la livraison automatisées de microservices.