La fusion de Jib et Cloud Run

Le point de non retour a été atteint et on ne peut plus faire marche arrière, les conteneurs font partie intégrante du paysage de notre métier.

Mais que dois-je faire ?!

- c’est du travail d’ops, f*** off !!!

- Docker, pourquoi pas, mais je fais tourner ça comment ???

- Kubernetes ? Bordel j’ai déjà du mal à le dire 😱, alors comprendre le concept, j’en ai pour des mois

- Google n’aurait pas fait un truc pour me faciliter la vie ?

Effectivement, et comme souvent, Google nous facilite la vie et pas seulement avec une barre de recherche.

JIB

Késako ???

Jib est un outil créé par Google qui permet de générer des conteneurs sans le Docker Deamon sur votre machine ni Dockerfile dans votre projet, mais ce n’est pas tout. Généralement, une application Java est définie par un seul layer de type jar qui regroupe l’ensemble du code et des dépendances. Jib propose de découper ce jar en plusieurs couches (classes et dépendances) et permettre un build d’image plus rapide et plus optimisé afin de ne recréer que les couches qui ont été modifiées. Ces couches sont ensuite ajoutées à une base image Java “distroless”, qui ne contient exclusivement que les dépendances nécessaires au fonctionnement d’une JVM.

Pour plus d’information => Distroless

KomanFège ??

