Déployer à chaque push

D'un premier déploiement à la main à un déploiement à chaque push, depuis GitHub Actions ou GitLab CI/CD, avec un identifiant qui ne peut rien faire de plus, et ce qui se passe quand une version échoue.

Une demi-heure. À la fin, un push sur votre branche principale se déploie tout seul, le job passe au rouge quand la version est mauvaise, et une mauvaise version ne fait pas tomber le site.

Avant de commencer

  • La CLI, installée et connectée. Voir Installer la CLI.
  • Un dépôt sur GitHub ou GitLab, connecté à votre organisation. isogrid repos list doit l'afficher, avec create-app et deploy dans la colonne YOU. Voir Dépôts Git.
  • jq sur votre machine, pour l'étape 2.

Ce tutoriel appelle l'application shop et le dépôt acme/shop.

1. Déployer une fois à la main

isogrid apps create --name shop --url https://github.com/acme/shop \
  --replicas 2 --public --wait

Vous devez voir Build #1 succeeded., puis shop is running. et son adresse. Ouvrez-la.

Ne sautez pas cette étape. Un pipeline qui échoue à sa première exécution peut échouer à cause de l'identifiant, des variables ou de l'application. Après un premier déploiement à la main, seule l'application peut être en cause.

Deux copies, pas une. Avec une seule copie, il n'y a nulle part où démarrer la nouvelle version pendant que l'ancienne répond : chaque déploiement a une coupure de quelques secondes.

2. Créer un identifiant pour le pipeline

Pas le vôtre. Un identifiant réservé à la CI, révocable sans vous déconnecter :

export ISOGRID_CONFIG_HOME="$(mktemp -d)"
isogrid --api https://api.isogrid.skyvault.pro login \
  --scope application:write-any \
  --name shop-ci

Le navigateur s'ouvre sur la page d'approbation. Vérifiez l'organisation qui y est affichée : l'identifiant y est rattaché et est refusé partout ailleurs. Approuvez, puis affichez le jeton et supprimez la configuration temporaire :

jq -r '.contexts[].token' "$ISOGRID_CONFIG_HOME/config.json"
rm -rf "$ISOGRID_CONFIG_HOME"
unset ISOGRID_CONFIG_HOME

Vous devez voir une longue ligne : le jeton. Copiez-le maintenant.

N'oubliez pas la dernière ligne. Sans elle, ce terminal continue de chercher votre connexion dans un dossier qui n'existe plus.

La portée est volontairement courte. L'application existe : le pipeline n'a pas besoin de application:create, et une faute de frappe dans son nom échoue au lieu de créer une seconde application. application:deploy-any est plus restreinte encore, et suffit tant que le pipeline ne passe aucun paramètre : pas de fichier d'environnement, pas de changement de branche.

Un identifiant dure 90 jours, sauf si vous avez choisi une durée plus courte sur la page d'approbation. Notez la date dans votre agenda.

3. Le donner au système de CI

GitHub, sous Settings → Secrets and variables → Actions : un secret nommé ISOGRID_TOKEN, et une variable nommée ISOGRID_API_URL avec la valeur https://api.isogrid.skyvault.pro.

GitLab, sous Settings → CI/CD → Variables : ISOGRID_TOKEN, marquée Masked, et ISOGRID_API_URL.

Ne marquez le jeton Protected que si la branche qui déploie est protégée. Une variable protégée n'est pas transmise aux autres branches, et le job indique alors not signed in.

4. Ajouter le pipeline

À la racine du dépôt :

isogrid ci init github --app shop
isogrid ci init gitlab --app shop

Lancez celle qui correspond à votre hébergeur de code. Vous devez voir Wrote .github/workflows/isogrid-deploy.yml (ou .gitlab-ci.yml), suivi des deux réglages de l'étape 3. Committez le fichier et poussez.

--app doit être le nom de l'étape 1. Sans cette option, le pipeline utilise le nom du dépôt. Si les deux diffèrent, il cherche une application qui n'existe pas, tente de la créer et se voit refuser, ce à quoi sert justement la portée courte.

Un fichier existant n'est pas écrasé. --output - affiche le pipeline à la place, pour fusionner le job dans celui que vous avez.

5. Suivre la première exécution

Le push la déclenche. Dans le journal du job, vous devez voir la version de la CLI, puis Started build, Build … succeeded. et shop is running. Le job est vert.

Ce qu'il a fait : demander si shop existe, construire exactement le commit que vous avez poussé, et non ce vers quoi la branche pointe à ce moment-là, puis attendre le résultat.

S'il passe au rouge avant de construire quoi que ce soit, faites de isogrid whoami la première commande du job. Elle affiche à qui appartient l'identifiant, son organisation et ce qu'il peut faire. not signed in signifie que le jeton n'est pas arrivé jusqu'au job. Une erreur de permission, c'est la portée.

6. Pousser une version qui échoue

Une fois, exprès. Faites en sorte que l'application s'arrête au démarrage, et poussez.

Vous devez voir le job échouer avec shop was rolled back to the previous version, suivi de la raison. Ouvrez maintenant l'adresse : la version précédente répond toujours.

Un job rouge avec le site toujours en ligne, c'est la plateforme qui fonctionne. La nouvelle version n'est jamais devenue saine : l'ancienne a été remise en place.

Pour voir pourquoi, puis corriger et pousser de nouveau :

isogrid apps status shop
isogrid apps logs shop

Une construction qui échoue arrête le job plus tôt, et rien n'est déployé.

7. Décider de ce que fait un échec

Sur la page de l'application, ouvrez Déploiements en échec.

  • Revenir en arrière automatiquement est le choix par défaut : la version précédente est rétablie dès qu'une nouvelle copie échoue.
  • Arrêter et me laisser décider arrête le déploiement à la première copie en échec. Les copies pas encore remplacées gardent la version précédente.
  • Ne jamais revenir en arrière donne la nouvelle version à toutes les copies, même si certaines échouent. Utile pour déboguer une version ; l'application peut être indisponible jusqu'à votre correction.

Fenêtre de surveillance (secondes) est le temps pendant lequel une nouvelle copie doit rester active pour être considérée comme saine : 30 par défaut, de 5 à 300. Augmentez-la pour une application lente à démarrer, sinon une version qui allait fonctionner sera sans cesse annulée. Enregistrer la politique ; elle s'applique à partir du prochain déploiement.

Rien de tout cela ne rattrape une version qui démarre correctement et qui est simplement fausse. Pour cela, le bouton Revenir en arrière, en haut de la page, revient à la version qui tournait avant le dernier déploiement : image, environnement, secrets et taille ensemble. Annulez ensuite le commit et poussez. Le prochain déploiement applique de nouveau les réglages actuels, et le prochain push ramènerait le mauvais commit.

Pour continuer