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
Ce guide présente Cloud Run pour les utilisateurs qui connaissent déjà App Engine. Il couvre les principales similitudes et différences entre les plates-formes sans serveur pour vous aider à préparer la migration depuis l'environnement standard ou flexible App Engine.
Présentation
Cloud Run est la dernière évolution de Google Cloud sans serveur, développé depuis plus de 10 ans sur l'expérience d'exécution d'App Engine. Cloud Run s'exécute en grande partie sur la même infrastructure que l'environnement standard App Engine. Il existe donc de nombreuses similitudes entre ces deux plates-formes.
Cloud Run est conçu pour améliorer l'expérience App Engine, en intégrant bon nombre des meilleures fonctionnalités de l'environnement standard et de l'environnement flexible App Engine. Les services Cloud Run peuvent gérer les mêmes charges de travail que les services App Engine, mais Cloud Run offre beaucoup plus de flexibilité aux clients dans la mise en œuvre de ces services. Cette flexibilité, ainsi que l'amélioration des intégrations à Google Cloud et à des services tiers, permet également à Cloud Run de gérer les charges de travail qui ne peuvent pas s'exécuter sur App Engine.
Résumé comparatif
Bien qu'il existe de nombreuses similitudes et différences entre App Engine et Cloud Run, cette présentation se concentre sur les domaines les plus pertinents pour les clients App Engine qui font leurs premiers pas avec Cloud Run.
| Environnement standard App Engine | Environnement flexible App Engine | Cloud Run | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Terminologie | Application | ND | |||||||||||||||||||
| Service | Service | ||||||||||||||||||||
| Version | Révision | ||||||||||||||||||||
Points de terminaison d'URL |
|||||||||||||||||||||
| URL de l'application (service default)
|
https://PROJECT_ID.REGION_ID.r.appspot.com
|
ND | |||||||||||||||||||
| URL de service |
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
https://SERVICE_IDENTIFIER.run.app
|
|||||||||||||||||||
| URL de version/révision |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
https://TAG---SERVICE_IDENTIFIER.run.app
|
|||||||||||||||||||
Scaling |
|||||||||||||||||||||
| Un scaling automatique | Oui | Oui | Oui | ||||||||||||||||||
| Scaling manuel | Oui | Oui | Bien qu'il n'existe pas de paramètre de scaling manuel spécifique, le même comportement peut être répliqué en configurant le nombre maximal d'instances égal au nombre minimal d'instances | ||||||||||||||||||
| Scaling à zéro instance | Oui | Non | Oui | ||||||||||||||||||
| Requêtes de préchauffage | Configurable | Non | Automatique | ||||||||||||||||||
| Délai d'inactivité de l'instance (après la fin de la dernière requête) | 15 minutes maximum | Dépend du paramètre d'allocation de processeurs. Utiliser l'allocation systématique du processeur pour émuler le comportement d'App Engine | |||||||||||||||||||
| Délai avant expiration de la requête |
|
60 minutes | Configurable jusqu'à 60 minutes (par défaut : 5 minutes) | ||||||||||||||||||
Déploiement |
|||||||||||||||||||||
| À partir d'une source | Oui | Oui | |||||||||||||||||||
| Image de conteneur | Non | Oui (environnements d'exécution personnalisés) | Oui | ||||||||||||||||||
Ressources de calcul |
|||||||||||||||||||||
| vCPU |
|
Jusqu'à 80 vCPU | Jusqu'à 8 vCPU | ||||||||||||||||||
| Memory | Jusqu'à 6,5 Go par vCPU | Jusqu'à 32 Go | |||||||||||||||||||
Modèle tarifaire |
|||||||||||||||||||||
| Frais par requête | Non |
Non, lorsque le processeur est toujours alloué. Oui, lorsque le processeur n'est alloué que lors du traitement des requêtes. |
|||||||||||||||||||
| Nombre minimal d'instances inactives | Même coût que les instances actives | Coûts réduits pour les instances inactives (voir Temps d'instance de conteneur facturable) | |||||||||||||||||||
| Remises sur engagement d'utilisation | Non | Oui | |||||||||||||||||||
Sécurité |
|||||||||||||||||||||
| Paramètres d'entrée | Oui | Oui | Oui | ||||||||||||||||||
| Rôle de demandeur | Non | Oui | |||||||||||||||||||
| IAP | Oui | Oui | Configurer à l'aide de Cloud Load Balancing | ||||||||||||||||||
| Pare-feu | Oui | Oui | Configurer à l'aide de Google Cloud Armor | ||||||||||||||||||
Connectivité |
|||||||||||||||||||||
| Domaines personnalisés | Oui | Oui | Configurer à l'aide de Cloud Load Balancing | ||||||||||||||||||
| Connectivité VPC (y compris VPC partagé) | Oui | ND | Oui | ||||||||||||||||||
| Paramètres de sortie VPC | Oui | ND | Oui | ||||||||||||||||||
| Équilibrage de charge multirégional | Non | Oui | |||||||||||||||||||
Accéder aux services Google Cloud |
|||||||||||||||||||||
| Cloud SQL | Oui | Oui | Oui | ||||||||||||||||||
| Bibliothèques clientes Google Cloud | Si vous utilisez des bibliothèques clientes Cloud dans App Engine, vous n'avez rien à modifier lors de la migration vers Cloud Run. Votre application bénéficiera d'une plus grande portabilité, car ces bibliothèques clientes fonctionnent partout. | ||||||||||||||||||||
| Anciens services groupés App Engine | Oui (Java, Python, Go, PHP uniquement) | Non | Non | ||||||||||||||||||
Modèle de ressource
Le modèle de ressource Cloud Run est très semblable à App Engine, mais il existe quelques différences clés :
- Cloud Run ne dispose pas de ressource Application de premier niveau ni du service
defaultcorrespondant. - Les services Cloud Run du même projet peuvent être déployés dans différentes régions. Dans App Engine, tous les services du projet se trouvent dans la même région.
- Cloud Run utilise le terme Révision au lieu de Version pour s'aligner sur le modèle de ressource Knative.
- Les noms des révisions Cloud Run utilisent le format
SERVICE_NAME-REVISION_SUFFIX, oùREVISION_SUFFIXest généré automatiquement ou défini à l'aide de l'option de déploiement--revision-suffix=REVISION_SUFFIX. - Les révisions Cloud Run sont immuables, ce qui signifie que vous ne pouvez pas réutiliser les noms comme vous le feriez avec les versions d'App Engine (à l'aide de l'option de déploiement
--version=VERSION_ID). - Les URL de service Cloud Run sont basées sur un identifiant de service généré automatiquement lors du premier déploiement du service. Les identifiants de service utilisent le format suivant :
SERVICE_NAME-<auto-generated identifier>. L'identifiant de service est unique et ne change pas pendant la durée de vie du service. - Dans Cloud Run, seules les URL de service (
SERVICE_IDENTIFIER.run.app) sont exposées par défaut. Pour traiter une révision spécifique, vous devez configurer un tag de trafic. Dans App Engine, les URL de service et de version sont exposées automatiquement.
Déploiement et configuration
Dans App Engine, la plupart des configurations sont effectuées dans le fichier app.yaml inclus dans chaque déploiement. Cette simplicité a un coût : si certains paramètres peuvent être mis à jour à l'aide de l'API Admin, la plupart des modifications nécessitent de redéployer le service.
Bien que Cloud Run dispose du fichier de configuration service.yaml, il n'est pas utilisé de la même manière que le fichier app.yaml. Le fichier service.yaml de Cloud Run ne peut pas être utilisé lors du déploiement à partir de la source, car l'un des éléments requis est le chemin d'accès à l'image de conteneur finale. En outre, service.yaml est conforme à la spécification Knative et peut être difficile à lire pour les utilisateurs qui ne connaissent pas les fichiers de configuration de type Kubernetes. Pour en savoir plus sur l'utilisation de service.yaml pour gérer la configuration, consultez la documentation Cloud Run.
Pour les clients App Engine qui font leurs premiers pas avec Cloud Run, l'utilisation des options de déploiement de gcloud CLI s'aligne beaucoup plus sur la gestion de la configuration lors du déploiement d'App Engine.
Pour définir la configuration lors du déploiement d'un nouveau code dans Cloud Run, utilisez les options gcloud run deploy :
gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY
Bien qu'il ne soit pas nécessaire d'utiliser les options de configuration avec chaque déploiement (voir Gérer les configurations), vous pouvez le faire pour simplifier la gestion de la configuration.
Dans Cloud Run, vous pouvez également mettre à jour la configuration sans redéployer le code source à l'aide de gcloud run services update :
gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY
Comme les révisions Cloud Run sont immuables, cette commande crée une nouvelle révision avec la configuration mise à jour, mais utilise la même image de conteneur que la révision existante.
Gérer les configurations
Pour les déploiements App Engine, tous les paramètres doivent être fournis pour chaque déploiement. Si des paramètres ne sont pas fournis, des valeurs par défaut leur sont attribuées. Prenons l'exemple d'App Engine service-a, avec des versions utilisant les fichiers app.yaml indiqués ci-dessous :
| App Engine service-a version1 | App Engine service-a version2 |
|---|---|
| app.yaml | |
runtime: python39 service: service-a instance_class: F4 |
runtime: python39 service: service-a |
| Configuration appliquée | |
runtime: python39 service: service-a instance_class: F4 default values: |
runtime: python39 service: service-a default values: |
version1 est configuré avec instance_class: F4, tandis que version2, qui n'a fourni aucune valeur pour instance_class, est configuré avec la valeur par défaut instance_class: F1.
Pour Cloud Run, tous les paramètres de configuration fournis sont appliqués, mais ceux qui ne sont pas fournis conservent leurs valeurs existantes. Il vous suffit de fournir les valeurs des paramètres que vous souhaitez modifier. Exemple :
| Cloud Run service-a revision1 | Cloud Run service-a revision2 |
|---|---|
| Commande de déploiement | |
gcloud run deploy service-a \ --cpu=4 |
gcloud run deploy service-a |
| Configuration appliquée | |
service: service-a vCPUs: 4 default values: |
service: service-a vCPUs: 4 default values: |
Dans App Engine, le déploiement sans paramètres de configuration crée une version utilisant tous les paramètres par défaut. Dans Cloud Run, le déploiement sans paramètre de configuration crée une révision utilisant les mêmes paramètres de configuration que la révision précédente. Pour la première révision d'un service Cloud Run sans déploiement de configuration, une révision est créée à l'aide de tous les paramètres par défaut.
Configuration par défaut
| Paramètre de configuration | Environnement standard App Engine | Environnement flexible App Engine | Cloud Run |
|---|---|---|---|
| Ressources de calcul | F1 | 1 vCPU, .6 Go | 1 vCPU, 512 Mo |
| Simultanéité maximale (requêtes) | 10 | Aucun | 80 |
| Délai avant expiration de la requête |
|
60 minutes | 5 minutes |
| Objectif d'utilisation du CPU | 60 % | 50 % | 60 % |
| Nombre maximal d'instances | Aucun | 20 | 100 |
| Nombre minimal d'instances | 0 | 2 | 0 |
Point d'entrée
Lors du déploiement à partir de la source, App Engine lit la commande entrypoint à partir de l'attribut entrypoint dans le fichier app.yaml. Si aucun point d'entrée n'est fourni, une valeur par défaut spécifique à l'environnement d'exécution est appliquée. Cloud Run utilise les buildpacks de Google Cloud lors du déploiement à partir de la source. Certains langages ne disposent pas de point d'entrée par défaut, ce qui signifie que vous devez en fournir un, sinon la compilation échouera. Par exemple, les buildpacks Python nécessitent un fichier Procfile ou la spécification de la variable d'environnement de build GOOGLE_ENTRYPOINT.
Veuillez consulter la documentation sur les buildpacks pour connaître les exigences de configuration spécifiques au langage.
Scaling
Bien que Cloud Run et l'environnement standard App Engine partagent en grande partie la même infrastructure de scaling, Cloud Run a été simplifié pour accélérer le scaling. Pour les besoins de cette simplification, les paramètres configurables sont limités aux éléments suivants :
- Simultanéité maximale
- Nombre maximal et Nombre minimal d'instances
Pour les instances Cloud Run, l'objectif d'utilisation du processeur n'est pas configurable et est fixe à 60 %. Consultez la documentation Cloud Run pour plus de détails sur l'autoscaling.
L'environnement flexible App Engine utilise l'autoscaler Compute Engine. Il présente donc des caractéristiques de scaling très différentes de celles de l'environnement standard et de Cloud Run.
Délai d'inactivité de l'instance
Dans App Engine, les instances inactives restent actives pendant 15 minutes après la fin du traitement de la dernière requête. Cloud Run vous permet de configurer ce comportement à l'aide de l'allocation de processeurs. Pour obtenir le même comportement qu'App Engine, définissez l'allocation de processeurs sur Processeur toujours alloué. Vous pouvez également utiliser l'option Processeur uniquement alloué lors du traitement des requêtes pour que les instances inactives soient arrêtées immédiatement (en l'absence de requêtes en attente).
Requêtes de préchauffage
Cloud Run préchauffe automatiquement les instances à l'aide de la commande entrypoint du conteneur. Vous n'avez donc pas besoin d'activer manuellement les requêtes de préchauffage ni de configurer un gestionnaire /_ah/warmup. Si vous souhaitez exécuter du code au démarrage d'une instance, avant que des requêtes soient traitées, vous pouvez soit:
- Configurer votre application pour écouter les requêtes
- Configurer une vérification de démarrage personnalisée
Contenu statique
Dans l'environnement standard App Engine, vous pouvez diffuser du contenu statique sans utiliser de ressources de calcul en diffusant depuis Cloud Storage ou en configurant des gestionnaires. Cloud Run ne propose pas d'option de gestionnaires pour la diffusion de contenu statique. Vous pouvez donc diffuser le contenu à partir du service Cloud Run (identique au contenu dynamique) ou depuis Cloud Storage.
Rôle de demandeur Cloud Run
Cloud Run offre également la possibilité de contrôler l'accès au service avec IAM (Identity and Access Management). Les liaisons de stratégie IAM pour un service peuvent être définies à l'aide de gcloud CLI, de la console ou de Terraform.
Pour répliquer le comportement d'App Engine, vous pouvez rendre le service public en autorisant les requêtes non authentifiées. Vous pouvez définir cela au déploiement ou en mettant à jour les liaisons de stratégie IAM sur un service existant.
Déploiement
Utilisez l'option de déploiement --allow-unauthenticated :
gcloud run deploy SERVICE_NAME ... --allow-unauthenticated
Service existant
Exécutez la commande gcloud run services add-iam-policy-binding :
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member="allUsers" \ --role="roles/run.invoker"
où SERVICE_NAME correspond au nom du service Cloud Run.
Vous pouvez également choisir de contrôler qui a accès au service en attribuant le rôle IAM Demandeur Cloud Run qui est configurable par service.
Déploiement
gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated gcloud run services add-iam-policy-binding SERVICE_NAME \ --member=MEMBER_TYPE \ --role="roles/run.invoker"
où SERVICE_NAME correspond au nom du service et MEMBER_TYPE au type de compte principal. Exemple : user:email@domain.com.
Pour obtenir la liste des valeurs acceptées pour MEMBER_TYPE, consultez la section sur les concepts de Cloud IAM.
Service existant
gcloud run services add-iam-policy-binding SERVICE_NAME \ --member=MEMBER_TYPE \ --role="roles/run.invoker"
où SERVICE_NAME correspond au nom du service et MEMBER_TYPE au type de compte principal. Exemple : user:email@domain.com.
Pour obtenir la liste des valeurs acceptées pour MEMBER_TYPE, consultez la section sur les concepts de Cloud IAM.
Variables d'environnement et métadonnées
App Engine et Cloud Run disposent de certaines variables d'environnement qui sont définies automatiquement. Le tableau ci-dessous présente les variables d'environnement App Engine, ainsi que leurs équivalents dans Cloud Run. Par rapport à App Engine, Cloud Run n'implémente que quelques variables d'environnement, mais les données disponibles à partir du serveur de métadonnées sont pour la plupart équivalentes.
Variables d'environnement par défaut
| Nom App Engine | Nom Cloud Run | Description |
|---|---|---|
GAE_SERVICE
|
K_SERVICE
|
Nom du service actuel. Dans App Engine, défini sur "default" si non spécifié. |
GAE_VERSION
|
K_REVISION
|
Libellé de la version actuelle du service. |
PORT
|
PORT
|
Port qui reçoit les requêtes HTTP. |
| ND | K_CONFIGURATION
|
Nom de la configuration Cloud Run ayant créé la révision. |
GOOGLE_CLOUD_PROJECT
|
ND | ID du projet Cloud associé à votre application. |
GAE_APPLICATION
|
ID de votre application App Engine. Cet ID est précédé du préfixe "code de région~", tel que "e~" pour les applications déployées en Europe. | |
GAE_DEPLOYMENT_ID
|
ID du déploiement actuel. | |
GAE_ENV
|
Environnement App Engine. Défini sur "standard" si dans l'environnement standard. | |
GAE_INSTANCE
|
ID de l'instance sur laquelle votre service est en cours d'exécution. | |
GAE_MEMORY_MB
|
Quantité de mémoire disponible pour le processus d'application, en Mo. | |
NODE_ENV (disponible uniquement dans l'environnement d'exécution Node.js)
|
Variable définie sur production lorsque votre service est déployé. | |
GAE_RUNTIME
|
Environnement d'exécution spécifié dans le fichier app.yaml. |
Chemins d'accès de serveur de métadonnées courants
| Chemin | Description | Exemple |
|---|---|---|
/computeMetadata/v1/project/project-id
|
ID du projet auquel appartient le service | test_project |
/computeMetadata/v1/project/numeric-project-id
|
Numéro du projet auquel appartient le service | 12345678912 |
/computeMetadata/v1/instance/id
|
Identifiant unique de l'instance de conteneur (également disponible dans les journaux). | 16a61494692b7432806a16 (chaîne de caractères alphanumériques) |
/computeMetadata/v1/instance/region** Non disponible pour l'environnement flexible App Engine |
Région de ce service, renvoie projects/PROJECT_NUMBER/regions/REGION
|
projects/12345678912/regions/us-central1 |
/computeMetadata/v1/instance/service-accounts/default/email
|
Adresse e-mail du compte de service d'exécution de ce service. | service_account@test_project.iam.gserviceaccount.com |
/computeMetadata/v1/instance/service-accounts/default/token
|
Génère un jeton d'accès OAuth2 pour le compte de service de ce service. Ce point de terminaison renverra une réponse JSON avec un attribut access_token.
|
{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" } |
Étapes suivantes
- Guide de démarrage rapide : déployer un service Web avec Cloud Run
- Mon application est-elle adaptée à Cloud Run ?
- Migrer mon domaine personnalisé App Engine vers Cloud Load Balancing
- Autres ressources :
- Migrer depuis App Engine vers Cloud Run avec Docker (Python : atelier de programmation, vidéo, Java : atelier de programmation)
- Migrer depuis App Engine vers Cloud Run avec les buildpacks (Python : atelier de programmation, vidéo, Java : atelier de programmation)