Site Web statique : exemples et conseils

Cette page présente des exemples et des conseils pour héberger un site Web statique avec des buckets.

Pages spécialisées

Pages d'index

Une page d'index (également appelée index de répertoire de serveur Web) est un fichier diffusé aux visiteurs qui demandent une URL sans fichier associé. Lorsque vous attribuez une propriété MainPageSuffix, Cloud Storage recherche un fichier qui porte ce nom et dont le préfixe correspond à l'URL demandée par le visiteur.

Par exemple, supposons que vous définissez l'élément MainPageSuffix de votre site Web statique sur index.html. Supposons également que votre bucket www.example.com ne comporte aucun fichier nommé directory. Dans ce cas, si un utilisateur demande l'URL http://www.example.com/directory, Cloud Storage tente de diffuser le fichier www.example.com/directory/index.html. Si ce fichier n'existe pas non plus, Cloud Storage renvoie une page d'erreur.

L'élément MainPageSuffix contrôle également le fichier diffusé lorsque la requête de l'utilisateur concerne le site de premier niveau. Si nous reprenons l'exemple ci-dessus, lorsqu'un utilisateur demande http://www.example.com, Cloud Storage tente de diffuser le fichier www.example.com/index.html.

Lorsque vous tentez d'accéder à une URL comportant une barre oblique finale, telle que http://www.example.com/dir/, consultez la section Dépannage.

Page d'erreur

La page d'erreur est le fichier renvoyé aux visiteurs de votre site statique lorsqu'ils demandent une URL qui ne correspond à aucun fichier existant. Si vous avez attribué un élément MainPageSuffix, Cloud Storage ne renvoie la page d'erreur que s'il n'existe ni fichier portant le nom demandé, ni page d'index applicable.

En cas de renvoi d'une page d'erreur, le code de réponse HTTP est 404. La propriété qui contrôle le fichier utilisé comme page d'erreur est NotFoundPage. Si vous ne définissez pas NotFoundPage, les utilisateurs reçoivent une page d'erreur générique.

Exemples de configuration de site Web

Bucket à trois objets

Supposons qu'un bucket nommé www.example.com ait été configuré en tant que site Web à l'aide des paramètres et fichiers suivants :

• MainPageSuffix = "index.html"
• NotFoundPage = "404.html"
• Le bucket contient trois objets partagés publiquement : "index.html", "404.html" et "dir/index.html".

Remarque : Un objet vide peut exister à l'adresse http://www.example.com/dir/. Si un objet vide existe, il est renvoyé à la place du fichier index.html du répertoire. Consultez la rubrique de dépannage si vous obtenez une réponse HTTP 301 lorsque vous tentez d'accéder à http://www.example.com/dir/.

Le tableau suivant présente le contenu diffusé pour les URL sélectionnées :

URL demandée	Contenu diffusé	Code de réponse HTTP
http://www.example.com http://www.example.com/ http://www.example.com/index.html	Objet "index.html"	200
http://www.example.com/hello	Objet "404.html"	404
http://www.example.com/dir/index.html	Objet "dir/index.html"	200
http://www.example.com/dir	Objet "dir/index.html"	301
http://www.example.com/dir/	Objet "dir/index.html", en supposant qu'aucun objet de zéro octet ne figure dans /dir/.	200
	Objet vide de zéro octet dans /dir/, le cas échéant. Consultez la procédure de dépannage pour supprimer cet objet de zéro octet.	301

Bucket à deux objets

Supposons qu'un bucket nommé www.example.com ait été configuré en tant que site Web à l'aide des paramètres et fichiers suivants :

• MainPageSuffix = "main.html"
• NotFoundPage = "404.html"
• Le bucket contient deux objets partagés publiquement : "main.html" et "404.html".

Le tableau suivant présente le contenu diffusé pour les URL sélectionnées :

URL demandée	Contenu diffusé	Code de réponse HTTP
http://www.example.com http://www.example.com/	Objet "main.html"	200
http://www.example.com/index.html	Objet "404.html"	404

Si un objet est partagé publiquement, vous pouvez également l'afficher à l'aide de l'URL :

http://storage.googleapis.com/BUCKET_NAME/OBJECT_NAME

Par exemple, l'URL d'un objet index.html serait la suivante :

http://storage.googleapis.com/www.example.com/index.html

Pour en savoir plus sur l'utilisation des données accessibles au public, consultez Accéder aux données publiques.

Conseils d'utilisation d'un bucket configuré en tant que site Web

Voici quelques conseils à garder à l'esprit lorsque vous hébergez un site Web statique à l'aide d'un bucket.

Ajouter des sous-domaines

Supposons que vous souhaitiez également diffuser du contenu sur test.example.com, à partir d'un bucket différent de celui qui diffuse du contenu sur www.example.com. Pour ce faire :

1. Créez un bucket pour diffuser votre contenu supplémentaire.

