Cette page répertorie les exigences et les comportements clés des conteneurs dans Cloud Run. Le cas échéant, la page indique également les différences entre les services Cloud Run, les jobs Cloud Run et les pools de nœuds de calcul Cloud Run.
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 conteneur 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 d'exécution Cloud Run publiées par les buildpacks de Google Cloud pour recevoir des mises à jour automatiques de sécurité et de maintenance. Pour connaître les environnements d'exécution compatibles, consultez le calendrier de compatibilité des environnements d'exécution.
Exigences relatives aux conteneurs
Lorsque vous déployez des conteneurs sur Cloud Run, les exigences suivantes doivent être respectées :
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.
En particulier, 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é du réseau VPC
Les services et les jobs Cloud Run sont compatibles avec la sortie VPCdirecte. Cela signifie qu'ils peuvent envoyer du trafic vers des ressources privées au sein de votre réseau VPC configuré, telles que des bases de données ou des services internes. Les services et les jobs Cloud Run ne sont pas compatibles avec l'entrée VPC directe.
Les pools de nœuds de calcul Cloud Run sont compatibles avec le trafic sortant et le trafic entrant VPC direct. Lorsque vous configurez le VPC direct pour le déploiement de votre pool de nœuds de calcul Cloud Run, chaque instance de nœud de calcul reçoit une adresse IP privée sur le réseau et le sous-réseau configurés. Seules les ressources de votre réseau VPC peuvent se connecter au point de terminaison d'adresse IP privée du pool de nœuds de calcul. Pour en savoir plus sur l'obtention des adresses IP privées de l'instance de votre pool de nœuds de calcul, consultez Récupérer les adresses IP privées à l'aide du serveur de métadonnées (MDS).
Pour les pools de nœuds de calcul Cloud Run avec entrée VPC directe, tels que les connexions à une base de données ou tout autre protocole TCP personnalisé, le conteneur doit écouter les connexions TCP sur le port exposé dans votre image de conteneur via le fichier 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 livrer de requêtes, le conteneur ne doit pas écouter sur un port ni démarrer de serveur Web.
Chiffrement de la couche de transport (TLS)
Le conteneur ne doit pas implémenter directement de sécurité de la couche 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, plus espace et tabulation horizontale, 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 est arrêtée.
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.