Cette page explique comment déployer des images de conteneur dans un nouveau service Cloud Run ou dans une nouvelle version d'un service Cloud Run existant.
L'image de conteneur est importée par Cloud Run lors du déploiement. Cloud Run conserve cette copie de l'image du conteneur tant qu'elle est utilisée par une révision de diffusion. Les images de conteneur ne sont pas extraites de leur dépôt de conteneur lorsqu'une nouvelle instance Cloud Run est démarrée.
Pour obtenir un exemple de déploiement d'un nouveau service, consultez la section Guide de démarrage rapide sur le déploiement d'un exemple de conteneur.
Avant de commencer
Si vous êtes soumis à une règle d'administration de restriction de domaine limitant les appels non authentifiés pour votre projet, vous devez accéder au service déployé comme décrit dans la section Tester les services privés.
Rôles requis
Pour obtenir les autorisations nécessaires pour déployer des services Cloud Run, demandez à votre administrateur de vous accorder les rôles IAM suivants :
-
Développeur Cloud Run (
roles/run.developer
) sur le service Cloud Run -
Utilisateur du compte de service (
roles/iam.serviceAccountUser
) sur l'identité du service -
Lecteur Artifact Registry (
roles/artifactregistry.reader
) sur le dépôt Artifact Registry de l'image de conteneur déployée (le cas échéant)
Pour obtenir la liste des rôles et des autorisations IAM associés à Cloud Run, consultez les sections Rôles IAM Cloud Run et Autorisations IAM Cloud Run. Si votre service Cloud Run communique avec les API Google Cloud, telles que les bibliothèques clientes Cloud, consultez le guide de configuration de l'identité du service. Pour en savoir plus sur l'attribution de rôles, consultez les sections Autorisations de déploiement et Gérer les accès.
Registres de conteneurs et images acceptés
Vous pouvez utiliser directement des images de conteneurs stockées dans Artifact Registry ou Docker Hub. Nous vous recommandons d'utiliser Artifact Registry.
Vous pouvez utiliser des images de conteneurs provenant d'autres registres publics ou privés (tels que JFrog Artifactory, Nexus ou GitHub Container Registry) en configurant un dépôt Artifact Registry distant.
Envisagez d'utiliser Docker Hub uniquement pour déployer des images de conteneurs populaires, telles que des images officielles Docker ou des images OSS sponsorisées par Docker. Pour accroître la disponibilité, Google recommande de déployer ces images Docker Hub via un dépôt Artifact Registry distant.
Déployer un nouveau service
Vous pouvez spécifier une image de conteneur avec un tag (par exemple, us-docker.pkg.dev/my-project/container/my-image:latest
) ou avec un condensé exact (par exemple, us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...
).
Le déploiement d'un service pour la première fois crée sa première révision. Notez que les révisions sont immuables. Si vous déployez à partir d'un tag d'image de conteneur, il sera transformé en condensé et la révision desservira toujours ce condensé.
Cliquez sur l'onglet pour obtenir des instructions concernant l'utilisation de l'outil de votre choix.
Console
Pour déployer une image de conteneur, procédez comme suit :
Dans la console Google Cloud, accédez à la page Cloud Run :
Cliquez sur Déployer un conteneur et sélectionnez Service pour afficher le formulaire Créer un service.
Dans le formulaire, sélectionnez l'option de déploiement :
Si vous souhaitez déployer manuellement un conteneur, sélectionnez Déployer une révision à partir d'une image de conteneur existante, puis spécifiez l'image de conteneur.
Pour une automatisation à des fins de déploiement continu, sélectionnez Déployer de nouvelles révisions en continu à partir d'un dépôt source et suivez les instructions pour les déploiements continus.
Saisissez le nom du service requis. Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet. Un nom de service ne peut pas être modifié ultérieurement et il est visible publiquement.
Sélectionnez la région dans laquelle vous souhaitez créer votre service. Le sélecteur de région indique le niveau de tarification et la disponibilité des mappages de domaines, et met en évidence les régions avec l'impact carbone le plus faible.
Définissez l'allocation et la tarification du processeur si nécessaire.
Sous Autoscaling, spécifiez des instances minimum et maximum.
Définissez les paramètres de l'objet Ingress dans le formulaire, le cas échéant.
Sous Authentification, configurez les éléments suivants :
- Si vous créez une API ou un site Web public, sélectionnez Allow unauthenticated invocations (Autoriser les appels non authentifiés). En sélectionnant cette option, le rôle Demandeur IAM est attribué à l'identifiant spécial
allUser
. Vous pouvez utiliser IAM pour modifier ce paramètre ultérieurement après avoir créé le service. - Si vous souhaitez qu'un service sécurisé soit protégé par authentification, sélectionnez Require authentication (Exiger l'authentification).
- Si vous créez une API ou un site Web public, sélectionnez Allow unauthenticated invocations (Autoriser les appels non authentifiés). En sélectionnant cette option, le rôle Demandeur IAM est attribué à l'identifiant spécial
Cliquez sur Conteneur(s), volumes, mise en réseau et sécurité pour définir d'autres paramètres facultatifs dans les onglets appropriés :
Une fois la configuration du service terminée, cliquez sur Créer pour déployer l'image sur Cloud Run, puis patientez jusqu'à la fin du déploiement.
Cliquez sur le lien URL affiché pour ouvrir le point de terminaison unique et stable de votre service déployé.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Pour déployer une image de conteneur, procédez comme suit :
Exécutez la commande suivante :
gcloud run deploy SERVICE --image IMAGE_URL
- Remplacez SERVICE par le nom du service sur lequel vous souhaitez déployer l'image. Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet. Si le service n'existe pas encore, cette commande le crée lors du déploiement. Vous pouvez omettre ce paramètre, mais dans ce cas le nom du service vous sera demandé.
- 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
. Notez que si vous ne fournissez pas l'option--image
, la commande de déploiement tente d'effectuer le déploiement à partir du code source.
Si vous créez une API ou un site Web public, autorisez les appels non authentifiés de votre service à l'aide de l'option
--allow-unauthenticated
. Cela attribue le rôle IAM Demandeur Cloud Run àallUsers
. Vous pouvez également spécifier--no-allow-unauthenticated
pour interdire les appels non authentifiés. Si vous omettez l'une de ces options, vous êtes invité à confirmer l'exécution de la commandedeploy
.Patientez jusqu'à la fin du déploiement. Une fois l'opération achevée, un message de réussite indiquant l'URL du service déployé s'affiche.
Notez que pour effectuer un déploiement dans un emplacement différent de celui que vous avez défini à l'aide des propriétés
run/region
etgcloud
, vous devez exécuter les commandes suivantes :gcloud run deploy SERVICE --region REGION
YAML
Vous pouvez stocker votre spécification de service dans un fichier YAML
, puis la déployer à l'aide de gcloud CLI.
Créez un fichier
service.yaml
avec le contenu suivant :apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: spec: containers: - image: IMAGE
Remplacer
- SERVICE par le nom de votre service Cloud Run ; Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
- IMAGE par l'URL de votre image de conteneur
Vous pouvez également spécifier d'autres éléments de configuration, tels que des variables d'environnement ou des limites de mémoire.
Déployez le nouveau service à l'aide de la commande suivante :
gcloud run services replace service.yaml
Vous pouvez éventuellement rendre votre service public si vous souhaitez autoriser un accès non authentifié à celui-ci.
Cloud Code
Pour déployer avec Cloud Code, consultez les guides IntelliJ et Visual Studio Code.
Terraform
Si vous utilisez Terraform, définissez votre service dans une configuration Terraform à l'aide de la ressource google_cloud_run_v2_service
du fournisseur Google Cloud Platform.
Créez un fichier
main.tf
avec le contenu suivant :provider "google" { project = "PROJECT-ID" } resource "google_cloud_run_v2_service" "default" { name = "SERVICE" location = "REGION" client = "terraform" template { containers { image = "IMAGE" } } } resource "google_cloud_run_v2_service_iam_member" "noauth" { location = google_cloud_run_v2_service.default.location name = google_cloud_run_v2_service.default.name role = "roles/run.invoker" member = "allUsers" }
Remplacer
- PROJECT-ID par l'ID du projet Google Cloud
- REGION par la région Google Cloud
- SERVICE par le nom de votre service Cloud Run ; Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
- 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
Cette configuration autorise l'accès public (l'équivalent de
--allow-unauthenticated
). Pour rendre le service privé, supprimez le stanzagoogle_cloud_run_v2_service_iam_member
.Initialisez Terraform :
terraform init
Appliquez la configuration Terraform :
terraform apply
Confirmez que vous souhaitez appliquer les actions décrites en saisissant
yes
.
Bibliothèques clientes
Pour déployer un service à partir du code, procédez comme suit :
API REST
Pour déployer un service, envoyez une requête HTTP POST
au point de terminaison service
de l'API Cloud Run Admin.
Exemple, à l'aide de curl
:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X POST \ -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE
Remplacez :
- ACCESS_TOKEN par un jeton d'accès valide pour un compte disposant des autorisations IAM pour déployer les services.
Par exemple, si vous êtes connecté à gcloud, vous pouvez récupérer un jeton d'accès à l'aide de
gcloud auth print-access-token
. À partir d'une instance de conteneur Cloud Run, vous pouvez récupérer un jeton d'accès via le serveur de métadonnées d'instance de conteneur. - 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
. - SERVICE par le nom du service sur lequel vous souhaitez déployer l'image. Les noms de service doivent comporter un maximum de 49 caractères et être uniques par région et par projet.
- REGION par la région Google Cloud du service.
- PROJECT-ID par l'ID du projet Google Cloud.
Emplacements Cloud Run
Cloud Run est régional, ce qui signifie que l'infrastructure qui exécute vos services Cloud Run est située dans une région spécifique et gérée par Google pour être disponible de manière redondante dans toutes les zones de cette région.
Lors de la sélection de la région dans laquelle exécuter vos services Cloud Run, vous devez tout d'abord considérer vos exigences en matière de latence, de disponibilité et de durabilité.
Vous pouvez généralement sélectionner la région la plus proche de vos utilisateurs, mais vous devez tenir compte de l'emplacement des autres produits Google Cloud utilisés par votre service Cloud Run.
L'utilisation conjointe de produits Google Cloud dans plusieurs emplacements peut avoir une incidence sur la latence et le coût de votre service.
Cloud Run est disponible dans les régions suivantes :
Soumis aux tarifs de niveau 1
asia-east1
(Taïwan)asia-northeast1
(Tokyo)asia-northeast2
(Osaka)asia-south1
(Mumbai, Inde)europe-north1
(Finlande) Faibles émissions de CO2europe-southwest1
(Madrid) Faibles émissions de CO2europe-west1
(Belgique) Faibles émissions de CO2europe-west4
(Pays-Bas) Faibles émissions de CO2europe-west8
(Milan)europe-west9
(Paris) Faibles émissions de CO2me-west1
(Tel Aviv)us-central1
(Iowa) Faibles émissions de CO2us-east1
(Caroline du Sud)us-east4
(Virginie du Nord)us-east5
(Columbus)us-south1
(Dallas) Faibles émissions de CO2us-west1
(Oregon) Faibles émissions de CO2
Soumis aux tarifs de niveau 2
africa-south1
(Johannesburg)asia-east2
(Hong Kong)asia-northeast3
(Séoul, Corée du Sud)asia-southeast1
(Singapour)asia-southeast2
(Jakarta)asia-south2
(Delhi, Inde)australia-southeast1
(Sydney)australia-southeast2
(Melbourne)europe-central2
(Varsovie, Pologne)europe-west10
(Berlin) Faibles émissions de CO2.europe-west12
(Turin)europe-west2
(Londres, Royaume-Uni) Faibles émissions de CO2europe-west3
(Francfort, Allemagne) Faibles émissions de CO2europe-west6
(Zurich, Suisse) Faibles émissions de CO2me-central1
(Doha)me-central2
(Dammam)northamerica-northeast1
(Montréal) Faibles émissions de CO2northamerica-northeast2
(Toronto) Faibles émissions de CO2southamerica-east1
(São Paulo, Brésil) Faibles émissions de CO2southamerica-west1
(Santiago, Chili) Faibles émissions de CO2us-west2
(Los Angeles)us-west3
(Salt Lake City)us-west4
(Las Vegas)
Si vous avez déjà créé un service Cloud Run, vous pouvez afficher la région dans le tableau de bord Cloud Run de la console Google Cloud.
Déployer une nouvelle révision d'un service existant
Vous pouvez déployer une nouvelle révision à l'aide de Google Cloud Console, de la ligne de commande gcloud
ou d'un fichier de configuration YAML.
Notez que la modification des paramètres de configuration entraîne la création d'une révision, même si l'image du conteneur ne change pas. Chaque révision créée est immuable.
L'image de conteneur est importée par Cloud Run lors du déploiement. Cloud Run conserve cette copie de l'image du conteneur tant qu'elle est utilisée par une révision de diffusion.
Cliquez sur l'onglet pour obtenir des instructions concernant l'utilisation de l'outil de votre choix.
Console
Pour déployer une nouvelle révision d'un service existant, procédez comme suit :
Dans la console Google Cloud, accédez à la page Cloud Run :
Recherchez le service que vous souhaitez mettre à jour dans la liste des services, puis cliquez dessus pour en afficher les détails.
Cliquez sur Modifier et déployer la nouvelle révision pour afficher le formulaire de déploiement de version.
Si nécessaire, fournissez l'URL de la nouvelle image de conteneur que vous souhaitez déployer.
Configurez le conteneur si nécessaire.
Définissez l'allocation et la tarification du processeur si nécessaire.
Sous "Capacité", spécifiez les limites de mémoire et les limites de processeur.
Spécifiez le délai d'expiration de requête et la simultanéité si nécessaire.
Spécifiez l'environnement d'exécution si nécessaire.
Sous Autoscaling, spécifiez des instances minimum et maximum.
Utilisez les autres onglets si nécessaire pour configurer les éléments suivants si vous le souhaitez :
Pour envoyer l'ensemble du trafic vers la nouvelle révision, sélectionnez Diffuser immédiatement la révision. Pour déployer progressivement une nouvelle révision, décochez cette case. Cela se traduit par un déploiement dans lequel aucun trafic n'est envoyé à la nouvelle révision. Suivez les instructions de déploiement progressif après avoir effectué votre déploiement.
Cliquez sur Déployer et attendez la fin du déploiement.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Pour déployer une image de conteneur, procédez comme suit :
Exécutez la commande suivante :
gcloud run deploy SERVICE --image IMAGE_URL
- Remplacez SERVICE par le nom du service sur lequel vous déployez l'image. Vous pouvez omettre ce paramètre, mais dans ce cas le nom du service vous sera demandé.
- 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
.
Le suffixe de révision est attribué automatiquement aux nouvelles révisions. Si vous souhaitez spécifier votre propre suffixe de révision, utilisez le paramètre --revision-suffix de gcloud CLI.
Patientez jusqu'à la fin du déploiement. Une fois l'opération achevée, un message de réussite indiquant l'URL du service déployé s'affiche.
YAML
Si vous devez télécharger ou consulter la configuration d'un service existant, exécutez la commande suivante pour enregistrer les résultats dans un fichier YAML :
gcloud run services describe SERVICE --format export > service.yaml
Dans un fichier YAML de configuration de service, modifiez les attributs enfants spec.template
en fonction de vos besoins pour mettre à jour les paramètres de révision, puis déployez la nouvelle révision :
gcloud run services replace service.yaml
Cloud Code
Pour déployer une nouvelle révision d'un service existant avec Cloud Code, consultez les guides IntelliJ et Visual Studio Code.
Terraform
Assurez-vous d'avoir configuré Terraform comme décrit dans l'exemple Déployer un nouveau service.
Apportez une modification au fichier de configuration.
Appliquez la configuration Terraform :
terraform apply
Confirmez que vous souhaitez appliquer les actions décrites en saisissant
yes
.
Bibliothèques clientes
Pour déployer une nouvelle révision à partir du code, procédez comme suit :
API REST
Pour déployer une révision, envoyez une requête HTTP PATCH
au point de terminaison service
de l'API Cloud Run Admin.
Exemple, à l'aide de curl
:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X PATCH \ -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE
Remplacez :
- ACCESS_TOKEN par un jeton d'accès valide pour un compte disposant des autorisations IAM pour déployer les révisions.
Par exemple, si vous êtes connecté à gcloud, vous pouvez récupérer un jeton d'accès à l'aide de
gcloud auth print-access-token
. À partir d'une instance de conteneur Cloud Run, vous pouvez récupérer un jeton d'accès via le serveur de métadonnées d'instance de conteneur. - 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
. - SERVICE par le nom du service sur lequel vous déployez l'image.
- REGION par la région Google Cloud du service.
- PROJECT-ID par l'ID du projet Google Cloud.
Emplacements Cloud Run
Cloud Run est régional, ce qui signifie que l'infrastructure qui exécute vos services Cloud Run est située dans une région spécifique et gérée par Google pour être disponible de manière redondante dans toutes les zones de cette région.
Lors de la sélection de la région dans laquelle exécuter vos services Cloud Run, vous devez tout d'abord considérer vos exigences en matière de latence, de disponibilité et de durabilité.
Vous pouvez généralement sélectionner la région la plus proche de vos utilisateurs, mais vous devez tenir compte de l'emplacement des autres produits Google Cloud utilisés par votre service Cloud Run.
L'utilisation conjointe de produits Google Cloud dans plusieurs emplacements peut avoir une incidence sur la latence et le coût de votre service.
Cloud Run est disponible dans les régions suivantes :
Soumis aux tarifs de niveau 1
asia-east1
(Taïwan)asia-northeast1
(Tokyo)asia-northeast2
(Osaka)asia-south1
(Mumbai, Inde)europe-north1
(Finlande) Faibles émissions de CO2europe-southwest1
(Madrid) Faibles émissions de CO2europe-west1
(Belgique) Faibles émissions de CO2europe-west4
(Pays-Bas) Faibles émissions de CO2europe-west8
(Milan)europe-west9
(Paris) Faibles émissions de CO2me-west1
(Tel Aviv)us-central1
(Iowa) Faibles émissions de CO2us-east1
(Caroline du Sud)us-east4
(Virginie du Nord)us-east5
(Columbus)us-south1
(Dallas) Faibles émissions de CO2us-west1
(Oregon) Faibles émissions de CO2
Soumis aux tarifs de niveau 2
africa-south1
(Johannesburg)asia-east2
(Hong Kong)asia-northeast3
(Séoul, Corée du Sud)asia-southeast1
(Singapour)asia-southeast2
(Jakarta)asia-south2
(Delhi, Inde)australia-southeast1
(Sydney)australia-southeast2
(Melbourne)europe-central2
(Varsovie, Pologne)europe-west10
(Berlin) Faibles émissions de CO2.europe-west12
(Turin)europe-west2
(Londres, Royaume-Uni) Faibles émissions de CO2europe-west3
(Francfort, Allemagne) Faibles émissions de CO2europe-west6
(Zurich, Suisse) Faibles émissions de CO2me-central1
(Doha)me-central2
(Dammam)northamerica-northeast1
(Montréal) Faibles émissions de CO2northamerica-northeast2
(Toronto) Faibles émissions de CO2southamerica-east1
(São Paulo, Brésil) Faibles émissions de CO2southamerica-west1
(Santiago, Chili) Faibles émissions de CO2us-west2
(Los Angeles)us-west3
(Salt Lake City)us-west4
(Las Vegas)
Si vous avez déjà créé un service Cloud Run, vous pouvez afficher la région dans le tableau de bord Cloud Run de la console Google Cloud.
Déployer des images à partir d'autres projets Google Cloud
Vous pouvez déployer des images de conteneurs à partir d'autres projets Google Cloud si vous définissez les autorisations IAM appropriées :
Dans la console Google Cloud, ouvrez le projet de votre service Cloud Run.
Sélectionnez Inclure les attributions de rôles fournies par Google.
Copiez l'adresse e-mail de l'agent de service Cloud Run. Elle porte le suffixe @serverless-robot-prod.iam.gserviceaccount.com.
Ouvrez le projet qui contient le registre de conteneurs que vous souhaitez utiliser.
Cliquez sur Ajouter pour ajouter une entité principale.
Dans le champ Nouveaux comptes principaux, collez l'adresse e-mail du compte de service que vous avez copié précédemment.
Dans le menu déroulant Sélectionner un rôle, si vous utilisez Container Registry, sélectionnez le rôle Stockage -> Lecteur des objets de l'espace de stockage. Si vous utilisez Artifact Registry, sélectionnez le rôle Artifact Registry -> Lecteur Artifact Registry.
Déployez l'image de conteneur sur le projet contenant votre service Cloud Run.
Déployer des images à partir d'autres registres
Pour déployer des images de conteneurs publiques ou privées qui ne sont pas stockées dans Artifact Registry ou Docker Hub, configurez un dépôt distant Artifact Registry.
Les dépôts distants Artifact Registry vous permettent d'effectuer les opérations suivantes :
- Déployez une image de conteneur publique, par exemple GitHub Container Registry (
ghcr.io
). - Déployer des images de conteneurs à partir de dépôts privés nécessitant une authentification, par exemple JFrog Artifactory ou Nexus.
Si vous ne pouvez pas utiliser un dépôt distant Artifact Registry, vous pouvez également extraire et transférer temporairement des images de conteneur vers Artifact Registry à l'aide de docker push
afin de les déployer sur Cloud Run.
L'image de conteneur est importée par Cloud Run lors du déploiement. Par conséquent, après le déploiement, vous pouvez supprimer l'image d'Artifact Registry.
Déployer plusieurs conteneurs sur un service (side-cars)
Un déploiement Cloud Run avec side-cars contient un conteneur d'entrée gère toutes les requêtes HTTPS entrantes sur le port de conteneur que vous indiquez et un ou plusieurs conteneurs side-car. Les side-cars ne peuvent pas écouter les requêtes HTTP entrantes sur le port du conteneur d'entrée, mais ils peuvent communiquer entre eux et avec le conteneur d'entrée à l'aide d'un port localhost. Le port localhost utilisé varie en fonction des conteneurs que vous utilisez.
Dans le schéma suivant, le conteneur d'entrée communique avec le side-car à l'aide de localhost:5000
.
Vous pouvez déployer jusqu'à 10 conteneurs par instance (y compris le conteneur d'entrée). Tous les conteneurs d'une instance partagent le même espace de noms réseau et peuvent également partager des fichiers via un volume partagé en mémoire, comme illustré dans le diagramme.
Vous pouvez déployer plusieurs conteneurs dans l'environnement d'exécution de première ou deuxième génération.
Par défaut, le processeur n'est alloué aux sidecars que lorsque l'instance traite au moins une requête. Si vous avez besoin que votre sidecar puisse utiliser le processeur en dehors du traitement des requêtes (par exemple, pour la collecte de métriques), configurez votre service pour qu'il alloue toujours le processeur. Pour en savoir plus, consultez la section Allocation du processeur (services).
Vous pouvez exiger que tous les déploiements utilisent un sidecar spécifique en créant des règles d'administration personnalisées.
Cas d'utilisation
Voici quelques cas d'utilisation de side-cars dans un service Cloud Run :
- Surveillance, journalisation et traçage des applications
- Utilisation de Nginx, Envoy ou Apache2 comme proxy devant votre conteneur d'applications
- Ajouter des filtres d'authentification et d'autorisation (par exemple, Open Policy Agent)
- Exécution de proxys de connexion sortants tels que le proxy d'authentification Alloy DB
Déployer un service avec des conteneurs side-car
Vous pouvez déployer plusieurs side-cars sur un service Cloud Run à l'aide de la console Google Cloud, de Google Cloud CLI, de YAML ou de Terraform.
Cliquez sur l'onglet pour obtenir des instructions concernant l'utilisation de l'outil de votre choix.
Console
Dans la console Google Cloud, accédez à la page Cloud Run :
- Pour déployer un service existant, recherchez-le dans la liste des services et cliquez pour l'ouvrir, puis cliquez sur MODIFIER ET DÉPLOYER LA NOUVELLE RÉVISION pour afficher le formulaire de déploiement de révision.
- Cliquez sur Déployer un conteneur et sélectionnez Service pour afficher le formulaire Créer un service.
Pour un nouveau service :
- Indiquez le nom du service et l'URL de l'image de conteneur d'entrée que vous souhaitez déployer.
- Cliquez sur Conteneur(s), volumes, mise en réseau, sécurité.
Dans la fiche Modifier le conteneur, configurez le conteneur d'entrée si nécessaire.
Cliquez sur Ajouter un conteneur et configurez un conteneur side-car que vous souhaitez ajouter avec le conteneur d'entrée. Si le side-car dépend d'un autre conteneur dans le service, indiquez-le dans le menu déroulant Ordre de démarrage du conteneur. Répétez cette étape pour chaque conteneur side-car que vous déployez.
Pour envoyer l'ensemble du trafic vers la nouvelle révision, sélectionnez Diffuser immédiatement la révision. Pour un déploiement progressif, décochez cette case. Cela se traduit par un déploiement dans lequel aucun trafic n'est envoyé à la nouvelle révision. Suivez les instructions de déploiement progressif après avoir effectué votre déploiement.
Cliquez sur Créer pour un nouveau service ou sur Déployer pour un service existant, puis attendez la fin du déploiement.
gcloud
Les paramètres container
dans Google Cloud CLI sont disponibles en version bêta.
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Pour déployer plusieurs conteneurs sur un service, exécutez la commande suivante :
gcloud run deploy SERVICE \ --container INGRESS_CONTAINER_NAME \ --image='INGRESS_IMAGE' \ --port='CONTAINER_PORT' \ --container SIDECAR_CONTAINER_NAME \ --image='SIDECAR_IMAGE'
Remplacez :
- SERVICE par le nom du service sur lequel vous déployez l'image. Vous pouvez omettre ce paramètre, mais dans ce cas le nom du service vous sera demandé.
- INGRESS_CONTAINER_NAME par le nom du conteneur recevant les requêtes, par exemple
app
. - INGRESS_IMAGE par une référence à l'image de conteneur qui doit recevoir des requêtes, par exemple
us-docker.pkg.dev/cloudrun/container/hello:latest
. - CONTAINER_PORT par le port sur lequel le conteneur d'entrée écoute les requêtes entrantes. Contrairement au scénario avec service à conteneur unique, il n'existe pas de port par défaut pour le conteneur d'entrée d'un service incluant des side-cars. Vous devez configurer explicitement le port du conteneur pour le conteneur d'entrée, et le port ne peut être exposé que sur un seul conteneur.
- SIDECAR_CONTAINER_NAME par le nom du conteneur side-car, par exemple
sidecar
. - SIDECAR_IMAGE par une référence à l'image de conteneur side-car.
Si vous souhaitez configurer chaque conteneur dans la commande de déploiement, indiquez la configuration de chaque conteneur après les paramètres
container
, par exemple :gcloud run deploy SERVICE \ --container CONTAINER_1_NAME \ --image='INGRESS_IMAGE' \ --set-env-vars=KEY=VALUE \ --port='CONTAINER_PORT' \ --container SIDECAR_CONTAINER_NAME \ --image='SIDECAR_IMAGE' \ --set-env-vars=KEY_N=VALUE_N
Patientez jusqu'à la fin du déploiement. Une fois l'opération réussie, un message de réussite s'affiche indiquant l'URL du service déployé.
YAML
Ces instructions présentent un fichier YAML de base pour votre service Cloud Run avec side-cars.
Créez un fichier nommé service.yaml
et insérez-y les éléments suivants :
apiVersion: serving.knative.dev/v1 kind: Service metadata: annotations: name: SERVICE spec: template: spec: containers: - image: INGRESS_IMAGE ports: - containerPort: CONTAINER_PORT - image: SIDECAR_IMAGE
Remplacer
- SERVICE par le nom de votre service Cloud Run ; Les noms de service ne doivent pas comporter plus de 49 caractères.
- CONTAINER_PORT par le port sur lequel le conteneur d'entrée écoute les requêtes entrantes. Contrairement au scénario avec service à conteneur unique, il n'existe pas de port par défaut pour le conteneur d'entrée d'un service incluant des side-cars. Vous devez configurer explicitement le port du conteneur pour le conteneur d'entrée, et le port ne peut être exposé que sur un seul conteneur.
- INGRESS_IMAGE par une référence à l'image de conteneur qui doit recevoir des requêtes, par exemple
us-docker.pkg.dev/cloudrun/container/hello:latest
. - SIDECAR_IMAGE par une référence à l'image de conteneur side-car. Vous pouvez spécifier plusieurs side-cars en ajoutant plus d'éléments dans le tableau
containers
du fichier YAML.
Après avoir mis à jour le fichier YAML pour inclure les conteneurs d'entrée et side-car, déployez sur Cloud Run à l'aide de la commande suivante :
gcloud run services replace service.yaml
Terraform
Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la page Commandes Terraform de base.
Ajoutez les éléments suivants à une ressource google_cloud_run_v2_service
dans votre configuration Terraform.
resource "google_cloud_run_v2_service" "default" {
name = "SERVICE"
location = "REGION"
ingress = "INGRESS_TRAFFIC_ALL"
template {
containers {
name = "INGRESS_CONTAINER_NAME"
ports {
container_port = CONTAINER_PORT
}
image = "INGRESS_IMAGE"
depends_on = ["SIDECAR_CONTAINER_NAME"]
}
containers {
name = "SIDECAR_CONTAINER_NAME"
image = "SIDECAR_IMAGE"
}
}
}
Le CONTAINER_PORT représente le port sur lequel le conteneur d'entrée écoute les requêtes entrantes. Contrairement au scénario avec service à conteneur unique, il n'existe pas de port par défaut pour le conteneur d'entrée d'un service incluant des side-cars. Vous devez configurer explicitement le port du conteneur pour le conteneur d'entrée, et le port ne peut être exposé que sur un seul conteneur.
Fonctionnalités notables disponibles pour les déploiements avec side-cars
Vous pouvez spécifier l'ordre de démarrage des conteneurs dans un déploiement comportant plusieurs conteneurs, si vous avez des dépendances nécessitant le démarrage de certains conteneurs avant d'autres conteneurs dans le déploiement.
Si vous avez des conteneurs qui dépendent d'autres conteneurs, vous devez utiliser des vérifications d'état dans votre déploiement. Si vous utilisez les vérifications d'état, Cloud Run suit l'ordre de démarrage des conteneurs et inspecte l'état de chaque conteneur, afin de s'assurer que chaque conteneur réussit avant que Cloud Run ne démarre le conteneur suivant dans l'ordre. Si vous n'utilisez pas les vérifications d'état, les conteneurs opérationnels démarrent même si les conteneurs dont ils dépendent ne sont pas en cours d'exécution.
Plusieurs conteneurs d'une même instance peuvent accéder à un volume en mémoire partagé, qui est accessible à chaque conteneur via des points d'installation que vous créez.
Étapes suivantes
Après avoir déployé un nouveau service, vous pouvez effectuer les opérations suivantes :
- Déploiements progressifs, révisions de rollback, migration du trafic
- Afficher les journaux du service
- Surveiller les performances du service
- Définir les limites de mémoire
- Définir des variables d'environnement
- Changer la simultanéité du service
- Gérer le service
- Gérer les révisions du service
- Exemple de side-car OpenTelemetry Cloud Run
- Déployer uniquement des images de confiance avec l'autorisation binaire (Prévisualiser)
Vous pouvez automatiser la création et le déploiement de vos services Cloud Run avec les déclencheurs Cloud Build.
Vous pouvez également utiliser Cloud Deploy pour configurer un pipeline de livraison continue afin de déployer des services Cloud Run dans plusieurs environnements :