Cloud Seed : Déployer plus rapidement avec GitLab 🚀
Étiez-vous à la Cloud Next en octobre ? Google y a organisé son événement annuel où de nouvelles fonctionnalités autour sa plateforme Cloud sont présentées. Cette année fut l’occasion de découvrir un nouveau projet de GitLab : Cloud Seed.
⛅ 🌱 Cloud Seed ?
Qu’est-ce que Cloud Seed ? C’est un projet créé à la fin de 2021 par l’équipe incubatrice de GitLab et dirigé par Sri Rangan.
L’objectif de Cloud Seed est très simple : accélérer le déploiement de vos applications – présentes sur GitLab – vers Google Cloud Platform.
Ce projet a tout d’abord été ouvert en bêta testing. J’ai eu l’opportunité de faire partie de ces 100 personnes qui ont pu tester Cloud Seed et donner leur feedback en avant-première.
À la Cloud Next, Sri a annoncé la première release de Cloud Seed ! L’occasion de sortir ce projet de la phase de bêta testing et de le mettre à disposition de tous.
⏪ Avant Cloud Seed, les déploiements ressemblaient à ceci…
Avant Cloud Seed, les déploiements sur Google Cloud pouvaient être réalisés de plusieurs façons. Dans tous les cas, l’intégration et le déploiement continus de vos applications stockées dans GitLab sont réalisés avec un outil fait maison : GitLab CI. Écrits en Go, les GitLab Runners permettent d’exécuter très rapidement ces opérations de CI/CD définis dans des pipelines.
Il y a deux concepts à connaître quand on évoque GitLab CI : les “stages” et les “jobs”.
- un “stage” est une étape de votre pipeline, par exemple “test”, “build”, “deploy”, pour tester, construire et déployer votre application.
- un “job” est une entité très petite, qui va permettre de réaliser une opération sur votre application. Plusieurs jobs peuvent être présents dans le même “stage”.
La création d’un pipeline GitLab CI se fait dans un fichier de référence .gitlab-ci.yml.
Cette cheat sheet que j’ai créée explique les bases des pipelines GitLab CI : figure 1.
Retournons sur nos déploiements vers le Cloud. Je vais me focaliser uniquement sur des solutions basées sur GitLab CI. En excluant volontairement des outils externes comme Ansible et Terraform qui peuvent être exécutés à partir d’un pipeline GitLab CI, je retiens deux options pour déployer un projet sur GCP.
La première consiste à utiliser l’outil de ligne de commande (“Command Line Interface” – CLI) de Google, gcloud, que vous utilisez probablement déjà sur votre ordinateur.
À partir d’un nouveau job se basant sur l’image google/cloud-sdk, vous allez accéder à un environnement mettant à disposition l’outil gcloud. Après avoir configuré la partie authentification de votre projet, vous pouvez déployer rapidement avec gcloud une Cloud Function, une application avec App engine ou d’autres services Google. Ce job pourrait ressembler à ceci :
deploy-with-gcloud-image:
[...]
image: google/cloud-sdk:<version>
script:
- echo $GCP_SERVICE_KEY | base64 -d > /tmp/gcloud-service-key.json
- gcloud auth activate-service-account --key-file /tmp/gcloud-service-key.json
- gcloud functions deploy my_function [...]
Si vous travaillez sur un projet plus conséquent, déployé sur Google Kubernetes Engine, vous pouvez utiliser l’agent Kubernetes créé par GitLab il y a un an environ. Cet agent a remplacé une intégration Kubernetes plus ancienne, dépréciée dans la version 14.5 de GitLab et supprimée dans la version 15 sortie en 2021.
Comment l’agent fonctionne-t-il ? Vous configurez un agent sur votre projet GitLab. Cet agent est représenté par un ou plusieurs fichiers de configuration yaml. Après avoir déclaré dans l’interface de GitLab où se trouvait votre agent, GitLab vous donne une commande qui vous permettra d’installer cet agent sur votre cluster Kubernetes. Et c’est tout ! Après cela, chaque commit sur votre projet sera détecté par l’agent et votre application sera déployée automatiquement. Top !
Si malgré cela, vous voulez ou devez déployer des éléments sur votre cluster Kubernetes avec GitLab CI, cet agent vous offre la possibilité d’utiliser le “tunnel de CI/CD”.
Ce tunnel consiste à vous simplifier la connexion entre GitLab et votre cluster Kubernetes en déclarant uniquement votre agent. Dans un job basé sur l’image bitnami/kubectl, la déclaration de votre contexte Kubernetes avec votre agent vous suffira pour appliquer des fichiers yaml de configuration Kubernetes avec l’outil kubectl. Par exemple :
deploy-with-cicd-tunnel:
before_script:
- kubectl config use-context "group/project:agentk"
image:
name: bitnami/kubectl:
entrypoint: [""]
script:
- kubectl apply -f
L’intégration Kubernetes est expliquée dans cette cheat sheet : figure 2.
🚀 Cloud Seed, le facilitateur de déploiement
L’objectif principal de Cloud Seed est d’accélérer le déploiement de vos applications. Dans le précédent paragraphe, vous avez pu voir que la déclaration et rédaction d’un pipeline était une étape obligatoire pour pouvoir déployer votre application. Rien de vraiment compliqué, mais cela reste une tâche à réaliser et qui est généralement copiée collée d’autres projets.
Cloud Seed apporte également d’autres objectifs “indirects”. Si le déploiement de vos applications dans le Cloud est plus rapide et plus facile, cela permettra d’attirer et de convaincre d’autres personnes de migrer vers le Cloud. Ensuite, si ces applications sont déployées sur le Cloud, elles pourront profiter des avantages des plateformes Cloud, leur apportant de la modernité.
🔎 Comment Cloud Seed fonctionne ?
Cloud Seed est disponible dans GitLab à partir du menu “Infrastructure > Google Cloud”. Cela amène à voir une nouvelle page contenant trois parties : “Configuration”, “Deployments” et “Database” : figure 3.
Configuration
Cette première section, obligatoire, permet de configurer votre connexion à votre compte Google. Après avoir rentré et choisi votre compte Google, vous pouvez sélectionner votre projet GCP préalablement créé. Ensuite, vous spécifiez sur quelle branche Git vous voulez créer un compte de service : figure 4
Note : pendant mes tests, je n’ai pas essayé de créer des éléments sur une branche spécifique. Ce sera pour plus tard.
Après cette étape, vous verrez votre nouveau compte de service affiché à l’écran et dans votre projet GCP. La dernière chose à configurer est la région GCP. La région par défaut est “us-central1”.
Ces opérations impactent vos variables de CI/CD. En vérifiant dans la partie “Settings > CI/CD > Variables”, vous verrez une liste de variables configurées pour vous. Avant Cloud Seed, ces déclarations étaient à faire manuellement.
Déploiements
Maintenant que la configuration est effective, nous allons pouvoir se concentrer sur l’objectif principal de Cloud Seed : le déploiement de votre application.
Au moment d’écrire cet article, il y a deux services GCP visibles dans GitLab : Cloud Run et Cloud Storage. Seul Cloud Run est activé pour le moment.
Cloud Run est une plateforme serverless qui permet de se concentrer sur le développement. Cloud Run construit pour vous votre application à partir d’un Dockerfile ou, si ce fichier est manquant, essaye de déterminer la typologie de votre projet à partir d’une liste de buildpacks.
Cloud Seed vous permet d’intégrer Cloud Run à votre projet simplement avec une merge request contenant une modification sur le fichier .gitlab-ci.yml.
include:
- remote: https://gitlab.com/gitlab-org/incubation-engineering/five-minute-production/library/-/raw/main/gcp/cloud-run.gitlab-ci.yml
Cette modification crée un lien avec un autre projet GitLab, appartenant à GitLab, contenant des templates de CI/CD pour les différents services GCP.
En regardant ce fichier yaml dans le détail, nous pouvons voir que le job est assez simple :
deploy-to-cloud-run:
stage: deploy
image: registry.gitlab.com/gitlab-org/incubation-engineering/five-minute-production/library/google-cloud-sdk-for-gitlab:main
script:
- cp /cloud-run.sh .
- ./cloud-run.sh
Le job inclus dans votre projet sera exécuté dans le stage deploy dans un job appelé deploy-to-cloud-run. Ce job exécutera le script cloud-run.sh, sauvegardé dans le même projet. C’est un script shell qui vérifie la présence de toutes les variables nécessaires et exécute une commande gcloud telle que vous le feriez sur votre ordinateur ou dans votre CI.
Et c’est tout !
Si vous avez un fichier Dockerfile ou travaillez sur un projet dont sa typologie apparaît dans la liste des Google buildpacks, votre application sera déployée dans Cloud Run une fois ce job terminé.
Si vous avez un doute, vous pouvez voir dans la console GCP ou avec la CLI gcloud que vous avez bien un service Cloud Run en cours d’exécution : figure 5
L’application, dans mon exemple une API Quarkus, est bien disponible ! 🎉 : figure 6
Dans le job deploy-to-cloud-run, il y a la notion d’environnement que j’ai précédemment et volontairement mis de côté :
environment:
name: $CI_COMMIT_REF_NAME
url: $DYNAMIC_URL
Ces trois lignes vont permettre à Cloud Seed de créer un service Cloud Run par branche. Très pratique pour vérifier vos développements en cours.
Dans GitLab, vous pouvez visualiser ces environnements : figure 7
Un environnement, dans le sens GitLab, n’a pas d’action directe sur GCP. GitLab affiche les informations et vous permet d’accéder à l’URL accessible dans GCP.
Dans mon exemple (figure 7), trois branches sont présentes, deux possèdent l’intégration avec Cloud Run. Le bouton Open permet d’accéder à l’URL de votre service Cloud Run.
⚠️ Pour le moment, le bouton “Stop” n’a pas d’impact sur GCP. Votre service Cloud Run ne sera donc pas supprimé. Il permet seulement de supprimer l’environnement visible dans GitLab.
Bases de données
Cloud Seed permet également de créer des bases de données et d’afficher leurs informations directement dans GitLab. Actuellement, la création d’instance de bases de données Cloud SQL est possible en quelques clics pour Postgres, MySQL et SQL Server : figure 8.
Pour créer une base de données Postgres à partir de Cloud Seed, il suffit d’inscrire le nom, le type de machine, la version de Postgres et une référence de branche si l’on veut créer une instance de base de données pour cette branche uniquement : figure 9.
Après cette étape, vous verrez bien entendu cette nouvelle instance sur la console GCP ou via la CLI gcloud : figure 10.
Actuellement, seules ces informations sont disponibles sur GitLab : figure 11. Dans une issue que j’ai créée, je soumets l’idée d’en afficher plus 😄.
🗺️ La roadmap
Comme tous les projets GitLab, le plan de route de Cloud Seed est accessible à tout le monde. La roadmap prévoit de traiter la partie Cloud Functions and App engine : figure 12.
🔭 Le futur de Cloud Seed
Après avoir pu tester ces premières fonctionnalités, je suis content d’avoir pu constater et profiter de la rapidité et de la simplicité avec laquelle Cloud Seed nous permet de déployer des applications sur GCP sans avoir à écrire et à configurer la connexion avec GCP dans des jobs de CI/CD.
Cette étape n’est pas la plus difficile. Je le fais pour tester des services. Lorsque je développe, je souhaite me concentrer sur le développement.
Sur Cloud Seed et comme sur la majorité des projets GitLab, les feedbacks sont les bienvenus, sont pris en compte et permettent d’échanger et de participer à la roadmap de ce projet. Les contributions sont les bienvenues !
Depuis ces premiers tests, j’ai décidé d’intégrer Cloud Seed sur d’autres projets et attends avec impatience l’arrivée des prochaines intégrations de services GCP.
Pour expliquer rapidement ce qu’est Cloud Seed, j’ai créé cette 14ème cheat sheet GitLab : figure 13.
J’ai eu la chance de pouvoir présenter Cloud Seed au DevFest Nantes 2022. Si vous avez des questions ou des commentaires à propos de cet article ou de Cloud Seed, vous pouvez me contacter sur Twitter (@JPhi_Baconnais) 👋 , pinguer directement le compte Twitter de Cloud Seed (@OpenCloudSeed) ou venir sur le Discord GitLab où vous trouverez un canal #cloud-seed : https://discord.gg/gitlab.
🇬🇧 Cet article est également disponible en anglais sur dev.to
