La mode est au statique et c’est une bonne nouvelle !
Avoir besoin de gérer un serveur applicatif pour servir un site de contenu n’a pas un grand intérêt. Il existe à l’heure actuelle une flopée de générateurs qui vous permettront localement de démarrer un serveur pour rédiger votre contenu, apercevoir le rendu puis générer le site en HTML avant de le déployer.
L’objet de cet article n’est pas de se focaliser sur ces outils, mais si vous avez besoin de pointeurs sachez que Jekyll ou Pelican font le job.
Imaginons que vous ayez un site HTML à héberger, soit issu de la génération d’un outil, soit parce que vous écrivez directement vos pages HTML. Comment l’héberger simplement ?
Vous n’avez pas envie d’aller configurer un Nginx, encore moins Apache, ni même de prendre un serveur spécialement pour ça.
Vous savez que Let’s Encrypt c’est cool mais ça fait 3 fois que vous oubliez de renouveler vos certificats à l’issue des 3 mois et votre fichu cron de renouvellement automatique ne fonctionne pas…
Si vous ne vous sentez pas familier d’un de ces soucis, vous êtes sans aucun doute un barbu qui a automatisé toute son infra avec Terraform et qui a maintenant les doigts de pied en éventail devant son écran.
Autrement voyons ensemble comment déployer simplement son site sur S3.
Partons d’une bête page HTML que je souhaite utiliser pour mon site web personnel :
<html>
<body>Hello World !</body>
</html>
Partons à l’abordage de l’austère interface d’AWS. Si vous n’avez pas encore de compte créez-en un, je vous épargne le pas à pas.
Une fois connecté rendez-vous dans le service S3.
Maintenant créons un bucket en utilisant comme nom celui de notre site, dans mon cas martin.catty.fr. Il est important d’utiliser le DNS exact.
Libre à vous de choisir la région, j’ai gardé l’Irlande qui est le choix par défaut sur mon compte.
On n’active aucune des propriétés type versioning, journalisation, etc.
Il est de bon ton de restreindre l’accès à vos buckets. J’ai tendance à avoir un utilisateur dédié par bucket, ce qui permet de limiter les dégâts en cas de compromission de l’accès (notamment une fuite de clés). Nous nous rendons cette fois dans le service IAM de gestion d’identité de l’interface.
On crée un utilisateur qui n’aura accès à AWS que par le biais de l’API, il ne pourra pas se connecter directement à l’interface.
En termes d’autorisation, on attache directement une stratégie existante.
En fait ma stratégie n’existe pas encore, donc je vais la créer via le bouton dédié. Je souhaite ajouter une police d’utilisation permettant à cet utilisateur d’accéder à ce bucket.
Dans le nouvel onglet on choisit « Créer votre propre stratégie »
Vous pouvez nommer votre stratégie comme bon vous semble, j’ai choisi AccessToWebsiteBucket. Je vous laisse faire preuve d’imagination pour la description.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::martin.catty.fr"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::martin.catty.fr/*"
}
]
}
Cette police me donne accès à la racine du bucket et au reste. Je vous conseille de la tester avec le bouton « Valider la stratégie » avant de la créer. Une fois terminé, revenez sur l’écran de création de l’utilisateur et rafraîchissez la liste des stratégies.
Je vois maintenant apparaître la police que je viens de créer, je la choisis et je passe à la suite. L’écran suivant est capital, il vous donne les informations de connexion relatives à votre utilisateur ; conservez-les précieusement elles ne seront plus accessibles une fois la page fermée.
Nous allons maintenant installer le client AWS. Vous pouvez l’installer via brew install awscli sur OSX ou encore en utilisant pip, le gestionnaire de paquets de python.
Il est temps de configurer nos credentials (ID de clé d’accès et clé d’accès secrète) que nous avons récupéré de l’interface AWS.
Pour ce faire nous allons créer le fichier ~/.aws/config et configurer notre profil :
[profile martin-catty]
aws_access_key_id = XXX
aws_secret_access_key = YYY
Vous pouvez donner le nom que vous souhaitez à votre profil. Nous pouvons maintenant vérifier que nous avons accès au bucket avec ce profil en utilisant le client AWS :
aws s3 ls s3://martin.catty.fr --profile martin-catty
Si tout se passe bien, la commande ne renverra… rien. C’est normal notre bucket est vide. Poussons-y un fichier pour nous assurer que tout fonctionne.
touch /tmp/foo
aws s3 cp /tmp/foo s3://martin.catty.fr --profile martin-catty
upload: ../../../../../tmp/foo to s3://martin.catty.fr/foo
A priori tout est en ordre, si vous relancez la commande pour lister le contenu de votre bucket vous y verrez votre fichier foo.
Sur le même principe mettons-y notre fichier index.html.
Nous savons dorénavant mettre des fichiers dans un bucket, activons l’hébergement de site avec S3. Pour ce faire, retour dans l’interface AWS, service S3, on clique sur notre bucket, onglet propriété.
On active la propriété « Hébergement de site Web statique » en indiquant que le document d’index sera index.html.
En suivant le point de terminaison donné par AWS (dans mon cas http://martin.catty.fr.s3-website-eu-west-1.amazonaws.com/), on aura droit à une 403. C’est normal, de base le reste du monde n’a pas accès à notre bucket, fort heureusement.
Il faut donc ajouter une police au niveau du bucket cette fois, dans l’onglet « Autorisations ».
{
"Version":"2012-10-17",
"Statement":[{
"Sid":"PublicReadGetObject",
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::martin.catty.fr/*"]
}
]
}
Celle-ci permet à n’importe qui de lire les fichiers dans le bucket. En rafraîchissant on a maintenant notre index.
C’est bien, mais on souhaite que le site soit disponible à travers HTTPS, sans avoir à acheter de certificats ni à gérer le renouvellement.
Chez AWS il y a un service pour ça : Certificate Manager. Avant de démarrer le processus assurez-vous de basculer sur la région «Virginie du Nord» car c’est un pré-requis du service dans lequel nous allons utiliser notre certificat.
On suit le processus, qui nous enverra une confirmation par email pour vérifier que nous sommes bien propriétaires du site.
Une fois la requête approuvée, notre certificat est prêt. La subtilité de ces certificats est qu’on ne peut pas les récupérer pour les utiliser à l’extérieur d’AWS, vendor locking quand tu nous tiens.
Nous allons donc devoir le rattacher à une distribution CloudFront.
CloudFront est un CDN, c’est-à-dire qu’il permet de diffuser des contenus au plus près des utilisateurs, en les répliquant dans différents points de présence.
Cela permet de limiter la latence et les temps d’affichage quel que soit l’endroit dans le monde où se situent nos utilisateurs.
Nous créons donc une distribution de type web.
Pas d’inquiétude devant ce formulaire copieux, allons-y pas à pas. Dans le nom du domaine d’origine nous choisissons notre bucket qui doit être listé.
Niveau stratégie de protocole on choisit de rediriger automatiquement HTTP vers HTTPS.
Plus bas dans les paramètres de distribution ont saisit comme domaine alternatif martin.catty.fr, on choisit le certificat précédemment créé et on crée la distribution.
Enfin nous définissons index.html comme objet racine par défaut.
Le processus de création de la distribution prend un peu de temps, notez toutefois dans un coin le DNS de la distribution CloudFront.
Il ne reste plus qu’à faire pointer votre nom de domaine sur la distribution CloudFront, pour cela il vous suffit d’enregistrer votre nom de domaine en tant que CNAME de la distribution CloudFront.
Si vous utilisez Route53 (le service de DNS d’Amazon Web Services), c’est un peu différent, créez un enregistrement de type A. Choisissez oui par Alias et vous devriez maintenant pouvoir choisir la distribution CloudFront dessous.
Voilà c’est terminé !
Certes il y a quelques étapes à parcourir pour y arriver mais maintenant pour mettre à jour votre site, il suffit d’une simple commande avec le client AWS telle que :
aws s3 sync . s3://martin.catty.fr --profile martin-catty
Cette commande va copier uniquement les fichiers modifiés vers votre bucket. Temps de déploiement : 3 secondes !
L’équipe Synbioz.
Libres d’être ensemble.
