Déploiements GitHub (préversion) avec Google Cloud Platform : un guide essentiel

Motivation et présentation

Les aperçus de construction ne sont rien de nouveau ou d'innovant. Heroku les avait depuis des années. Cependant, si vous construisez sur Google Cloud Platform, les choses sont un peu plus difficiles. Google Cloud Build peut être utilisé pour déployer sur Cloud Functions, Cloud Run, Kubernetes, App Engine, etc. etc. C'est ce qui rend les aperçus légèrement compliqués, car Cloud Build ne sait pas où vous déployez votre application ou votre service. Ils ont une application GitHub pour connecter les référentiels et afficher l'état de la construction dans GitHub, mais c'est tout. Pas d'aperçus, de commentaires ou de trucs "normaux" auxquels nous sommes habitués avec des produits comme Heroku, Vercel ou Fly.

Il existe un moyen "simple" de publier un commentaire sur une requête d'extraction GitHub à partir de Cloud Build avec une simple requête HTTP. Mais pourquoi facile quand vous pouvez utiliser l' API GitHub Deployments .

Avec cette API, vous pouvez créer des environnements, avoir différentes variables par environnement et afficher l'état de construction et de déploiement directement sur une demande d'extraction. Et une fois le déploiement effectué sur votre plate-forme CD, vous pouvez ajouter l'URL à l'état du déploiement. C'est ce que nous allons faire dans cet article.

Statut de déploiement GitHub

Encore une fois, il existe une autre façon de procéder en utilisant l'API Deployments directement avec les requêtes HTTP. Cela peut parfois être délicat et vous devrez définir un jeton d'accès personnel pour vous authentifier auprès de GitHub. Au lieu de cela, nous avons décidé de créer un petit service Node.js qui utilise GitHub Apps pour générer un jeton d'application et interagir avec l'API Deployments. Cela permet un contrôle un peu plus fin du processus de déploiement.

Clause de non-responsabilité

Cet article est exclusivement écrit pour Google Cloud Platform et GitHub. Une compréhension de base de Google Cloud Platform, Google Cloud Build et des autorisations IAM est supposée.

Vous devez avoir configuré un projet Google Cloud Platform.

Déployeur GitHub (Node.js & Docker)

GitHub Deployer est un petit service Node.js autorisé avec une application GitHub et interagit avec l'API GitHub Deployments. Les commandes sont prédéfinies et certaines informations doivent être intégrées à l'image Docker, sinon la configuration d'exécution dans Cloud Build deviendrait trop complexe.

L'image Docker n'est pas prête à être créée ; vous devrez le construire vous-même et le pousser dans votre registre. Le meilleur endroit est Google Artifact Registry où les images de votre application sont également stockées (Container Registry est obsolète) :

1. Si ce n'est pas déjà fait, créez un dépôt Artifact Registry

   
   

2. Créez une application GitHub et installez-la sur votre organisation

   • Créer une application GitHub

   • Autorisations requises : 'pull_requests', 'deployments', 'metadata'

     
     

3. Copiez l'ID de l'application (à partir de l'écran Paramètres de l'application) et l'ID d'installation de l'application (après avoir cliqué sur "Configurer", vous trouverez l'ID d'installation dans l'URL. Aucune idée d'où cela peut être trouvé)

   
   

4. Créez et téléchargez une clé privée et convertissez-la en base64 ( base64 -i your.private-key.pem )

Créer l'image Docker

Source

Cloud Build s'exécute sur amd64 , nous avons donc besoin buildx pour créer l'image pour la plate-forme x86 :

docker buildx build --platform linux/amd64 . -t us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer \

--build-arg GH_APP_ID=[GITHUB_APP_ID] \

--build-arg GH_APP_PRIVATE_KEY=[GITHUB_PRIVATE_KEY_BASE_64] \

--build-arg GH_APP_INSTALLATION_ID=[GITHUB_INSTALLATION_ID] \

--build-arg GH_OWNER=[GITHUB_ORG]

Poussez l'image vers votre registre :

docker push us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer

Exécutez l'image Docker localement

docker run -it -e REPO_NAME=test -e REF=main -e ENVIRONMENT=test us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer:latest create

Variables d'environnement requises :

• REPO_NAME : requis le nom du référentiel (par exemple gh-deployer )
• REF : nécessite la branche, la balise ou le SHA à déployer (par exemple, main )
• ENVIRONMENT : nécessite l'environnement de déploiement (par exemple, preview )
• TRANSIENT_ENVIRONMENT : optionnel/false si défini sur true , le déploiement sera supprimé après un certain temps
• DESCRIPTION : facultatif une description du déploiement

