Serverless App Engine:Premiers pas

La figure suivante illustre le flux de travail d'utilisation de SAE.

SAE permet le déploiement d'applications à partir de packages de code ainsi que le déploiement d'applications à partir d'images.

Commande de démarrage et paramètres

• Déploiement par image

  Vous pouvez écrire la commande de démarrage et les paramètres associés directement dans le Dockerfile. Vous pouvez également remplacer la commande de démarrage lors de la création de l'application.

• Déploiement par package

  Vous pouvez configurer les paramètres de la commande de démarrage de l'application. Par exemple, pour Java, le format de commande de démarrage par défaut est Java[-Options] -jar jarfile[arg...]. Vous pouvez personnaliser les paramètres [-Options] et [arg...].

Liste d'autorisation de base de données

Contrairement aux instances ECS, les applications SAE s'exécutent dans des conteneurs dont les adresses IP peuvent changer après chaque déploiement. Toutefois, le bloc CIDR du vSwitch associé à l'application reste inchangé. Vous pouvez donc ajouter le bloc CIDR du vSwitch à la liste d'autorisation de la base de données. Pour plus d'informations, consultez Accéder aux bases de données Alibaba Cloud depuis des applications.

CI/CD

Outre le déploiement via la console et l'API, SAE s'intègre à plusieurs outils d'intégration continue et de livraison continue (CI/CD), tels qu'Alibaba Cloud DevOps et Jenkins. Ces outils permettent de déployer automatiquement les applications après la validation du code. Pour plus d'informations, consultez Vue d'ensemble de l'hébergement d'applications.

• Déploiement basé sur des plug-ins

  Pour Java, SAE fournit divers plug-ins de déploiement, notamment pour Maven, IntelliJ IDEA et Eclipse. Pour plus d'informations, consultez Vue d'ensemble de l'hébergement d'applications.

• Interconnexion entre applications locales et cloud

  Dans un modèle de microservices, un service est souvent divisé en plusieurs applications. Si votre environnement de test est déployé sur Alibaba Cloud, le débogage conjoint peut s'avérer complexe. SAE fonctionne avec Cloud Toolkit pour offrir une interconnexion distante entre les applications locales et cloud. Vous pouvez ainsi appeler directement les consommateurs et fournisseurs basés sur le cloud depuis votre machine locale. Pour plus d'informations, consultez Utiliser Cloud Toolkit pour implémenter l'interconnexion entre applications locales et cloud (IntelliJ IDEA).

• Terraform

  SAE prend en charge Terraform. Pour plus d'informations, consultez terraform-provider-alicloud et Vue d'ensemble de Terraform.

Mise à niveau et restauration

SAE prend en charge diverses stratégies de publication, telles que la publication par lot unique, la publication progressive, la publication canari et la restauration vers des versions historiques. Pour plus d'informations, consultez Mettre à niveau et restaurer une application.

Configuration des permissions

SAE offre un contrôle d'accès granulaire. Vous pouvez configurer les permissions en fonction des namespaces, des applications et des opérations de lecture/écriture. L'assistant de permissions simplifie ce processus de configuration. Pour plus d'informations, consultez Assistant de permissions SAE.

Autres

• Variables d'environnement

  Avant qu'une application puisse s'exécuter, vous devez configurer des variables d'environnement spécifiques. Vous pouvez ensuite exécuter des commandes pour gérer l'application. Les variables d'environnement sont stockées sous forme de paires clé-valeur. Chaque application utilise ses propres variables d'environnement, sans impact sur la configuration des autres. Pour plus d'informations, consultez Configurer les variables d'environnement.

• Association Hosts

  En configurant l'association hosts, une application SAE peut utiliser un nom de domaine plutôt qu'une adresse IP pour accéder à des services externes.

Concepts fondamentaux des réseaux Alibaba Cloud

Principaux scénarios et méthodes d'accès réseau SAE

Après le déploiement d'une application sur SAE, vous pouvez rencontrer les besoins d'accès réseau suivants. La figure ci-dessous illustre ce concept.

Comparaison des méthodes d'accès réseau SAE

Microservices améliorés

En tant que produit de référence pour l'architecture de microservices serverless, SAE offre de nombreuses améliorations des capacités de microservices.

Prise en charge de l'environnement d'exécution PHP

SAE fournit un environnement d'exécution PHP par défaut.

Hébergement de fichiers statiques

À l'aide de NAS et d'OSS, SAE permet l'hébergement indépendant de fichiers statiques. Il offre un stockage persistant pour le code, les modèles et les fichiers téléchargés pendant l'exécution, tout en permettant le partage de fichiers entre les instances.

Débogage distant

