Cloud Run, le chaînon manquant entre Kubernetes et Cloud Functions

Cloud Run en bref et en détail

L’idée derrière Cloud Run est de permettre de déployer simplement un service basé sur des conteneurs, tout en garantissant l’autoscaling de 0 à N conteneurs stateless en toute transparence. Il s’agit donc d’un service entièrement géré et dont le coût ne dépend que de l’utilisation : si pas d’utilisation, pas de facturation !

Pour y parvenir Cloud Run implémente la solution Open Source Knative et plus particulièrement le composant Serving. Pour en savoir plus sur Knative n’hésitez pas à aller regarder l’article de blog dédié. Selon Google, cette implémentation est conforme aux standards Knative et doit permettre de facilement déplacer des workloads d’un cluster Knative à un autre, peu importe qu’il soit géré via Cloud Run, sur GKE, ou même on-premise.

Pour terminer sur ce rapide tour, il faut noter que Cloud Run existe en deux versions :

• Une version entièrement gérée où les conteneurs s'exécutent sur l’infrastructure partagée de GCP. Dans ce mode, il suffit uniquement d’indiquer l’image de conteneur à utiliser pour que le service démarre. La facturation se fait au temps d'exécution, comme les Cloud Functions.
• L’autre mode est Cloud Run sur GKE, qui permet d’automatiser le déploiement et la configuration de Knative sur son propre cluster GKE, donc au sein d’un VPC, tout en bénéficiant de la gestion par Google. La facturation est comprise dans les frais normaux GKE.

Le détail sur la facturation est disponible dans la documentation.

Cloud Run dans l’écosystème Compute de GCP

Une des questions légitimes est de se demander pourquoi créer une nouvelle façon d'exécuter des charges de travail. Le produit vient en réalité en complémentarité des 4 autres déjà existantes (Compute, Container, AppEngine, Functions).

On peut considérer que Cloud Run vient se positionner à la croisée de GKE, Cloud Functions, et AppEngine :

• Il reste proche de GKE car il permet aussi de conteneuriser l’application, mais sans toute la complexité et la gestion induite par un cluster Kubernetes.
• Il ressemble à AppEngine car il est entièrement géré et propose d’abstraire la capacité d'exécution, mais n’oblige pas à écrire du code spécifique et une configuration particulière pour fonctionner.
• Enfin, il s’approche de Cloud Functions par son aspect serverless et scale from 0, mais sans se limiter à quelques langages et en permettant d’utiliser n’importe quel conteneur.

En pratique comment ça marche ?

Essayons de l’utiliser et d’explorer sommairement ses fonctionnalités.

Dans la console Google Cloud UI

L’accès au service se fait simplement via le menu Cloud Run, on peut déjà observer la liste des services déployés, ainsi que leur état. La première étape consiste à créer un service, et comme vous pouvez le constater la liste des options est simple :

Il s’agit de donner l’url de l’image qu’on souhaite lancer. À noter que seules les images hébergées sur le conteneur registry (GCR) de GCP peuvent être lancées. Ensuite, on ajoute un nom de service.
Une dernière option permet d’autoriser les appels non authentifiés, donc publics. Par défaut un service déployé est totalement privé et l’accès se fait via des rôles IAM spécifiques : roles/run.invoker.

Si on regarde le service déployé, on peut voir l’URL d’accès, les différentes révisions avec leur détail. Les journaux sont également disponibles, il s’agit d’une vue sur stackdriver.

Enfin l’accès à l’URL nous retourne la réponse du serveur web :

Via la CLI gcloud

Si on essaye de faire la même chose via la CLI gcloud, cela donne simplement :

# Deployment
$ gcloud beta run deploy --image gcr.io/lab-bcadiot/simple-web:1.0 simple-web --region us-central1 --allow-unauthenticated
Deploying container to Cloud Run service [simple-web] in project [lab-bcadiot] region [us-central1]
✓ Deploying new service... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [simple-web] revision [simple-web-a7632d8c-0dea-4b59-8ae8-1c3f7f28ec4e] has been deployed and is serving traffic at https://simple-web-zhm6refx7a-uc.a.run.app

# Test access
$ curl https://simple-web-zhm6refx7a-uc.a.run.app
Hello World!

Le détail de la documentation est disponible directement sur la doc GCP Cloud Run.

Quelques prérequis tout de même

Pour que Cloud Run fonctionne il y a tout de même quelques contraintes à respecter dans la création du conteneur et dans le type de workloads qui peuvent être exécutés. Ces contraintes sont définies sur la page Container Contract, en voici quelques unes des plus structurantes :

• Le conteneur doit être compilé pour Linux 32 ou 64 bits
• Uniquement des services web HTTP / HTTPS
• Seulement des services sans état
• Le serveur web doit démarrer en moins de 4 minutes
• Le service déployé doit répondre en moins de 15 minutes (par défaut 5 minutes)
• Le service doit écouter sur 0.0.0.0/0
• Le port d’écoute doit se configurer depuis la variable d’environnement ${PORT}
• La mémoire allouable au conteneur ne peut excéder 2 go de RAM

Pour aller plus loin

Ce nouveau produit est très puissant, et permet de construire de nouvelles architectures un peu plus ancrées “serverless”. Restez à l’écoute, il se pourrait bien que de futurs articles proposent des PoC et solutions utilisant Cloud Run !