Remarque : Go 1.11 n'est plus compatible à partir du 30 janvier 2024. Vos applications Go 1.11 existantes continueront à fonctionner et à recevoir du trafic. Toutefois, App Engine peut bloquer le redéploiement des applications qui utilisent des environnements d'exécution après leur date de fin de compatibilité. Nous vous recommandons de migrer vers la dernière version compatible de Go.

Tester et déployer votre application

ID de la région

Le REGION_ID est un code abrégé que Google attribue en fonction de la région que vous sélectionnez lors de la création de votre application. Le code ne correspond pas à un pays ou une province, même si certains ID de région peuvent ressembler aux codes de pays et de province couramment utilisés. Pour les applications créées après février 2020, REGION_ID.r est inclus dans les URL App Engine. Pour les applications existantes créées avant cette date, l'ID de région est facultatif dans l'URL.

En savoir plus sur les ID de région

Découvrez comment exécuter votre application en local, la déployer et la tester sur App Engine.

Exécution locale

Pour tester la fonctionnalité de l'application avant le déploiement, exécutez-la dans l'environnement local avec les outils de développement que vous utilisez habituellement. Par exemple, la commande go run.

Avant de déployer votre application

Avant de déployer votre application, les conditions suivantes doivent être remplies :

Le propriétaire du projet Google Cloud doit activer App Engine.
Vous devez vous assurer que votre compte utilisateur inclut les droits requis.

Déployer l'application

Déployez votre application sur App Engine à l'aide de la commande gcloud app deploy.

Pendant le déploiement, le service Cloud Build crée une image de conteneur de votre application à exécuter dans l'environnement standard App Engine. Les builds sont créés dans la région de l'application. Pour en savoir plus, consultez la section Gérer les images de build.

Pour déployer vos applications par programmation, utilisez l'API Admin.

Déployer un service

Déployer une application sur App Engine implique de mettre en œuvre des versions des services de votre application et de chacun de leurs fichiers de configuration.

Pour déployer une version du service de votre application, exécutez la commande suivante à partir du répertoire contenant le fichier app.yaml de votre service :

gcloud app deploy

Le fait de ne spécifier aucun fichier avec la commande a pour effet de ne déployer que le fichier app.yaml dans votre répertoire actuel. Par défaut, la commande deploy génère un ID unique pour la version que vous déployez. Elle effectue le déploiement de la version dans le projet Google Cloud pour lequel vous avez configuré Google Cloud CLI et achemine tout le trafic vers la nouvelle version.

Vous pouvez modifier le comportement par défaut de la commande en ciblant des fichiers spécifiques ou en incluant des paramètres supplémentaires :

Pour déployer les autres fichiers de configuration de votre service, vous devez cibler et déployer chaque fichier séparément. Exemple :
```
gcloud app deploy cron.yaml
gcloud app deploy dispatch.yaml
gcloud app deploy index.yaml
```
Pour spécifier un ID de version personnalisé, utilisez l'option --version.
Pour empêcher que le trafic ne soit automatiquement acheminé vers la nouvelle version, utilisez l'option --no-promote.
Pour effectuer un déploiement dans un projet Google Cloud spécifique, utilisez l'option --project.

Par exemple, pour déployer le service défini par le fichier app.yaml dans un projet Google Cloud spécifique, attribuez-lui un ID de version personnalisé et empêchez que le trafic ne soit acheminé vers la nouvelle version :

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

Pour en savoir plus sur cette commande, consultez la documentation de référence sur gcloud app deploy.

Déployer plusieurs services

La même commande de déploiement permet de déployer ou mettre à jour les différents services constituant votre application.

Pour déployer plusieurs services, déployez séparément le fichier app.yaml de chaque service. Vous pouvez spécifier plusieurs fichiers à l'aide d'une seule commande gcloud app deploy :

gcloud app deploy service1/app.yaml service2/app.yaml

Conditions requises pour déployer plusieurs services

Pour pouvoir créer et déployer des services supplémentaires, vous devez d'abord déployer une version de votre application sur le service default.
L'ID de chacun de vos services doit être spécifié dans les fichiers de configuration app.yaml correspondants. Pour spécifier l'ID d'un service, incluez la définition de l'élément service dans chaque fichier de configuration. Par défaut, le fait d'exclure cette définition d'élément de votre fichier de configuration entraîne le déploiement de la version sur le service default.

Afficher des journaux de compilation

Cloud Build diffuse des journaux de compilation et de déploiement visibles dans la section Historique Cloud Build de la console Google Cloud. Pour afficher les builds de la région de l'application, utilisez le menu déroulant Région en haut de la page pour choisir la région selon laquelle vous souhaitez filtrer les builds.

Ignorer des fichiers

Vous pouvez utiliser un fichier .gcloudignore pour spécifier les fichiers et répertoires à ne pas importer dans App Engine lorsque vous déployez vos services. Cela s'avère utile pour ignorer les artefacts de build et d'autres fichiers qui n'ont pas besoin d'être importés lors du déploiement.

