Aller au contenu

Hébergement de sites web statiques avec Ceph S3

Avec le stockage objet compatible S3 de Ceph, vous pouvez héberger des sites web statiques simplement, avec une haute disponibilité et de manière économe en ressources. Au lieu d'exploiter un serveur web traditionnel (comme Apache ou NGINX), vous pouvez stocker vos fichiers HTML, CSS et JavaScript ainsi que vos images directement dans un bucket S3 et les rendre accessibles sur Internet.

Ce type d'hébergement est idéal pour :

  • Sites web statiques et blogs (par ex. générés avec Hugo, Jekyll ou MkDocs)
  • Applications monopage (SPA) (par ex. React, Vue.js, Angular)
  • Documentation, portfolios et catalogues en ligne

Avantages de l'hébergement web S3

  • Aucune gestion de serveur : il n'est pas nécessaire de mettre à jour des systèmes d'exploitation ni de configurer et de maintenir des serveurs web.
  • Haute scalabilité et performances : Ceph gère la distribution et la réplication des données en arrière-plan. Votre site reste performant et accessible, même lors de pics de trafic soudains.
  • Économique : les frais liés à l'exploitation de machines virtuelles complètes sont éliminés ; seul le stockage objet réel est utilisé.

Dans les sections suivantes, vous apprendrez comment préparer un bucket pour l'hébergement web, téléverser les fichiers de votre site et définir les autorisations d'accès correctes (Bucket Policies) afin que votre site devienne accessible publiquement.

Fonctionnement de la diffusion

Le diagramme suivant illustre comment les requêtes des visiteurs sont traitées directement par la passerelle objet Ceph, sans nécessiter de serveur web dédié (comme Apache/NGINX) intermédiaire :

graph LR
    Client([Visitor / Web Browser]) -- "GET Request\nhttps://my-bucket.sites..." --> Gateway{Ceph S3 Gateway}
    Gateway --> Bucket[(S3 Bucket)]
    Bucket -. "index.html,\nImages, CSS, JS" .-> Gateway
    Gateway -. "Delivers website" .-> Client

Prérequis

Pour que votre site soit diffusé correctement via Ceph S3, plusieurs conditions préalables doivent être remplies :

