Cette page répertorie les exigences et les comportements clés des conteneurs dans Cloud Run. Elle indique également les différences entre les services Cloud Run, les jobs Cloud Run et les pools de nœuds de calcul Cloud Run, le cas échéant.
Langages et images acceptés
Votre image de conteneur peut exécuter du code écrit dans le langage de programmation de votre choix et utiliser n'importe quelle image de base, à condition de respecter les contraintes présentées sur cette page.
Les fichiers exécutables dans l'image de conteneur doivent être compilés pour Linux 64 bits. Cloud Run est spécifiquement compatible avec le format ABI de Linux x86_64.
Cloud Run accepte les images de conteneur aux formats d'image Docker Image Manifest V2, Schéma 1, Schéma 2 et OCI. Cloud Run accepte également les images de conteneurs compressées au format Zstd.
Si vous déployez une image multi-architecture, la liste de fichiers manifestes doit inclure linux/amd64.
Pour les fonctions déployées avec Cloud Run, vous pouvez utiliser l'une des images de base de l'environnement d'exécution Cloud Run publiées par les buildpacks de Google Cloud pour recevoir des mises à jour de sécurité et de maintenance automatiques. Consultez le calendrier de compatibilité des environnements d'exécution pour connaître les environnements d'exécution compatibles.
Exigences relatives aux conteneurs
Lorsque vous déployez des conteneurs sur Cloud Run, les conditions suivantes doivent être remplies :
Le conteneur déployé sur les services doit écouter les requêtes sur le bon port
Un service Cloud Run démarre des instances Cloud Run pour gérer les requêtes entrantes. Une instance Cloud Run comporte toujours un seul conteneur d'entrée qui écoute les requêtes et éventuellement un ou plusieurs conteneurs side-car. Les informations de configuration de port suivantes ne s'appliquent qu'au conteneur d'entrée, et non aux side-cars.
Le conteneur d'entrée dans une instance doit écouter les requêtes envoyées à l'adresse 0.0.0.0, sur le port auquel ces requêtes sont envoyées.
Notez que le conteneur d'entrée ne doit pas écouter sur 127.0.0.1.
Par défaut, les requêtes sont envoyées à 8080, mais vous pouvez configurer Cloud Run pour envoyer des requêtes au port de votre choix. Cloud Run injecte la variable d'environnement PORT dans le conteneur d'entrée.
Connectivité réseau VPC
Cloud Run vous permet de vous connecter à un réseau VPC à l'aide du VPC direct.
- Pour envoyer du trafic vers des ressources privées de votre réseau VPC configuré, telles que des bases de données ou des services internes, utilisez la sortie VPC directe.
- Pour recevoir du trafic provenant de ressources ou d'adresses IP privées sur le réseau ou le sous-réseau VPC configuré, utilisez l'entrée VPC directe.
Chaque ressource Cloud Run accepte les configurations de VPC direct suivantes :
- Services : sortie uniquement
- Jobs : sortie uniquement
- Pools de nœuds de calcul : sortie et entrée
- Instances : sortie et entrée
Lorsque vous utilisez le VPC direct, ces adresses IP ne sont pas statiques. Pour les instances Cloud Run, ces adresses IP ne sont pas récupérables après l'exécution de redémarrages, d'arrêts ou de mises à jour. Chaque fois que vous démarrez, arrêtez ou mettez à jour une instance, vous obtenez une nouvelle adresse IP.
Lorsque vous utilisez l'entrée VPC directe pour les pools de nœuds de calcul ou les instances Cloud Run :
Seules les ressources de votre réseau VPC peuvent se connecter au point de terminaison d'adresse IP privée de la ressource. Pour en savoir plus sur l'obtention des adresses IP privées de votre pool de nœuds de calcul ou de votre instance, consultez Récupérer les adresses IP privées à l'aide du serveur de métadonnées (MDS).
Pour les connexions telles que les connexions de base de données ou tout autre protocole TCP personnalisé, le conteneur doit écouter les connexions TCP sur le port exposé dans l'image de conteneur via le Dockerfile ou spécifié par la variable d'environnement
PORT.
Le conteneur s'exécutant dans le cadre d'une tâche doit se fermer une fois l'opération terminée
Pour les tâches Cloud Run, le conteneur doit se fermer avec le code de sortie "0" si la tâche s'est terminée correctement et avec un code de sortie différent de zéro en cas d'échec de la tâche.
Étant donné que les jobs ne doivent pas diffuser de requêtes, le conteneur ne doit pas écouter sur un port ni démarrer de serveur Web.
Chiffrement de la couche transport (TLS)
Le conteneur ne doit pas mettre en œuvre directement de sécurité de la couche de transport. TLS est interrompu par Cloud Run dans le cas de HTTPS et gRPC, puis les requêtes sont transmises par proxy via HTTP/1 ou gRPC au conteneur sans TLS.
Si vous configurez un service Cloud Run pour qu'il utilise HTTP/2 de bout en bout, votre conteneur doit gérer les requêtes au format texte clair HTTP/2 (h2c), car TLS est toujours arrêté automatiquement par Cloud Run.
Réponses (services)
Pour les services Cloud Run, votre instance doit envoyer une réponse dans le délai spécifié par le paramètre de délai avant expiration de la requête après la réception d'une requête, y compris le délai de démarrage de l'instance. Sinon, la requête est abandonnée et une erreur 504 est renvoyée.
Mise en cache des réponses et cookies
Si la réponse de votre service Cloud Run contient un en-tête Set-Cookie, Cloud Run définit l'en-tête Cache-Control sur private afin que la réponse ne soit pas mise en cache. Cela empêche les autres utilisateurs de récupérer le cookie.
Variables d'environnement
Différents ensembles de variables d'environnement sont disponibles pour les services et les tâches Cloud Run.
Variables d'environnement pour les services
Les variables d'environnement suivantes sont automatiquement ajoutées à tous les conteneurs en cours d'exécution, à l'exception de PORT. La variable PORT n'est ajoutée qu'au conteneur d'entrée :
| Nom | Description | Exemple |
|---|---|---|
PORT |
Port sur lequel le serveur HTTP doit écouter. | 8080 |
K_SERVICE |
Nom du service Cloud Run en cours d'exécution. | hello-world |
K_REVISION |
Nom de la révision Cloud Run en cours d'exécution. | hello-world.1 |
K_CONFIGURATION |
Nom de la configuration Cloud Run ayant créé la révision. | hello-world |
Variables d'environnement pour les tâches
Pour les tâches Cloud Run, les variables d'environnement suivantes sont définies :
| Nom | Description | Exemple |
|---|---|---|
CLOUD_RUN_JOB |
Nom de la tâche Cloud Run en cours d'exécution. | hello-world |
CLOUD_RUN_EXECUTION |
Nom de l'exécution Cloud Run en cours d'exécution. | hello-world-abc |
CLOUD_RUN_TASK_INDEX |
Index de cette tâche. Démarre à 0 pour la première tâche, puis incrémente de 1 pour chaque nouvelle tâche, jusqu'à atteindre le nombre maximal de tâches moins 1. Si vous définissez --parallelism sur une valeur supérieure à 1, les tâches risquent de ne pas suivre l'ordre des index. Par exemple, il est possible que la tâche 2 démarre avant la tâche 1. |
0 |
CLOUD_RUN_TASK_ATTEMPT |
Nombre de fois où une tâche a fait l'objet de nouvelles tentatives d'exécution. Démarre à 0 pour la première tentative, puis incrémente de 1 pour chaque nouvelle tentative, jusqu'à atteindre le nombre maximal de tentatives. | 0 |
CLOUD_RUN_TASK_COUNT |
Nombre de tâches définies dans le paramètre --tasks. |
1 |
Variables d'environnement pour les pools de nœuds de calcul
Cloud Run définit les variables d'environnement suivantes pour les pools de nœuds de calcul :
| Nom | Description | Exemple |
|---|---|---|
CLOUD_RUN_WORKER_POOL |
Nom du pool de nœuds de calcul Cloud Run en cours d'exécution. | hello-world |
CLOUD_RUN_REVISION |
Nom de la révision du pool de nœuds de calcul Cloud Run en cours d'exécution. | hello-world.1 |
Exigences relatives aux en-têtes de requête et de réponse (services)
Pour les services, Cloud Run limite les noms d'en-tête aux caractères ASCII imprimables, sans espace blanc, et ne peuvent pas contenir de signes deux-points. Cloud Run limite les valeurs d'en-tête aux caractères ASCII visibles, ainsi qu'aux espaces et aux tabulations horizontales, conformément à la norme IETF RFC 7230.
Accès au système de fichiers
Le système de fichiers de chaque conteneur est accessible en écriture et obéit au comportement suivant :
- Il s'agit d'un système de fichiers en mémoire. Par conséquent, les opérations d'écriture sur ce système de fichiers utilisent la mémoire de l'instance.
- Les données écrites dans le système de fichiers ne sont pas conservées lorsque l'instance s'arrête.
Vous ne pouvez pas spécifier de limite de taille pour ce système de fichiers. Vous pouvez donc potentiellement utiliser toute la mémoire allouée à votre instance en écrivant dans le système de fichiers en mémoire, ce qui entraînerait le plantage de l'instance. Vous pouvez éviter ce problème si vous utilisez un volume en mémoire dédié avec une limite de taille.
Cycle de vie de l'instance
Les caractéristiques du cycle de vie diffèrent pour les tâches et les services Cloud Run. Elles sont donc décrites individuellement dans les sous-sections suivantes.
Pour les services
Les caractéristiques suivantes s'appliquent uniquement aux services.
Scaling de service
Par défaut, un service Cloud Run est automatiquement adapté au nombre d'instances nécessaires pour gérer toutes les requêtes entrantes, tous les événements ou l'utilisation du processeur. Vous pouvez éventuellement utiliser l'autoscaling manuel si vous avez besoin de plus de contrôle sur le comportement de scaling.
Chaque instance exécute un nombre fixe de conteneurs : un conteneur d'entrée et éventuellement un ou plusieurs conteneurs side-car.
Lorsqu'une révision ne reçoit aucun trafic, elle subit un scaling vertical à hauteur du nombre minimal d'instances configurées (zéro par défaut).
Démarrage
Pour les services Cloud Run, vos instances doivent écouter les requêtes dans les quatre minutes suivant leur démarrage et tous les conteneurs de l'instance doivent être opérationnels. Pendant ce temps de démarrage, le processeur est alloué aux instances. Vous pouvez activer l'optimisation du CPU au démarrage afin d'augmenter temporairement l'allocation de CPU lors du démarrage de l'instance et ainsi de réduire la latence de démarrage.
Les requêtes seront envoyées au conteneur d'entrée dès qu'il écoute sur le port configuré.
Une requête en attente d'une instance est conservée dans une file d'attente comme suit :
Les requêtes seront mises en attente pendant une durée maximale de 3,5 fois le temps de démarrage moyen des instances de conteneur de ce service, ou de 10 secondes, selon la valeur la plus élevée.
Vous pouvez configurer une vérification de démarrage pour déterminer si le conteneur a démarré et est prêt à diffuser des requêtes.
Pour un service Cloud Run composé d'instances multiconteneurs, vous pouvez spécifier la séquence dans laquelle les conteneurs sont démarrés dans l'instance en configurant l'ordre de démarrage des conteneurs.
Traiter une requête
Pour les services Cloud Run, le processeur est toujours alloué à tous les conteneurs, y compris aux side-cars d'une instance, tant que la révision Cloud Run traite au moins une requête.
Inactif
Pour les services Cloud Run, une instance inactive est une instance qui ne traite aucune requête.
Le processeur alloué à tous les conteneurs d'une instance inactive dépend des paramètres de facturation configurés.
À moins qu'une instance ne soit désactivée en raison du paramètre de nombre minimal d'instances défini, elle ne restera pas inactive pendant plus de 15 minutes.
Arrêt
Pour les services Cloud Run, une instance inactive peut être arrêtée à tout moment, y compris les instances maintenues en veille via le paramètre "nombre minimal d'instances". Si une instance qui traite des requêtes doit être arrêtée, les requêtes en cours de traitement bénéficient d'un temps suffisant pour se terminer, et les nouvelles requêtes entrantes sont acheminées vers d'autres instances. Dans des cas exceptionnels, Cloud Run peut déclencher un arrêt et envoyer un signal SIGTERM à un conteneur qui traite toujours des requêtes.
Avant d'arrêter une instance, Cloud Run envoie un signal SIGTERM à tous les conteneurs d'une instance, indiquant le début de la période de 10 secondes avant l'arrêt réel marqué par l'envoi d'un signal SIGKILL par Cloud Run.
Au cours de cette période, l'instance se voit attribuer un ou plusieurs processeurs et est facturée.
Dans les services qui utilisent l'environnement d'exécution de première génération, si l'instance ne capture pas le signal SIGTERM, elle est immédiatement arrêtée. Dans les services qui utilisent l'environnement d'exécution de deuxième génération, nous vous recommandons d'installer un gestionnaire SIGTERM sur votre conteneur pour recevoir un avertissement lorsque Cloud Run est sur le point d'arrêter une instance.
Arrêt forcé
Si un ou plusieurs conteneurs Cloud Run dépassent la limite de mémoire totale des conteneurs, l'instance est arrêtée. Toutes les requêtes en cours de traitement sur l'instance se terminent avec une erreur HTTP 500.
Pour les tâches
Pour les tâches Cloud Run, les instances de conteneur s'exécutent jusqu'à leur fermeture, ou jusqu'à ce que le délai avant expiration de la tâche soit atteint ou jusqu'au plantage du conteneur.
Codes de sortie
Vous pouvez utiliser les codes de sortie de job pour voir si le job s'est terminé correctement ou s'il a rencontré des erreurs. Les codes de sortie sont des valeurs numériques qui correspondent à une exécution réussie ou à des types d'erreurs spécifiques.
Le tableau suivant présente les codes de sortie courants et leurs définitions :
| Exit code | Signal | Description |
|---|---|---|
| 0 | Tâche terminée. | |
| 4 | SIGILL |
La tâche a tenté d'accéder à la mémoire à une adresse incorrecte. |
| 7 | SIGBUS |
La tâche a tenté d'accéder à la mémoire en dehors des limites qui lui ont été allouées. |
| 9 | SIGKILL |
La tâche est arrêtée de force, soit par une action de l'utilisateur, soit par une intervention manuelle. |
| 11 | SIGSEGV |
La tâche a tenté d'accéder à une mémoire non autorisée. |
| 15 | SIGTERM |
Lorsqu'une tâche dépasse le délai avant expiration configuré ou si elle est annulée, elle reçoit un signal SIGTERM. Le serveur d'applications envoie le signal SIGTERM pour que l'instance de conteneur s'arrête. Si l'instance ne s'arrête pas d'elle-même dans les quelques secondes qui suivent la réception de SIGTERM, Cloud Run envoie un signal SIGKILL pour un arrêt forcé. Si l'instance se ferme correctement avec SIGTERM, elle peut renvoyer un code d'erreur différent. Sinon, elle renvoie SIGTERM. |
Arrêt forcé
Une instance de conteneur Cloud Run dépassant la limite de mémoire autorisée est arrêtée. Toutes les requêtes en cours de traitement sur l'instance de conteneur se terminent avec une erreur HTTP 500.
Si une tâche dépasse le délai avant expiration de la tâche, Cloud Run envoie un signal SIGTERM indiquant le début d'une période de 10 secondes avant l'arrêt réel, moment où Cloud Run envoie un signal SIGKILL provoquant l'arrêt de l'instance de conteneur. Pour en savoir plus et obtenir des recommandations sur la gestion de ce problème, consultez Arrêt.
Au cours de cette période, les instances de conteneur sont affectées à des processeurs pour tout leur cycle de vie et sont facturées.
Pour les pools de nœuds de calcul
Les caractéristiques suivantes ne s'appliquent qu'aux pools de nœuds de calcul.
Scaling
Les pools de nœuds de calcul ne sont pas automatiquement mis à l'échelle. Procédez au scaling manuel du nombre d'instances dont votre pool de nœuds de calcul Cloud Run a besoin pour gérer sa charge de travail. Par défaut, Cloud Run définit le nombre d'instances sur 1. Vous pouvez augmenter ou diminuer ce nombre, ou désactiver le scaling en le définissant sur 0. Pour démarrer et rester active, votre charge de travail doit comporter au moins une instance. Si vous définissez le nombre minimal d'instances sur 0, l'instance de nœud de calcul ne démarrera pas, même si le déploiement réussit.
Démarrage
Les instances de pools de nœuds de calcul Cloud Run démarrent le conteneur avec le point d'entrée que vous spécifiez dans l'image de conteneur ou dans la configuration du pool de nœuds de calcul. Tous les conteneurs de l'instance doivent être opérationnels.
Par défaut, les instances de conteneur Cloud Run utilisent un processeur. Vous pouvez augmenter ou diminuer cette valeur en fonction de vos besoins.
Vous pouvez configurer une vérification de démarrage pour déterminer si le conteneur a démarré. La vérification du démarrage permet à Cloud Run d'inspecter l'état d'un conteneur dépendant pour s'assurer qu'il est opérationnel avant de démarrer le conteneur suivant. Si vous n'utilisez pas les vérifications d'état, Cloud Run démarre les conteneurs dans l'ordre spécifié, même si les conteneurs dont ils dépendent ne démarrent pas.
Allocation des ressources
Les pools de nœuds de calcul ne sont pas inactifs. Quel que soit son état, Cloud Run alloue toujours un processeur à tous les conteneurs, y compris aux side-cars d'une instance de pool de nœuds de calcul. Tant qu'elle est en cours d'exécution, une instance est considérée comme active et est facturée en conséquence.
Arrêt
Cloud Run ne réduit pas le nombre d'instances de pool de nœuds de calcul en fonction des instances inactives. Si une instance de traitement de charge de travail doit être arrêtée, Cloud Run laisse aux tâches en cours le temps de se terminer et achemine les nouvelles charges de travail vers d'autres instances. Cloud Run peut également déclencher un arrêt et envoyer un signal SIGTERM à un conteneur qui traite toujours une charge de travail.
Avant d'arrêter une instance, Cloud Run envoie un signal SIGTERM à tous les conteneurs de l'instance. Ce signal indique le début d'une période de 10 secondes avant l'arrêt réel, moment où Cloud Run envoie un signal SIGKILL.
Au cours de cette période d'arrêt, l'instance se voit attribuer un ou plusieurs processeurs et est facturée.
Nous vous recommandons d'installer un gestionnaire SIGTERM sur votre conteneur pour recevoir un avertissement lorsque Cloud Run est sur le point d'arrêter une instance.
Arrêt forcé
Si un ou plusieurs conteneurs Cloud Run dépassent la limite de mémoire totale des conteneurs, Cloud Run arrête l'instance. Toutes les requêtes en cours de traitement sur l'instance se terminent avec une erreur HTTP 500.
Ressources d'instance de conteneur
Votre conteneur s'exécute sous un contrôleur cgroup qui limite le processeur, la RAM et les autres ressources à celles configurées pour votre conteneur.
Les sections suivantes décrivent les ressources de votre instance de conteneur :
Processeur
Chaque conteneur Cloud Run d'une instance se voit attribuer par défaut le processeur virtuel qui a été configuré (1 par défaut). Il est possible de configurer les limites de processeur séparément sur chaque conteneur.
Un processeur virtuel est mis en œuvre sous la forme d'une abstraction de matériel sous-jacent pour fournir le temps CPU équivalent d'un seul hyper-thread matériel sur des plates-formes de processeur variables. Toutes les plates-formes de processeur utilisées par Cloud Run sont compatibles avec l'ensemble d'instructions AVX2. Notez que le contrat du conteneur ne contient aucune information supplémentaire sur la plate-forme de processeur.
Le conteneur peut être exécuté simultanément sur plusieurs cœurs.
Pour les services Cloud Run, l'allocation de processeur dépend de la facturation sélectionnée.
Si vous sélectionnez la facturation basée sur les instances, le processeur est alloué pendant la durée de vie de l'instance. Si vous sélectionnez la facturation basée sur les requêtes (par défaut), le processeur est alloué lorsque les instances traitent des requêtes. Pour en savoir plus, consultez Paramètres de facturation.
Si vous avez configuré un certain nombre d'instances minimales, vous devez utiliser la facturation basée sur les instances afin que le processeur soit alloué en dehors des requêtes.
Vous pouvez activer l'optimisation du CPU au démarrage afin d'augmenter temporairement l'allocation de CPU lors du démarrage de l'instance et ainsi de réduire la latence de démarrage.
Mémoire
Chaque instance Cloud Run reçoit par défaut la mémoire configurée (512 Mio par défaut). Il est possible de configurer les limites de mémoire séparément sur chaque conteneur.
Les utilisations types de la mémoire sont les suivantes :
- Code chargé dans la mémoire pour exécuter le service
- Écrire dans le système de fichiers
- Processus supplémentaires exécutés dans le conteneur, tel qu'un serveur nginx
- Systèmes de mise en cache en mémoire tels que l'OpCache PHP
- Utilisation de mémoire par requête
- Volumes en mémoire partagés
GPU
Vous pouvez configurer un conteneur dans une instance Cloud Run pour accéder à un GPU. Si le service Cloud Run est déployé avec des conteneurs side-car, un seul conteneur du déploiement peut accéder au GPU. Pour connaître les exigences et les détails, consultez Configurer un GPU.
Bibliothèques NVIDIA
Par défaut, toutes les bibliothèques de pilotes de GPU NVIDIA RTX PRO 6000 Blackwell et de GPU NVIDIA L4 sont installées sous /usr/local/nvidia/lib64. Cloud Run ajoute automatiquement ce chemin d'accès à la variable d'environnement LD_LIBRARY_PATH (c'est-à-dire ${LD_LIBRARY_PATH}:/usr/local/nvidia/lib64) du conteneur avec le GPU. Cela permet à l'éditeur de lien dynamique de trouver les bibliothèques de pilotes NVIDIA. L'éditeur de liens recherche et résout les chemins d'accès dans l'ordre que vous indiquez dans la variable d'environnement LD_LIBRARY_PATH. Toutes les valeurs que vous spécifiez dans cette variable prévalent sur le chemin d'accès par défaut des bibliothèques de pilotes Cloud Run, /usr/local/nvidia/lib64.
Si vous souhaitez utiliser une version de CUDA supérieure à 13.0, la méthode la plus simple consiste à dépendre d'une image de base NVIDIA plus récente avec les packages de compatibilité ascendante déjà installés. Une autre option consiste à installer manuellement les packages de compatibilité ascendante NVIDIA et à les ajouter à LD_LIBRARY_PATH. Consultez la matrice de compatibilité de NVIDIA pour déterminer quelles versions de CUDA sont compatibles de manière ascendante avec la version du pilote NVIDIA fournie.
Simultanéité (services)
Pour les services Cloud Run, chaque instance Cloud Run est définie par défaut sur simultanéité multiple, où le conteneur d'entrée peut recevoir plusieurs requêtes en même temps. Vous pouvez modifier ce paramètre en définissant la simultanéité.
Restrictions de sécurité des conteneurs
Les restrictions suivantes s'appliquent aux conteneurs exécutés dans Cloud Run. Elles s'appliquent quel que soit l'utilisateur Linux spécifié par l'image de conteneur pour l'exécution.
Privilèges réduits
Dans Cloud Run, vos conteneurs ne disposent pas des fonctionnalités racine de la limite de sécurité de l'instance. Les conteneurs ne peuvent pas effectuer d'actions réservées à l'hôte, telles que les suivantes :
- Ajouter ou supprimer des fonctionnalités du noyau Linux
- Utiliser des fonctionnalités de kernel spécifiques
- Manipuler des appareils
- Accéder à certaines ressources matérielles
L'élévation des privilèges est également désactivée dans vos conteneurs. L'utilisation des binaires sudo et setuid n'est pas compatible avec Cloud Run.
Vos conteneurs n'auront pas d'accès en écriture à la plupart des fichiers et répertoires de /dev, /proc et /sys.
Il n'existe pas d'équivalent Cloud Run au mode --privileged de Docker.
Isolement du conteneur
Cloud Run exécute vos conteneurs sous l'utilisateur, le réseau, le PID et d'autres espaces de noms Linux, en les isolant les uns des autres et de l'instance elle-même. Cela limite certaines fonctionnalités réseau et empêche vos conteneurs racine de s'exécuter en tant que "true root".
Limitation des installations de systèmes de fichiers depuis l'intérieur des conteneurs
La méthode acceptée pour installer des systèmes de fichiers dans Cloud Run consiste à utiliser la fonctionnalité d'installation de volumes entièrement gérée dans la configuration de votre conteneur Cloud Run.
Les autres mécanismes d'installation à partir de conteneurs utilisateur ne sont pas compatibles et ne fonctionneront pas. Les mécanismes non compatibles incluent, sans s'y limiter, les éléments suivants :
- Exécuter un processus d'installation dans le conteneur pour installer l'un des éléments suivants : NFS, Filestore, SMB/CIFS ou tout autre système de fichiers réseau.
- Appeler des appels système qui effectueraient des actions équivalentes.
De plus, Cloud Run n'est pas compatible avec les installations de volumes imbriqués qui installent un volume dans un autre volume.
Aucune modification de l'heure système
La modification de l'heure système à l'aide des appels système adjtimex et adjtime n'est pas possible, pas plus que l'utilisation d'outils permettant à votre conteneur de le faire.
Restrictions liées aux processus et aux appels système
Des profils de sécurité de base, semblables aux profils de sécurité seccomp pour Docker, sont appliqués à chacun de vos conteneurs.
L'utilisation d'eBPF et d'autres fonctionnalités de sécurité au niveau du noyau qui ne sont pas protégées ou limitées par les espaces de noms Linux est désactivée et n'est pas compatible avec l'utilisation dans les conteneurs.
L'utilisation d'autres appels système ou l'accès aux fichiers système nécessitant des droits d'accès racine sur l'instance Cloud Run peut également être restreinte pour cette raison.
Bac à sable de conteneur
Si vous utilisez l'environnement d'exécution de première génération, les conteneurs Cloud Run sont exécutés dans le bac à sable d'exécution gVisor. Comme indiqué dans la documentation de référence sur la compatibilité des appels système gVisor, certains appels système peuvent ne pas être compatibles avec ce bac à sable de conteneur.
Si vous utilisez l'environnement d'exécution de deuxième génération, vous disposez d'une compatibilité Linux complète.
Les tâches Cloud Run utilisent toujours l'environnement d'exécution de deuxième génération.
Dans l'environnement d'exécution de deuxième génération, /sys/class/dmi/id/product_name est défini sur Google Compute Engine.
L'environnement d'exécution de deuxième génération exécute le code de votre service dans un espace de noms de processus distinct. Il commence donc par le processus d'initialisation du conteneur présentant une sémantique de processus spéciale. Dans l'environnement d'exécution de première génération, le code de votre service ne s'exécute pas en tant que processus d'initialisation du conteneur.
Limites relatives aux descripteurs de fichiers
Les environnements Cloud Run de première et deuxième génération limitent à 25 000 le nombre de descripteurs de fichier qu'un processus peut ouvrir. Cela s'applique au conteneur et à tout processus enfant qu'il crée (forks). Il s'agit d'une limite stricte. Si vous dépassez la limite, votre instance risque de manquer de descripteurs de fichiers/sockets.
Limites dans l'environnement de deuxième génération
À l'exception des limites de descripteurs de fichiers décrites précédemment, les limites de l'environnement de deuxième génération sont des limites Linux standards.
Par exemple, les limites du nombre de descripteurs de fichiers pouvant être ouverts (comme indiqué dans /proc/sys/fs/file-max) utilisent la valeur par défaut d'environ 10% de la mémoire. Pour en savoir plus, consultez file-max et file-nr dans la documentation du noyau.
De même, max_map_count (tel que capturé dans /proc/sys/vm/max_map_count), qui définit le nombre de zones de mémoire qu'un processus peut avoir, utilise la valeur par défaut de 65535. Pour en savoir plus, consultez max-map-count dans la documentation du kernel.
Conteneurs privilégiés et binaires setuid
Cloud Run n'est pas compatible avec les conteneurs privilégiés. Par conséquent, Cloud Run n'est pas compatible avec les binaires qui utilisent des options setuid pour les utilisateurs non racine, tels que gcsfuse ou sudo, et peut échouer en raison d'autorisations insuffisantes.
Une alternative consiste à exécuter ces binaires en tant qu'utilisateur racine, puis à utiliser la commande su pour basculer vers un autre utilisateur au moment de l'exécution.
Par exemple, dans votre Dockerfile, supprimez l'instruction USER et, dans votre script de point d'entrée, utilisez la séquence suivante :
gcsfuse ... # Run gcsfuse as root
su myuser -c "/yourapp.sh" # Switch to 'myuser' and run 'yourapp.sh'
Utilisateur exécutant
Si le nom d'utilisateur n'existe pas, Cloud Run exécute le conteneur en tant qu'utilisateur racine (uid=0).
Communication entre les conteneurs d'une même instance
Cloud Run ajoute une entrée au fichier /etc/hosts dans chaque conteneur. Cette entrée mappe les noms de service à l'adresse IP de l'hôte local (127.0.0.1). Cela permet aux conteneurs de communiquer entre eux à l'aide de leur nom de conteneur.
Serveur de métadonnées d'instance
Les instances Cloud Run exposent un serveur de métadonnées que vous pouvez utiliser pour récupérer des informations sur vos conteneurs, telles que l'ID de projet, la région, l'ID d'instance ou les comptes de service. Vous pouvez également utiliser le serveur de métadonnées pour générer des jetons pour l'identité du service.
Pour accéder aux données du serveur de métadonnées, envoyez des requêtes HTTP au point de terminaison http://metadata.google.internal/ avec l'en-tête Metadata-Flavor: Google : aucune bibliothèque cliente n'est requise. Pour en savoir plus, consultez la section Obtenir des métadonnées.
Le tableau suivant répertorie certaines des informations sur le serveur de métadonnées disponibles :
| Chemin | Description |
|---|---|
/computeMetadata/v1/project/project-id |
ID du projet auquel appartient la ressource Cloud Run. |
/computeMetadata/v1/project/numeric-project-id |
Numéro du projet auquel appartient la ressource Cloud Run. |
/computeMetadata/v1/instance/region |
Région de cette ressource Cloud Run, renvoie projects/PROJECT-NUMBER/regions/REGION |
/computeMetadata/v1/instance/id |
Identifiant unique de l'instance (également disponible dans les journaux). |
/computeMetadata/v1/instance/service-accounts/default/email |
Adresse e-mail de l'identité de service de cette ressource Cloud Run. |
/computeMetadata/v1/instance/service-accounts/default/token |
Génère un jeton d'accès OAuth2 pour le compte de service de cette ressource Cloud Run. L'agent de service Cloud Run est utilisé pour récupérer un jeton. Ce point de terminaison renverra une réponse JSON avec un attribut access_token. Obtenez davantage d'informations sur l'extraction et l'utilisation de ce jeton d'accès. |
/computeMetadata/v1/instance/network-interfaces/0/ip |
Adresse IPv4 d'une instance de pool de nœuds de calcul sur un réseau VPC. |
/computeMetadata/v1/instance/network-interfaces/0/ipv6 |
Adresse IPv6 d'une instance de pool de nœuds de calcul. Assurez-vous de créer votre instance dans un sous-réseau à double pile. |
/computeMetadata/v1/instance/network-interfaces/ /computeMetadata/v1/instance/network-interfaces/0/ |
Chemin d'accès au répertoire de l'interface réseau pour les pools de nœuds de calcul. |
Cloud Run ne fournit pas de détails sur la zoneGoogle Cloud dans laquelle les instances sont en cours d'exécution. Par conséquent, l'attribut de métadonnées /computeMetadata/v1/instance/zone renvoie toujours projects/PROJECT-NUMBER/zones/REGION-1.
Noms des fichiers
Les noms de fichiers que vous utilisez dans des conteneurs doivent être compatibles avec UTF-8, ou être convertis en UTF-8 en toute sécurité. Si vos noms de fichiers utilisent différents encodages, exécutez Docker Build sur une machine avec des noms de fichiers compatibles avec UTF-8 et évitez de copier des fichiers dans un conteneur contenant des noms UTF-8 incompatibles.
Le déploiement du conteneur échoue si les noms de fichiers ne sont pas compatibles avec UTF-8. Notez que le codage des caractères que vous utilisez dans un fichier n'est soumis à aucune limite.
Délais avant expiration des requêtes sortantes
Pour les services et les jobs Cloud Run, un délai avant expiration s'applique après 10 minutes d'inactivité aux requêtes provenant de votre conteneur vers un VPC. Pour les requêtes provenant de votre conteneur vers Internet, le délai avant expiration est écoulé après 20 minutes d'inactivité.
Réinitialisation des connexions sortantes
Les flux de connexion de votre conteneur vers un VPC et Internet peuvent parfois être arrêtés et remplacés lorsque l'infrastructure sous-jacente est redémarrée ou mise à jour. Si votre application réutilise des connexions à longue durée de vie, nous vous recommandons de configurer votre application de manière à rétablir les connexions afin d'éviter la réutilisation d'une connexion interrompue.