Déployer un site statique client-side via Amazon S3

J'ai souvent tendance à traiter le déploiement au dernier moment. Ce qui est rarement une bonne solution. Et puis, à quoi bon s'arracher les cheveux à développer des fonctionnalités si elles ne sont de toute façon pas utilisables par les autres ?

Le déploiement fait partie intégrante des attentes durant la période d'intégration chez Marmelab. Et comme la méthode agile implique que le Product Owner puisse tester l'applicatif en cours de développement, j'ai dû sortir de ma zone de confort pour livrer au plus vite.

Voici la recette que j'ai appliquée. Voyez-la comme une introduction à la mise en ligne d'un site statique ou d'une Single-Page App via le service Amazon S3. J'espère qu'elle vous fera gagner du temps, et vous permettra d'éviter les principaux écueils.

Présentation

S3 Buckets

Amazon Simple Storage Service, abrégé en "Amazon S3", est un service proposé par AWS pour créer et gérer des espaces de stockage de données (compartiments ou "buckets" dans le jargon Amazon) sur l'internet.

Il y a quatre classes de stockage distinctes selon les besoins :

• Standard : accès fréquent, c'est celui par défaut et qui est utilisé dans ce tutoriel.
• Standard Infrequent Access : accès peu fréquent.
• One Zone-Infrequent Access : accès peu fréquent, mais une forte rapidité d'accès.
• Amazon Glacier : accès extrêmement peu fréquent et très faible rapidité d'accès.

Pour quelle utilisation ?

Ces compartiments peuvent être utilisés pour héberger des sites internet "statiques", au sens de fichiers HTML figés. Ils permettent aussi l'hébergement de sites "dynamiques" qui sont rendus directement sur le navigateur des visiteurs (Single-Page Apps). Pour en savoir plus sur les différents types de rendu des sites web, je vous recommande ce chouette article.

Par contre, aucun code source ne peut y être exécuté. Il n'est donc pas possible d'y héberger la partie backend d'un site internet. Pour cela je vous suggère par exemple ECS.

Démarrage rapide

Créer un premier compartiment de données

Assez discuté, je vous propose de commencer à mettre les mains dans le cambouis.

1. Créez un compte sur la plateforme Amazon Web Service (carte bancaire requise).
2. Accédez au service S3 via la barre de recherche (vous pouvez le mettre en favori pour la suite).
3. Cliquez sur Créer un compartiment.
4. Choisissez le nom pour votre stockage et une région.
5. Confirmez la création.

Maintenant que vous avez votre bucket, il faut le configurer pour qu'il puisse servir à héberger un site :

1. Ouvrez votre nouveau bucket.
2. Activez Hébergement de site Web statique dans Propriétés -> Hébergement de site Web statique et laissez les options par défaut.
3. Dans le champ Document d'index, entrez le nom du fichier HTML qui sert de page d'accueil de votre site web.

Dépôt de fichiers à la main

Votre bucket est prêt à l'emploi, je vais maintenant vous montrer comment vous en servir.

Si vous n'avez pas de quoi tester sous la main, je vous propose d'utiliser cette superbe démo de React-Admin.

1. Dans votre compartiment, dans Objets, cliquez sur Charger.
2. Sélectionner (bouton ou glissez-déposez) les fichiers constituant votre site.

3. Validez l'opération.

Mise à disposition du site

Notre site est stocké dans le compartiment, il ne reste plus qu'à le rendre accessible.

Pour cela vous pouvez utilisez le service de Content Delivery Network d'AWS nommé Cloudfront et qui vous octroie en prime plusieurs bonus.

• Prise en charge du HTTPS
• Réduction de la latence

Création d'un proxy Cloudfront

1. Recherchez Cloudfront dans la barre de recherche d'AWS.
2. Cliquez sur Créer une distribution.
3. Dans le champ Domaine de l'origine, sélectionnez le bucket précedemment créé.
4. Chargez ensuite la politique d'accès comme indiquez dans la capture ci-dessous, cela permet à Cloudfront de requêter votre bucket privé.