Les différentes fonctionnalités de SAE offrent diverses capacités de débogage au sein de SAE.

• Débogage distant PHP

  SAE intègre un plug-in Xdebug permettant le débogage distant.

• Téléchargement de fichiers

  SAE permet de se connecter aux instances via Webshell et de télécharger des fichiers à l'aide des fonctionnalités SAE ou OSS. Pour plus d'informations, consultez Charger et télécharger des fichiers via Webshell.

• Chargement de fichiers

  SAE facilite le développement et le débogage du code grâce à NAS et OSS.

SAE s'intègre à SLS et Kafka pour la collecte des journaux. La fonctionnalité de journaux en temps réel de SAE permet d'afficher 500 lignes d'informations de journal. Pour des besoins d'affichage plus importants, nous recommandons d'utiliser la fonctionnalité de collecte de journaux de fichiers. SAE collecte les journaux de fichiers métier (chemins des journaux dans les conteneurs) ainsi que les journaux de sortie standard (stdout) des conteneurs, puis les envoie vers SLS ou Kafka. Cela permet d'afficher un nombre illimité de lignes de journaux, d'agréger et d'analyser les journaux de manière autonome, facilitant ainsi l'intégration des journaux métier.

Journaux de fichiers

SAE s'intègre à SLS pour la collecte des journaux, qu'il suffit d'activer dans la console SAE. Contrairement à ECS où vous deviez maintenir manuellement une liste de machines pour la collecte, avec SAE, une fois le répertoire ou le fichier de collecte configuré, SAE se connecte automatiquement à SLS pour la collecte des journaux lors de chaque déploiement ou mise à l'échelle horizontale. Vous pouvez rechercher des journaux par mot-clé dans la console SLS. Pour plus d'informations, consultez Configurer la collecte de journaux vers SLS.

