ID de región
El REGION_ID
es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r
se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.
En esta guía se explica cómo estructurar los servicios y los recursos relacionados con ellos dentro de tu aplicación de App Engine.
Estructura de directorios
Cada versión de tu servicio de App Engine se define en un archivo de configuración app.yaml
. En el caso de las aplicaciones sencillas, el requisito mínimo para la implementación es definir el archivo app.yaml
. El archivo app.yaml
actúa como descriptor de implementación y define el tipo de escalado, el tiempo de ejecución, los controladores y otros ajustes de recursos de una versión específica de un servicio. Si vas a implementar varias versiones de un servicio, puedes crear varios archivos YAML en el mismo directorio para representar la configuración de cada una de tus versiones.
Para cada servicio, puedes crear directorios independientes en la raíz de tu aplicación cuando desarrolles de forma local. Si alojas tu aplicación fuera de un sistema de control de versiones (VCS), como GitHub, también puedes estructurar tu aplicación para que use directorios independientes en un repositorio o usar repositorios independientes para cada servicio. Cada directorio o repositorio debe representar un único servicio y contener el archivo app.yaml
de ese servicio junto con el código fuente asociado.
Puedes especificar un nombre único para cada archivo app.yaml
de tu servicio. Por ejemplo, puedes asignar a un archivo de configuración el nombre de tu servicio o usar nombres únicos para representar cada versión de ese servicio concreto, como service1.yaml
o app.standard.yaml
.
Los demás archivos de configuración opcionales deben estar en el directorio raíz o en el repositorio del servicio default
de tu aplicación. Estos archivos de configuración opcionales aplican ajustes en toda la aplicación que no son específicos de un servicio concreto, incluidos los archivos dispatch.yaml
, index.yaml
y cron.yaml
.
Ejemplos
Una aplicación sencilla solo requiere que se añada app.yaml
en la misma ubicación que los archivos de origen de la aplicación. En el caso de una aplicación de un solo servicio, esta solo incluirá el default
servicio y todos los archivos podrán estar en el mismo directorio, en la raíz de la aplicación:
En el siguiente ejemplo se muestra cómo estructurar una aplicación con tres servicios si la desarrollas de forma local. El archivo dispatch.yaml
opcional se ha añadido a esa aplicación en el directorio raíz. En la raíz también hay tres directorios para cada uno de los servicios de la aplicación. El subdirectorio de service1
incluye los archivos de origen y de configuración de ese servicio. Del mismo modo, service2
y service3
están en directorios independientes, que contienen los archivos de cada servicio, aunque service3
incluye dos versiones del archivo de configuración YAML:
En el ejemplo siguiente, un servicio tiene el archivo dispatch.yaml
opcional y dos archivos de configuración que representan diferentes versiones de ese servicio, service1.yaml
y service2.yaml
:
Consideraciones de diseño para el tiempo de actividad de las instancias
Los fallos de hardware o software que provocan la finalización anticipada o el reinicio frecuente de las instancias pueden producirse sin previo aviso y pueden tardar bastante tiempo en resolverse. Tu aplicación debe poder gestionar estos errores.
Estas son algunas estrategias eficaces para evitar el tiempo de inactividad debido a los reinicios de instancias:
- Reduce el tiempo que tardan en reiniciarse tus instancias o en iniciarse las nuevas.
- En el caso de los cálculos de larga duración, crea puntos de control periódicamente para poder reanudar el proceso desde ese estado.
- Tu aplicación debe ser "sin estado" para que no se almacene nada en la instancia.
- Usa colas para ejecutar tareas de forma asíncrona.
- Si configuras tus instancias para que se escalen manualmente, ten en cuenta lo siguiente:
- Usa el balanceo de carga en varias instancias.
- Configura más instancias de las necesarias para gestionar el tráfico normal.
- Escribe una lógica alternativa que use resultados almacenados en caché cuando no haya disponible una instancia de escalado manual.
Consulte más información sobre las instancias en el artículo Cómo se gestionan las instancias.
El servicio default
Todas las aplicaciones de App Engine incluyen un default
. Debes desplegar la versión inicial de tu aplicación en el servicio default
antes de poder crear y desplegar servicios adicionales en tu aplicación.
El servicio predeterminado se puede especificar de forma opcional en el app.yaml
con el ajuste
service: default
.
Si usas Java y los servicios empaquetados antiguos, puedes especificar el servicio predeterminado en appengine-web.xml
con el ajuste <service>default</service>
.
Las solicitudes enviadas a tu aplicación mediante tu proyecto Google Cloud se envían al servicio default
, por ejemplo, https://PROJECT_ID.REGION_ID.r.appspot.com
. Para obtener más información sobre cómo orientar tus otros servicios, consulta Establecer comunicaciones entre los servicios.
Archivos de configuración opcionales
Los siguientes archivos de configuración controlan las funciones opcionales que se aplican a todos los servicios de una aplicación. Consulta los siguientes temas para obtener información sobre cada una de las funciones opcionales:
cron.yaml
configura tareas programadas para operar a horas concretas o en intervalos regulares.dispatch.yaml
anula las reglas predeterminadas de enrutamiento enviando las solicitudes entrantes a un servicio específico en función de la ruta o el nombre de host de la URL.index.yaml
especifica los índices que necesita tu aplicación si usa consultas de Datastore.
Nombres de archivo
App Engine ejecuta aplicaciones en un contenedor en una distribución de Ubuntu Linux actualizada. Los nombres de archivo que utilices en el entorno estándar de App Engine deben ser compatibles con UTF-8, es decir, deben estar en UTF-8 o en un formato que se pueda convertir automáticamente a UTF-8 sin problemas. Si los nombres de los archivos usan codificaciones diferentes, implementa la aplicación desde un ordenador con ajustes de idioma de nombres de archivo compatibles con UTF-8.
La implementación falla si los nombres de los archivos no son compatibles con UTF-8. Ten en cuenta que no hay ninguna restricción en la codificación de caracteres que utilices en un archivo.
Consideraciones sobre el almacenamiento de datos y archivos
Desde App Engine, puedes acceder fácilmente a otros Google Cloud servicios, como Datastore, Cloud SQL y Cloud Storage.
También puedes usar una base de datos externa o de terceros si tu lenguaje la admite y se puede acceder a ella desde tu instancia de App Engine.
Para obtener más información sobre cómo almacenar archivos en Google Cloud o externamente, consulta el artículo Información sobre el almacenamiento de datos y archivos.
También puedes elegir cómo quieres publicar tu contenido estático. Puedes publicar el contenido estático de tu aplicación directamente desde esa aplicación en App Engine, alojar el contenido estático en una Google Cloud opción como Cloud Storage o usar una red de distribución de contenido (CDN) de terceros. Para obtener más información sobre cómo servir contenido estático, consulta Servir archivos estáticos.
Siguientes pasos
Si trabajas con varios servicios y quieres desplegarlos juntos, consulta los pasos para desplegar varios servicios.