À propos des environnements d'exécution

Par défaut, aucun environnement d'exécution n'est spécifié pour les services Cloud Run, ce qui signifie que Cloud Run sélectionne l'environnement d'exécution en fonction des fonctionnalités utilisées. Par conséquent, sauf si vous spécifiez un environnement d'exécution pour votre service, Cloud Run peut sélectionner l'environnement de première ou de deuxième génération.

Notez que les jobs Cloud Run n'utilisent que l'environnement d'exécution de deuxième génération, et que celui-ci ne peut pas être modifié pour les différents jobs.

L'environnement d'exécution de première génération propose des temps de démarrage à froid réduits, et l'émulation de la quasi-totalité des appels émis par le système d'exploitation. À l'origine, il s'agissait du seul environnement d'exécution disponible pour les services de Cloud Run.

L'environnement d'exécution de deuxième génération offre une compatibilité Linux complète plutôt qu'une émulation d'appel système. Cet environnement d'exécution fournit les éléments suivants :

  • Performances du processeur plus rapides
  • Performances réseau plus rapides, en particulier en cas de perte de paquets
  • Compatibilité complète avec Linux, y compris les appels système, les espaces de noms et les groupes de contrôle
  • Système de fichiers réseau compatible

Même si l'environnement d'exécution de deuxième génération fonctionne généralement plus rapidement en cas de charge soutenue, il présente, pour la plupart des services, des temps de démarrage à froid supérieurs à ceux de l'environnement de première génération.

Vous pouvez sélectionner l'environnement d'exécution de votre service Cloud Run lorsque vous déployez un nouveau service ou une nouvelle révision de votre service. Si vous ne spécifiez pas d'environnement d'exécution, la première génération est utilisée par défaut.

Choisir un environnement d'exécution

Vous devez utiliser la première génération si l'une des conditions suivantes s'applique :

  • Votre service Cloud Run présente un trafic intensif et doit évoluer rapidement vers de nombreuses instances, ou votre service est sensible aux temps de démarrage à froid.
  • Votre service Cloud Run génère peu de trafic, ce qui entraîne un scaling horizontal fréquent à partir de zéro.
  • Vous souhaitez utiliser moins de 512 Mio de mémoire. L'environnement d'exécution de deuxième génération nécessite au moins 512 Mio de mémoire.

Vous devez utiliser la deuxième génération si l'une des conditions suivantes s'applique à votre service Cloud Run :

  • Votre service doit utiliser un système de fichiers réseau qui n'est compatible qu'avec la deuxième génération.
  • Votre service dispose d'un trafic relativement stable et tolère les démarrages à froid légèrement plus lents.
  • Votre service dispose de charges de travail intensives.
  • Votre service peut bénéficier de performances réseau plus rapides.
  • Votre service doit utiliser des logiciels présentant des problèmes avec la première génération en raison d'appels système non mis en œuvre.
  • Votre service nécessite une fonctionnalité cgroup Linux.
  • Votre service utilise une infrastructure tierce pour sécuriser les conteneurs.

Bonnes pratiques lors de l'utilisation de l'environnement d'exécution de deuxième génération

Nous vous recommandons d'installer un gestionnaire SIGTERM, en particulier si vous utilisez le modèle de facturation à la demande pour le processeur.

La gestion des SIGGIS permet à votre conteneur d'effectuer les tâches de nettoyage nécessaires, telles que le vidage des journaux avant de quitter. Si votre conteneur n'intercepte pas SIGTERM, il aura toujours 10 secondes pour effectuer ces tâches. Ces 10 secondes sont facturables.

Vérifier si votre conteneur gère le signal SIGTERM

Pour déterminer si votre conteneur dispose d'un gestionnaire SIGTERM, procédez comme suit :

  1. Démarrez Cloud Shell. Vous pouvez trouver Bouton d'activation de Cloud Run Activer Cloud Shell dans l'en-tête de la page de documentation sur laquelle vous vous trouvez. Vous devrez peut-être l'autoriser et attendre qu'il soit provisionné. Vous pouvez également démarrer une session autonome.

  2. Exécuter le conteneur localement dans Cloud Shell :

    docker run IMAGE_URL

    Remplacez IMAGE_URL par une référence à l'image de conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest. Si vous utilisez Artifact Registry, le dépôt REPO_NAME doit déjà être créé. L'URL se présente sous la forme suivante : LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

  3. Ouvrez un autre onglet dans Cloud Shell et obtenez la liste des conteneurs s'exécutant dans la session Cloud Shell actuelle :

    docker container ls

    Vous devez localiser l'ID de conteneur renvoyé par la commande.

  4. Utiliser l'ID du conteneur pour envoyer un signal SIGTERM

    docker kill -s SIGTERM CONTAINER_ID

  5. Revenez à l'onglet où vous avez appelé docker run pour voir si le conteneur s'est fermé (arrêté). Si le signal SIGTERM a entraîné la fermeture de votre conteneur, celui-ci gère le signal SIGTERM.

Gérer le signal SIGTERM

Si votre conteneur ne gère pas le signal SIGTERM, le moyen le plus simple d'ajouter un gestionnaire SIGTERM consiste à encapsuler le service avec tini. Ainsi, votre service s'exécute en tant que sous-processus de tini, qui prend le rôle de processus d'initialisation de conteneur. Reportez-vous aux instructions Docker pour obtenir des instructions.

Vous pouvez également modifier votre application pour qu'elle gère directement SIGTERM.

Étapes suivantes