Déployer un Site Statique via GitHub et S3

Dans cet article, nous allons apprendre à déployer un site web statique dans un bucket Amazon S3.

Nous avons déjà vu comment utiliser CodeBuild pour générer les fichiers du site et envoyer l’artefact dans S3. Cette fois-ci, nous allons configurer un répertoire source et automatiser tout le processus de build : à chaque modification du code, l’artefact sera automatiquement déployé dans S3. À la fin, notre site sera accessible via un FQDN.

Commençons par créer un dépôt GitHub pour héberger notre code source.

Vous pouvez cocher la case permettant de créer un fichier README.md, puis cliquer sur Create repository.

Une fois le dépôt créé, copiez le lien HTTPS du repository.

Ouvrons maintenant Visual Studio Code, et exécutons la commande suivante dans le terminal intégré :

#git clone <URL-HTTPS-du-dépôt>

git clone https://github.com/mxdjo/doctor-website.git

Ensuite, ouvrons le dossier du projet dans Visual Studio Code, puis copions les fichiers de notre site web statique à l’intérieur.

À la racine du projet, créons un fichier nommé buildspec.yml.

Nous allons partir de la version utilisée dans le billet précédent, en y apportant quelques ajustements pour l’adapter à notre nouveau flux de déploiement automatisé.

Pour rappel, voici le contenu initial du fichier buildspec.yml tel qu’il avait été configuré précédemment :

version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.8  # Specify the Python version
    commands:
      - echo Installing dependencies...
      - pip install -r requirements.txt
  pre_build:
    commands:
      - echo start prebuild and end it    
  build:
    commands:
      - echo Running unit tests with pytest...
      - pytest --junitxml=reports/results.xml --tb=short  # Generate test report in JUnit format
  post_build:
    commands:
      - echo Build completed successfully.

artifacts:
  files:
    - "**/*"
  base-directory: .  # Specify where artifacts are stored
reports:
  pytest_reports:
    files:
      - "reports/results.xml"
    discard-paths: yes

Modification du fichier `buildspec.yml`

Comme nous déployons un simple site web statique, certaines sections du fichier buildspec.yml utilisé précédemment ne sont plus nécessaires. Nous allons donc le simplifier en supprimant les éléments superflus.

🎯 Ajustement n°1 : Suppression de l'installation d'un environnement d'exécution

Dans notre cas, nous n'avons pas besoin de spécifier une version de Python ni d’installer des dépendances via pip. Ces étapes sont inutiles pour un site statique.
Nous allons donc retirer les lignes suivantes :

```
  runtime-versions:
    python: 3.8
```
ainsi que :
```
  - pip install -r requirements.txt
```
🎯 Ajustement n°2 : Suppression des tests et des rapports

Comme il n’y a ni tests automatisés à exécuter ni rapports à générer pour un site statique, nous pouvons également supprimer la ligne suivante du fichier buildspec.yml :
```
  - pytest --junitxml=reports/results.xml --tb=short
```
ainsi que toute la section relative aux rapports :
```
  reports:
    pytest_reports:
      files:
        - "reports/results.xml"
      discard-paths: yes
```

Ces simplifications rendent le fichier buildspec.yml plus léger et parfaitement adapté au déploiement d’un site web statique.

Voici à quoi il ressemble désormais :

version: 0.2

phases:
  install:
    commands:
      - echo Installing dependencies...
  pre_build:
    commands:
      - echo start prebuild and end it    
  build:
    commands:
      - echo Running unit tests with pytest...
  post_build:
    commands:
      - echo Build completed successfully.

artifacts:
  files:
    - "**/*"
  base-directory: .  # Specify where artifacts are stored

J’ai également ajusté les messages echo pour qu’ils soient plus clairs et compréhensibles dans le contexte d’un site statique.

version: 0.2

phases:
  install:
    commands:
      - echo "Rien à installer pour un site statique..."
  pre_build:
    commands:
      - echo "Rien à prebuild pour un site statique..."    
  build:
    commands:
      - echo "phase de Build du site statique..."
  post_build:
    commands:
      - echo Build completed successfully.

artifacts:
  files:
    - "**/*"
  base-directory: .  # Specify where artifacts are stored

Voilà, nous sommes prêts à pousser cette première version. Rendez-vous à la racine du projet, puis lancez les commandes suivantes :

git add .
git commit -m "First Commit"
git push

Création du bucket S3 sur AWS

Nous allons maintenant nous connecter à la console AWS et créer un bucket S3 dans lequel sera stocké notre artefact.

Pour cela, créez un compartiment (appelé Create bucket en anglais).

Note : Les noms de buckets S3 sont uniques à l’échelle mondiale. Cela signifie que toi ou moi ne pouvons pas utiliser un nom de bucket déjà pris.

Comme notre artefact est un site web statique accessible publiquement, nous allons désactiver l’option Block all Public Access en décochant cette case.

Les paramètres deviennent:

Nous pouvons maintenant procéder à la création du bucket.