Gérer les images de build

Chaque fois que vous déployez une nouvelle version, une image de conteneur est créée à l'aide du service Cloud Build. Cette image de conteneur est créée dans la région de l'application, puis s'exécute dans l'environnement standard App Engine.

Les images de conteneur créées sont stockées dans le dossier app-engine-tmp/app de Container Registry. Vous pouvez les télécharger pour les conserver ou les utiliser ailleurs. Une fois le déploiement terminé, App Engine n'a plus besoin des images de conteneur. Sachez qu'elles ne sont pas automatiquement supprimées. Par conséquent, pour éviter d'atteindre votre quota de stockage, vous pouvez supprimer en toute sécurité les images dont vous n'avez pas besoin. Pour en savoir plus sur la gestion des images dans Container Registry, consultez la documentation de Container Registry.

Afficher votre application

Après avoir déployé votre application dans App Engine, vous pouvez exécuter la commande suivante pour lancer votre navigateur et l'afficher à l'adresse https://PROJECT_ID.REGION_ID.r.appspot.com :

gcloud app browse

Tester sur App Engine avant d'autoriser le trafic

Avant de configurer une nouvelle version pour recevoir du trafic, vous pouvez la tester sur App Engine. Par exemple, pour tester une nouvelle version de votre service default :

Déployez votre nouvelle version, mais empêchez que le trafic ne soit automatiquement acheminé vers la nouvelle version :
```
gcloud app deploy --no-promote
```
Affichez la nouvelle version en accédant à l'URL suivante :

https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Remarque : Vous pouvez trouver l'ID de version dans la console Google Cloud, ou en spécifier un lors du déploiement avec --version flag. Google Cloud CLI affiche également l'ID de version lors du déploiement.

Vous pouvez maintenant tester la nouvelle version dans l'environnement d'exécution App Engine. Vous pouvez déboguer l'application en consultant ses journaux. Pour en savoir plus, consultez la page Écrire des journaux d'application.

App Engine achemine les requêtes envoyées à https://PROJECT_ID.REGION_ID.r.appspot.com vers la version précédemment configurée pour recevoir le trafic.
Lorsque vous souhaitez envoyer du trafic vers la nouvelle version, utilisez la console Google Cloud pour migrer le trafic :

Gérer les versions

Sélectionnez la version que vous venez de déployer et cliquez sur Migrer le trafic.

Vous pouvez utiliser le même processus pour tester de nouvelles versions d'autres services en remplaçant default dans l'URL par le nom de votre service :

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Pour en savoir plus sur le ciblage de services et de versions spécifiques, consultez la page Mode de routage des requêtes.

Utiliser des variables d'environnement de compilation

Vous pouvez également définir des variables d'environnement de compilation pour les environnements d'exécution compatibles avec les packs de création Google Cloud.

Les variables d'environnement de compilation sont des paires clé/valeur déployées conjointement à une application. Elles vous permettent de transmettre des informations de configuration aux packs de création. Par exemple, vous pouvez personnaliser les options du compilateur. Vous pouvez ajouter ou supprimer ces variables d'environnement de compilation en configurant le champ build_env_variables dans votre fichier app.yaml.

Remarque : Les clés doivent commencer par une lettre ASCII en majuscule et ne contenir que des lettres ASCII en majuscules, des chiffres et des traits de soulignement. Vous devez éviter de créer des clés de variable comportant un préfixe GOOGLE_*. Afficher toutes les variables d'environnement des buildpacks compatibles

Utiliser le serveur de développement local

Vous pouvez utiliser dev_appserver pour exécuter vos applications localement, afin de simuler l'exécution de votre application en production dans App Engine. Ce serveur de développement simule partiellement l'environnement dans lequel votre application s'exécute, ce qui vous permet de tester les applications écrites pour n'importe quel environnement d'exécution standard.

Go 1.11 ayant atteint la fin de la période de compatibilité, vous ne pouvez plus utiliser la dernière version de dev_appserver.py pour exécuter localement vos applications. Pour continuer à utiliser dev_appserver.py, suivez les instructions de la page Utiliser le serveur de développement local.

Exécuter le serveur de développement local

Après avoir créé le fichier de configuration app.yaml pour votre application, vous pouvez démarrer le serveur de développement local avec la commande dev_appserver.py pour l'exécuter localement.

Pour obtenir les identifiants d'accès pour votre compte utilisateur, exécutez la commande suivante :
```
gcloud auth login
```
Autorisez votre application locale à utiliser temporairement vos identifiants utilisateur pour accéder à l'API :
```
gcloud auth application-default login
```
Pour démarrer le serveur de développement local, procédez comme suit :

