Créer des environnements d'exécution personnalisés

Un environnement d'exécution personnalisé vous permet d'utiliser une implémentation différente de n'importe quel langage de l'environnement flexible compatible ou de personnaliser un langage fourni par Google. Il vous permet également d'écrire du code dans n'importe quel autre langage capable de traiter les requêtes HTTP entrantes (exemple). Avec un environnement d'exécution personnalisé, l'environnement flexible fournit et gère votre infrastructure de scaling, de surveillance et d'équilibrage de charge pour vous, afin que vous puissiez vous concentrer sur la création de votre application.

Pour créer un environnement d'exécution personnalisé, vous devez effectuer les opérations suivantes :

Fournir un fichier app.yaml

Votre fichier de configuration app.yaml doit contenir au moins les paramètres suivants :

runtime: custom
env: flex

Pour plus d'informations sur les autres paramètres que vous pouvez définir pour votre application, consultez la page Configurer une application à l'aide d'un fichier app.yaml.

Créer un fichier Dockerfile

Une documentation complète sur la création de fichiers Dockerfile est disponible sur le site Web de Docker. Si vous utilisez un environnement d'exécution personnalisé, vous devez fournir un fichier Dockerfile, que vous utilisiez votre propre image de base ou l'une des images de base de Google.

Spécifier une image de base

La première commande d'un fichier Dockerfile est généralement une commande FROM spécifiant une image de base. Une image de base est utilisée pour créer le conteneur et votre application. Vous pouvez créer votre propre image de base ou en choisir une dans des registres de conteneurs tels que DockerHub.

Localiser le fichier Dockerfile

En règle générale, le fichier Dockerfile est toujours nommé Dockerfile et est placé dans le même répertoire que le fichier app.yaml correspondant. Dans certains cas, toutefois, l'environnement d'outils peut avoir des exigences différentes. Par exemple, les outils Java basés sur le SDK Cloud tels que les plug-ins Maven, Gradle, Eclipse et IntelliJ nécessitent que le fichier Dockerfile se trouve dans src/main/docker/Dockerfile et que le fichier app.yaml se trouve dans src/main/appengine/app.yaml. Pour plus d'informations, consultez la documentation de votre environnement d'outils.

Structure du code

Cette section décrit le comportement que votre code doit mettre en œuvre, que vous utilisiez une image de base fournie par Google ou votre propre image de base.

Écouter le port 8080

L'interface App Engine achemine les requêtes entrantes vers le module approprié sur le port 8080. Vous devez vous assurer que le code de votre application écoute le port 8080.

Gérer des événements de cycle de vie

L'environnement flexible envoie régulièrement à votre application certains événements de cycle de vie.

Arrêt de l'application

Lorsqu'une instance doit être arrêtée, les nouvelles requêtes entrantes sont acheminées vers d'autres instances (le cas échéant) et les requêtes en cours de traitement ont le temps de se terminer. Lors de l'arrêt d'une instance, l'environnement flexible envoie normalement un signal STOP (SIGTERM) au conteneur de l'application. Votre application n'a pas besoin de répondre à cet événement, mais elle peut l'utiliser pour effectuer toutes les actions de nettoyage nécessaires avant l'arrêt du conteneur. Dans des conditions normales, le système attend jusqu'à 30 secondes que l'application s'arrête, puis envoie un signal KILL (SIGKILL), arrêtant immédiatement l'instance.

Dans de rares cas, des pannes peuvent empêcher App Engine d'accorder un délai de 30 secondes avant l'arrêt, ce qui signifie que les signaux STOP et KILL peuvent ne pas être envoyés avant l'arrêt d'une instance. Pour gérer cette possibilité, vous devez contrôler régulièrement l'état de votre instance, en l'utilisant principalement comme cache en mémoire et non comme un datastore fiable.

Requêtes de vérification d'état

Vous pouvez utiliser des requêtes de vérification d'état périodiques pour confirmer qu'une instance de VM a été correctement déployée et pour vérifier le bon état d'une instance en cours d'exécution.

Créer et déployer votre environnement d'exécution personnalisé

Après avoir configuré les fichiers app.yaml et DOCKER, vous pouvez créer et déployer cette image de conteneur sur App Engine.

Vous pouvez également déployer des images de conteneurs prédéfinies de vos environnements d'exécution personnalisés stockées dans Artifact Registry. Par exemple, vous pouvez utiliser Cloud Build pour créer vos images séparément, puis les stocker dans Artifact Registry. Pour en savoir plus, consultez la page Transférer et extraire des images.

Intégrez votre application à Google Cloud

Les applications exécutées dans des environnements d'exécution personnalisés peuvent utiliser les bibliothèques clientes Google Cloud pour accéder aux services Google Cloud. Ces applications peuvent également utiliser n'importe quel service tiers à l'aide des API standards.

S'authentifier auprès des services Google Cloud

Les identifiants par défaut de l'application constituent le moyen le plus simple de s'authentifier et d'appeler les API Google.

Si votre application utilise Cloud Build pour compiler des images Docker, le réseau cloudbuild héberge les identifiants par défaut de l'application, permettant ainsi aux services Google Cloud associés de trouver automatiquement vos identifiants.

Pour en savoir plus sur l'authentification, consultez la page Authentification chez Google.

Journalisation

Lorsqu'une requête est envoyée à votre application exécutée dans App Engine, les détails de la requête et de la réponse sont automatiquement journalisés. Vous pouvez les consulter dans l'Explorateur de journaux de Google Cloud Console.

Lorsque votre application traite une requête, elle peut écrire ses propres messages de journalisation dans stdout et stderr. Ces fichiers sont automatiquement collectés et peuvent être consultés dans l'explorateur de journaux. Seules les entrées les plus récentes de stdout et stderr sont conservées, afin de limiter leur taille.

Vous pouvez également écrire des journaux personnalisés dans /var/log/app_engine/custom_logs à l'aide d'un fichier se terminant par .log ou .json.

Si vous incluez des agents tiers dans votre conteneur d'applications, veillez à les configurer pour qu'ils se connectent à stdout et stderr, ou à un journal personnalisé. Cela garantit que toutes les erreurs générées par ces agents sont visibles dans Cloud Logging.

Les journaux des requêtes et des applications de votre application sont collectés par un agent Cloud Logging et sont conservés pendant 90 jours maximum, jusqu'à une taille maximale de 1 Go. Si vous souhaitez stocker vos journaux pendant une période plus longue ou stocker des journaux d'une taille supérieure à 1 Go, vous pouvez exporter vos journaux vers Cloud Storage. Vous avez également la possibilité d'exporter vos journaux vers BigQuery et Pub/Sub en vue d'un traitement ultérieur.

D'autres journaux sont également à votre disposition. Voici quelques-uns des journaux configurés par défaut :

Nom du journal Type de charge utile Objectif
crash.log texte Informations enregistrées en cas d'échec de l'installation Si l'exécution de votre application échoue, consultez ce journal.
monitoring.* text Informations issues des données de publication du conteneur Docker vers Cloud Monitoring.
shutdown.log text Informations enregistrées sur l'arrêt
stdout texte Sortie standard de votre application
stderr texte Erreur type de votre conteneur
syslog texte Syslog de VM, à l'extérieur du conteneur Docker