Cet article a pour but de montrer qu’OpenShift Online est un outil “developer friendly” permettant de déployer facilement dans le cloud.

A qui s’adresse cet article ?

• Je souhaite déployer mon microservice (Stateless) Spring Boot (ou autre) sur une plateforme cloud, ouverte, avec en prime un mécanisme de déploiement continu.
• Je ne connais rien (ou pas grand-chose), aux obscures technologies du monde “DevOps” tel que : Docker, Kubernetes.
• J’ai des sources sur Git, et je souhaite tout simplement déployer de manière automatisée, à chaque commit, sans écrire le moindre script !
• Je n’ai pas mis en place toute la stack d’industrialisation (Jenkins, GitLab CI)...
• Ce que j’aime c’est coder, la tuyauterie de déploiement, les serveurs ne m'intéressent pas !

PaaS, CaaS, IaaS, FaaS ?

Pour commencer un peu de vocabulaire ! On peut vite se sentir perdu avec tous ces acronymes en *aaS !

IaaS : Plateforme managée qui permet la gestion de Machines Virtuelles (VMs), fait abstraction des serveurs physiques.
CaaS : Plateforme managée qui permet le déploiement de conteneurs Docker, fait abstraction des VMs
PaaS : Plateforme managée qui permet le déploiement d’applications, fait abstraction de la notion de conteneur.
FaaS : Plateforme managée qui permet le déploiement de fonctions d’API, fait abstraction de la notion d’application. Pour en savoir plus sur ce sujet, je vous conseille de consulter les articles de notre blog sur le serverless : GHOST_URL/2017/10/10/how-to-do-serverless/

OpenShift

