(*) Le WeSpeakCloud est un meetup organisé par WeScale, une fois par mois sur des sujets autour du cloud computing.
Sans plus tarder, je vous présente le slot Architecture.
Dans ce chapitre, j’aborderai les différentes étapes de réalisation pour mettre en place l’infrastructure GCP, mettre en place GitLab et GitLab CI/CD.
L’intégration de GitLab avec Kubernetes peut se faire de deux façons :
Le but de cette intégration est de bénéficier de l'élasticité et la haute disponibilité de votre CI gérée par Kubernetes.
Vous avez un GitLab, et vous voulez le connecter avec un cluster Kubernetes afin de monter une CI/CD.
L’architecture peut varier d’un cas d’usage à un autre, mais le schéma classique de cette première solution contient généralement :
Compute Engine GitLab, idéalement sur deux zones différentes.instance profile permettant aux instances d’écrire sur GCS.auto-scaling qui garde un nombre minimum d’instances disponibles.load balancer en frontal des instances pour répartir le trafic entre les deux instances.hosted Zone dansCloud DNS pour la résolution DNS. Il faut prévoir son nom de domaine public pour le brancher avec cette zone.Le schéma suivant illustre les différents services utilisés :
opérations.Add cluster Dans cette fenêtre vous avez deux choix : créer un nouveau cluster GKE en suivant la documentation GitLab, ou choisir un cluster existant. Dans ce cas vous pouvez choisir un cluster hébergé ailleurs.le GitLab Runner qui nous intéresse dans cette partie.(k8s service account) que vous donnez à GitLab pour qu’il installe le tiller Helm dans k8s, créez un service account non admin sur le cluster avec des droits bien définis, par exemple.Une fois le Runner déployé, vous pouvez lancer un premier test sur votre CI GitLab, mais elle n’est pas encore prête à 100%. Ceci est un ensemble de points que j’ai eu à traiter pour que la CI soit prête :
Gestion de backup, il faut penser à sauvegarder régulièrement votre base de code.Gestion du cache, artifacts, etc .., permet de passer des dépendances, des résultats etc entre les stages.Configuration du Runner: il faut mettre à jour la configuration pour que le cache spot soit pris en charge.Pour le sujet CD, j’en parlerai dans la prochaine partie, puisque c’est déployé de la même façon.
Cette méthode présente certains avantages comme :
auto scaling pour implémenter la scalabilité et la haute disponibilité de votre machine GitLab, comme votre cluster GKE.Mais les inconvénients suivants :
autoscaling.Minio par exemple pour sauvegarder vos caches, artifacts, ...etc entre lesstage de votre CI.gitlab.tom pour qu’il puisse communiquer avecMini.Cette méthode est la plus simple à mettre en place en utilisant le Chart Helm fourni par GitLab. Une fois ce chart est installé, votre CI est déjà prête à être utilisée, il vous reste juste à gérer les backups. On en parlera plus loin dans l’article.
n1-standard-4, dans la zone europe-west1-b avec l’autoscaling activé. L'auto scaling est géré en toute transparence par GCP, et vous permet de scaler vos nodes assez facilement, en définissant le min_node_count et max_node_count de votre cluster.client_certificate, client_key ,cluster_ca_certificate et endpointpour configurer le client kubectl sur votre machine.Helm, et initialisez le client avec helm init. Helm se base sur la configuration kubectl dans ~/.kube/config afin de lancer son serveur appelé tiller sur k8s. Ce tiller est utilisé pour déployer les applications dans GKE.IP publique et une hosted zone branchée avec un domaine public. Ceci est un exemple Terraform qui vous permet de créer le nécessaire.chart Helm de GitLab. Vous pouvez le personnaliser en lui passant des paramètres au lancement. Dans notre cas, on a utilisé le nom de domaine, l’adresse IP publique créés précédemment et une adresse email pour signer les certificats déployés avec le chart.helm install gitlab/gitlab --name=gitlab --namespace=gitlab --set global.hosts.domain=gcp.mydomain.com --set global.hosts.externalIP=35.X.X.X
--set certmanager-issuer.email=myemail@wescale.fr
gitlab. Si vous avez les droits rbac activés dans votre cluster, votre déploiement risque d’échouer, puisque le tiller n’a pas les droits pour utiliser ce nouveau namespace. Il faut modifier/créer un serviceAccount et l’attacher au tiller.Après quelques minutes, si tout fonctionne bien, votre GitLab sera accessible depuis l’adresse gitlab.gcp.mydomain.com. Pour avoir les différents accès :
mot de passe de l’utilisateur root avec :kubectl get secret gitlab-gitlab-initial-root-password -ojsonpath='{.data.password}' -n gitlab | base64 --decode
Minio est accessible depuis l’addresse minio.gcp.my-domain.com.
user/password de Minio sont visibles avec :kubectl get secret minio-secret -ojsonpath='{.data.password}' -n gitlab | base64 --decode
Le chart Helm de GitLab, se repose sur d’autres charts pour déployer les différents composants afin de faire fonctionner le service. Je vous invite à regarder la documentation officielle si vous voulez en savoir plus.
Maintenant, allons voir ce qui s’est passé dans le cluster :
disques ont été créés sur votre compte. Oui, c’est normal, ce sont les différents disques utilisés par les différents pods qui assurent le service GitLab.load balancer attaché a votre DNS gcp.mydomaine.com et qui a comme target l’adresse ip publique que vous avez créée et attachée au node GKE. Pour accéder à GitLab depuis l'extérieur.gitlab avec kubectl get pods -n gitlab , vous allez voir plusieurs pods qui sont créés. Cela ressemble à ce schéma non exhaustif :maître qui lance les build GitLab CI en lançant d’autres pods runner.Dans cette deuxième implémentation, les backups sont poussés sur Minio plutôt que sur GCS. Ce choix est lié au fait que l’intégration est déjà faite dans le chart Helm de GitLab, avec toute la configuration nécessaire.
Un petit bonus, Minio peut être paramétré comme une gateway et utiliser le GCS.
Le reste à faire est d'ajouter un job qui tourne en continue pour créer et pousser les backups dans Minio. Cela nous mène au schéma suivant :
Notre Job est configuré comme suit :
CronJob Kubernetes qui se lance deux fois par jour, du lundi au vendredi, à 13h et à 20h: 00 13-20 * * 1-5.CronJob lance un job/pod qui exécute la commande GitLab backup-utility dans le pod gitlab-task-runner-*.zip et le pousse sur Minio.Notre application est déployée dans un cluster GKE, et on a choisi Helm comme outil de déploiement. L’idée est d’avoir un tiller (Helm) propre à chaque cluster Kubernetes, avec un service account attaché en lui permettant d’utiliser des namespaces spécifiques. Le tillersera utilisé par GitLab (le client Helm configuré dans un pod en vrai) pour déployer l’application. Cela est présenté par le schéma suivant :
Nous reviendrons avec plus de détails sur cette partie dans le 2ème article qui expliquera en détails la CI/CD.
Cette méthode présente des avantages :
Autoscaling à deux niveaux, au niveau pods et au niveau nodes (VM) gérés par GKE.Les limitations :
Dans cet article, j’ai présenté les deux possibilités pour avoir une CI/CD avec GKE et GitLab. J’ai fait un focus sur la deuxième méthode, que j’ai trouvée plus simple et plus rapide pour la mise en place. Pour le prochain article, Bassem et Alexis nous détaillerons la partie CI/CD de ce projet.