Comment héberger son site Astro ?

Une fois mon site créé à l’aide d’Astro Build, la seconde étape a été de trouver un hébergeur pour mon site.
Astro diffère un peu des sites CMS traditionnels tels que Wordpress, car il s’agit principalement d’un site statique.

On verra au travers de ce post le cheminement qui m’a conduit à installer, pour le moment, mon site sur le cloud AWS.

Pourquoi le cloud ?

Traditionnellement, l’hébergement d’un site Internet se faisait sur un serveur fournit par un hébergeur. On devait s’y connecter FTP(S) (et oui il y a 20 ans, on utilisait encore le FTP) pour y déposer les fichiers de notre site. Cette approche traditionnelle a encore de beaux jours devant elle, mais elle a ses limites me concernant.
En effet, elle nécessite un serveur dédié, ce qui a un coût, et surtout, il faut gérer la maintenance de ce serveur. En effet, l’hébergeur vous fournit le matériel, mais ensuite, c’est à vous, ou à l’hébergeur moyennant un coût supplémentaire, pour gérer la maintenance de ce serveur.

C’est pourquoi j’ai préféré me pencher sur des infrastructures cloud de type “serverless”.
Cela me permet de ne pas avoir à gérer de serveur et de ne payer que ce que j’utilise.

C’est quoi le serverless ?

Derrière ce terme se cache une infrastructure qui permet de déployer des applications sans avoir à gérer de serveur, ni même connaître l’infrastructure sous-jacente. C’est le fournisseur de cloud qui s’occupe de tout.

De quoi avons-nous donc besoin pour héberger un site statique sur une infrastructure serverless ?

Simplement d’un espace de stockage de type objet (object storage) et éventuellement d’un CDN, pour optimiser la distribution de notre site.

Quel fournisseur de cloud choisir ?

Initialement, je m’étais tout simplement dit que j’allais utiliser les pages de mon fournisseur GIT (github et gitlab).

Un point qui ne m’allait pas dans cette première option était qu’il fallait rendre public le code source de mon site. En soi, ce n’était pas un problème vu que j’utilise Astro Build ; mais je ne souhaitais pas rendre le contenu en cours de rédaction publique. De plus, si un jour, je fais une fausse manip comme uploader des credentials (ça peut malheureusement arriver un jour où on ne fait pas attention) alors, je ne souhaite pas rendre cela publique 😅

J’ai donc préféré me tourner vers un fournisseur de cloud sur lequel j’allais pusher le build de mon site hébergé sur un repository GIT privé.

Une fois ce choix fait, je m’étais fixé un objectif : passer par un fournisseur de cloud français.

J’ai essayé de faire l’inventaire des fournisseurs les plus connus sur le marché : OVHCloud, Outscale et Scaleway.

Celui qui a retenu le plus mon attention est Scaleway, dont les services se développent de plus en plus et qui possède une interface très fluide et intuitive.

Je n’ai rien contre OVHCloud qui, selon moi, possède le plus d’expérience. J’ai d’ailleurs un nom de domaine chez eux 😉 mais je n’ai pas trouvé d’offre qui correspondait à mes besoins ; et je n’ai pas été pour l’instant convaincu sur leur intégration dans des outils d’automatisation (CLI, Terraform).

Concernant Outscale, c’est un fournisseur très bien également mais, à mon sens, plus orienté grosse entreprise. Pour une TPE/SASU de ma taille, je n’ai pas trouvé d’offre qui correspondait à mes besoins.

Scaleway

Scaleway est un fournisseur de cloud français qui propose des services aussi bien Cloud que d’hébergement classique.

Ce que tu as poussé mon choix vers eux, c’est le nombre de services qu’ils proposent et leur intégration avec des outils d’automatisation tels que Terraform ou CLI.

Ils proposent l’ensemble des services basiques que je peux trouver sur AWS:

NOTE : une nouvelle fois, les autres clouds providers français restent aussi très intéressants, car ils développent également de plus en plus de services managés ; comme OVHCloud

Bref, personnellement, j’ai fait le choix de Scaleway qui possède par ailleurs un site web très attrayant 😀

Premiers tests sur Scaleway

Application que nous allons déployer

On se basera sur une application AstroBuild. On utilisera le thème que j’ai choisi dans mes précédents posts:

git clone https://github.com/clevertechware/astrolus.git
cd astrolus
npm install
npm run build

Création d’un bucket S3

Pour commencer, j’ai créé un compte sur Scaleway et j’ai créé un bucket S3 (Object Storage) pour y déposer mon site statique.

Clever Tech Ware Bucket

Ensuite, j’ai activé le mode statique du bucket S3, pour que les fichiers soient accessibles publiquement via le protocole HTTP(S) :

