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 :
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.
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).
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 :
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.
É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 :
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.