Serverless App Engine:Primeros pasos

Si es nuevo en SAE, vea el video para conocer SAE y sus operaciones básicas.

Requisitos previos

Prepare los siguientes elementos antes de su primer despliegue:

• Recursos de red — Planifique una VPC y sus vSwitches. Al crear un vSwitch, planifique la cantidad de direcciones IP como se describe en Limits and quotas.

• Namespaces — Planifique los namespaces que separan sus entornos de prueba, preproducción y producción.

• Origen de la aplicación — Prepare un paquete de código o una imagen de contenedor. Para ver los orígenes compatibles, consulte Deployment sources.

• Entrada a la consola — Cree su primera aplicación en la consola de SAE.

  Para más detalles, consulte Prerequisites.

Límites y cuotas

Tome en cuenta los siguientes límites durante la planificación. Cada uno afecta la posibilidad de crear, escalar u observar una aplicación.

• Disco del sistema — SAE proporciona 20 GB de almacenamiento en disco del sistema. Para leer o escribir en almacenamiento externo, utilice Apsara File Storage NAS u Object Storage Service (OSS). Para más detalles, consulte Storage.

• Registros en tiempo real — La función de registros en tiempo real muestra 500 líneas de datos de registro. Para ver más datos, utilice la recolección de registros de archivos. Para más detalles, consulte Logs.

• Cantidad de EIP — Cuando cada instancia se vincula a una EIP, asegúrese de que la cantidad de EIP sea como mínimo igual al número de instancias más uno. Si las EIP son insuficientes, la creación de instancias falla y la instancia no puede atender tráfico.

• Direcciones IP de vSwitch — Planifique 100 o más direcciones IP para cada vSwitch, ya que la falta de direcciones IP provoca fallos en la creación y en el escalado elástico.

• Asignación de puertos — Un Service expone un puerto para una aplicación. Un ingress expone un puerto para varias aplicaciones.

Orígenes de despliegue

SAE admite code package deployment y image deployment.

Comando y parámetros de inicio

El comando de inicio se define de manera distinta para cada origen de despliegue.

• Despliegue por imagen — Defina el comando de inicio y sus parámetros directamente en el Dockerfile. También puede sobreescribir el comando de inicio al crear la aplicación.

• Despliegue por paquete de código — Configure los parámetros del comando de inicio de la aplicación. Para aplicaciones Java, el formato predeterminado del comando es java [-Options] -jar jarfile [arg...], donde puede personalizar los parámetros [-Options] y [arg...].

Variables de entorno

Una aplicación requiere variables de entorno específicas para ejecutarse en el sistema antes de que puedan ejecutarse sus comandos. Las variables de entorno se almacenan como pares clave-valor. Cada aplicación tiene sus propias variables de entorno, las cuales no afectan a otras aplicaciones. Para más detalles, consulte Configure environment variables.

Vinculación de hosts

Con Hosts binding, una aplicación de SAE puede usar un nombre de dominio en lugar de una dirección IP para acceder a servicios externos.

Lista blanca de base de datos

A diferencia del despliegue directo de aplicaciones en instancias de Elastic Compute Service (ECS), SAE ejecuta aplicaciones en contenedores, por lo que la dirección IP puede cambiar cada vez que se despliega una aplicación. El bloque CIDR del vSwitch al que está vinculada la aplicación no cambia, así que agregue el bloque CIDR del vSwitch a la lista blanca de la base de datos. Para más detalles, consulte Access Alibaba Cloud databases from applications.

CI/CD y complementos de despliegue

Además del despliegue desde la consola y la API, SAE se integra con muchas herramientas de CI/CD, generalmente Alibaba Cloud DevOps y Jenkins, para que el despliegue inicie automáticamente después de un commit de código. Si utiliza Java, SAE también ofrece un conjunto de complementos de despliegue, incluidos complementos para Maven, IntelliJ IDEA y Eclipse. Para más detalles, consulte Overview of application hosting.

Para gestionar los recursos de SAE como código, utilice Terraform. Para más detalles, consulte terraform-provider-alicloud y Terraform overview.

Para desarrollo local y depuración conjunta con servicios que ya se ejecutan en la nube, consulte Microservices development.

Publicación y reversión

SAE admite publicación por lotes únicos, publicación por fases y publicación canary. Si una versión causa problemas, puede revertir la aplicación a una versión histórica. Para más detalles, consulte Upgrade and roll back an application.

Configuración de permisos

SAE admite control de acceso detallado a nivel de namespace, aplicación y lectura/escritura, y el asistente de permisos simplifica el proceso de configuración. Para más detalles, consulte SAE permission assistant.

Conceptos de red

La siguiente figura muestra cómo se relacionan estos recursos de red de Alibaba Cloud.