Enable website on bucket scw

Plus qu’à déposer le contenu de mon build dans le bucket S3 (dossier dist):

Uploaded files on bucket scw

Jusque-là, cool 😎, tout fonctionne plutôt bien 😀

Astro build on Scaleway bucket S3

Problème : accéder au site static via une URL du type https://www.clevertechware.fr n’est pas possible 🤐
En effet, effectuer un CNAME sur un bucket chez Scaleway est faisable à condition de respecter une règle de nommage stricte : le nom du bucket doit être le même que le nom de domaine.

Malheureusement s’il est possible d’y accéder ensuite via un nom de domaine nous appartenant, il n’y est accessible que via le protocole HTTP et non HTTPS. Une demande d’évolution ce sens a été faite chez Scaleway.

Une solution pourrait d’exposer le bucket via un CDN comme cela est possible sur AWS. Mais, pour le moment, Scaleway ne propose pas de service de CDN. Cependant, il est actuellement en version beta 😎

Ne pouvant pas attendre sa sortie officielle, j’ai décidé de me tourner vers un autre fournisseur de cloud.

PS : je compte bien retenter ma chance sur Scaleway dès que le service CDN sera sortie 💪

Mon plan B, AWS

Finalement, j’ai décidé de me tourner vers AWS pour héberger mon site. C’est de loin le provider Cloud que je maitrise le mieux aujourd’hui (il y a 4 ans, j’aurai plutôt dit Azure 😅).

Plan d’architecture envisagé sur AWS

Architecture AWS

Cette architecture a les intérêts suivants :

  • pas besoin d’exposer publiquement le bucket S3,
  • nom de domaine personnalisé,
  • exposition en HTTPS,
  • utilisation CDN (CloudFront) permettant une mise en cache du contenu,

Création d’un bucket S3

Pour commencer, j’ai créé un bucket S3 (Object Storage) pour y déposer mon site statique :

aws s3api create-bucket \
  --bucket clevertechwareastro \
  --region eu-west-3 \
  --create-bucket-configuration LocationConstraint=eu-west-3

Ensuite, j’ai chargé le contenu de mon build dans le bucket S3 (dossier dist):

aws s3 sync dist s3://clevertechwareastro

AWS S3 bucket astrolus content

Création du CDN CloudFront

Ensuite, j’ai créé un CDN CloudFront pour exposer le contenu de mon bucket S3. Avant de lancer la création du CDN, if faut créer :

  • la politique d’accès de l’origin (S3):
aws cloudfront create-origin-access-control \
  --origin-access-control-config \
'{
    "Name": "clevertechwareastro.s3.amazonaws.com",
    "Description": "string",
    "SigningProtocol": "sigv4",
    "SigningBehavior": "always",
    "OriginAccessControlOriginType": "s3"
  }' \
  --query 'CloudFrontOriginAccessIdentity.Id'
  • la configuration via un fichier JSON du CDN:
cat << EOF > cloudfront-config.json 
{
  "CallerReference": "cf-distribution-for-bucket-s3",
  "Comment": "Cloud Front Distribution for S3 Bucket",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Quantity": 1,
        "Items": [
          {
            "Id": "clevertechwareastro.s3.amazonaws.com-cf-origin",
            "DomainName": "clevertechwareastro.s3.amazonaws.com",
            "OriginPath": "",
            "S3OriginConfig": {
              "OriginAccessIdentity": ""
            },
            "OriginAccessControlId": "<OriginAccessControlIdPreviouslyCreated>"
          }
        ]
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "clevertechwareastro.s3.amazonaws.com-cf-origin",
    "ViewerProtocolPolicy": "redirect-to-https",
    "TrustedSigners": {
      "Enabled": false,
      "Quantity": 0
    },
    "TrustedKeyGroups": {
      "Enabled": false,
      "Quantity": 0
    }
  }
}
EOF
# Création du cloudfront
aws cloudfront create-distribution \
  --origin-domain-name clevertechwareastro.s3.amazonaws.com \
  --default-root-object index.html \
  --distribution-config file://cloudfront-config.json \
  --query 'Distribution.DomainName'

Il ne reste plus qu’à autoriser le CDN à accéder au contenu du bucket S3 :

# Récupération de l'ID du cloudfront
aws cloudfront list-distributions \
  --query 'DistributionList.Items[?DomainName==`<DomainName>`].Id'

# Ajout de la permission
aws s3api put-bucket-policy \
  --bucket clevertechware-astro \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow CloudFront access to S3 bucket",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::clevertechwareastro/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::039841557767:distribution/<DistributionId>"
                }
            }
        }
    ]
}'

