Dans cet article, nous allons voir comment utiliser Cloud Run sur un cluster GKE (Google Kubernetes Engine). Pour rappel, Cloud Run est un service serverless qui a été annoncé à la Google Next 2019, il permet de déployer des conteneurs stateless HTTP entièrement gérés sur GCP avec la scalabilité de 0 à N grâce à Knative. Il est possible de faire du Cloud Run directement sur GKE, ce qui permet de conteneuriser l’application, mais sans toute la complexité qu’on aurait dans la gestion des différents fichiers Yaml et le déploiement dans notre cluster Kubernetes.
Sommaire
Passons à la pratique
Avant tout, il vous faudra activer les API pour Cloud Run et Kubernetes Engine sur GCP. Pour cela, allez dans le menu de GCP et sélectionnez “API et services”, puis allez sur “+ ACTIVER DES API ET DES SERVICES”.
Il ne vous restera plus qu’à chercher “Kubernetes Engine API“ et “Cloud Run API” afin de les activer.
Création du cluster Kubernetes en activant le service Cloud Run sur le cluster
La première étape consiste à disposer d’un cluster GKE, pour cela allez dans le menu de GCP et allez dans Kubernetes Engine :
Cliquez sur “créer un cluster” afin de pouvoir arriver sur la page de configuration de votre cluster. Pour la création du cluster, dans notre cas, nous allons laisser les différentes valeurs par défaut et créer notre cluster en mode “standard cluster”. Les seules modifications que nous devons faire sont dans la partie “Disponibilité, mise en réseau, sécurité et autres fonctionnalités“.
Afin de pouvoir activer Cloud Run sur GKE, il faut obligatoirement activer le service Stackdriver Logging et Monitoring ainsi que la version bêta de ses services Stackdriver et activer Istio. Sans cela vous ne pourrez pas cocher la case d’activation de Cloud Run sur GKE qui restera grisée.
Création d'un service Cloud Run sur le cluster GKE
Allez dans le menu de GCP et sélectionnez Cloud Run puis “Créer un service” :
Dans emplacement, choisissez bien votre cluster Kubernetes où vous avez activé Cloud Run, dans notre cas le cluster est “standard-cluster-1” sur us-central1-a :
Après avoir sélectionné le namespace, vous pourrez choisir ou lancer vos containers via Cloud Run sur notre cluster GKE.
Accès au service
Maintenant que notre container Hello, basé sur l'image par défaut "gcr.io/cloudrun/hello" est bien déployé dans notre cluster GKE "Cluster GKE : standard-cluster-1" via Cloud Run, nous disposons de l'URL pour accéder au service "URL :http://hello.default.example.com". Attention, cette url n’est pas accessible depuis l’extérieur, car c’est une url par défaut, elle est interne à notre cluster GKE et non rattachée à un enregistrement DNS. Nous avons donc deux solutions possibles afin de vérifier que le service est bien déployé, soit via Cloud Shell, en modifiant le header Host, ou directement en nous connectant à notre cluster Kubernetes en exécutant la commande curl sur “http://hello.default.example.com”.
Je vais opter pour la solution de Cloud Shell en passant par notre Ingress Controller Istio afin d'accéder au service HTTP.
Nous allons prendre l’IP avec le port 80, que nous pouvons voir ci-dessus, afin de pouvoir accéder en direct à notre service.
Test du service via Cloud Shell
Dans un premier temps, il vous faudra ouvrir Cloud Shell :
Une fois Cloud Shell lancé, vous pourrez utiliser cette commande afin de vérifier que le service déployé est fonctionnel, dans mon cas c’est hello.default.example.com et l’IP de mon Ingress gateway 35.226.121.201:80, à vous bien sûr d’adapter selon votre configuration :
Après avoir exécuté cette commande, nous obtenons le résultat suivant avec le “Congratulations | cloud run” qui nous indique que notre conteneur avec l’image Hello a bien été déployé via Cloud Run sur notre cluster GKE.
Le mot de la fin
On peut constater que l’installation et l’utilisation de Cloud Run sur un cluster GKE est vraiment simple, en 10 minutes chrono en incluant le temps de création du cluster GKE, on dispose d’un service déployé par Cloud Run sur notre cluster Kubernetes.
Vous évoluez dans une structure où l’infrastructure est hébergée sur Amazon Web Services (AWS) ? Vous souhaitez valoriser vos compétences techniques d’administration sur le premier fournisseur de cloud du marché ? Ce post est fait pour vous ! Dans cet article nous allons passer en revue la certification AWS Certified SysOps Administrator Associate (communément appelée SysOps) et vous donner des conseils pour que vous puissiez commencer sereinement vos révisions en vue d'obtenir ce badge orange.
Face aux Cloud Américains, qui en Europe pour prendre le lead ?
Le cloud est l’un des sujets les plus en vue et discutés dans l’informatique, de plus en plus d’entreprises l’utilisent pour ses capacités à répondre rapidement à leurs besoins et la facilité de l'utiliser à la demande en ne facturant que notre consommation. Les Américains ont un monopole sur la tech, notamment le cloud computing avec leurs 3 mastodontes que sont AWS, Azure et GCP. Pourquoi les clouds providers américains sont dans une telle position dominante ? Pourquoi n'y a-t-il pas de cloud européen comparable ?
Comment mettre en place une politique de tagging sur AWS ?
La façon dont nous déployons, gérons et mettons à l'échelle nos ressources informatiques a radicalement changé avec l’adoption du Cloud. AWS (Amazon Web Services) est l'un des principaux acteurs de cette transformation, offrant des services et des ressources en constante évolution.