Probar y desplegar una aplicación

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.

Más información sobre los IDs de región

Aceptar

Go Java Node.js PHP Python Ruby

Aprende a ejecutar tu aplicación de forma local, desplegarla y probarla en App Engine.

Ejecutar localmente

Para probar tu aplicación antes de desplegarla, ejecútala en tu entorno local con las herramientas de desarrollo que sueles usar. Te recomendamos que uses herramientas estándar de Python, como virtualenv, para crear entornos aislados y pytest para ejecutar pruebas unitarias y pruebas de integración, en lugar de depender de dev_appserver, el servidor de desarrollo local que se proporciona con el SDK de Google Cloud.

Por ejemplo, normalmente puedes ejecutar una aplicación Flask con el servidor de desarrollo de Flask mediante el siguiente comando:

python main.py

Inicia aplicaciones Django con el siguiente comando:

python manage.py runserver

Para simular un entorno de producción de App Engine, ejecuta el servidor completo de interfaz de pasarela de servidor web (WSGI) de forma local. Usa el mismo comando que se especifica como punto de entrada en el archivo app.yaml. Por ejemplo:

gunicorn -b :$PORT main:app

Antes de desplegar tu aplicación

Antes de desplegar tu aplicación:

• El propietario del proyecto Google Cloud debe configurar el proyecto para App Engine Google Cloud .
• Asegúrate 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 la implementación, el servicio Cloud Build crea una imagen de contenedor de tu aplicación para que se ejecute en el entorno estándar. Cada compilación se ejecuta en la misma región que tu Google Cloud proyecto. Para obtener más información, consulta el artículo sobre cómo 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.

Nota: Puedes definir propiedades para la CLI de Google Cloud y crear y gestionar configuraciones del SDK para no tener que especificar marcas como --project cada vez que implementes.

Cuando despliegas una versión nueva con el mismo nombre que una versión ya existente, App Engine migra inmediatamente el tráfico a la nueva versión. Hay un pico de latencia cuando App Engine carga solicitudes a la nueva versión. La nueva versión sobrescribe la anterior y no podrás migrar el tráfico a la versión anterior. Todas las instancias de la versión anterior se cierran inmediatamente. Para obtener más información, consulta el artículo Migrar tráfico.

Desplegar varios servicios

Utilizas el mismo comando de implementación para implementar o actualizar los distintos servicios que componen tu aplicación.

Antes de empezar:

• 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 elemento service 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 servicio default.

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

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 compilaciones de Cloud Build en la consola de Google Cloud . Para ver las compilaciones de la región de la aplicación, usa el menú Región para filtrar por región.

Gestionar imágenes de compilación

Precaución: Container Registry está obsoleto. A partir del 18 de marzo del 2025, Container Registry se retirará y no se podrán escribir imágenes en él. Para obtener más información sobre la retirada y cómo migrar a Artifact Registry, consulta el artículo sobre la retirada de Container Registry.

Cada vez que implementes una nueva versión:

1. App Engine crea una imagen de contenedor con el servicio Cloud Build.

2. 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.

3. 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 podrías 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.

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 es útil para ignorar artefactos de compilación y otros archivos que no es necesario subir con tu implementación.

Nota: No puedes especificar el campo skip_files en tu archivo app.yaml si tienes un archivo .gcloudignore.

Ver tu solicitud

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

Hacer 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:

1. Despliega la nueva versión, pero evita que el tráfico se dirija automáticamente a ella:

   gcloud app deploy --no-promote

2. 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

   Nota: Puedes encontrar el ID de versión en la Google Cloud consola o especificar uno al implementar con --version flag. La CLI de Google Cloud también muestra el ID de versión cuando realizas la implementación.

   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 el artículo 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.

3. Cuando quieras enviar tráfico a la nueva versión, usa laGoogle Cloud consola para migrar el tráfico:

   Gestionar versiones

   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

Puedes definir variables de entorno de compilación para los tiempos de ejecución que admitan paquetes de compilación.

Las variables de entorno de compilación son pares clave-valor que puede especificar para configurar el paquete de compilación que usa para desplegar su aplicación. Por ejemplo, puede especificar opciones de compilador.

Antes de empezar:

• Las claves deben empezar por una letra ASCII en mayúscula y pueden incluir letras ASCII en mayúscula, números y guiones bajos.
• No debes crear ninguna variable con el prefijo de clave GOOGLE_*.
• Las siguientes claves están reservadas para el uso de Google:
  • GOOGLE_RUNTIME
  • GOOGLE_RUNTIME_VERSION
  • GOOGLE_ENTRYPOINT
  • GOOGLE_DEVMODE
• Puedes usar cualquier clave compatible con buildpacks.

Para usar variables de entorno con buildpacks, especifica el campo build_env_variables en tu archivo app.yaml.

Más información sobre los buildpacks

Usar el servidor de desarrollo local

La CLI de Google Cloud incluye un servidor de desarrollo local llamado dev_appserver que puedes ejecutar localmente para simular el funcionamiento de tu aplicación en el entorno 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.

Ejecutar el servidor de desarrollo local

Importante: Antes de ejecutar el servidor de desarrollo local, sigue las instrucciones de configuración.

Una vez que hayas creado 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.

1. Para obtener las credenciales de acceso de tu cuenta de usuario, ejecuta el siguiente comando:

   gcloud auth login
   

2. Permite que tu aplicación local use temporalmente tus credenciales de usuario para acceder a la API:

   gcloud auth application-default login
   

3. Para iniciar el servidor de desarrollo local, sigue estos pasos:

   En el directorio que contiene el archivo de configuración app.yaml, ejecuta el comando dev_appserver.py y especifica el ID del proyecto y la ruta al archivo app.yaml:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml

   Para cambiar el puerto, incluye la opción --port:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

   Para probar una aplicación de Python 3, ejecuta dev_appserver.py con un intérprete de Python 3. Debes especificar el archivo binario de Python 3 en la marca --runtime_python_path. Por ejemplo:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999

   Para obtener más información sobre las opciones del comando dev_appserver.py, consulta Opciones del servidor de desarrollo local.

4. 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.

5. 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.

6. 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 Google Cloud dependen de la presencia de la variable de entorno GOOGLE_CLOUD_PROJECT, que debe ser elGoogle Cloud ID de tu proyecto. 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 archivos dispatch.yaml que incluyan nombres de host, como 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.

Usar Cloud Trace

Cloud Trace es útil para entender cómo se propagan las solicitudes por toda la aplicación. Puedes inspeccionar información detallada sobre la latencia de una solicitud o ver la latencia agregada de toda tu aplicación.

Para ver los detalles de las trazas en Cloud Trace, puedes seguir las instrucciones de Buscar y explorar trazas. En el explorador de trazas, puedes usar los filtros para filtrar por tu servicio y versión específicos de App Engine.