Nous avons:
- **Amazon Route 53**: Qui héberge notre Hosted Zone et notre domaine (`mehdilaruelle.com`)
- **Amazon CloudFront**: Qui fait office de CDN (Content Delivery Network) et point d'entrée pour nos end users
- **AWS Certificate Manager**: Qui va héberger notre certificat et être utilisé par Amazon CloudFront pour le `HTTPS`
- **Un bucket S3**: Qui hébergera notre site web statique déployé par Hugo et uniquement accessible par Amazon CloudFront. Notre bucket est donc `privé`
L'ensemble de [l'infrastructure est déployé par Terraform](https://github.com/mehdilaruelle/terraform-aws-hugo-website).
## Remplacement de l'OAI par l'OAC
Dans l'architecture que nous avons vue, le bucket S3 est privé et est uniquement accessible par Amazon CloudFront.
Anciennement, la méthode utilisée était l'[Origin Access Identity (OAI)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-restricting-access-to-s3-oai) qui est aujourd'hui dépréciée.
En guise de remplacement, AWS a mis en place l'[Origin Access Control (OAC)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#create-oac-overview-s3).
Contrairement à l'OAI qui était vu comme un principal IAM CloudFront, ici l'OAC est vu comme une ressource AWS CloudFront.
Les avantages de l'OAC par rapport à l'OAI sont le support de:
- Tous les buckets S3 dans toutes les régions.
- Chiffrement server-side encryption avec AWS KMS (SSE-KMS)
- Requêtes dynamiques (PUT et DELETE) vers Amazon S3
Cette migration est plutôt simple car il suffit de:
1. [Créer un OAC](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudfront_origin_access_control)
2. [Mettre la bucket policy](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#migrate-from-oai-to-oac)
3. Mettre à jour Amazon CloudFront en remplaçant l'OAI par l'OAC
Vous retrouverez [le commit GitHub concernant cette migration](https://github.com/mehdilaruelle/terraform-aws-hugo-website/commit/163ce5812f9c338da4c9fcd8eb8f5ebc5e24e8dd) ou encore
la [documentation officielle d'AWS sur le sujet](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#migrate-from-oai-to-oac).
## Upgrade du Terraform provider AWS v5
Ce n'est pas tous les jours que le provider `AWS` de Terraform reçoit une mise à jour majeure et c'est donc tout naturellement que l'upgrade s'imposait.
Pour les plus curieux qui souhaitent en savoir plus sur les nouveautés du provider, je vous invite à [regarder le Upgrade Guide d'HashiCorp](https://registry.terraform.io/providers/BigEyeLabs/aws-test/latest/docs/guides/version-5-upgrade#provider-version-configuration)
Aucun impact au niveau du code Terraform mais je préfère explicitement l'indiquer au niveau du code Terraform:
```hcl
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~>5.0"
}
}
}
```
Pour ceux qui ne connaissent pas, vous avez [tfupdate](https://github.com/minamijoyo/tfupdate)
utilisable via le [pre-commit-terraform](https://github.com/antonbabenko/pre-commit-terraform#tfupdate) pour rester à jour sur vos dépendances.
## Github action et credentials dynamiques AWS
Jusqu'à peu, les déploiements de mes blog posts ou mise à jour des thèmes se faisaient localement depuis mon terminal car ma fréquence de déploiement de mes blog posts
était assez faible. Cependant, je faisais face à 2 problématiques:
1. À chaque déploiement, je pouvais avoir des problèmes de résidus de cache ou encore d'autres anomalies liées à mon environnement
2. Des credentials AWS statiques qui étaient utilisés une fois tous les 3 mois au mieux. Plutôt dommage pour des credentials statiques
Pour répondre à ces problématiques, j'ai:
1. Mis en place GitHub Action (gratuit jusqu'à 2000 minutes par mois) pour automatiser le déploiement de mon site à chaque `git push`
2. Mise en place de credentials AWS temporaires à chaque déploiement dans GitHub action
### Mise en place de GitHub Action
Mon objectif est: "À chaque `push` sur ma branche `master`, je veux que mon site `Hugo` soit déployé sur `S3`".
Bonne nouvelle, sur [GitHub Action](https://docs.github.com/en/actions) c'est possible de le faire (et gratuitement) assez facilement car il existe des [Actions](https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions).
Dans un premier temps, j'ai utilisé l'[Action Hugo](https://github.com/peaceiris/actions-hugo) de [peaceiris](https://github.com/peaceiris)
pour l'usage de Hugo dans Github Action.
Voilà le contenu de mon fichier `.github/workflows/main.yml` de GitHub action:
```yaml
name: Hugo deploy website on S3
on:
push:
branches: [ main ] # Only when a push is done on main branch
permissions:
contents: read # This is required for actions/checkout
jobs:
Build_and_Deploy:
runs-on: ubuntu-latest
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- name: Git clone the repository
uses: actions/checkout@v4
with:
submodules: 'true' # Some Hugo theme are imported as a submodule, so you need it
# Sets up Hugo with latest version
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
hugo-version: 'latest'
extended: true
- name: Build
run: hugo --minify
- name: Deploy to S3
run: hugo deploy --force
```
Si nous résumons les étapes de notre job, nous avons:
1. **Checkout**: Permet de cloner notre repository avec les submodules nécessaires pour les Hugo thèmes
2. **Setup Hugo**: Installation de **Hugo** en édition [extended](https://gohugo.io/installation/linux/#editions).
car certains de mes thèmes utilisent des fonctionnalités de cette édition
3. **Build**: On construit notre site web statique en version [minify](https://en.wikipedia.org/wiki/Minification_(programming))
4. **Deploy**: Enfin, on déploie notre site web Hugo sur S3
Pour que Hugo sache comment déployer, au niveau de l'étape 4, il faudra ajouter la bonne configuration au niveau du `config.toml`.
Dans mon cas, le bout de configuration ressemble à ça:
```toml
[deployment]
[[deployment.targets]]
name = "aws"
URL = "s3://hugo-website-mlaruelle?region=eu-west-3"
```
Remarque
L’URL doit contenir la region. La région dans mon cas est eu-west-3 (Paris).
Pour ce faire, j'ai mis en place [un Terraform pour mettre en place la Web Identity que j'invite les plus curieux à regarder](https://github.com/mehdilaruelle/terraform-aws-hugo-website/blob/master/github-action.tf).
Dans le [repository Terraform](https://github.com/mehdilaruelle/terraform-aws-hugo-website/tree/master), pour activer le déploiement de la Web Identity pour votre repository GitHub,
vous devez fournir les valeurs aux variables `github_org` (le nom de l'organisation GitHub) et `github_repositories` (Une liste de repositories GitHub autorisés à assumer le Web Identity role).
Dans mon cas, cela donne ça:
```hcl
github_org = "mehdilaruelle" # GitHub Organization name
github_repositories = ["blog_hugo"] # The list of GitHub repositories to allow to assume the Web Identity role
```
Puis faites un `terraform apply` et récupérez l'output de `aws_role_arn` via un `terraform output aws_role_arn`.
Gardez l'output, nous en aurons besoin pour la configuration de notre GitHub Action.
#### Étape 2: Mise en place du GitHub Action configure-aws-credentials-for-github-actions
Enfin, l'étape 2 consiste à ce que GitHub Action puisse assumer notre rôle.
Toujours en version simplifiée, cela représente ça:
Nous allons compléter notre GitHub Action Workflow avec l'action [configure-aws-credentials-for-github-actions](https://github.com/aws-actions/configure-aws-credentials#configure-aws-credentials-for-github-actions).
Pour ce faire, il faudra:
1. Ajouter la **permission** à notre workflow d'utiliser un [JSON Web Token](https://jwt.io/) GitHub.
2. Ajouter la **step** avec notre GitHub Action [configure-aws-credentials-for-github-actions](https://github.com/aws-actions/configure-aws-credentials#configure-aws-credentials-for-github-actions) tout en mettant notre `aws_role_arn` en paramètre de la step.
Ce qui nous donne le rendu final et fonctionnel suivant:
```yaml
name: Hugo deploy website on S3
on:
push:
branches: [ main ]
permissions:
id-token: write # This is required for requesting the JWT
contents: read # This is required for actions/checkout
jobs:
Build_and_Deploy:
runs-on: ubuntu-latest
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- name: Git clone the repository
uses: actions/checkout@v4
with:
submodules: 'true'
- name: configure aws credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::012345678912:role/GitHubOIDCRole # To replace with aws_role_arn
role-session-name: githubActionHugoDeploy
aws-region: eu-west-3
# Sets up Hugo with latest version
- name: Setup Hugo
uses: peaceiris/actions-hugo@v2
with:
hugo-version: 'latest'
extended: true
- name: Build
run: hugo --minify
- name: Deploy to S3
run: hugo deploy --force
```
Avec le résultat suivant, à la suite d'un `git push`, via GitHub Action:
## Auto setup d'ACM (AWS Certificate Manager)
Dans la construction du site web, nous partons du principe dans l'[article précédent](https://mehdilaruelle.com/fr/posts/2022/08/deployer-votre-site-hugo-sur-aws-avec-terraform/)
que le nom de domaine (ou sous domaine) est hébergé sur Amazon Route 53 et que la [Hosted Zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html) doit être créée manuellement.
Jusqu'à récemment, la création du certificat dans AWS Certificate Manger (ACM) devait aussi être manuelle. Chose révolue
à la suite de [ce commit](https://github.com/mehdilaruelle/terraform-aws-hugo-website/commit/620f4256444457dac919c93535a9a83d91996e05)
qui peut se résumer au travers du snippet suivant:
```hcl
resource "aws_acm_certificate" "hugo" {
provider = aws.aws_cloudfront # CloudFront uses certificates from US-EAST-1 region only
domain_name = local.dns_name
validation_method = "DNS"
}
resource "aws_route53_record" "hugo" {
for_each = {
for dvo in aws_acm_certificate.hugo.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.hugo.zone_id
}
resource "aws_acm_certificate_validation" "hugo" {
provider = aws.aws_cloudfront # CloudFront uses certificates from US-EAST-1 region only
certificate_arn = aws_acm_certificate.hugo.arn
validation_record_fqdns = [for record in aws_route53_record.hugo : record.fqdn]
}
```
Information
Vous pouvez retrouver ce snippet directement dans la documentation officielle d’HashiCorp.
Information
Dans le repository Terraform pour déployer ce site, le pre-commit-terraform est utilisé.