Déployer automatiquement un service Cloud Run avec Cloud Build

Publié le mercredi 24 février 2021
#Cloud Build #Google Cloud #Cloud Run #COVID-19 #Ensemble de données publiques #Microservice
This post thumbnail

Déployer Cloud Run Covid 19 API avec de Cloud Build

Dans cet article, nous allons automatiser le déploiement du projet Cloud Run COVID-19 API de l’article précédent à l’aide de Cloud Build.

Dans l’article précédent, le projet a été créé à l’aide du plug-in Visual Studio Code et le service est déployé manuellement à l’aide de l’explorateur Cloud Run. Cela demande à toutes les fois que l’on veut tester le service dans le nuage d’appuyer sur le bouton et attendre le résultat.

Alors que la mise en place d’un déploiement continue va permettre d’automatiser le tout et de pouvoir par la suite ajouter des séries de tests pour valider nos nouvelles versions. C’est une première étape dans la mise en place d’un processus d’intégration continue lors du développement d’une application.

Aussitôt qu’un push sera effectué vers la branche main du référentiel GitHub du projet, le service Google Cloud Build récupérera les fichiers sources, fera les tests, déploiera automatiquement une nouvelle version du service sur Cloud Run.

Allons-y.

Configurer en place le déploiement continu

Première étape, allons sur la console à l’onglet Cloud Run. Cliquons sur le service que nous voulons déployer en continu. Pour notre exemple, cliquons sur covid19-api.

Nous avons un aperçu général du service avec divers onglets. Au haut de l’écran, il suffit de cliquer sur “SET UP CONTINUOUS DEPLOYMENT” :

Configurer le déploiement continu Configurer le déploiement continu

Apparaît alors l’écran suivant “Set up with Cloud Build” :

Activer l'API Cloud Build Activer l'API Cloud Build

Si l’API Cloud Build n’est pas encore activé pour le projet, on peut l’activer à ce moment.

Le code source du projet étant hébergé sur GitHub, nous allons choisir cette option à la liste déroulante “Repository Provider”. Il est possible aussi d’utiliser BitBucket comme référentiel du code source.

Nous allons pouvoir nous identifier sur GitHub et un écran d’autorisation de déléguer l’accès à GitHub sera affiché :

Autoriser Google Cloud Build Autoriser Google Cloud Build

Ensuite, il suffit de choisir le projet à déployer à l’aide de Cloud Build :

Choisir le projet à déployer Choisir le projet à déployer

Par la suite, nous pouvons choisir le nom de la branche qui sera surveillée et le type de fichier utilisé pour créer l’image. Nous allons choisir la branche principale main et le “Build Type” Dockerfile et inscrire la localisation et le nom du fichier.

Choisir la branche du projet à déployer Choisir la branche du projet à déployer

Cliquons sur SAVE et le premier déploiement sera effectué automatiquement.

Premier déploiement sur Cloud Run Premier déploiement sur Cloud Run

Nous pouvons vérifier si le tout fonctionne en modifiant notre code source et en faisant un PUSH sur GitHub de notre projet.

Note : Il est possible de modifier les “triggers” pour utiliser d’autres types de “trigger”, par exemple lors de l’ajout d’une étiquette particulière (tag) sur GitHub ou BitBucket. Il est même possible de le faire à l’aide d’un webhook. Voir la section référence pour plus de détails.

Ajout du Hash de GitHub lors du Build

Cependant comme dans le projet, on désire insérer le HASH identifiant la version du projet déployé afin de pouvoir offrir un point d'arrivé /version qui permet de vérifier la version du service en ligne.

Pour ce faire, nous allons devoir récupérer le fichier en YAML qui a été créée “Inline” lors de la configuration. Et l’utiliser pour en faire une version modifiée que nous allons conserver directement dans notre référentiel. Il est possible d’examiner le contenu du fichier en allant éditer le trigger dans la console de Cloud Build à la section Build Configuration :

Fichier YAML inline à copier Fichier YAML inline à copier

En copiant le contenu du fichier inline dans un fichier CloudBuild en format YAML local et en supprimant la section substitutions. Le contenu des variables de substitution est déjà inclus dans la configuration du trigger de Cloud Build, les valeurs ont été inscrire lors de la configuration du déploiement en continu.

Variables de substitution Variables de substitution

Pour insérer le hash court provenant de GitHub, nous ajoutons les lignes suivantes à la section Deploy :

      - "--update-env-vars" 
      - "VERSION_HASH=${SHORT_SHA}"

Cela donne le fichier cloudbuild-generer-automatiquement.yml suivant :

steps:
  - name: gcr.io/cloud-builders/docker
    args:
      - build
      - '--no-cache'
      - '-t'
      - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
      - .
      - '-f'
      - Dockerfile
    id: Build
  - name: gcr.io/cloud-builders/docker
    args:
      - push
      - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
    id: Push
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    args:
      - run
      - services
      - update
      - $_SERVICE_NAME
      - '--platform=managed'
      - '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
      - >-
        --labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS
      - '--region=$_DEPLOY_REGION'
      - '--quiet'
      - "--update-env-vars" 
      - "VERSION_HASH=${SHORT_SHA}"
    id: Deploy
    entrypoint: gcloud
images:
  - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
options:
  substitutionOption: ALLOW_LOOSE
tags:
  - gcp-cloud-build-deploy-cloud-run
  - gcp-cloud-build-deploy-cloud-run-managed
  - covid19-api

Pour déployer à nouveau le service, il suffit de faire un PUSH sur GitHub dans la branche main.

Une fois le Build automatisé, il est possible de vérifier si le service à bien la bonne valeur de SHORT HASH en allant interroger le point de service :

Vérification du SHA Vérification du SHA à l'aide de l'API

Conclusion

Cet article démontre qu’il est relativement peu complexe d’automatiser le déploiement d’un microservice à l’aide des outils sans serveur de Google Cloud. Dans un futur article, je vais montrer comment faire une série de tests d’intégration pour vérifier que le service fonctionne bien. Pour l’instant, seuls les tests unitaires sont effectués lors du déploiement à l’étape de la création de l’image Docker. C’est à suivre...

Références

Article précédent : Rendre disponible des données d’un ensemble BigQuery à l’aide de Cloud Run

Code source du projet : https://github.com/konato/covid-19-cloud-run-bigquery-api

Cloud Run

Cloud Build

https://cloud.google.com/code/docs/vscode/quickstart-cloud-run

https://cloud.google.com/build/docs/automating-builds/create-github-app-triggers

https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values