Dans le répertoire contenant votre fichier de configuration app.yaml, exécutez la commande dev_appserver.py et spécifiez votre ID de projet et le chemin d'accès à votre fichier app.yaml :
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
```
Pour modifier le port, incluez l'option --port :
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Remplacez DEVAPPSERVER_ROOT par le chemin d'accès au dossier dans lequel vous extrayez la version archivée de devapp_server.py. Pour en savoir plus sur le téléchargement et l'utilisation de la version archivée de dev_appserver.py, consultez la page Utiliser le serveur de développement local.

Pour en savoir plus sur les options de la commande dev_appserver.py, consultez la page Options du serveur de développement local.
Lorsque le serveur de développement local démarre, il configure un environnement de développement qui préinstalle les dépendances identifiées dans votre fichier requirements.txt.
Le serveur de développement local est désormais en cours d'exécution et à l'écoute des requêtes. Saisissez l'adresse http://localhost:8080/ dans votre navigateur Web pour observer l'application en action.

Si vous avez spécifié un port personnalisé avec l'option --port, n'oubliez pas d'ouvrir votre navigateur pour ce port.
Pour arrêter le serveur local à partir de la ligne de commande, appuyez sur Ctrl-C sur votre clavier.

Détecter l'environnement d'exécution de l'application

Pour déterminer si votre code est en cours d'exécution en production ou sur le serveur de développement local, vous pouvez examiner la variable d'environnement GAE_ENV :

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Utiliser le serveur de développement local avec les services Google Cloud

Vous pouvez intégrer l'outil dev_appserver avec d'autres composants Google Cloud.

Bibliothèques clientes Cloud

De nombreuses bibliothèques clientes Cloud dépendent de la présence de la variable d'environnement GOOGLE_CLOUD_PROJECT, qui doit être votre ID de projet Google Cloud. Vous pouvez trouver sa valeur en exécutant la commande gcloud config list project ou en consultant la page de votre projet dans la console Google Cloud.

Pour vous assurer que cette variable d'environnement est définie correctement lors du développement local, initialisez dev_appserver à l'aide du paramètre --application=PROJECT_ID, comme indiqué dans l'exemple précédent.

Émulateurs Cloud

Vous pouvez tester votre application avec des émulateurs pour Cloud Datastore, Cloud Bigtable et Cloud Pub/Sub.

Actualiser automatiquement les modifications apportées aux fichiers `requirements.txt` et `app.yaml`

Le serveur de développement local installe automatiquement les dépendances identifiées dans votre fichier requirements.txt. L'outil dev_appserver vous permet également de tester les fonctionnalités configurées via le fichier app.yaml. Par exemple, vous pouvez tester la capacité de votre application à diffuser des fichiers statiques. Si vous apportez des modifications aux fichiers requirements.txt et app.yaml lorsque l'outil dev_appserver est en cours d'exécution, votre application redémarre automatiquement afin de refléter ces modifications. Cela peut nécessiter un délai d'exécution ponctuel, en raison du téléchargement et de l'installation des dépendances.

Gestion des instances et routage dans le serveur de développement

Découvrir les adresses d'instance

Le serveur de développement local crée toutes les instances de scaling manuel au démarrage. Les instances des services de scaling automatique et de base sont gérées de manière dynamique. Le serveur attribue un port à chaque service, et les clients peuvent compter sur le serveur pour équilibrer la charge et sélectionner une instance automatiquement. Les attributions de port pour l'adressage de chaque service s'affichent dans le flux de messages du journal du serveur.

Voici les ports attribués à une application qui définit trois services :

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

Lorsque vous utilisez l'adresse d'un service, par exemple http://localhost:8082/, le serveur crée ou sélectionne une instance du service et lui envoie la requête.

Le serveur attribue des ports uniques à chaque instance d'un service. Vous pouvez utiliser le serveur d'administration pour connaître ces ports. Ce dernier dispose d'un port unique qui s'affiche dans le journal des messages :

INFO Starting admin server at: http://localhost:8000

Cette adresse vous permet d'accéder à la console du serveur d'administration. Cliquez sur Instances pour afficher l'état dynamique des instances de votre application.

Une entrée distincte s'affiche pour chaque instance manuelle et de base. Les numéros d'instance sont des liens renvoyant à des adresses de port uniques pour chaque instance. Cliquez sur le lien pour envoyer une requête directement à cette instance.

Fichiers de distribution

Si votre application inclut un fichier dispatch.yaml, le flux de messages du journal inclut un port de coordinateur :

INFO Starting dispatcher running at: http://localhost:8080

Les requêtes adressées à ce port sont acheminées conformément aux règles du fichier de distribution. Le serveur n'accepte pas les règles du fichier dispatch.yaml qui incluent des noms d'hôte (par exemple, url: "customer1.myapp.com/*"). Les règles comportant des formats de chemins relatifs (url: "*/fun") sont acceptées. Vous pouvez donc utiliser des URL telles que http://localhost/fun/mobile pour atteindre des instances. Le serveur signale une erreur dans le flux du journal si vous tentez de démarrer une application avec un fichier dispatch.yaml contenant des règles basées sur l'hôte.