2. Si vous avez suivi le tutoriel Héberger un site Web statique pour diffuser votre contenu via HTTPS, modifiez votre équilibreur de charge dans la console Google Cloud comme suit :

   1. Pour Configuration du backend, créez un bucket backend test-bucket en sélectionnant le bucket que vous venez de créer.
   2. Pour Règles d'hôte et de chemin d'accès, ajoutez une nouvelle règle comme suit :

      Hosts                  Paths     Backends
      test.example.com       /*        test-bucket
      

   3. Pour Configuration du frontend, ajoutez une adresse IP et un port frontend avec les mêmes valeurs que votre première configuration, avec les exceptions suivantes :

      • Pour Adresse IP, créez et réservez une nouvelle adresse IP.
      • Dans le champ Certificat, créez un certificat SSL pour test.example.com.

3. Après avoir mis à jour l'équilibreur de charge, ajoutez un nouvel enregistrement A à votre service d'enregistrement de domaine avec l'adresse IP de la nouvelle configuration du frontend :

   NAME                  TYPE     DATA
   test                  A        IP_ADDRESS
   

Remarque : Si vous diffusez sans équilibreur de charge à l'aide d'une redirection CNAME, votre nom de bucket doit correspondre au sous-domaine test.example.com. Dans ce scénario, étant donné que vous avez déjà validé le domaine example.com, vous pouvez créer des buckets pour accepter les sous-domaines sans validation supplémentaire. Une fois le bucket créé, ajoutez un nouvel enregistrement CNAME pour le sous-domaine :

NAME                  TYPE     DATA
test                  CNAME    c.storage.googleapis.com.

Comportement de l'API

Les configurations de site Web MainPageSuffix et NotFoundPage ne sont utilisées que pour les requêtes adressées à Cloud Storage via une redirection CNAME ou A. Par exemple, une requête envoyée à www.example.com affiche la page d'index, mais pas une requête équivalente envoyée à storage.googleapis.com/www.example.com.

Ainsi, le comportement de l'API pour les requêtes vers des domaines Cloud Storage, tels que storage.googleapis.com/www.example.com, est préservé. Par exemple, vous pouvez continuer à répertorier les objets dans le bucket www.example.com comme vous le feriez pour n'importe quel autre bucket. Dans le cas du bucket www.example.com, la liste d'objets que vous recevez inclut 404.html et index.html.

Héberger les éléments statiques pour un site Web dynamique

Cloud Storage vous permet d'héberger les éléments statiques d'un site Web dynamique hébergé, par exemple, dans Google App Engine or dans Google Compute Engine. L'hébergement de vos éléments statiques, tels que les images ou les fichiers JavaScript, dans un bucket présente les avantages suivants :

• Cloud Storage se comporte comme un réseau de diffusion de contenu (CDN), car les objets lisibles publiquement sont mis en cache dans le réseau Cloud Storage par défaut.

• Les frais d'utilisation de la bande passante pour accéder aux contenus sont généralement moins élevés avec Cloud Storage.

• La charge de vos serveurs Web est réduite lorsque vous diffusez du contenu statique à partir de Cloud Storage.

Lorsque vous hébergez les éléments statiques d'un site Web dynamique, vous n'avez pas besoin de créer des enregistrements DNS, ni de pointer vers un bucket ou un équilibreur de charge comme vous le feriez pour un site Web statique. Par exemple, vous pouvez définir un bucket nommé www_example_com_assets avec des éléments appropriés configurés pour être partagés en mode public, puis accéder à ces éléments à l'aide du domaine Cloud Storage. Par exemple, si votre fichier JavaScript library.js se trouve dans le bucket www_example_com_assets qui est partagé en mode public, vous pouvez y accéder en tant que http://storage.googleapis.com/www_example_com_assets/library.js.

Définir les paramètres du cache

Vous pouvez configurer les métadonnées Cache-Control pour contrôler la mise en cache des éléments de votre site Web. En règle générale, vous devez uniquement définir les métadonnées de contrôle du cache pour les objets accessibles à tous les utilisateurs anonymes. C'est une nécessité pour tout objet diffusé à partir d'un bucket Cloud Storage dans un site Web statique.

Cloud Storage applique un paramètre de contrôle du cache de 3 600 secondes aux objets accessibles à tous les utilisateurs anonymes, sauf si vous spécifiez des paramètres de contrôle explicites. Pour obtenir des instructions concernant la définition de métadonnées d'objets, telles que Cache-Control, consultez la page Afficher et modifier des métadonnées.

Vous pouvez également utiliser Cloud CDN pour mettre en cache du contenu équilibré en charge HTTP(S) externe à proximité de vos utilisateurs, ce qui réduit souvent les coûts de diffusion. Pour en savoir plus, consultez la section Mise en cache.

Surveiller vos frais

Si vous diffusez des éléments à partir d'un bucket configuré en tant que site Web statique ou d'un bucket pour un site Web dynamique hébergé en dehors de Cloud Storage, vous devez surveiller les frais de votre projet dans lequel se trouve le bucket. La diffusion de contenu implique des coûts dans Cloud Storage pour stocker le contenu, utiliser le réseau et effectuer des opérations de récupération. Pour en savoir plus, consultez la page Tarifs de Cloud Storage.

Des frais de mise en réseau peuvent également vous être facturés si vous utilisez un équilibreur de charge d'application externe pour configurer HTTPS. Pour en savoir plus, consultez la section Tarifs du réseau.

L'exemple de tarification simple de la page "Exemples de tarifs" correspond à une estimation dans le cas d'un site Web statique à faible trafic. Notez cependant que cet exemple ne tient pas compte des frais associés à l'équilibreur de charge d'application externe, qui représentent souvent la plus grande part des frais pour l'hébergement d'un site Web statique. Vous pouvez utiliser le Simulateur de coût pour générer une estimation du coût en fonction de votre utilisation prévue.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai offert.

Si vous êtes déjà un utilisateur de Google Cloud, vous pouvez obtenir une répartition détaillée des coûts de votre projet sur la page de facturation.

Dépannage

Consultez la page Dépannage pour passer en revue les problèmes courants liés à l'utilisation d'un bucket configuré pour diffuser le contenu d'un site Web statique.

Étape suivante

• Essayez les solutions de démarrage Google Cloud qui utilisent Cloud Storage.
• Découvrez d'autres options de diffusion Web sur Google Cloud.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de Cloud Storage en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de Cloud Storage