5. Validez.

Votre Cloudfront sera déployé dans quelques minutes, et avec lui un nom de domaine sera disponible pour vous permettre d'accéder à votre site.

Résultats

Votre site est maintenant en ligne, bravo 🎉!

Comme vous pouvez le constater, le HTTPS est fonctionnel par défaut. En fait, Amazon a généré automatiquement un certificat SSL avec votre nom de domaine.

Malgré tout, il est d'usage d'offrir aux utilisateurs un nom de domaine un peu plus pertinent. Vous pouvez lire cet article pour utiliser le vôtre.

J'étais très content à cette étape car j'avais une app accessible depuis n'importe où, que de joie ! Mais c'était sans compter un petit imprévu.

Invalidation du cache

En effet, durant la seconde mise en ligne je ne voyais aucune modification s'effectuer sur le site...

Cela s'explique par la mise en cache des fichiers à travers les différents serveurs constituant le CDN d'Amazon. Dès lors, les modifications au niveau du bucket ne sont pas répercutées sur le site.

Heureusement, à tout problème existe sa solution (enfin presque) : ici la technique consiste à invalider les anciens fichiers mis en cache pour en diffuser de nouveaux.

1. Remplacer les fichiers de votre bucket
2. Dans votre distribution Cloudfront, cliquez sur Créer une invalidation.
3. Entrez le nom des fichiers à invalider, sinon vous pouvez tous les invalider avec /*
4. Appuyer sur Invalider.

Tarification

Les systèmes de tarification des services AWS mériteraient sans doute un article à part entière. À défaut, voici quelques ressources utiles.

D'abord pour la tarification des buckets S3, vous pouvez trouver des informations ici : https://aws.amazon.com/fr/s3/pricing/.

Pour Cloudfront, l'usage est gratuit en dessous d'un certain volume mensuel. Pour en apprendre plus, c'est ici : https://aws.amazon.com/fr/cloudfront/pricing/.

En pratique, l'hébergement d'un site statique via AWS S3 et CloudFront est peu onéreux - moins de 10€ pour le blog de Marmelab, qui fait plus de 80 000 vues par mois.

Retour d'expérience

Malgré mon manque d'expérience concernant la plateforme AWS, elle m'a été suggerée durant l'intégration du fait de son utilisation fréquente dans les projets à Marmelab.

Pour ne rien vous cacher, je me suis senti plutôt perdu lors de mes premiers pas et ce, notamment, à cause de la densité de services mis à disposition. Finalement le domptage des services requis (une fois bien identifiés) a été fluide notamment grâce à la pléthore de documentations disponibles.

Je privilégierai cependant sur de futurs projets perso d'autres solutions comme Gitlab Pages ou Github Pages. Elles sont gratuites, rapides à mettre en oeuvre, intégrées à la CI et aussi branchables à un CDN.

Il n'empêche que je ne regrette pas cette expérience. Elle m'a permis de me familiariser avec AWS et son vaste écosystème que je vais très probablement réutiliser bientôt.

Conclusion

Vous avez découvert les étapes minimales pour déployer un site internet statique.

Maintenant que vous savez déployer votre site, il est temps d'automatiser ce processus, pour qu'il s'exécute par exemple à chaque publication sur votre branche de production. Vous pouvez vous inspirer de cet exemple de déploiement continu via GitHub Actions mis en oeuvre dans le cadre d'un projet d'intégration à Marmelab.

L'hébergement de Single-Page-Apps avec cette technique peut amener des soucis de Cross-Origin Resource Sharing (CORS), il faut donc pouvoir autoriser le domaine proposé par CloudFront (ou le domaine spécifique si vous en avez un) au niveau du serveur d'API.

Il existe de nombreuses alternatives à AWS S3+CloudFront, toutes fonctionnant peu ou prou sur le même principe. La tarification peut parfois varier beaucoup, mais comme il s'agit de toutes façons de petits montants, la meilleure solution est celle que vous connaissez déjà et qui ne vous fait pas perdre de temps.