Désormais, c’est bon, on peut accéder à notre site via le CDN CloudFront 😎

Création du nom de domaine

Mon nom de domaine n’est pas géré par AWS. Je n’ai pas eu envie de transféré la gestion du nom de domaine sur AWS car je garde toujours l’envie d’essayer des fournisseurs de Cloud français telle que Scaleway. Dans cette configuration, il faut donc créer un CNAME vers le nom de domaine du CDN CloudFront :

# Récupération du nom de domaine du CDN CloudFront
aws cloudfront list-distributions \
  --query 'DistributionList.Items[?DomainName==`<DomainName>`].Id'

Puis sur le provider, vous ajoutez un enregistrement DNS de type CNAME vers le nom de domaine du CDN CloudFront :

www.clevertechware.fr CNAME <CloudFrontDomainName>

Remarque sur les noms de domaines et AWS

AWS propose un service de gestion de nom de domaine (Route53). Ce service est très bien et permet de gérer facilement les enregistrements DNS. Si vous prévoyez de faire d’AWS votre fournisseur Cloud principal alors je vous recommande fortement d’utiliser Route53.

Même si vous n’avez pas acheté votre domaine chez AWS, vous pouvez tout de même utiliser ce service. Pour ce faire, il suffit soit :

  • transférer la gestion de votre domaine chez AWS,
  • ou bien, si vous ne souhaitez pas transférer la gestion de votre domaine chez AWS, il suffit de créer une zone DNS publique dans Route53 et de récupérer les enregistrements DNS à ajouter chez votre fournisseur de nom de domaine.

À partir de ce moment-là, l’ensemble des noms de domaines associé à votre zone DNS Route53 seront gérés par AWS. Il sera alors plus facile et optimale d’utiliser les services AWS via l’usage d’Alias plus performant et optimal qu’un CNAME classique comme réalisé dans notre exemple.

Ajout d’un certificat SSL

Pour finir, il ne reste plus qu’à ajouter un certificat SSL pour que notre site soit accessible en HTTPS.

# Création du certificat SSL
aws acm request-certificate \
  --region us-east-1 \
  --domain-name www.clevertechware.fr \
  --validation-method DNS \
  --query 'CertificateArn'

Remarque : afin de pouvoir apposer le certificat sur notre CDN (service global AWS), il faut créer le certificat dans la région North Virginia (us-east-1)

Une fois la demande de certificat réalisé, il vous suffira alors de rajouter sur votre fournisseur de DNS un enregistrement CNAME vers le nom de domaine fournit par AWS afin de valider la demande de certificat :

# Récupération du nom de domaine du CDN CloudFront
aws acm describe-certificate \
  --certificate-arn <CertificateArn> \
  --query 'Certificate.DomainValidationOptions[0].ResourceRecord'

Il ne reste plus qu’à ajouter le certificat sur le CDN CloudFront :

# Récupération de l'ID du cloudfront
aws cloudfront list-distributions \
  --query 'DistributionList.Items[?DomainName==`<DomainName>`].Id'
# Ajouter le certificat sur le CDN CloudFront
aws cloudfront update-distribution \
  --id <DistributionId> \
  --distribution-config '{
    "Aliases": {
        "Quantity": 1,
        "Items": [
            "www.clevertechware.fr"
        ]
    },
    "ViewerCertificate": {
        "ACMCertificateArn": "<CertificateArn>",
        "SSLSupportMethod": "sni-only",
        "MinimumProtocolVersion": "TLSv1.2_2021",
        "Certificate": "<CertificateArn>",
        "CertificateSource": "acm"
    }
}'

Désormais c’est bon vous pouvez accéder à votre site Astro Build en HTTPS via votre nom de domaine 😎

Ex : https://www.clevertechware.fr

Site astro avec des sous dossiers

Si votre site Astro possède des sous routes(sous dossier) que vous souhaitez afficher alors il vous faudra rajouter une Lambda@Edge qui permettra de rediriger vers la page HTML. Voici le code à rajouter :

function handler(event) {
  var request = event.request;
  var uri = request.uri;

  // Check whether the URI is missing a file name.
  if (uri.endsWith('/')) {
    request.uri += 'index.html';
  }
  // Check whether the URI is missing a file extension.
  else if (!uri.includes('.')) {
    request.uri += '/index.html';
  }

  return request;
}

Conclusion

En conclusion, j’ai pu héberger mon site Astro Build à moindre coût (à peine 1€/mois, selon le traffic) sur AWS. Je n’abandonne pas pour autant Scaleway, que je compte bien utiliser pour d’autres projets ; et dès que le service CDN sera sortie, je compte bien essayer de nouveau d’y héberger mon site Astro Build.

Resources