Les commandes suivantes sont disponibles en premier argument :

• create - crée un nouveau déploiement
• pending - la construction est en attente
• in_progress - la construction est en cours
• queued - la construction est mise en file d'attente
• success - le déploiement a réussi
• error - quelque chose s'est mal passé
• failure - le déploiement a échoué

Avec Cloud Build, les options sont actuellement un peu limitées. Il n'y a pas d'état pending , car Cloud Build doit démarrer pour créer le déploiement initial. queued n'a pas beaucoup de sens non plus, donc dans notre propre configuration, nous utilisons ce qui suit :

1. gh-deployer/create pour créer le déploiement transitoire pour un commit
2. pgh-deployer/ending directement après la création
3. Exécutez kaniko build pour créer l'image Docker pour le déploiement
4. gh-deployer/in_progress une fois la construction terminée et avant le déploiement de l'image
5. gh-deployer/success après le déploiement de l'image

Encore une fois, avec Cloud Build, nous ne savons pas où se déroulera le déploiement. Il existe donc deux façons de transmettre l'URL de déploiement à l'étape success :

1. Dans une étape de génération, écrivez l'URL dans /workspace/deployer_environment_url
2. Passez un deuxième argument à l'image Docker après success

Nous utilisons Cloud Run pour nos déploiements. Voici donc l'étape de compilation permettant de récupérer l'URL de déploiement pour un numéro de demande d'extraction donné :

- nom : gcr.io/google.com/cloudsdktool/cloud-sdk

 env: - PR_NUMBER=$_PR_NUMBER script: >- gcloud run services list --project [project] --filter preview-$PR_NUMBER --format "value(status.address.url)" > /workspace/deployer_environment_url

Configuration de la création cloud/Terraform

cloudbuild.yaml

cloudbuild.yaml

Voici un exemple complet utilisant le fichier de configuration cloudbuild.yaml . Nous utilisons Kaniko pour compiler et Cloud Run comme cible de déploiement.

Si vous travaillez avec Terraform, un fichier Terraform est également disponible : preview.tf

Actions GitHub

En utilisant l'API Deployments, vous pouvez déclencher des actions GitHub sur deployment_status . Cela facilite l'exécution de contrôles d'assurance qualité, de tests de bout en bout, etc. sur chaque version d'aperçu. Voici un exemple d'exécution de Playwright sur chaque aperçu à l'aide de l' environment_url transmise pour l'état success :

dramaturge-qa :

 if: ${{ github.event.deployment\_status.state == 'success' }} timeout-minutes: 60 runs-on: ubuntu\-latest steps: \- uses: actions/[\[email protected\]](/cdn-cgi/l/email-protection) \- uses: actions/setup\-[\[email protected\]](/cdn-cgi/l/email-protection) with: node-version: 20 cache: 'npm' \- run: npm ci \- name: Install Playwright Browsers run: npm exec playwright install \-\-with\-deps \-y \- name: Run Playwright tests run: pnpm exec playwright test env: BASE\_URL: ${{github.event.deployment\_status.environment\_url}} \- uses: actions/upload\-[\[email protected\]](/cdn-cgi/l/email-protection) if: always() with: name: playwright\-report path: playwright\-report/ retention-days: 30

Optimisations

• l'image de base gcr.io/google.com/cloudsdktool/cloud-sdk est relativement grande. Vous pouvez créer votre propre petite image gcloud avec des composants Cloud Run pour accélérer les compilations.

Conclusion

Statut de déploiement GitHub terminé

Les commentaires sur les requêtes d'extraction GitHub sont faciles au début, mais lorsque vous avez plusieurs déploiements par requête d'extraction, des builds défaillants, etc., ils n'offrent pas beaucoup de flexibilité et sont difficiles à maintenir/mettre à jour. L'API GitHub Deployments offre un moyen élégant de créer et de gérer des déploiements à partir de n'importe quel système CI/CD tiers. Avec le GitHub Deployer nous avons essayé de rationaliser l'interaction avec l'API de déploiement et de prendre en charge certains effets secondaires ou pièges impossibles à résoudre uniquement avec l'API HTTP.

Un autre avantage de l'utilisation de l'API GitHub Deployments est que vous pouvez utiliser le déclencheur deployment_status pour les actions GitHub et obtenir l' environment_url directement avec la charge utile de l'événement.

Vous pouvez trouver des instructions d'installation/construction un peu plus détaillées et tout le code sur le dépôt GitHub

Si vous avez des questions ou des commentaires , n'hésitez pas à nous contacter sur BlueSky / Twitter ou à participer à la discussion sur GitHub .

Également publié ici.