Les sources de journaux prennent en charge les caractères génériques. Par exemple, /tmp/log/*.log indique la collecte de tous les fichiers se terminant par log dans le répertoire /tmp/log et ses sous-répertoires.

S'il n'est pas pratique d'utiliser SLS pour la collecte ou si un utilisateur RAM ne peut pas consulter les journaux SLS, vous pouvez choisir d'importer les journaux vers Kafka. Sur cette base, vous pouvez acheminer les données de Kafka vers d'autres bases de données persistantes, telles qu'Elasticsearch, selon vos scénarios métier. Cela facilite la gestion et l'analyse centralisées des journaux. Pour plus d'informations, consultez Configurer la collecte de journaux vers Kafka.

Vous pouvez également définir les paramètres de démarrage de Logtail à l'aide de variables d'environnement. Pour plus d'informations, consultez Améliorer les performances de collecte Logtail.

Journaux en temps réel

SAE collecte automatiquement les journaux stdout, conserve les 500 dernières entrées et permet de les consulter dans la console SAE. Pour plus d'informations, consultez Afficher les journaux en temps réel.

Si vous souhaitez également collecter le contenu stdout vers SLS, vous pouvez d'abord rediriger le contenu vers un fichier, puis configurer la collecte de fichiers. Les paramètres sont illustrés dans la figure suivante.

SAE dispose de 20 Go de stockage sur disque système. Pour lire et écrire sur un stockage externe, nous recommandons d'utiliser NAS et OSS. Le diagnostic des applications SAE implique deux méthodes : les vérifications de routine et le chargement de journaux. Pour le chargement de journaux, outre OSS, vous pouvez utiliser la fonctionnalité intégrée de chargement et téléchargement en un clic de SAE.

NAS

SAE prend en charge le stockage NAS, ce qui résout les problèmes de persistance des données pour les instances d'application et de distribution des données entre les instances. Le stockage NAS n'est accessible que lorsqu'il est monté sur une instance ECS ou une application SAE. Pour plus d'informations, consultez Configurer le stockage NAS.

OSS

OSS fournit des outils pratiques et une console pour la gestion visuelle des buckets. OSS convient aux scénarios à forte intensité de lecture, tels que le montage de fichiers de configuration ou de fichiers statiques frontend. Après avoir configuré le stockage OSS lors du déploiement d'une application dans la console SAE, vous pouvez accéder aux données via la console OSS. Pour plus d'informations, consultez Configurer le stockage OSS.

Chargement et téléchargement de fichiers

Pour télécharger des fichiers de SAE vers votre machine locale, utilisez la fonctionnalité de chargement et téléchargement de fichiers intégrée à Webshell. Pour plus d'informations, consultez Charger et télécharger des fichiers via Webshell.

Outre l'utilisation du stockage NAS ou OSS, vous pouvez également utiliser l'outil ossutil. Pour savoir comment utiliser Alibaba Cloud OSS pour le chargement et le téléchargement de journaux, consultez Diagnostiquer les applications via des vérifications de routine.

SAE intègre une surveillance de l'infrastructure ainsi qu'une surveillance métier ARMS pour Java et PHP. Le système de gestion des alertes offre une convergence fiable des alertes, des notifications, une escalade automatique et d'autres fonctionnalités pour vous aider à détecter et résoudre rapidement les alertes métier.

Surveillance de l'infrastructure

La surveillance de l'infrastructure couvre le CPU, la charge, la mémoire, le disque, le réseau et les connexions TCP. Pour plus d'informations, consultez Surveillance de l'infrastructure. La surveillance intégrée de l'infrastructure est fournie par Alibaba CloudMonitor. Vous pouvez également vous connecter à la console CloudMonitor pour configurer des tableaux de bord personnalisés.

Surveillance des applications

Les applications SAE Professional Edition intègrent les fonctionnalités de surveillance des applications ARMS Pro. Une fois la surveillance des applications activée, aucun frais supplémentaire n'est engagé et la fonctionnalité surveille votre application en temps réel. Pour plus d'informations, consultez Surveillance des applications Professional Edition.

Les applications SAE Standard Edition intègrent la surveillance ARMS Basic Edition. Une fois la surveillance des applications activée, vous pouvez utiliser cette fonctionnalité gratuitement. Toutefois, une option permettant d'activer les fonctionnalités de surveillance ARMS Pro est également disponible. Après activation, des frais supplémentaires s'appliquent et vous devez consulter les données dans ARMS. Pour plus d'informations, consultez Surveillance des applications Standard Edition.

Paramètres d'alerte

SAE permet de définir des alertes pour chacune des métriques mentionnées ci-dessus. Pour plus d'informations, consultez Système de gestion des alertes.

Après avoir déployé une application dans SAE, utilisez la fonctionnalité de vérification de l'état de santé pour un démarrage et un arrêt progressifs du trafic. Cette fonctionnalité permet de vérifier si les instances d'application et les opérations métier fonctionnent normalement, afin de localiser les problèmes en cas d'anomalie. Parallèlement, SAE prend en charge le déploiement d'applications sur plusieurs vSwitch pour faire face aux pannes au niveau du centre de données, ainsi que l'utilisation d'AHAS pour mettre en œuvre la limitation de débit et la dégradation pour les applications Java. Ces fonctionnalités garantissent globalement la disponibilité des applications.

Déploiement multi-vSwitch

Pour faire face aux pannes au niveau du centre de données, nous recommandons de configurer plusieurs vSwitch pour les applications SAE de niveau production. Vous pouvez configurer plusieurs vSwitch lors de la création d'une application ou ajouter des vSwitch après la création de l'application. Lors de la création d'un vSwitch, nous recommandons d'allouer un nombre suffisant d'adresses IP (plus de 100 est recommandé). Si le nombre d'adresses IP est insuffisant, la création de l'application ou la mise à l'échelle élastique peut échouer. Pour plus d'informations, consultez Changer de vSwitch.

Grâce à l'utilisation de plusieurs vSwitch, SAE aide les entreprises à mettre à l'échelle automatiquement les ressources sur plusieurs zones. Vous n'avez pas besoin de surveiller la répartition des ressources, car SAE assure la disponibilité globale de celles-ci. Par exemple, en cas de point de défaillance unique ou de panne de zone, SAE migre les instances défaillantes vers des nœuds sains ou d'autres zones en quelques secondes.

• Sélectionnez plusieurs vSwitch lors de la création.

  

• Ajoutez un vSwitch après la création.

  

  Remarque

  Lorsque vous ajoutez un vSwitch, assurez-vous de synchroniser la configuration de la liste d'autorisation de la base de données. Pour plus d'informations, consultez Accéder aux bases de données Alibaba Cloud depuis des applications.

Démarrage et arrêt progressifs

SAE repose sur Kubernetes et propose deux méthodes de vérification de l'état de santé : les sondes de vivacité (configuration Liveness) et les sondes de disponibilité (configuration Readiness). Pour répondre à ces deux problématiques, SAE permet de configurer une sonde de disponibilité. Celle-ci vérifie périodiquement si une instance est prête. Dès qu'une nouvelle instance est opérationnelle, SAE y dirige le trafic. En cas d'échec de la vérification, SAE n'y dirige pas le trafic. Avant d'être détruites, les anciennes instances sont d'abord retirées du flux de trafic. Vous pouvez également configurer un script d'arrêt et un délai d'attente avant la destruction des instances. Pour plus d'informations, consultez Configurer les vérifications de l'état de santé.

La sonde de vivacité vérifie également périodiquement si une instance a démarré. En cas d'échec, SAE redémarre automatiquement le conteneur. Cette fonctionnalité est utile pour l'O&M automatisé dans des scénarios exceptionnels, mais elle peut entraîner la perte du contexte de la panne, rendant l'investigation des causes impossible. Décidez de configurer ou non une sonde de vivacité en fonction de votre scénario réel.

Outre la configuration des sondes de disponibilité ou de vivacité, les scénarios de microservices nécessitent également la configuration d'un arrêt progressif pour les microservices afin de résoudre le problème de mise en cache dans le registre de services. Pour plus d'informations, consultez Configurer le démarrage et l'arrêt progressifs. Dans un environnement de production, l'utilisation de fonctionnalités telles que la mise à l'échelle élastique automatique et les mises à niveau par restauration peut rendre les services indisponibles pendant une courte période et générer de nombreuses erreurs dans la surveillance métier. Pour résoudre ces difficultés, SAE permet de configurer un démarrage progressif pour les microservices. Pour plus d'informations, consultez Configurer le démarrage et l'arrêt progressifs.

Limitation de débit et dégradation

Pour les scénarios à fort trafic, SAE intègre la fonctionnalité de protection du trafic de Microservices Engine (MSE) afin de configurer et gérer facilement les règles de limitation de débit et de dégradation, garantissant ainsi la disponibilité des applications. Pour plus d'informations, consultez Protection du trafic.

SAE prend en charge des politiques élastiques telles que la mise à l'échelle manuelle, la mise à l'échelle planifiée, la mise à l'échelle basée sur des métriques, la mise à l'échelle hybride, ainsi que le démarrage et l'arrêt planifiés. L'élasticité est une caractéristique typique des architectures et applications cloud-native qui permet de réduire les coûts d'infrastructure et d'améliorer l'efficacité de l'O&M.

Mise à l'échelle manuelle

La mise à l'échelle manuelle convient aux scénarios d'O&M manuel. Comparé au processus de mise à l'échelle ECS, relativement complexe et lent, la mise à l'échelle SAE repose sur des images de conteneur et est plus rapide. Pour plus d'informations, consultez Mise à l'échelle manuelle.

Mise à l'échelle planifiée

La mise à l'échelle planifiée convient aux scénarios où le trafic est prévisible. Par exemple, les secteurs de la restauration et de l'éducation connaissent des pics d'activité marqués chaque matin et soir. Vous pouvez ainsi configurer différents nombres d'instances à exécuter à différents moments afin d'aligner au mieux les ressources serveur sur le trafic réel du service. Pour plus d'informations, consultez Configurer une politique Auto Scaling.

Mise à l'échelle basée sur des métriques

La mise à l'échelle basée sur des métriques convient aux scénarios où le trafic est relativement imprévisible. Elle prend actuellement en charge des métriques telles que le CPU, la mémoire, les connexions TCP, le QPS et le RT. Pour plus d'informations, consultez Configurer une politique Auto Scaling.

Élasticité hybride

La mise à l'échelle hybride convient aux scénarios combinant des pics de trafic et des besoins de mise à l'échelle planifiée, tels que ceux des secteurs Internet, éducatif et de la restauration. Elle permet un ajustement granulaire du nombre d'instances pour des périodes connues.

Par exemple, en semaine, le nombre maximal d'instances élastiques est configuré à max et le minimum à min. Cependant, si vous n'avez pas besoin de maintenir min instances le week-end, vous pouvez configurer un nombre différent d'instances pour le week-end afin de réduire la valeur de min. Pour plus d'informations, consultez Configurer une politique Auto Scaling.

Démarrage et arrêt planifiés

La fonctionnalité de démarrage et d'arrêt planifiés permet de démarrer et d'arrêter des applications d'un namespace par lots à des heures programmées. Par exemple, vous pouvez planifier le démarrage et l'arrêt de toutes les applications d'un environnement de développement ou de test. Supposons que vous n'ayez besoin d'utiliser un environnement de développement et de test que de 08h00 à 20h00 chaque jour, celui-ci restant inactif le reste du temps. Vous pouvez configurer le démarrage et l'arrêt planifiés dans SAE pour réduire les coûts. Pour plus d'informations, consultez Créer une règle de démarrage et d'arrêt planifiés.

SAE propose des bonnes pratiques pour divers besoins métier. Cette rubrique couvre l'élasticité, le réseau, le stockage et l'accès des applications aux bases de données Alibaba Cloud. D'autres bonnes pratiques incluent les images, l'accélération des applications et la configuration des paramètres JVM. Pour plus d'informations sur les scénarios courants, consultez Bonnes pratiques.