En deux mots, OpenShift est un PaaS OpenSource (https://github.com/openshift/origin) développé par RedHat. Il s’appuie sur l’orchestrateur Kubernetes et lui ajoute les fonctions inhérentes à une plateforme managée ; par exemple la gestion de build des conteneurs à partir des sources (Git) !
Il est donc possible de l’utiliser en tant que PaaS, mais aussi comme un CaaS (car OpenShift embarque Kubernetes).
Si on préfère construire les images dockers en dehors d’OpenShift, on pourra profiter ainsi du meilleur des deux mondes ! Dans ce cas, il faudra bien sûr adapter les images Docker pour les rendres conforme aux exigences de sécurité d’OpenShift (à savoir : les containers ne sont pas lancés avec le compte root!)

OpenShift OnLine

OpenShift Online est une version hébergée sur le cloud Amazon AWS par Red Hat. Ce service est accessible à tous gratuitement (plan Starter) avec les limitations suivantes :

• 1 Projet OpenShift
• 1 Go de RAM pour les Pods (Unité de base qui héberge un ou plusieurs conteneurs)
• 1 Go de stockage permanent
• 2 Pods.

Il existe aussi une offre pro dans OpenShift online à partir de 50$ / mois.

Ces limitations peuvent paraître importantes, par exemple il ne sera pas possible de déployer une application JHipster avec un front en raison de la consommation en RAM de la compilation et du packaging de la partie Angular. Mais rappelons tout de même que ce service est complètement gratuit !
Vous l’aurez compris, ce service “Starter” n’est absolument pas adapté à la production. Utilisez-le plutôt dans le cadre de vos POC, Lab, Tests…

S2I : Source 2 Image

Source To Image (S2I) est un mécanisme intégré à OpenShift qui permet de construire automatiquement des images Docker à partir des sources de votre application. Nous allons utiliser cette fonctionnalité dans notre exemple.
S2I fonctionne grâce à une image de base qui fournit deux scripts :
assemble qui est un script de construction de l’application
run qui est le script de démarrage de l’application

Par défaut OpenShift met à disposition des images S2I pour les principaux langages et frameworks (Java, Go, PHP, Ruby, Python)

En pratique, déployons notre microservice JHipster !

Création d’un compte OpenShift Online et d’un projet

• https://manage.openshift.com/accounts/auth/keycloak
• Choisir le plan : "Starter" ainsi que la région de déploiement (Pour l’instant US West ou Canada)
• Votre compte est en cours de provisioning !

• Vous pouvez accéder à la console OpenShift et créer votre premier projet !

• Accédez au dashboard de votre projet :

• Vous disposez maintenant d’un projet OpenShift dans lequel nous allons pouvoir déployer nos applications JHipster!

Déploiement d’un microservice JHipster

Le but de cet article n’est pas d’apprendre à créer un microservice JHipster (jetez un oeil ici : https://www.jhipster.tech/creating-microservices/). Nous partirons donc d’une application microservice générée par JHipster et disponible sur GitLab : https://gitlab.com/hufon/jhipster-demo-openshift-ms

Adaptation du build S2I

S2I est un mécanisme souple, il permet de construire des applications complexes. Il est donc possible de personnaliser le build Maven pour gérer les spécificités JHipster (notamment le fait que JHipster configure maven pour qu’il génère des .war, alors que le S2I SpringBoot attend un .jar).

On ajoute donc un fichier .s2i/environment avec le contenu suivant

JAVA_APP_JAR=jhopenshiftms-0.0.1-SNAPSHOT.war
ARTIFACT_COPY_ARGS=*.war
MAVEN_ARGS=-Pprod -DskipTests package

Vous avez la liste des configurations possibles sur : https://docs.openshift.com/online/using_images/s2i_images/java.html#s2i-images-java-configuration

Pour une application Spring Boot classique (qui génère un .jar au lieu d’un .war) il n’y a pas besoin de spécifier d’options. Si le besoin de construction devient plus spécifique, il est possible de construire sa propre image S2I.

Création de l’application



• Ajouter l’application en cliquant sur “Browse Catalog”
  

• Choisir parmis la liste : Redhat OpenJDK

• Renseigner le nom de l’application (ce nom sera utilisé dans la route d’accès) et l’URL du repository Git https://gitlab.com/hufon/jhipster-demo-openshift-ms.git

• Cliquez sur “Create”

• L’application est maintenant en cours de construction et est visible sur le dashboard

• Une fois construite l’application est déployée automatiquement

Et disponible sur l’url : http://jhipster-ms-ippon.7e14.starter-us-west-2.openshiftapps.com

Mettre en place du déploiement continu (avec GitLab) ?

Bien sûr, nous ne parlons pas ici d’une stack complète de CI/CD, mais on peut simplement déclencher un build et un déploiement à chaque push dans une branche et ce sans utiliser la partie CI de Gitlab.

Pour cela OpenShift nous fournit un WebHook à appeler pour lancer la construction et le déploiement.

• Pour récupérer l’URL du WebHook, aller dans “Builds -> Build -> Configuration”

• Côté GitLab : Rendez-vous dans “Settings -> Integrations”

Pour en savoir plus : https://docs.openshift.org/latest/dev_guide/migrating_applications/web_hooks_action_hooks.html

Ce mécanisme est bien sûr transposable pour d’autres forges git : (GitHub, Gogs)

Et sous le capot ?

Déployer une application dans OpenShift paraît simple, même magique, cependant il faut savoir que cette action déclenche la création de plusieurs objets Kubernetes :

• Un BuildConfig : Objet responsable de la construction de l’image Docker (porte l’URL du repository Git)
• Une ImageStream : Objet responsable du stockage de l’image Docker dans le repository d’OpenShift
• Un DeploymentConfig : Objet responsable du cycle de vie des Pods (par exemple pour effectuer une mise à jour en cas de mise à jour d’une image dans l’ImageStream)
• Un Service : Expose en interne un service sur une adresse et un port TCP (en faisant du load balancing s’il y a plusieurs Pods)
• Une Route : permet d’exposer un service en HTTP vers l’extérieur

Aller plus loin ?

Grâce à cette introduction, vous savez maintenant comment tester rapidement un déploiement dans le cloud. Malheureusement, la démarche décrite ne convient pas pour le passage à l’échelle, où il faudra se familiariser avec Docker, Kubernetes, les templates OpenShift et déployer une vraie stack CI/CD. L’intérêt d’OpenShift est qu’il saura s’adapter à ces situations, et sera toujours plus accessible que Kubernetes “from scratch”.

En espérant avoir donné le goût de creuser le sujet !