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.
Aprende a ejecutar tu aplicación de forma local, desplegarla y probarla en App Engine.
Ejecutar localmente
Para probar la funcionalidad de tu aplicación antes de desplegarla, ejecútala en tu entorno local con las herramientas de desarrollo que sueles usar. Por ejemplo, el comando go run
.
Antes de desplegar tu aplicación
Antes de poder implementar tu aplicación, debes hacer lo siguiente:
- El propietario del proyecto Google Cloud debe habilitar App Engine.
- Debes asegurarte de que tu cuenta de usuario incluya los privilegios necesarios.
Desplegar una aplicación
Despliega tu aplicación en App Engine con el comando
gcloud app deploy
.
Durante el despliegue, el servicio Cloud Build crea una imagen de contenedor de tu aplicación para que se ejecute en el entorno estándar de App Engine. Las compilaciones se crean en la región de la aplicación. Consulta más información en el artículo Gestionar imágenes de compilación.
Para desplegar tus aplicaciones de forma programática, usa la API Admin.
Desplegar un servicio
Para desplegar tu aplicación en App Engine, debes desplegar las versiones de los servicios de tu aplicación y cada uno de sus archivos de configuración.
Para desplegar una versión del servicio de tu aplicación, ejecuta el siguiente comando desde el directorio en el que se encuentra el archivo app.yaml
de tu servicio:
gcloud app deploy
Si no especificas ningún archivo con el comando, solo se implementará el archivo app.yaml
del directorio actual. De forma predeterminada, el comando deploy
genera un ID único para la versión que despliegues, la despliega en el proyectoGoogle Cloud que hayas configurado para usar la CLI de Google Cloud y dirige todo el tráfico a la nueva versión.
Puedes cambiar el comportamiento predeterminado del comando segmentando archivos específicos o incluyendo parámetros adicionales:
- Para implementar los demás archivos de configuración de tu servicio, debes seleccionar e implementar cada archivo por separado. Por ejemplo:
gcloud app deploy cron.yaml gcloud app deploy dispatch.yaml gcloud app deploy index.yaml
- Para especificar un ID de versión personalizado, usa la marca
--version
. - Para evitar que el tráfico se dirija automáticamente a la nueva versión, usa la marca
--no-promote
. - Para implementar en un proyecto específico, usa la marca
--project
. Google Cloud
Por ejemplo, para desplegar el servicio definido por el archivo app.yaml
en un proyectoGoogle Cloud específico, asígnale un ID de versión personalizado e impide que el tráfico se dirija a la nueva versión:
gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote
Para obtener más información sobre este comando, consulta la gcloud app deploy
referencia.
Desplegar varios servicios
Utilizas el mismo comando de implementación para implementar o actualizar los distintos servicios que componen tu aplicación.
Para desplegar varios servicios, despliega por separado el archivo app.yaml
de cada servicio. Puedes especificar varios archivos con un único comando gcloud app deploy
:
gcloud app deploy service1/app.yaml service2/app.yaml
Requisitos para desplegar varios servicios
- Primero debes desplegar una versión de tu aplicación en el servicio
default
para poder crear y desplegar otros servicios. - El ID de cada uno de tus servicios debe especificarse en sus correspondientes archivos de configuración
app.yaml
. Para especificar el ID de servicio, incluye la definición del elementoservice
en cada archivo de configuración. De forma predeterminada, si excluyes esta definición de elemento de tu archivo de configuración, la versión se desplegará en el serviciodefault
.
Ver registros de compilación
Cloud Build transmite los registros de compilación y despliegue, que se pueden ver en la sección Historial de Cloud Build de laGoogle Cloud consola. Para ver las compilaciones de la región de la aplicación, usa el menú desplegable Región de la parte superior de la página para elegir la región por la que quieras filtrar.
Ignorar archivos
Puedes usar un archivo .gcloudignore
para especificar los archivos y directorios que no se subirán a App Engine cuando despliegues tus servicios. Esto resulta útil para ignorar artefactos de compilación y otros archivos que no es necesario subir con tu implementación.
Gestionar imágenes de compilación
Estos son los pasos que se siguen cada vez que implementas una versión nueva:
App Engine crea una imagen de contenedor con el servicio Cloud Build.
Cloud Build crea la imagen de contenedor en la región de la aplicación y se ejecuta en el entorno estándar de App Engine.
App Engine almacena las imágenes de contenedor creadas en Artifact Registry. Puedes descargar estas imágenes para conservarlas o ejecutarlas en otro lugar.
Una vez completado el despliegue, App Engine ya no necesita las imágenes de contenedor. Las imágenes de contenedor no se eliminan automáticamente. Para no alcanzar tu cuota de almacenamiento, puedes eliminar de forma segura las imágenes que no necesites. Sin embargo, si crees que vas a necesitar las imágenes en el futuro o quieres conservar una copia, debes exportarlas antes de eliminarlas. Si quieres obtener más información sobre cómo gestionar imágenes en Artifact Registry, consulta el artículo sobre cómo gestionar imágenes.
Visualizar la aplicación
Después de desplegar la aplicación en App Engine, puedes ejecutar el siguiente comando para iniciar el navegador y verla en
https://PROJECT_ID.REGION_ID.r.appspot.com
:
gcloud app browse
Pruebas en App Engine antes de cambiar el tráfico
Antes de configurar una nueva versión para que reciba tráfico, puedes probarla en App Engine. Por ejemplo, para probar una nueva versión de tu servicio default
, sigue estos pasos:
Despliega la nueva versión, pero evita que el tráfico se dirija automáticamente a ella:
gcloud app deploy --no-promote
Para acceder a la nueva versión, ve a la siguiente URL:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
Ahora puedes probar la nueva versión en el entorno de tiempo de ejecución de App Engine. Puedes depurar tu aplicación consultando sus registros. Para obtener más información, consulta Escribir registros de aplicaciones.
App Engine dirige las solicitudes enviadas a
https://PROJECT_ID.REGION_ID.r.appspot.com
a la versión configurada anteriormente para recibir tráfico.Cuando quieras enviar tráfico a la nueva versión, usa la Google Cloud consola para migrar el tráfico:
Seleccione la versión que acaba de implementar y haga clic en Migrar tráfico.
Puedes usar el mismo proceso para probar nuevas versiones de otros servicios. Para ello, sustituye default
en la URL por el nombre de tu servicio:
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
Para obtener más información sobre cómo orientar las solicitudes a servicios y versiones específicos, consulta Cómo se enrutan las solicitudes.
Usar variables de entorno de compilación
También puedes definir variables de entorno de compilación para los tiempos de ejecución que admitan los buildpacks de Google Cloud.
Las variables de entorno de compilación son pares clave/valor que se implementan junto con una aplicación y que te permiten enviar información de configuración a los buildpacks. Por ejemplo, puede que quieras personalizar las opciones del compilador. Puedes añadir o quitar estas variables de entorno de compilación configurando el campo build_env_variables
en tu archivo app.yaml
.
Utilizar el servidor de desarrollo local
Puedes usar dev_appserver
para ejecutar tus aplicaciones de forma local y simular que se ejecutan en la versión de producción de App Engine. Este servidor de desarrollo simula parcialmente el entorno en el que se ejecuta tu aplicación, lo que te permite probar aplicaciones escritas para cualquiera de los tiempos de ejecución del entorno estándar.
Como Go 1.11 ha llegado al final de su ciclo de asistencia, ya no puedes usar la última versión de dev_appserver.py
para ejecutar tus aplicaciones de forma local. Para seguir usando dev_appserver.py
, sigue las instrucciones de Utilizar el servidor de desarrollo local.
Ejecutar el servidor de desarrollo local
Después de crear el archivo de configuración app.yaml
de tu aplicación, puedes iniciar el servidor de desarrollo local con el comando dev_appserver.py
para ejecutar la aplicación de forma local.
Para obtener las credenciales de acceso de tu cuenta de usuario, ejecuta el siguiente comando:
gcloud auth login
Permite que tu aplicación local use temporalmente tus credenciales de usuario para acceder a la API:
gcloud auth application-default login
Para iniciar el servidor de desarrollo local, sigue estos pasos:
En el directorio que contiene el archivo de configuración
app.yaml
, ejecuta el comandodev_appserver.py
y especifica el ID del proyecto y la ruta al archivoapp.yaml
:python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
Para cambiar el puerto, incluye la opción
--port
:python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
Sustituye DEVAPPSERVER_ROOT por la ruta a la carpeta en la que extraes la versión archivada de
devapp_server.py
. Para obtener más información sobre cómo descargar y usar la versión archivada dedev_appserver.py
, consulta el artículo Utilizar el servidor de desarrollo local.Para obtener más información sobre las opciones del comando
dev_appserver.py
, consulta Opciones del servidor de desarrollo local.Cuando se inicia el servidor de desarrollo local, se configura un entorno de desarrollo que preinstala las dependencias que se encuentran en el archivo
requirements.txt
.El servidor de desarrollo local ya está en funcionamiento y a la espera de solicitudes. Visita http://localhost:8080/ en tu navegador web para ver la aplicación en acción.
Si has especificado un puerto personalizado con la opción
--port
, recuerda abrir tu navegador en ese puerto.Para detener el servidor local desde la línea de comandos, pulsa Control-C en el teclado.
Detectar el entorno de tiempo de ejecución de la aplicación
Para determinar si tu código se está ejecutando en producción o en el servidor de desarrollo local, puedes consultar la variable de entorno GAE_ENV
:
if os.getenv('GAE_ENV', '').startswith('standard'): # Production in the standard environment else: # Local execution.
Usar el servidor de desarrollo local con los servicios de Google Cloud
Puedes integrar dev_appserver
con otros Google Cloud componentes.
Bibliotecas de cliente de Cloud
Muchas bibliotecas de cliente de Cloud dependen de la presencia de la variable de entorno GOOGLE_CLOUD_PROJECT
, que debe ser el ID de tu proyectoGoogle Cloud . Puedes consultar su valor ejecutando el comando gcloud config list project
o en la página de tu proyecto en laGoogle Cloud console.
Para asegurarte de que esta variable de entorno se define correctamente durante el desarrollo local, inicializa dev_appserver
con el parámetro --application=PROJECT_ID
, tal como se muestra en el ejemplo anterior.
Emuladores de Cloud
Puedes probar tu aplicación con emuladores de Cloud Datastore, Cloud Bigtable y Cloud Pub/Sub.
Recarga automática de los cambios de requirements.txt
y app.yaml
El servidor de desarrollo local instala automáticamente las dependencias que se encuentran en el archivo requirements.txt
. dev_appserver
también te permite probar las funciones que se configuran a través de app.yaml
. Por ejemplo, puedes probar la capacidad de tu aplicación para servir archivos estáticos. Cuando dev_appserver
está en ejecución, cualquier cambio en requirements.txt
y app.yaml
reinicia automáticamente tu aplicación para reflejar estos cambios. Esto puede provocar un retraso temporal mientras se descargan e instalan las dependencias.
Gestión de instancias y enrutamiento en el servidor de desarrollo
Descubrir direcciones de instancias
El servidor de desarrollo local crea todas las instancias de escalado manual al iniciarse. Las instancias de los servicios de escalado automático y básico se gestionan de forma dinámica. El servidor asigna un puerto a cada servicio y los clientes pueden depender del servidor para equilibrar la carga y seleccionar una instancia automáticamente. Las asignaciones de puertos para dirigirse a cada servicio aparecen en el flujo de mensajes de registro del servidor.
Estos son los puertos de una aplicación que define tres servicios:
INFO Starting module "default" running at: http://localhost:8084 INFO Starting module "service1" running at: http://localhost:8082 INFO Starting module "service2" running at: http://localhost:8083
Cuando usas la dirección de un servicio, por ejemplo, http://localhost:8082/
, el servidor crea o selecciona una instancia del servicio y envía la solicitud a esa instancia.
El servidor asigna puertos únicos a cada instancia de un servicio. Puedes usar el servidor de administración para descubrir estos puertos. Hay un puerto único para el servidor de administración, que aparece en el registro de mensajes:
INFO Starting admin server at: http://localhost:8000
Esta dirección te lleva a la consola del servidor de administración. Haz clic en Instancias para ver el estado dinámico de las instancias de tu aplicación.
Aparece una entrada independiente por cada instancia manual y básica. Los números de instancia son enlaces con direcciones de puerto únicas para cada instancia. Haga clic en el enlace para enviar una solicitud directamente a esa instancia.
Archivos de envío
Si tu aplicación incluye un archivo dispatch.yaml
, el flujo de mensajes de registro incluye un puerto de distribuidor:
INFO Starting dispatcher running at: http://localhost:8080
Las solicitudes a este puerto se enrutan según las reglas del archivo de envío.
El servidor no admite reglas de archivo dispatch.yaml
que incluyan nombres de host (por ejemplo, url: "customer1.myapp.com/*"
). Las reglas con patrones de ruta relativos (url: "*/fun"
) sí funcionan, por lo que puedes usar URLs como http://localhost/fun/mobile
para acceder a las instancias. El servidor registra un error en el flujo de registro si intentas iniciar una aplicación con un archivo dispatch.yaml
que contenga reglas basadas en el host.