Créer une API dans OpenShift

OpenShift est une plateforme en tant que service (PaaS) développée par RedHat qui permet de faire de la gestion et de l’orchestration de conteneurs. Pour y parvenir, OpenShift utilise Kubernetes et Docker.

Mais… Sylvain, pourquoi ne pas utiliser Kubernetes et Docker et ne pas aller vers une solution propriétaire?

OpenShift est supporté par RedHat. Il sera donc possible d’avoir du support de qualité rapidement. De plus, la plateforme offre des outils assez complets et simples à comprendre. Et, aujourd’hui, on va voir comment on peut déployer une API RESTful en Node dans OpenShift.

Étape 1 – Créer un compte RedHat avec une license d’essai Cloud d’OpenShift.

Cette étape devrait être assez simple, suivez simplement les instructions sur le site d’OpenShift.

Étape 2 – Installer le CLI OpenShift.

Le client OpenShift permet de faire des opérations directement dans votre cloud OpenShift depuis une invite de commande. C’est avec ce client qu’on va créer les entités nous permettant de déployer l’application.

Vous trouverez le lien d’installation dans le guide utilisateur.

Étape 3 – Créer l’application dans Git

Pour les besoins de cet article, j’ai créé un service qui retourne l’heure. Rien de bien compliqué, mais si vous n’avez pas de connaissance Node JS, je vous invite à lire cet article.

En gros, il n’y a pas grand chose à prévoir au niveau organique pour le déploiement dans OpenShift. Nous avons simplement besoin d’une application Node normale. Pour l’exécution, on va utiliser les scripts npm.

Pour suivre, récupérer le code déjà fait sur notre compte GitLab.

Si vous voulez l’exécuter localement, suivez les instructions du README.md. Pour cet exercice, vous pouvez utiliser directement notre dépôt Git.

Étape 4 – Authentifier le client

Lorsque votre cloud OpenShift est prêt, vous devriez recevoir un courriel avec une URL pour atteindre votre interface d’administration. Dans le haut à droite, cliquez sur votre nom et choisir « Copy login command » et copier la commande qui s’affiche. Elle devrait ressembler à :

Si vous collez cette commande dans une invite, ceci devrait vous créer une session locale pour le client OpenShift.

Étape 5 – Créer le flux d’image Docker

Le flux d’image Docker sert à définir où OpenShift ira déposer l’image construite par la configuration de Build (voir prochaine section). Pour cet article, nous utiliserons le dépôt docker public.

Pour débuter, rendez-vous sur le docker hub pour créer un compte et un dépôt. Créer un dépôt public pour fins de simplicité.

Puis, à la racine du projet de GitLab à l’étape 3, créer un fichier image-stream.yml. Le nom peut être ce que vous voulez :

Ici, rien de bien compliqué. Le metadata namespace correspond au namespace OpenShift dans lequel se trouve votre projet. La propriété lookupPolicy, quant à elle, sert à dire à OpenShift que l’image se trouve sur un dépôt externe. En effet, OpenShift a un dépôt d’images offert à leurs utilisateurs, donc si on veut utiliser le docker hub, il faut lui spécifier le dockerImageRepository externe (que vous devrez changer pour le votre!)

Une fois le yaml créé, exécuter :

Vous devriez voir :

Étape 6 – Créer la configuration de Build

Une fois le flux d’image créé, il nous faut définir une configuration pour la construction de l’image. Le build a la responsabilité de lire un dépôt (par exemple), de lancer la compilation de l’image, puis de la publier sur le flux d’image. Voici le yaml à créer. Nommez-le build-config.yml :

On peut voir ici dans les spec qu’il y a un output de définit à notre stream d’image. Le nom est le même que celui définit dans image-stream.yml à l’étape 5. Au niveau du paramètre source, simplement configurer l’URL vers le dépôt et spécifier la branche sous ref (ici, master). Ceci correspond au dépôt du code de l’application.

Au niveau du sourceStrategy, ce paramètre correspond à l’image de base sur laquelle sera construite notre application. Ici, c’est une image node js de base offerte sur le dépôt d’image d’OpenShift.

Exécuter :

Étape 7 – Créer la configuration de déploiement

Dernier point avant de lancer un build en bonne et due forme, c’est créer le plan de déploiement du pod de l’application. Pour se faire, créer un deploy.yml qui servira à définir le flux d’image Docker à utiliser ainsi que les configurations de base du pod, telles que le nombre de réplique ou des variables d’environnement.

Sous spec, nous avons le nombre de réplique à lever par défaut avec la propriété replicas. Sous template, puis spec, on peut voir le lien vers l’image Docker créée par la configuration de build. Vous pouvez aussi voir sous template, spec et port le numéro du port à ouvrir sur le pod pour accepter des connexions.

Un dernier point sur lequel je voudrais attirer votre attention est au niveau des triggers à la fin du fichier. En gros, OpenShift va écouter sur le flux d’image et lancer un déploiement dès qu’une nouvelle version est disponible. Sachez que, dans cet exemple, le build est lancé manuellement, mais au aurait pu configurer un trigger au niveau de Git pour lancer le build automatique lorsqu’une branche est modifiée.

Exécuter :

Étape 8 – Exposer le pod derrière un service

Le service dans OpenShift nous sert à exposer un pod. Dans notre cas, il sera assez simple et ne fera que rediriger les connexions du port 80 vers le port de notre pod 3000.

Créer un fichier yaml service.yml :

Je crois qu’il s’explique de lui-même, exécuter simplement :

Étape 9 – Exposition du service via une route

La route va nous servir à permettre l’accès à notre service via un nom de domaine. OpenShift fourni des noms pour vous si vous n’en avez pas un. Créer simplement un route.yml :

Encore une fois, très simple, la route / va pointer sur notre service blog-ezo-openshift créé à l’étape 8.

Exécuter :

Étape 10 – Lancer le build

Dans l’interface d’OpenShift web, rendez-vous sous Build > Build Config. Cliquez sur votre build, puis dans le haut de la page, vous devriez voir Action > Start Build.

C’est tout!

Conclusion

Donc, si on résume comment tout ça fonctionne ensemble, ça commence par une application normale sur un Git, puis un pod de génération d’image Docker va récupérer le code, le construire sous forme d’image Docker et pousser l’image sur un dépôt. Dans OpenShift, le plan de déploiement de l’application écoute en permanence sur le flux d’image et s’exécute dès qu’une nouvelle version est disponible. Il crée le/les pods selon les configurations.

Pour atteindre ce pod, l’utilisateur passe par un répartiteur de charge dans OpenShift qui redirige vers le service qui va répartir la charge dans le cluster de pod de notre application.

Si vous avez aimé, prenez le temps de partager et de commenter pour me le laisser savoir 🙂 Je pourrais couvrir un peu plus large sur OpenShift ou même vous montrer comment déployer d’autres types d’application.

Cheers!