Cloud Run est une plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
Vous pouvez déployer du code écrit dans n'importe quel langage de programmation sur Cloud Run si vous pouvez créer une image de conteneur à partir de celui-ci. En réalité, la création d'images de conteneurs est facultative. Si vous utilisez Go, Node.js, Python, Java, .NET Core ou Ruby, vous pouvez choisir l'option de déploiement basé sur la source qui crée le conteneur en suivant les bonnes pratiques du langage que vous utilisez.
Google a conçu Cloud Run pour qu'il fonctionne bien avec d'autres services sur Google Cloud afin que vous puissiez développer des applications complètes.
En résumé, Cloud Run permet aux développeurs de passer leur temps à écrire leur code, et très peu de temps à utiliser, configurer et faire évoluer leur service Cloud Run. Vous n'avez pas besoin de créer de cluster ni de gérer une infrastructure pour être productif avec Cloud Run.
Services et tâches : deux méthodes pour exécuter votre code
Sur Cloud Run, votre code peut être exécuté en continu en tant que service ou en tant que tâche. Les services et les tâches s'exécutent dans le même environnement et peuvent utiliser les mêmes intégrations avec d'autres services sur Google Cloud.
- Services Cloud Run. Utilisés pour exécuter du code qui répond aux requêtes Web, aux événements ou aux fonctions.
- Tâches Cloud Run. Utilisés pour exécuter du code qui effectue un travail (un job) et se ferme une fois le travail terminé.
Services Cloud Run
Un service Cloud Run fournit l'infrastructure requise pour exécuter un point de terminaison HTTPS fiable. Vous devez vous assurer que votre code écoute sur un port TCP et gère les requêtes HTTP.
Un service standard comprend les fonctionnalités suivantes :
- Point de terminaison HTTPS unique pour chaque service
- Chaque service Cloud Run est fourni avec un point de terminaison HTTPS sur un sous-domaine unique du domaine
*.run.app
, et vous pouvez également configurer des domaines personnalisés. Cloud Run gère automatiquement le protocole TLS et inclut la compatibilité avec WebSockets, HTTP/2 (de bout en bout) et gRPC (de bout en bout). - Autoscaling rapide basé sur les requêtes
- Cloud Run est conçu pour offrir un scaling horizontal suffisamment rapide pour gérer toutes les requêtes entrantes, ou pour gérer une augmentation de l'utilisation de processeur sans lien avec les requêtes si Allocation de processeur est défini sur
always on
. Un service peut évoluer rapidement jusqu'à un millier d'instances, voire plus si vous demandez une augmentation de quota. Si la demande diminue, Cloud Run supprime les conteneurs inactifs. Si vous avez des préoccupations concernant les coûts ou la surcharge des systèmes en aval, vous pouvez limiter le nombre maximal d'instances. - Gestion du trafic intégrée
- Chaque déploiement crée une révision immuable. Vous pouvez acheminer le trafic entrant vers la dernière révision, effectuer un rollback vers une révision précédente ou répartir le trafic vers plusieurs révisions en même temps pour effectuer un déploiement progressif. Cette fonctionnalité est utile si vous souhaitez réduire le risque de déploiement d'une nouvelle révision. Vous pouvez commencer par envoyer 1 % des requêtes à une nouvelle révision, puis augmenter ce pourcentage tout en surveillant la télémétrie.
- Services privés et publics
- Un service Cloud Run peut être accessible depuis Internet. Vous pouvez restreindre l'accès de trois façons différentes :
- Spécifiez une stratégie d'accès à l'aide de Cloud IAM.
- Utilisez des paramètres d'entrée pour restreindre l'accès au réseau. Cette fonctionnalité est utile si vous souhaitez n'autoriser que le trafic interne provenant du VPC et des services internes.
- Autorisez uniquement les utilisateurs authentifiés avec Cloud Identity-Aware Proxy (IAP).
Vous pouvez mettre en place un service Cloud Run avec un réseau de diffusion de contenu (CDN) pour diffuser les éléments pouvant être mis en cache à partir d'un emplacement périphérique plus proche des clients. Firebase Hosting et Cloud CDN offrent tous deux cette fonctionnalité.
Scaling à zéro et nombre minimal d'instances
Cloud Run ajoute et supprime automatiquement des instances pour gérer l'intégralité des requêtes entrantes ou pour gérer une augmentation de l'utilisation de processeur sans lien avec les requêtes si Allocation de processeur est défini sur always on
. S'il n'y a aucune requête entrante à votre service, la dernière instance restante sera supprimée. Ce comportement est communément appelé "scaling à zéro instance".
Si aucune instance n'est active, une nouvelle instance est créée à la demande dès qu'une requête est envoyée. Cela a un impact négatif sur le temps de réponse pour ces premières requêtes, en fonction de la vitesse à laquelle votre conteneur est prêt à gérer les requêtes.
Pour vous assurer que votre service ne procède pas à un scaling à zéro instance, vous pouvez configurer Cloud Run de sorte qu'une quantité minimale d'instances actives soit conservée.
Tarification à l'utilisation pour les services
Le scaling à zéro instance est intéressant pour des raisons économiques, car vous payez le processeur et la mémoire alloués à une instance avec une précision de 100 ms. Si vous ne configurez pas un nombre minimal d'instances, votre service n'est pas facturé.
Vous pouvez activer deux modèles de tarification :
- Basée sur les requêtes
- Si une instance ne traite pas les requêtes, le processeur n'est pas alloué et aucuns frais ne vous sont facturés. De plus, vous payez des frais par requête.
- Basée sur les instances
- La durée de vie d'une instance vous est facturée, et le processeur est toujours alloué. Aucuns frais par requête ne sont appliqués.
Il existe une version gratuite généreuse. Pour plus d'informations, consultez la page Tarifs, et reportez-vous à la section Allocation des processeurs pour découvrir comment activer la tarification basée sur les requêtes ou sur les instances pour votre service.
Système de fichiers de conteneur temporaire
Les instances sur Cloud Run sont suppressibles. Chaque conteneur possède une superposition de système de fichiers en mémoire, accessible en écriture, qui n'est pas conservée si le conteneur s'arrête. Cloud Run décide quand arrêter d'envoyer des requêtes à une instance et de l'arrêter, par exemple lors du scaling vertical.
Pour recevoir un avertissement lorsque Cloud Run est sur le point d'arrêter une instance, votre application peut intercepter le signal SIGTERM. Cela permet à votre code de vider les tampons locaux et de conserver les données locales dans un datastore externe.
Pour conserver les fichiers de manière permanente, vous pouvez intégrer Cloud Storage ou installer un système de fichiers réseau (NFS).
Quand utiliser les services Cloud Run ?
Les services Cloud Run sont parfaitement adaptés au code qui gère les requêtes, les événements ou les fonctions. Voici quelques exemples de cas d'utilisation :
- Sites et applications Web
- Créez votre application Web à l'aide de votre pile préférée, accédez à votre base de données SQL et affichez des pages HTML dynamiques.
- API et microservices
- Vous pouvez créer une API REST, une API GraphQL ou des microservices privés qui communiquent via HTTP ou gRPC.
- Traitement de flux de données
- Les services Cloud Run peuvent recevoir des messages provenant d'abonnements push Pub/Sub et d'événements Eventarc.
- Charges de travail asynchrones
- Les fonctions Cloud Run peuvent répondre à des événements asynchrones, tels qu'un message sur un sujet Pub/Sub, une modification dans un bucket Cloud Storage ou un événement Firebase.
- Inférence de l'IA
- Les services Cloud Run avec ou sans GPU configuré peuvent héberger des charges de travail d'IA telles que les modèles d'inférence et l'entraînement de modèles.
Tâches Cloud Run
Si votre code fonctionne, puis s'arrête (un script est un bon exemple), vous pouvez utiliser une tâche Cloud Run pour exécuter votre code. Vous pouvez exécuter une tâche depuis la ligne de commande à l'aide de gcloud CLI, programmer une tâche récurrente ou l'exécuter dans le cadre d'un workflow.
Les tâches de tableau sont un moyen plus rapide d'exécuter des tâches
Une tâche peut démarrer une instance pour exécuter votre code. C'est un moyen courant d'exécuter un script ou un outil. Cependant, vous pouvez également démarrer de nombreuses instances indépendantes et identiques en parallèle, c'est-à-dire une tâche de tableau.
Les tâches de tableau sont un moyen plus rapide de traiter des tâches pouvant être divisées en plusieurs tâches indépendantes, comme indiqué ci-dessous :
Par exemple, si vous redimensionnez et recadrez 1 000 images à partir de Cloud Storage, il est plus lent de les traiter l'une après l'autre que de les traiter en parallèle avec de nombreuses instances, que Cloud Run gère avec l'autoscaling.
Quand utiliser les tâches Cloud Run ?
Les tâches Cloud Run conviennent parfaitement à l'exécution de code qui effectue une tâche (qui est terminée) et se ferme une fois la tâche terminée. Voici quelques exemples :
- Script ou outil
- Exécutez un script pour effectuer des migrations de bases de données ou d'autres tâches opérationnelles.
- Tâche de tableau
- Effectuez un traitement hautement parallèle de tous les fichiers d'un bucket Cloud Storage.
- Job planifié
- Créez et envoyez des factures à intervalles réguliers, ou enregistrez les résultats d'une requête de base de données au format XML et importez le fichier toutes les deux ou trois heures.
Intégrations Cloud Run
Cloud Run s'intègre à l'écosystème plus large de Google Cloud, qui vous permet de créer des applications complètes.
Les intégrations essentielles incluent les suivantes :
- Stockage de données
- Cloud Run s'intègre à Cloud SQL (services gérés MySQL, PostgreSQL et SQL Server), Memorystore (services gérés Redis et Memcached), Firestore, Spanner, Cloud Storage, etc. Pour obtenir la liste complète, consultez la page Stockage des données.
- Journalisation et rapports d'erreurs
- Les journaux de conteneurs sont automatiquement ingérés par Cloud Logging. Si les journaux contiennent des exceptions, Error Reporting les regroupe, puis vous avertit. Les langages suivants sont compatibles : Go, Java, Node.js, PHP, Python, Ruby et .NET.
- Identité du service
- Chaque révision Cloud Run est associée à un compte de service, et les bibliothèques clientes Google Cloud l'utilisent de manière transparente pour s'authentifier auprès des API Google Cloud.
- Livraison continue
- Si vous stockez votre code source dans GitHub, Bitbucket ou Cloud Source Repositories, vous pouvez configurer Cloud Run pour qu'il déploie automatiquement les nouveaux commits.
- Mise en réseau privée
- Les instances Cloud Run peuvent atteindre des ressources dans le réseau de cloud privé virtuel (VPC) via le connecteur d'accès au VPC sans serveur. Votre service peut ainsi se connecter aux machines virtuelles ou aux produits Compute Engine basés sur Compute Engine, tels que Google Kubernetes Engine ou Memorystore.
- API Google Cloud
- Le code de votre service s'authentifie de manière transparente avec les API Google Cloud. Exemples : les API d'IA et de machine learning, telles que l'API Cloud Vision, l'API Speech-to-Text, l'API AutoML Natural Language, l'API Cloud Translation et bien d'autres encore.
- Tâches en arrière-plan
- Si vous souhaitez planifier l'exécution du code ultérieurement ou immédiatement après le renvoi d'une requête Web, Cloud Run fonctionne bien avec Cloud Tasks pour fournir une exécution asynchrone fiable et évolutive.
Consultez la page Se connecter aux services Google Cloud pour obtenir la liste de tous les services Google Cloud qui fonctionnent bien avec Cloud Run.
Les services ou les tâches doivent être empaquetés dans une image de conteneur
Pour que votre service ou votre tâche puisse être déployé sur Cloud Run, vous devez l'empaqueter dans une image de conteneur. Si vous ne connaissez pas bien les conteneurs, voici une brève présentation conceptuelle.
Une image de conteneur est un package contenant tout ce dont votre service a besoin pour s'exécuter. Cela inclut les artefacts de compilation, les éléments, les packages système et (éventuellement) un environnement d'exécution. Ainsi, une application conteneurisée est intrinsèquement portable : elle s'exécute partout où un conteneur peut s'exécuter. Voici des exemples d'artefacts de compilation : les fichiers binaires ou les fichiers de script compilés. L'environnement d'exécution JavaScript Node.js ou une machine virtuelle Java (JVM) sont des exemples d'environnements d'exécution.
Les experts avancés considèrent que Cloud Run n'impose pas de charge supplémentaire à l'exécution de leur code : vous pouvez exécuter n'importe quel binaire sur Cloud Run. Pour les utilisateurs, y compris les experts qui souhaitent plus de commodité ou pour déléguer la conteneurisation de leur application à Google, Cloud Run s'intègre aux packs de création Open Source de Google Cloud pour proposer un déploiement basé sur la source.
Étape suivante
- Déployer un service Cloud Run
- Créer et exécuter une tâche Cloud Run
- Exécuter des jobs selon un calendrier
- Explorer le modèle de ressource
- En savoir plus sur le contrat d'exécution du conteneur