Vous apprendre 7 étapes pour créer rapidement un environnement d'intégration continue GitLab

Auteur | Cuncheng Alibaba Cloud Elastic Computing Team
Source | Compte officiel sans serveur, compilé à partir du "Cours ouvert sur la technologie sans serveur"

Introduction : Cette section du cours vous explique comment créer rapidement un environnement d'intégration continue GitLab basé sur les services Alibaba Cloud Serverless Kubernetes (ASK).

DEMANDEZ l'introduction

Tout d'abord, qu'est-ce que ASK? ASK est un service de conteneur Kubernetes sans serveur lancé par Alibaba Cloud. Par rapport au service Kubernetes traditionnel, la plus grande caractéristique d'ASK est qu'il se connecte au cluster Kubernetes via des nœuds virtuels, et le nœud Kubernetes Master est également entièrement hébergé par Alibaba Cloud Container Service. Par conséquent, dans l'ensemble du cluster ASK, les utilisateurs n'ont pas besoin de gérer et d'exploiter de vrais nœuds, mais seulement de se soucier des ressources du pod.

Les principaux avantages d'ASK sont les suivants:

• Abaissez le seuil permettant aux utilisateurs d'utiliser Kubernetes sans gérer les nœuds Node;
• Pas besoin de considérer la planification de la capacité des nœuds;
• Facturation à la demande basée sur Pod;
• Les pannes de temps d'arrêt ont un faible impact et sont du niveau du pod.

Dans le même temps, les principaux scénarios applicables d'ASK sont:

• Flexibilité commerciale en ligne (diffusion vidéo en direct, éducation en ligne);
• Informatique Big Data (Spark);
• Tâche chronométrée
• Intégration continue CI / CD.

Avantages de GitLab CI sur ASK

En parlant de CI / CD, les deux outils les plus connus sont Jenkins et GitLab CI. Avec la popularité du rôle Devops, de plus en plus d'entreprises adoptent GitLab CI comme outil d'intégration continue. Permettez-moi de vous présenter Téléchargez GitLab CI sur ASK. gitlab-runner est enregistré dans le cluster ASK en tant que pod, et chaque étape CI / CD correspond à un pod.

Les avantages de ceci sont les suivants:

• Haute disponibilité des services (déploiement + PVC);
• Il n'est pas nécessaire de gérer les nœuds Master et Node de K8. Sans aucune tâche de construction, un seul pod (gitlab-runner) doit être exécuté;
• Déclenchez une tâche de construction, démarrez un pod et chargez à la demande;
• Une panne de temps d'arrêt n'affectera que le pod en tant qu'unité.

Démonstration pratique

Ensuite, je vais vous montrer comment déployer gitlab-runner sur le cluster ASK d'Alibaba Cloud et déployer des applications Java sur le cluster ASK via le pipeline gitlab CICD.

Les principaux points de connaissance concernés sont:

• Enregistrez la configuration de gitlab runner et executor via configMap;
• Enregistrez les informations d'identification d'accès du cluster ASK et la clé de l'entrepôt miroir via le secret;
• Cache le cache du coureur et l'entrepôt maven via PVC;
• Mettez en cache les images de conteneurs via imageCache.

Tous les fichiers de configuration (yaml) impliqués dans cette leçon ont été téléchargés sur github pour que tout le monde puisse les télécharger [ lien de téléchargement ].

Commençons la démonstration. Pour la démonstration vidéo, veuillez cliquer sur [ Regarder le lien ].

1. Préparez le cluster ASK

• Créer un cluster K8 sans serveur standard dans [ Container Service Console ]

• Une fois le cluster créé, l'adresse du lien réseau public du serveur API figure dans les informations de base

• Il existe des informations d'identification d'accès au cluster ASK dans les informations de connexion

2. Préparez PV / PVC

Préparez deux disques nas, un pour le cache du runner gitlab et un pour l'entrepôt maven, veuillez remplacer l'adresse et le chemin du serveur nas par vous-même

kubectl apply -f mvn-pv.yaml
kubectl apply -f mvn-pvc.yaml
kubectl apply -f nas-pv.yaml
kubectl apply -f nas-pvc.yaml

3. Préparez le secret

• Copiez les clés publique et privée du certificat dans kubeconfig dans secret, secret.yaml

kubectl apply -f secret.yaml

• Les informations d'authentification du registre docker, ECI prend en charge l'extraction sans mot de passe, mais l'image docker push doit toujours être utilisée

kubectl create secret docker-registry registry-auth-secret --docker-server=registry.cn-hangzhou.aliyuncs.com --docker-username=${xxx} --docker-password=${xxx}

• Pour afficher le secret généré, vous pouvez utiliser la commande suivante

kubectl get secret registry-auth-secret --output=yaml

4. Préparez ConfigMap

Copiez l'url et le jeton du runner gitlab et l'adresse du serveur api du cluster ASK dans config.yaml

kubectl apply -f config-map.yaml

5. Préparez imageCache (facultatif, économisez le temps d'extraction de l'image)

Actuellement, AS K installe imagecache-crd par défaut, vous pouvez utiliser la commande suivante pour interroger, sinon, vous pouvez l'installer vous-même

# 查看image cache crd 是否安转
kubectl get crd
# 安装image cache crd
kubectl apply -f imagecache-crd.yaml
# 制作imagecache
kubectl apply -f imagecache.yaml

6. Déployez gitlab runner

kubectl apply -f gitlab-runner-deployment.yaml

7. Effectuer une tâche CI simple

Le .gitlab-ci.yml dans git repo est similaire à Jenkinsfile et définit le flux de travail de la tâche de construction. Nous modifions le fichier src / main / webapp / index.jsp dans le projet de démonstration, puis git commit -m "change index info" pour le soumettre. La tâche de pipeline dans gitlab est déclenchée et l'ensemble du processus implique la compilation, l'empaquetage et le déploiement.

Comparaison des coûts

La comparaison des coûts entre l'utilisation d'ASK et un ECS prépayé:

À partir du calcul des coûts ci-dessus, on peut voir que lorsque vous avez moins de 126 tâches CI / CD par jour, utiliser ASK + ECI sera plus rentable que d'acheter un ECS avec un abonnement mensuel. Tout en bénéficiant du paiement à la demande, il réduit également les coûts d'exploitation et de maintenance. Plus important encore, lorsque la taille de l'entreprise se développe et que le nombre de tâches CI / CD augmente fortement, il n'est pas nécessaire de s'inquiéter de l'expansion des nœuds Node. La solution ASK + ECI peut être considérée comme un standard sur mesure pour les scénarios d'intégration continue CI / CD.

Le compte officiel sans serveur publie les dernières informations sur la technologie sans serveur, rassemble le contenu le plus complet de la technologie sans serveur, prête attention à la tendance sans serveur et accorde plus d'attention à la confusion et aux problèmes que vous rencontrez dans votre pratique.