Après toutes ces belles promesses, comment fait-on pour utiliser tout ça ? Il existe des plugins pour Maven et pour Gradle. Et si vous êtes un peu maso (#sbt), vous pouvez l’implémenter vous même avec la lib jib-core. Nous verrons ici le fonctionnement avec le plugin Maven.

Let’s code

On se place ici dans le contexte d’une application Spring Boot générée depuis ‎Spring Initializr.

Commençons par la configuration Maven pour le plugin Jib

et … ben c’est fini, il n’y a rien d’autre à faire, tout est prêt pour créer notre conteneur.

Dans notre cas, nous allons générer le conteneur sans Docker.

mvn jib:build

Que va t’il se passer ici:

• téléchargement de l’image distroless java depuis gcr.io
• création du conteneur à partir de l’image distroless
• upload du conteneur sur la registry saisie dans la configuration (ici Docker Hub). Il faut donc d’abord être connecté sur Docker Hub à l’aide la commande “docker login”. Il est possible de préciser les credentials dans la configuration maven.
• done

Il est également possible de générer son conteneur avec Docker, à l’aide de la commande

mvn jib:dockerBuild

Votre conteneur sera du coup upload dans votre registry local.

Oui mais maintenant, il est temps de faire tourner tout ça.

Cloud Run

Re késako ?

Cloud Run est une plateforme de service totalement managée de Google permettant de déployer et d’exécuter des conteneurs stateless. Le but de cette plateforme est de profiter des avantages des conteneurs mais sans les potentielles difficultés du management d’une plateforme d’orchestration de conteneur. Autre avantage, la facturation ne se fait que lorsque le conteneur est en activité. On peut assimiler Cloud Run à une Cloud Function mais avec des conteneurs.

Let’s use it

Si nous prenons en compte que vous avez déjà un projet dans GCP, vous pouvez accéder au service Cloud Run via la barre de recherche de la console Google Cloud Platform

Il faut ensuite activer le service Cloud Run :

Vous allez ensuite devoir activer Api Registry :

Et enfin pour terminer, il faut installer le Google Cloud SDK, , puis configurer gcloud comme Docker credential helper. Cela va installer le cli gcloud sur votre machine, et le credential helper va vous permettre d’upload votre conteneur sur la registry Google.

Une fois que tout est installé et configuré, nous sommes up and ready pour utiliser Cloud Run. Nous allons commencer par faire une petite modification dans la configuration maven de Jib :

Ici “cloud-run-jib” est l’id de notre projet GCP. On spécifie donc que nous souhaitons upload notre conteneur “jib-demo” dans la registry Google pour le projet cloud-run-jib. Maintenant si vous relancez la commande de build, vous devriez générer et uploader votre conteneur sur la registry Google.

mvn jib:build
...
[INFO] Built and pushed image as gcr.io/cloud-run-jib/jib-demo, gcr.io/cloud-run-jib/jib-demo:0.0.1-SNAPSHOT
...

Une fois que notre conteneur est dans la registry de votre projet GCP, il est temps de le faire tourner dans Cloud Run, pour cela retournez dans le service Cloud Run et cliquez sur Créer un service

Choisissez votre région, le nom de votre service et autorisez les appels non authentifiés afin d’exposer votre service comme une api public:

Sélectionnez ensuite votre conteneur précédemment upload et cliquez sur Créer

Une fois le service créé, vous avez une url disponible pour y accéder

Et voila, vous avez votre conteneur qui tourne sur le Cloud, sans avoir à manipuler ni Docker ni Kubernetes ni tout autres technologies liées aux conteneurs.

Nous venons de voir que Jib et Cloud Run fonctionnent bien de consort, nous allons maintenant voir qu’ils peuvent également travailler ensemble et automatiquement.

Pour cela il va d’abord falloir ajouter l’application Google Cloud Build à votre compte Github. Une fois ajoutée, il faut lui donner accès au repository contenant l’application générant votre conteneur avec Jib:

Une fois l’application activée sur votre repository, nous allons ajouter le fichier de configuration de Cloud Build dans le dossier .cloudbuild/cloudbuild-jib-maven.yaml.

Il y a trois étapes :

• Il va tout d’abord lié la configuration Docker de Cloud Build afin que Jib puisse l’utiliser
• Il va ensuite générer notre conteneur avec Jib
• Et enfin il va déployer notre nouveau conteneur dans Cloud Run

Et petite subtilité, nous allons commenter “image” et “credHelper” dans la configuration Maven de Jib car les identifiants sont configurés dans la première étape du build et l’image est configurée dans la seconde étape

Nous retournons ensuite dans la console de la GCP pour activer Cloud Build

Une fois activer, nous allons connecter notre repository Github à Cloud Build

Et on va ignorer la création d’un déclencheur, que nous allons faire juste après

Maintenant nous allons créer un déclencheur

Une fois ajouté, on peut tester notre déclencheur en cliquant sur “Exécuter le déclencheur”

Il ne reste plus qu’à tester votre déclencheur en faisant un push sur votre repository github, et vérifier que le build a réussi. Si jamais votre application n’est pas accessible depuis l’extérieur, il faut aller activer les appels non authentifiés une fois dans la configuration de votre service Cloud Run.

Si tout s’est bien passé, nous avons maintenant une chaine de ci/cd (très simple) qui permet de générer et déployer un conteneur sur le cloud sans avoir à manipuler Docker ou tout autres technologies liées aux conteneurs. Autre point interessant la facturation, pour une instance de conteneur donnée, le temps d’utilisation est facturé lorsque :

• l’instance de conteneur démarre ;
• une requête au moins est en cours de traitement par l’instance de conteneur.

Vous ne payez que le processeur et la mémoire alloués lorsqu’une requête est active sur une instance de conteneur, le total étant arrondi à la centaine de millisecondes la plus proche.

Si une instance de conteneur reçoit plusieurs requêtes en même temps, le temps facturable commence au démarrage du traitement de la première requête et se termine à la fin de la dernière requête, comme indiqué dans le schéma suivant :

Une instance de service Cloud Run peut supporter jusqu’à 80 appels concurrents, et Cloud Run démarre une nouvelle instance au-delà. Si le conteneur n’est pas utilisé il est éteint et n’est pas facturé. Il faut donc prendre en compte qu’il est possible d’avoir un démarrage à froid lors d’un première appel ou au démarrage d’une nouvelle instance.

Vous pouvez trouver sur mon Github l’ensemble du code et des configurations utilisées précédemment : https://github.com/Charon11/jib-demo