• VPC — Una red privada personalizada que usted crea en Alibaba Cloud. Las VPC están completamente aisladas entre sí en la capa lógica.

  Nota

  De forma predeterminada, una red privada no puede acceder a Internet.

• vSwitch — Un dispositivo de red básico de una VPC que corresponde a un centro de datos físico. Al crear un recurso en la nube dentro de una VPC, debe especificar el vSwitch al que se conecta el recurso.

• EIP — Una Elastic IP address que solo se puede vincular a un recurso, como una instancia de ECS o una instancia de SAE. El recurso vinculado puede enviar y recibir tráfico de Internet.

• NAT Gateway — Permite que los recursos de una VPC accedan a Internet mediante SNAT. La diferencia clave respecto a una EIP es que un NAT gateway de Internet atiende a todos los recursos de una VPC, mientras que una EIP solo atiende a un recurso dentro de la VPC.

Métodos de acceso según la dirección del tráfico

Después de desplegar una aplicación en SAE, es posible que enfrente los siguientes requisitos de acceso a la red. La siguiente figura ilustra estos conceptos.

Comparación de los métodos de acceso

Registro de servicios y centro de configuración

Las aplicaciones de SAE se registran y se descubren mutuamente mediante un registro de servicios. Elija una implementación según sus necesidades.

• MSE Nacos (recomendado) — Use the Nacos service registry of MSE, que funciona tanto como registro de microservices como centro de configuración.

• Registro de servicios Nacos integrado — El registro de servicios Nacos integrado en SAE. Para las aplicaciones que lo utilizan, SAE proporciona capacidades básicas de consulta de listas de servicios.

• Gestión de configuración integrada — La función distributed configuration management (ACM) integrada en SAE, que funciona como centro de configuración.

  Para más detalles sobre el registro y descubrimiento, incluida la compatibilidad con otros registros de servicios, consulte Service registration and discovery based on Nacos and other service registries.

Desarrollo de microservices

Gobernanza de servicios

Capacidades relacionadas con microservices

• Inicio y apagado graceful, incluido el apagado graceful para microservices: consulte Graceful start and shutdown.

• Limitación de tasa y degradación: consulte Throttling and degradation.

• Monitoreo, rastreo y alertas de aplicaciones: consulte Monitoring and alerts.

Compatibilidad con el entorno de ejecución PHP

SAE admite los siguientes métodos de despliegue para aplicaciones PHP.

• Imagen: cualquier arquitectura de aplicación PHP.

• Paquete ZIP de PHP: cualquier aplicación en línea que utilice una arquitectura PHP-FPM y Nginx.

  SAE proporciona un entorno de ejecución PHP de forma predeterminada.

Depuración remota de PHP

SAE incluye un complemento Xdebug integrado que puede habilitar para la depuración remota. Para mover archivos entre una instancia y su máquina local mientras depura, consulte Upload and download files.

Registros de archivos

SAE integra la recolección de registros de SLS, y solo necesita habilitarla en la consola de SAE. A diferencia del despliegue directo de aplicaciones en instancias de ECS, donde se mantiene manualmente la lista de máquinas de recolección, SAE se conecta automáticamente a la recolección de registros de SLS en cada despliegue y escalado horizontal después de configurar el directorio o el archivo de recolección. Luego puede buscar registros por palabra clave en la consola de SLS. Para más detalles, consulte Configure log collection to SLS.

Para configurar la recolección, vaya a la página Log Configurations y haga lo siguiente:

1. Active Enable SLS Log Service.

2. Seleccione Create New SLS Resources o Use Existing SLS Resources.

3. En la tabla de configuración de recolección, seleccione un Log Type, como Container Standard Output, y establezca el Log Source, como stdout.log.

