En esta página, se muestran ejemplos y consejos sobre usar buckets para alojar un sitio web estático.
Páginas especializadas
Páginas de índice
Una página de índice (también llamada índice de directorio de servidor web) es un archivo que se entrega a los visitantes cuando solicitan una URL que no tiene un archivo asociado. Cuando asignas una propiedad MainPageSuffix
, Cloud Storage busca un archivo con ese nombre cuyo prefijo coincida con la URL que solicitó el visitante.
Por ejemplo, supongamos que configuraste el MainPageSuffix
de tu sitio web estático como index.html
. Además, supongamos que no tienes un archivo llamado directory
en tu bucket www.example.com
. En esta situación, si un usuario solicita la URL http://www.example.com/directory
, Cloud Storage intenta entregar el archivo www.example.com/directory/index.html
. Si ese archivo tampoco existe, Cloud Storage muestra una página de error.
El MainPageSuffix
también controla el archivo que se entrega cuando los usuarios solicitan el sitio de nivel superior. En el mismo ejemplo anterior, si un usuario solicita http://www.example.com
, Cloud Storage intenta entregar el archivo www.example.com/index.html
.
Cuando intentas acceder a una URL con una barra diagonal, como http://www.example.com/dir/
, consulta Solución de problemas.
Página de error
La página de error es el archivo que se muestra a los visitantes del sitio estático que solicitan una URL que no corresponde a un archivo existente. Si asignaste un MainPageSuffix
, Cloud Storage solo muestra la página de error si no hay un archivo con el nombre solicitado ni una página de índice aplicable.
Cuando se muestra una página de error, el código de respuesta HTTP es 404
. La propiedad que controla qué archivo actúa como página de error es NotFoundPage
. Si no configuras NotFoundPage
, los usuarios reciben una página de error genérica.
Ejemplos de configuración del sitio web
Bucket de tres objetos
Supongamos que un depósito llamado www.example.com
se configuró como un sitio web con los siguientes archivos y opciones de configuración:
MainPageSuffix
= “index.html”NotFoundPage
= "404.html"- El bucket contiene tres objetos compartidos públicamente: "index.html", "404.html" y "dir / index.html"
En la siguiente tabla, se muestra el contenido entregado para las URL seleccionadas:
URL solicitada | Contenido entregado | Código de respuesta HTTP |
---|---|---|
http://www.example.com http://www.example.com/ http://www.example.com/index.html |
El objeto "index.html" | 200 |
http://www.example.com/hello | El objeto "404.html" | 404 |
http://www.example.com/dir/index.html | El objeto "dir / index.html" | 200 |
http://www.example.com/dir | El objeto "dir / index.html" | 301 |
http://www.example.com/dir/ | El objeto "dir / index.html", si suponemos que no existe ningún objeto de cero bytes para / dir / | 200 |
Un objeto vacío de cero bytes, si existe para / dir /. Consulta el tema sobre la solución de problemas para quitar este objeto de cero bytes. | 301 |
Bucket de dos objetos
Supongamos que un depósito llamado www.example.com
se configuró como un sitio web con los siguientes archivos y opciones de configuración:
MainPageSuffix
= “main.html”NotFoundPage
= "404.html"- El bucket contiene dos objetos compartidos de manera pública: “main.html” y “404.html”
En la siguiente tabla, se muestra el contenido entregado para las URL seleccionadas:
URL solicitada | Contenido entregado | Código de respuesta HTTP |
---|---|---|
http://www.example.com http://www.example.com/ |
El objeto "main.html" | 200 |
http://www.example.com/index.html | El objeto "404.html" | 404 |
Si un objeto se comparte de manera pública, también puedes ver ese objeto con la siguiente URL:
http://storage.googleapis.com/BUCKET_NAME/OBJECT_NAME
Por ejemplo, la siguiente sería la URL de un objeto index.html
:
http://storage.googleapis.com/www.example.com/index.html
Para obtener más información sobre cómo trabajar con datos de acceso público, consulta Acceso a datos públicos.
Sugerencias para trabajar con un bucket configurado como sitio web
Las siguientes son algunas sugerencias que debes tener en cuenta cuando uses un bucket para alojar un sitio web estático.
Agrega subdominios
Supongamos que también deseas entregar contenido en test.example.com
desde un bucket diferente del que entrega contenido en www.example.com
. Para ello, deberás hacer lo siguiente:
Crea un bucket nuevo para publicar tu contenido adicional.
Si seguiste el instructivo en Aloja un sitio web estático para entregar el contenido a través de HTTPS, edita tu balanceador de cargas en la consola de Google Cloud de la siguiente manera:
- En Configuración de backend, crea un bucket de backend nuevo
test-bucket
, para ello, selecciona el bucket nuevo que creaste. - En Reglas de host y ruta de acceso, agrega una regla nueva de la siguiente manera:
Hosts Paths Backends test.example.com /* test-bucket
Para la Configuración de frontend, agrega una IP y puerto de frontend nuevos con los mismos valores que la primera configuración, con las siguientes excepciones:
- En Dirección IP, crea y reserva una dirección IP nueva.
- En Certificado, crea un certificado SSL nuevo para
test.example.com
.
- En Configuración de backend, crea un bucket de backend nuevo
Después de actualizar el balanceador de cargas, agrega un registro
A
nuevo a tu servicio de registro de dominio mediante la dirección IP de la configuración de frontend nueva:NAME TYPE DATA test A IP_ADDRESS
Comportamiento de la API
La configuración de sitios web MainPageSuffix
y NotFoundPage
solo se usa para solicitudes que llegan a Cloud Storage a través de un redireccionamiento CNAME
o A
. Por ejemplo, con una solicitud a www.example.com
, se muestra la página de índice, pero con una solicitud equivalente a storage.googleapis.com/www.example.com
, no.
Por lo tanto, se conserva el comportamiento de la API para las solicitudes a dominios de Cloud Storage, como storage.googleapis.com/www.example.com
. Por ejemplo, puedes continuar enumerando objetos del bucket www.example.com
, como lo harías con cualquier otro bucket. En el caso del bucket www.example.com
, la lista de objetos que recibes incluye 404.html
y index.html
.
Aloja elementos estáticos en un sitio web dinámico
Puedes usar Cloud Storage para alojar elementos estáticos en un sitio web dinámico alojado, por ejemplo, en Google App Engine o en Google Compute Engine. Algunos beneficios de alojar tus elementos estáticos, como imágenes o archivos JavaScript, en un bucket incluyen los siguientes:
Cloud Storage se comporta como una red de distribución de contenido (CDN) porque los objetos legibles de forma pública se almacenan en caché en la red de Cloud Storage de forma predeterminada.
Generalmente, el costo de los cargos de ancho de banda para acceder al contenido es menor con Cloud Storage.
La carga en tus servidores web se reduce cuando se entrega el contenido estático de Cloud Storage.
Cuando alojas elementos estáticos para un sitio web dinámico, no necesitas crear registros DNS y apuntar a un bucket o balanceador de cargas como lo haces con un sitio web estático. Por ejemplo, podrías tener un bucket llamado www_example_com_assets
con los elementos apropiados configurados como compartidos públicamente y, luego, acceder a esos elementos con el dominio de Cloud Storage.
Por ejemplo, si tienes un archivo JavaScript library.js
en el bucket www_example_com_assets
, el cual se comparte de forma pública, puedes acceder a él como http://storage.googleapis.com/www_example_com_assets/library.js
.
Configura parámetros de caché
Cuando configuras los metadatos Cache-Control
, puedes controlar si los elementos del sitio web se almacenan en caché o cómo lo hacen. En general, solo configura los metadatos de control de caché con los objetos que son accesibles a todos los usuarios anónimos, lo cual es un requisito para cualquier objeto entregado desde un bucket de Cloud Storage como parte de un sitio web estático.
Cloud Storage aplica una configuración de control de caché de 3,600 segundos a los objetos a los que pueden acceder todos los usuarios anónimos, a menos que especifiques una configuración de control de caché explícita. Consulta Ve y edita metadatos para obtener instrucciones sobre cómo configurar metadatos de objetos, como Cache-Control
.
También puedes usar Cloud CDN para almacenar en caché contenido con balanceo de cargas HTTP(S) externo cerca de tus usuarios, lo que a menudo reduce los costos de servicio. Para obtener más información, consulta Almacenamiento en caché.
Supervisa tus cargos
Si entregas elementos de un bucket configurado como un sitio web estático o entregas elementos estáticos de un bucket para un sitio web dinámico alojado fuera de Cloud Storage, debes supervisar los cargos al proyecto que contiene el bucket. La entrega de contenido genera costos de Cloud Storage por almacenar el contenido, usar la red y realizar operaciones de recuperación. Para obtener más información, consulta la página Precios de Cloud Storage.
También puedes generar cargos de red si usas un balanceador de cargas de aplicaciones externo para configurar HTTPS. Para obtener más detalles, consulta Precios de red.
El ejemplo simple de precios en la página de ejemplos de precios se puede usar como una aproximación para el caso de uso de un sitio web estático de tráfico bajo. Sin embargo, ten presente que en el ejemplo no se tienen en cuenta los cargos asociados con el balanceador de cargas de aplicaciones externo, que suele ser el mayor cargo por el hosting de sitios web estáticos. Puedes usar la calculadora de precios para generar una estimación de costos según el uso previsto.
Si eres un usuario actual de Google Cloud, puedes obtener un desglose detallado de los costos de tu proyecto en la página de facturación.
Soluciona problemas
Consulta Solución de problemas a fin de obtener más información sobre problemas comunes asociados con el uso de un depósito configurado para entregar contenido de sitios web estáticos.
¿Qué sigue?
- Prueba las soluciones de puesta en marcha de Google Cloud que usan Cloud Storage.
- Obtén información sobre otras opciones de entrega web en Google Cloud.
Pruébalo tú mismo
Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud Storage en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
Probar Cloud Storage gratis