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

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:

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

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:

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

  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

    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.

  3. Cuando quieras enviar tráfico a la nueva versión, usa la Google 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

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.

  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:

    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 de dev_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.

  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 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") 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.