Configuration de Codebuild

Notre bucket créé, nous allons nous rendre dans AWS Codebuild pour créer un build.

Cliquer sur Create project
Nom du projet: doctor-website
Source: Github.
Pour les informations d’identifications du compte, je choisis Personal Access token

Je choisis l’option Create new token.

Nom secret: doctor
jeton d’accès personnel: Je dois le récupérer sur Github:

🔐 Création de mon access token GitHub (nom du secret : doctor)

Pour obtenir votre jeton d’accès personnel GitHub, procédez comme suit :
1. Connectez-vous à GitHub à l’adresse https://github.com/login.
2. Cliquez sur votre photo de profil en haut à droite, puis allez dans Settings → Developer settings → Personal access tokens → Tokens (classic).
  (Vous pouvez aussi y accéder directement via ce lien : https://github.com/settings/tokens)
3. C liquez sur Generate new token, puis sélectionnez Generate new token (classic).
4. Donnez un nom à votre token, par exemple doctor.
5. Choisissez une durée de validité : 30 jours, 90 jours, personnalisée ou sans expiration.
6. Sélectionnez les permissions nécessaires :
  - repo s i vous voulez accéder à tous vos dépôts (publics et privés).
  - public_repo si vous travaillez uniquement avec des dépôts publics.

Note : Il est possible de cocher toutes les permissions, mais cela comporte un risque si quelqu’un récupère votre to ken, car il pourrait alors avoir un accès complet à vos dépôts.

Cliquez sur Generate token.
Une fois le token affiché, copiez-le immédiatement, car vous ne pourrez plus le voir à nouveau.
Vous pourrez ensuite coller ce token dans CodeBuild, dans le champ GitHub personal access token, puis enregistrer les changements.
Pour le référen tiel GitHub (GitHub Repository), collez l’URL HTTPS de votre dépôt.
Cochez la case Reconstruire à chaque fois qu’une modification de code est transférée (Rebuild every time a code change).

Buildspec: Utiliser un fichier Buildspec
Artifacts: Amazon S 3 - On choisit le bucket créé
Nom du dossier: /

Disable artifact encryption

On peut laisser les autres paramètres par défaut et cliquer sur Créer projet de génération (Create build project)

on devrait avoir ceci à la fin:

Nous lançons maintenant le build.
Voici ce que vous devriez voir :

Dans S3, vous pourrez alors visualiser les fichiers (artefacts) générés.

Cependant, notre site n’est pas encore accessible.
Pour cela, cliquez sur Propriétés (ou Properties), puis en bas sur Hébergement de site Web statique (ou Static Website Hosting), et activez cette option en cliquant sur Activer (ou Enable).

Configurez ensuite les paramètres suivants :

Type d’hébergement (ou Hosting type) : choisissez Host a static website
Document d'index (ou Index document) : saisissez index.html

Enregistrez les modifications. Un lien s’affichera alors, vous permettant de visiter votre site.

Lors de notre première visite, une erreur 403 peut apparaître, car certaines permissions doivent être configurées.

Pour cela, rendez-vous dans l’onglet Autorisations (ou Permissions) puis éditez la Stratégie de compartiment (ou Bucket Policy).

En suivant la documentation AWS ici, on remarque que l’étape 1 est déjà réalisée.
L’étape 2 consiste à rendre les objets du bucket accessibles en lecture publique. Comment faire ?

Dans la section Compartiments (ou Buckets), cliquez sur le nom de votre bucket.
Accédez à l’onglet Autorisations (ou Permissions).
Dans la section Stratégie de Compartiment (ou Bucket Policy), cliquez sur Modifier.
Pour autoriser l’accès public en lecture à votre site web, copiez la politique suivante et collez-la dans l’éditeur de stratégie du bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::Bucket-Name/*"
            ]
        }
    ]
}

Pensez à remplacer Bucket-Name par le nom réel de votre bucket, puis cliquez sur Enregistrer.

Votre site devrait maintenant être accessible.

Comment déployer un site statique automatiquement en utilisant GitHub, Codebuild et S3

Modification du fichier `buildspec.yml`

🎯 Ajustement n°1 : Suppression de l'installation d'un environnement d'exécution

Création du bucket S3 sur AWS

Configuration de Codebuild

🔐 Création de mon access token GitHub (nom du secret : `doctor`)

Subscribe to my newsletter

Mario Fadegnon

Mario Fadegnon

Comment déployer un site statique automatiquement en utilisant GitHub, Codebuild et S3

Modification du fichier buildspec.yml

🎯 Ajustement n°1 : Suppression de l'installation d'un environnement d'exécution

Création du bucket S3 sur AWS

Configuration de Codebuild

🔐 Création de mon access token GitHub (nom du secret : doctor)

Subscribe to my newsletter

Mario Fadegnon

Mario Fadegnon

Modification du fichier `buildspec.yml`

🔐 Création de mon access token GitHub (nom du secret : `doctor`)