Nom du bucket

  • Unicité : le nom de votre bucket S3 doit être unique au niveau mondial, car les URL d'accès sont basées sur le nom du bucket (par ex. s3://my-bucket).
  • Règles : respectez les conventions de nommage standard des buckets S3 (par ex. lettres minuscules, traits d'union, aucun caractère spécial ni espace).

Contenu du site

  • Fichiers statiques : vous avez besoin d'au moins un fichier index.html. Il s'agit de la page d'accueil par défaut chargée lorsqu'un utilisateur visite l'URL du site.
  • Page d'erreur facultative : il est recommandé de fournir un fichier error.html. Celui-ci s'affiche lorsqu'un utilisateur tente d'accéder à une page ou à un fichier inexistant.
  • Structure des fichiers : gardez la structure de votre site claire. Les structures de sous-dossiers complexes fonctionnent, mais exigent des références de chemins précises dans les liens de votre fichier HTML.

Autorisations d'accès

  • Accès en lecture public : le bucket doit être configuré de sorte que les utilisateurs anonymes (toute personne sur Internet) puissent lire les fichiers.
  • Aucun accès en écriture : assurez-vous que seuls les utilisateurs autorisés disposent des droits d'écriture pour modifier le contenu.
  • Bucket Policy : vous devez créer une bucket policy qui autorise explicitement l'accès public aux objets (fichiers) du bucket.

Une fois ces prérequis remplis, vous pouvez passer à la configuration.

Tutoriel

Étape 1 : installer et préparer l'AWS CLI

Pour interagir avec le stockage S3, nous avons besoin de l'AWS CLI.

Conseil : un guide détaillé pour l'installation recommandée de l'AWS CLI (via un venv Python) ainsi que des informations sur les fonctionnalités IAM avancées se trouvent dans notre documentation séparée : AWS CLI & fonctionnalités IAM.

Si vous avez déjà installé l'AWS CLI dans un environnement virtuel, assurez-vous qu'il est activé pour les étapes suivantes :

source ~/ceph.venv/bin/activate

Étape 2 : tester les endpoints S3 (facultatif)

Vous pouvez vérifier au préalable que les endpoints du site sont joignables :

curl http://sites.ewstorage.ch
curl https://sites.ewstorage.ch

Étape 3 : configurer l'AWS CLI et définir les variables d'environnement

Définissez les identifiants et les paramètres de configuration requis en tant que variables d'environnement. Remplacez les xxx de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY par vos identifiants S3 réels. Adaptez également le nom du bucket à vos besoins.

# Zugangsdaten und Einstellungen
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
export AWS_RESPONSE_CHECKSUM_VALIDATION=when_required
export AWS_MAX_ATTEMPTS=1

# Regionale Parameter und Bucket-Name
export AWS_ENDPOINT_URL=https://s3.ewstorage.ch 
export AWS_DEFAULT_REGION=ch-zh1
export bucket=meine-website-bucket

Étape 4 : créer le bucket

Nous créons maintenant le bucket S3 qui servira plus tard de serveur web :

# List existing buckets
aws  s3 ls

# Create new bucket
aws  s3 mb s3://${bucket}

# Verify the bucket was created
aws  s3 ls s3://${bucket}

Étape 5 : définir la Bucket Policy (accès en lecture public)

Pour que les visiteurs puissent consulter votre site, les fichiers du bucket doivent être lisibles publiquement. Pour ce faire, nous attribuons une policy au bucket :

Non combinable avec l'access fencing

Cette policy rend le bucket lisible publiquement. N'appliquez pas de bucket policy d'access fencing (DenyAllWithoutRole, voir Bucket Policies & Access Fencing) à un bucket de site web : le refus explicite l'emporte et le site cesse de fonctionner.

aws  s3api put-bucket-policy --bucket="${bucket}" --policy '
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::'${bucket}'/*"
        }
    ]
}'

# Query the policy for verification (requires jq)
aws  s3api get-bucket-policy --bucket="${bucket}" --output text | jq .

Étape 6 : activer l'hébergement web sur le bucket

Cette commande indique au bucket de se comporter comme un serveur web et de rechercher par défaut un fichier index.html.

aws s3api put-bucket-website \
  --bucket=${bucket} \
  --website-configuration='{"IndexDocument":{"Suffix":"index.html"}}'

Étape 7 : créer et téléverser un site de test (index.html)

Nous créons un index.html simple et le téléversons directement dans le bucket :

echo '<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Test Page</title>
</head>
<body>
    <h1>Hello, World</h1>
    <p>This is a simple test file for index.html.</p>
</body>
</html>' | aws s3 cp - s3://${bucket}/index.html --content-type "text/html"

Étape 8 : accéder au site et le tester

Votre site statique est maintenant en ligne ! Vous pouvez y accéder via le sous-domaine spécifique du bucket.

# Access the root directory (automatically loads index.html)
curl https://${bucket}.sites.ewstorage.ch/

# Direct access to index.html
curl https://${bucket}.sites.ewstorage.ch/index.html

# List bucket contents
aws s3 ls s3://${bucket}

Endpoints pour d'autres régions (par ex. région 2 : ch-ge1)

Si vous souhaitez héberger votre bucket dans une autre région (comme ch-ge1), adaptez l'URL et la région en conséquence :

export url=https://s3.ch-ge1.ewstorage.ch
export region=ch-ge1

# Test access for the second region
curl https://${bucket}.sites.ch-ge1.ewstorage.ch/index.html

Configurations avancées

Configurer CORS (Cross-Origin Resource Sharing)

Qu'est-ce que CORS ? CORS est un mécanisme de sécurité des navigateurs web modernes. Par défaut, il empêche un site web (par ex. https://www.my-website.com) d'accéder, via JavaScript ou des feuilles de style, à des ressources d'un domaine différent (par ex. https://my-bucket.sites.ewstorage.ch).

Quand avez-vous besoin de CORS dans S3 ? Si vous utilisez votre bucket S3 pour héberger des polices web (.woff, .ttf), des modules JavaScript ou des données JSON (API) que vous souhaitez ensuite intégrer sur un domaine différent, le navigateur bloquera le chargement pour des raisons de sécurité. Dans les outils de développement du navigateur, vous verrez alors l'erreur « CORS » typique.

Pour informer le bucket S3 que cet accès est explicitement autorisé, vous devez définir une policy CORS pour le bucket.

Définir la policy CORS via l'AWS CLI

Nous créons un fichier de configuration simple (cors.json) qui autorise les opérations de lecture (GET, HEAD) depuis tous les domaines (*), puis nous l'attribuons au bucket.

# 1. Create configuration file cors.json
cat <<EOF > cors.json
{
  "CORSRules": [
    {
      "AllowedOrigins": ["*"],
      "AllowedHeaders": ["*"],
      "AllowedMethods": ["GET", "HEAD"],
      "MaxAgeSeconds": 3000
    }
  ]
}
EOF

# 2. Apply CORS policy to the bucket
aws s3api put-bucket-cors \
  --bucket ${bucket} \
  --cors-configuration file://cors.json

# 3. Query for verification
aws s3api get-bucket-cors --bucket ${bucket}

Conseil de sécurité : si vous savez exactement sur quel domaine votre site fonctionne (par ex. https://www.my-website.com), vous devriez remplacer le joker "*" dans le fichier cors.json sous "AllowedOrigins" par votre domaine spécifique (par ex. ["https://www.my-website.com"]) afin de renforcer la sécurité.