4. Haga clic en Add para agregar más reglas de recolección.

   Los orígenes de registros admiten comodines. Por ejemplo, /tmp/log/*.log recolecta todos los archivos que terminan con .log en el directorio /tmp/log y sus subdirectorios.

También puede establecer parámetros de inicio de Logtail con variables de entorno. Para más detalles, consulte Improve Logtail collection performance.

Si importa los registros a Kafka, puede entregar los datos de Kafka a otro almacén persistente, como Elasticsearch, según su escenario de negocio, lo que facilita la gestión y el análisis centralizado de registros. Para más detalles, consulte Configure log collection to Kafka.

Registros en tiempo real

SAE recolecta registros de salida estándar automáticamente, conserva las últimas 500 entradas y le permite verlas en la consola de SAE. Para más detalles, consulte View real-time logs.

En la página Real-time Logs, seleccione una instancia de la lista desplegable Pod Name y establezca la Real-time Log Refresh Rate, que es de 15 s de forma predeterminada.

Para conservar los registros de salida estándar más allá de las últimas 500 entradas, rediríjalos a un archivo:

1. En el campo args de Startup Command Settings, introduzca >> /tmp/stdout.log 2>&1 para redirigir la salida estándar al archivo /tmp/stdout.log.

2. Configure la recolección de archivos para /tmp/stdout.log como se describe en File logs. También puede ver el archivo en línea a través de Webshell, que solo está disponible cuando la instancia se ejecuta correctamente.

NAS

SAE admite Apsara File Storage NAS, que resuelve la persistencia de datos para las instancias de aplicaciones y la distribución de datos entre instancias. El almacenamiento NAS solo es accesible después de montarlo en una instancia de ECS o en SAE. Para más detalles, consulte Configure NAS storage.

OSS

OSS proporciona herramientas prácticas y una consola para la gestión visual de buckets. OSS es adecuado para escenarios de lectura intensiva, como montar archivos de configuración o archivos estáticos de front-end. Después de configurar el almacenamiento OSS al desplegar una aplicación en la consola de SAE, puede acceder a los datos en la consola de OSS. Para más detalles, consulte Configure OSS storage.

Cargar y descargar archivos

Para descargar un archivo de una instancia de SAE a su máquina local, inicie sesión en la instancia a través de Webshell y utilice la función integrada de carga y descarga de archivos. Para más detalles, consulte Upload and download files using Webshell.

Además del almacenamiento NAS y OSS, puede usar ossutil. NAS y OSS también simplifican el desarrollo y la depuración de código. Puede diagnosticar una aplicación de SAE mediante comprobaciones rutinarias o cargando registros en OSS. Para obtener información sobre cómo cargar y descargar registros con Alibaba Cloud OSS, consulte Diagnose applications through routine checks.

Escalado manual

El escalado manual es adecuado para escenarios con operación y mantenimiento manual. En comparación con el escalado de aplicaciones desplegadas directamente en instancias de ECS, el escalado de SAE se basa en imágenes de contenedor y es más rápido. Para más detalles, consulte Manual scaling.

Escalado programado

El escalado programado es adecuado para escenarios con tráfico predecible. Por ejemplo, las industrias de restaurantes y educación tienen picos de actividad matutinos y vespertinos claros todos los días, por lo que puede configurar diferentes cantidades de instancias para distintos períodos de tiempo y alinear los recursos del servidor con el tráfico real del negocio. Para más detalles, consulte Configure an auto-scaling policy.

Escalado basado en métricas

El escalado basado en métricas es adecuado para escenarios con tráfico relativamente impredecible. Actualmente admite métricas como CPU, memoria, conexiones TCP, QPS y tiempo de respuesta (RT). Para más detalles, consulte Configure an auto-scaling policy.

Escalado híbrido

El escalado híbrido es adecuado para escenarios que requieren tanto el manejo de tráfico repentino como el escalado programado, como en los sectores de internet, educación y servicios de alimentación. En estos casos, se ajusta el número de instancias con una granularidad fina durante periodos de tiempo conocidos.

Por ejemplo, establezca el número máximo de instancias elásticas en max y el mínimo en min durante los días laborables. Si no necesita mantener min instancias los fines de semana, configure una cantidad diferente para esos días y reduzca el valor de min. Para obtener más información, consulte Configure an auto-scaling policy.

Inicio y detención programados

La función de inicio y detención programados permite iniciar y detener aplicaciones por lotes según el namespace y conforme a un horario establecido. Por ejemplo, programe el inicio y la detención de todas las aplicaciones en un entorno de desarrollo o pruebas. Si un entorno de desarrollo o pruebas solo se necesita de 08:00 a 20:00 horas diariamente y permanece inactivo el resto del tiempo, configure el inicio y la detención programados en SAE para reducir costos. Para obtener más información, consulte Create a scheduled start and stop rule.

Monitoreo de infraestructura

El monitoreo de infraestructura abarca CPU, carga, memoria, disco, red y conexiones TCP. Para obtener más información, consulte Infrastructure monitoring. Actualmente, el monitoreo de infraestructura funciona con Alibaba Cloud CloudMonitor, por lo que también puede iniciar sesión en la consola de CloudMonitor para configurar un panel de monitoreo personalizado.

Monitoreo de aplicaciones

En una arquitectura de microservices, la ausencia de un sistema de monitoreo dificulta la detección y el diagnóstico de problemas. SAE integra Application Real-Time Monitoring Service (ARMS) para proporcionar paneles de aplicaciones, monitoreo de JVM, monitoreo de llamadas lentas, análisis de rastreo y alertas. Esto reduce la barrera de entrada para que las empresas adopten una arquitectura de microservices. Para obtener más información, consulte Application Monitoring.

La edición de ARMS que integra una aplicación y las tarifas aplicables dependen de la edición de la aplicación.

Las aplicaciones Standard Edition de SAE integran el monitoreo ARMS Basic Edition, que es gratuito tras habilitar el monitoreo de aplicaciones. Standard Edition también ofrece un punto de entrada para habilitar el monitoreo ARMS Premium Edition. Si habilita ARMS Premium Edition en una aplicación Standard Edition, se generarán cargos adicionales y deberá consultar los datos en la consola de ARMS. Para obtener más información, consulte Standard Edition application monitoring.

Configuración de alertas

SAE le permite configurar alertas para todos los elementos de monitoreo mencionados anteriormente. Para obtener más información, consulte Alert management.

Despliegue multi-vSwitch

Para manejar fallos a nivel de centro de datos, configure varios vSwitches en las aplicaciones SAE de grado de producción. Al crear un vSwitch, planifique un número suficiente de direcciones IP (100 o más), ya que la insuficiencia de direcciones IP provoca fallos en la creación o en el escalado elástico. Para obtener más información, consulte Switch vSwitches.

Con múltiples vSwitches, SAE escala los recursos automáticamente en varias zonas, por lo que no necesita rastrear cómo se distribuyen los recursos y el pool de recursos general permanece disponible. Por ejemplo, cuando ocurre un punto único de fallo o un fallo de zona, SAE migra la misma cantidad de instancias defectuosas a nodos sanos u otras zonas.

Configure varios vSwitches de cualquiera de las siguientes maneras.

• Durante la creación: seleccione dos o más vSwitches en diferentes zonas para lograr recuperación ante desastres multizona.

• Después de la creación: en la página Application Information, haga clic en el enlace Multi-vSwitch Deployment y agregue un vSwitch.

Inicio y apagado controlados

Al desplegar una aplicación en SAE, el proceso generalmente escala horizontalmente primero y luego reduce su capacidad. El inicio y apagado controlados del tráfico implican dos puntos críticos principales.

• Si una instancia recién escalada está lista para manejar tráfico.

• Cómo destruir una instancia antigua de forma controlada.

  SAE se basa en Kubernetes y proporciona dos comprobaciones de estado: la prueba de actividad (liveness probe) para instancias de aplicaciones y la prueba de preparación (readiness probe) para servicios de aplicaciones. Para abordar los dos puntos críticos, SAE admite la prueba de preparación. Esta prueba verifica periódicamente si una instancia está lista, y SAE enruta el tráfico a una nueva instancia solo después de que esta esté lista. Si la comprobación falla, SAE no enruta tráfico a la instancia. Antes de destruir una instancia antigua, se elimina del lado del tráfico, y usted puede configurar un script de apagado y un tiempo de espera antes de que se destruya la instancia. Para obtener más información, consulte Configure health checks.

La prueba de actividad también comprueba periódicamente si una instancia se ha iniciado. Si la comprobación falla, SAE reinicia el contenedor automáticamente. Esta función admite operaciones y mantenimiento automatizados para escenarios de excepción, pero puede perder el contexto del fallo e impedirle investigar la causa. Decida si debe configurar la prueba de actividad según su escenario.

Además de la prueba de preparación y la prueba de actividad, los escenarios de microservices requieren un apagado controlado para resolver el problema de caché del registro de servicios. Dado que el cliente consumidor almacena datos en caché, no puede recibir a tiempo la notificación de desconexión de un proveedor de microservices. Como resultado, generalmente es necesario dar de baja la instancia del proveedor en el registro de servicios y esperar a que se actualice la caché del consumidor. Para resolver este problema, SAE se integra con la función de apagado controlado de Microservices Engine (MSE) y convierte este proceso en una capacidad del producto.

En un entorno de producción, funciones como el escalado elástico automático y la reversión o actualización pueden causar indisponibilidad del servicio a corto plazo o una gran cantidad de errores en el monitoreo de negocio. Para abordar estos puntos críticos, SAE admite el inicio controlado para microservices. Un consumidor puede llamar a un proveedor de microservices tan pronto como el proveedor se registre en el registro de servicios. Sin embargo, en ese momento, es posible que el proveedor aún requiera inicialización adicional, como la inicialización del pool de conexiones de la base de datos. Habilite el inicio controlado para aplicaciones de microservices con mucho tráfico. Para obtener más información, consulte Configure graceful start and shutdown.

Limitación de tráfico y degradación

Independientemente de si una aplicación utiliza una arquitectura de microservices o monolítica, puede fallar repentinamente al enfrentar tráfico repentino, como en una venta flash, y una aplicación de microservices también puede provocar un fallo en cascada. Para estos escenarios de alto tráfico, SAE integra la capacidad de protección de tráfico de Microservices Engine (MSE), que le permite configurar y gestionar reglas de limitación de tráfico y degradación para aplicaciones Java con facilidad, además de salvaguardar la disponibilidad de la aplicación. Para obtener más información, consulte Traffic protection.