Comment mettre rapidement différentes pages de maintenance sur différents CloudFronts avec Gitlab CI & AWS CLI ?

Fonctionnement de notre application

Dans le cadre d’une infrastructure AWS, nous avons un CloudFront qui renvoie les fichiers du site présent sur le bucket S3 Amazon. Lorsqu’un utilisateur cherche à accéder au site web, Amazon Route 53 renvoie ce dernier vers l’adresse du CloudFront associé au niveau de son record.

Résumons le cas d’utilisation de notre frontend :

• [Users] - Les utilisateurs accèdent au site depuis leur navigateur
  
  
• [Route53] - Route53 renvoie le CloudFront associé au record de notre site
  
  
• [Cloudfront] - CloudFront renvoie le contenu du bucket.
  
  
• [S3] - La page index.html est chargée sur le pc de l’utilisateur.

Imaginons maintenant que vous ayez besoin de mettre en maintenance votre site. Nous allons remplacer la page index.html par la page maintenance.html présente au sein du bucket.
L’opération ressemble à cela :

Une fois la mise à jour du site réalisée, on peut de nouveau remplacer l’actuel index.html par maintenance.html et remettre old_index.html à la place de l’index.html.

CloudFront Cache settings

Amazon CloudFront nous permet de configurer le serveur d’origine de manière à ajouter des en-têtes aux fichiers, afin notamment d’indiquer combien de temps ces fichiers doivent rester dans le cache des emplacements périphériques CloudFront. C'est-à-dire combien de temps CloudFront doit garder une version de fichier avant de les mettre à jour.

Par défaut, chaque fichier reste 24h dans l’emplacement périphérique avant d’arriver à expiration, passé ce délai, CloudFront ira de nouveau récupérer la dernière version du fichier pendant 24h. Le délai d’expiration minimum est de zéro seconde. Il nous permet notamment d’indiquer à CloudFront qu’il ne doit jamais garder en cache certains fichiers.

L’upload de la page de maintenance va s’effectuer avec l’outil aws-cli s3 en mettant en place des paramètres pour le cache CloudFront:

--cache-control="public, max-age=0, must-revalidate"

Ici, on force le CloudFront à récupérer la page index.html sur le bucket sans jamais le mettre dans son cache. Cela permet d’éviter que certains utilisateurs soient sur une ancienne version de la page index.html lors d’une migration ou downtime.

WARNING : Si dans votre cas, le caching de votre page index.html ne force pas CloudFront à appeler le bucket s3 de façon systématique, il faut penser à rajouter une étape pour créer une invalidation de cache CloudFront sur la page index.html (Vous pouvez vous référer àla documentation AWS CLI).

GitLab CI/CD manual pipeline

Passons aux fichiers gitlab-ci.yml, dans le cas présent, nous utilisons des rules afin de spécifier à GitLab quelles pipelines lancer via les variables d’environnement :

• gitlab-ci.yml :

Ici nous utiliserons l’image AWS-CLI afin d’effectuer les modifications au niveau du bucket s3 souhaité. Nous utilisons le CLI pour mettre en place la page de maintenance avec un cache control null (public, max-age=0, must-revalidate). Il est également possible de rajouter un job supplémentaire pour créer une invalidation de cache CloudFront pour forcer les utilisateurs à récupérer la dernière version.

• cloudfronts/gitlab-ci.yml :

• Les jobs de mise en maintenance n’ont pas de règles when: manualde défini pour qu’ils se lancent directement au lancement de la pipeline
  
  
• Les jobs de rollback ont eux la rule when: manual pour permettre à l’utilisateur de lancer manuellement les jobs de sa pipeline une fois la maintenance du site terminée.

Étendons ces jobs pour l’ensemble des CloudsFronts voulu au sein de notre fichier cloudfronts/gitlab-ci.yml. Pour aller plus loin, si votre projet comporte de nombreux fronts, vous pouvez lancer l’ensemble de vos jobs de mise en maintenance avec la variable d’environnement TRIGGER_ALL_APPS mise à true au moment de lancer la pipeline :

• Ici, nous déclenchons manuellement la pipeline en précisant la variable TRIGGER_ALL_APPS à true. Cela fait référence à nos rules présentes dans le gitlab-ci.yml.

• Une fois votre maintenance terminée, vous pouvez lancer un à un les jobs de rollback, ou alors directement lancer l’ensemble des rollback.

L’utilisation de Gitlab Ci & AWS-CLI nous permet ici de pouvoir rapidement lancer des Pipelines depuis notre projet GitLab en cas d’incident. Il est également important d’avoir une stratégie de cache bien définit pour votre application. CloudFront utilise de base un cache pour vos fichiers, mais il est grandement recommandé de configurer les en-têtes des fichiers pour définir leur temps d’expiration sur le cache CloudFront.