Désolé OpenShift, nous ne vous avons pas suffisamment apprécié et ne vous avons pas pris pour acquis

Cet article a été rédigé parce que nos employés ont eu beaucoup de conversations avec les clients sur le développement d'applications sur Kubernetes et sur les spécificités d'un tel développement sur OpenShift.







Nous commençons généralement par la thèse selon laquelle Kubernetes n'est que Kubernetes et OpenShift est déjà une plate-forme Kubernetes, comme Microsoft AKS ou Amazon EKS. Chacune de ces plateformes a ses propres avantages, centrés sur l'un ou l'autre public cible. Et après cela, la conversation débouche déjà sur une comparaison des forces et des faiblesses de plates-formes spécifiques.



En général, nous avons pensé écrire ce post avec une conclusion comme «Écoutez, peu importe où exécuter le code, sur OpenShift ou sur AKS, sur EKS, sur certains Kubernetes personnalisés, ou sur n'importe quel Kubernetes (pour faire court , appelons-le KUK) est vraiment simple, ici et là. "



Ensuite, nous avons prévu de prendre le plus simple "Hello World" et, à l'aide de son exemple, de montrer ce qui est commun et quelles sont les différences entre KUK et Red Hat OpenShift Container Platform (ci-après, OCP ou simplement OpenShift).



Cependant, au cours de la rédaction de cet article, nous avons réalisé que nous étions tellement habitués à utiliser OpenShift pendant si longtemps et à tel point que nous ne réalisons tout simplement pas à quel point il a grandi et s'est transformé en une plate-forme incroyable qui est devenue bien plus qu'une simple distribution Kubernetes. Nous sommes habitués à prendre la maturité et la simplicité d'OpenShift pour acquises tout en perdant de vue son éclat.



En général, le moment est venu pour la repentance active, et maintenant nous allons comparer étape par étape la mise en service de notre "Hello World" sur KUK et sur OpenShift, et nous le ferons aussi objectivement que possible (enfin, en montrant peut-être parfois une attitude personnelle sur le sujet). Si vous êtes intéressé par une opinion purement subjective sur cette question, vous pouvez la lire ici (EN) . Dans cet article, nous nous en tiendrons uniquement aux faits et aux faits.

Clusters

Donc, notre "Hello World" a besoin de clusters. Disons non à tous les clouds publics, pour ne pas payer pour les serveurs, registres, réseaux, transfert de données, etc. En conséquence, nous choisissons un simple cluster à nœud unique sur Minikube (pour KUK) et des conteneurs Code Ready (pour OpenShift cluster). Ces deux options sont vraiment faciles à installer, mais nécessiteront beaucoup de ressources sur votre ordinateur portable.

Montage sur KUK-e

Alors allons-y.

Étape 1 - Construire notre image de conteneur

Je vais commencer par déployer notre "Hello World" sur minikube. Cela nécessitera:

1. 1. Docker installé.
2. 2. Installé Git.
3. 3. Installé Maven (en fait ce projet utilise le binaire mvnw, vous pouvez donc vous en passer).
4. 4. En fait, la source elle-même, c'est-à-dire clone du référentiel github.com/gcolman/quarkus-hello-world.git

La première étape consiste à créer un projet Quarkus. Ne vous inquiétez pas si vous n'avez jamais travaillé avec Quarkus.io - c'est facile. Il vous suffit de sélectionner les composants que vous souhaitez utiliser dans le projet (RestEasy, Hibernate, Amazon SQS, Camel, etc.), puis Quarkus lui-même, sans votre participation, configure l'archétype maven et télécharge tout sur github. Autrement dit, littéralement un clic de souris - et vous avez terminé. C'est pourquoi nous aimons Quarkus.







La façon la plus simple de créer notre "Hello World" dans une image de conteneur est d'utiliser les extensions Docker quarkus-maven, qui feront tout le travail. Avec l'avènement de Quarkus, cela est devenu vraiment facile et simple: ajoutez l'extension container-image-docker et vous pouvez créer des images avec les commandes maven.

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

Enfin, nous construisons notre image en utilisant Maven. En conséquence, notre code source se transforme en une image de conteneur prête à l'emploi qui peut déjà être lancée dans le runtime du conteneur.

./mvnw -X clean package -Dquarkus.container-image.build=true

En fait, c'est tout, maintenant vous pouvez démarrer le conteneur avec la commande docker run, après avoir mappé notre service sur le port 8080 afin que vous puissiez y accéder.

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

Une fois l'instance de conteneur démarrée, il ne reste plus qu'à vérifier avec la commande curl que notre service est en cours d'exécution:







Donc tout fonctionne et c'était vraiment facile et simple.

Étape 2 - Pousser notre conteneur vers le référentiel d'images du conteneur

Jusqu'à présent, l'image que nous avons créée est stockée localement, dans notre stockage de conteneur local. Si nous voulons utiliser cette image dans notre environnement KUK, elle doit être placée dans un autre référentiel. Kubernetes n'a pas de telles fonctionnalités, nous allons donc utiliser dockerhub. Parce que, d'une part, c'est gratuit, et d'autre part, (presque) tout le monde le fait.



C'est également très simple et vous n'avez besoin que d'un compte dockerhub.



Donc, nous installons dockerhub et y envoyons notre image.

Étape 3 - Lancement de Kubernetes

Il existe de nombreuses façons de construire la configuration kubernetes pour exécuter notre Hello World, mais nous utiliserons la plus simple d'entre elles, nous sommes le genre de personnes que nous sommes ...



Tout d'abord, démarrez le cluster minikube:

minikube start

Étape 4 - Déployer notre image de conteneur

Nous devons maintenant transformer notre code et notre image de conteneur dans la configuration de kubernetes. En d'autres termes, nous avons besoin d'un pod et d'une définition de déploiement avec une indication de notre image de conteneur sur dockerhub. L'un des moyens les plus simples de le faire est d'exécuter la commande create deployment pointant vers notre image:

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

Avec cette commande, nous avons demandé à notre KUK de créer une configuration de déploiement qui devrait contenir la spécification de pod pour notre image de conteneur. Cette commande appliquera également cette configuration à notre cluster de minikube et créera un déploiement qui télécharge notre image de conteneur et démarre le pod sur le cluster.

Étape 5 - Accès ouvert à notre service

Maintenant que nous avons une image de conteneur déployée, il est temps de réfléchir à la façon de configurer l'accès externe à ce service Restful, qui, en fait, est programmé dans notre code.



Il existe de nombreuses manières. Par exemple, vous pouvez utiliser la commande exposer pour créer automatiquement les composants Kubernetes appropriés tels que les services et les points de terminaison. En fait, c'est exactement ce que nous allons faire en exécutant la commande exposer pour notre objet de déploiement:

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

Arrêtons-nous un instant sur l'option "- type" de la commande exposer.



Lorsque nous exposons et créons les composants nécessaires pour exécuter notre service, nous voulons, entre autres, pouvoir nous connecter de l'extérieur au service hello-quarkus qui se trouve à l'intérieur de notre SDN. Et le paramètre type nous permet de créer et de connecter des éléments tels que des équilibreurs de charge pour acheminer le trafic vers ce réseau.



Par exemple, en écrivant type = LoadBalancer, nous initialiserons automatiquement l'équilibreur de charge dans le cloud public pour nous connecter à notre cluster Kubernetes. Ceci, bien sûr, est excellent, mais vous devez comprendre qu'une telle configuration sera strictement liée à un cloud public spécifique et qu'il sera plus difficile de la transférer entre des instances Kubernetes dans différents environnements.



Dans notre exemple, tapez = NodePort , c'est-à-dire que l'appel à notre service passe par l'adresse IP du nœud et le numéro de port. Cette option vous permet de ne pas utiliser de clouds publics, mais nécessite un certain nombre d'étapes supplémentaires. Tout d'abord, vous avez besoin de votre propre équilibreur de charge, nous allons donc déployer un équilibreur de charge NGINX dans notre cluster.

Étape 6 - Installez l'équilibreur de charge

Minikube dispose d'un certain nombre de fonctions de plate-forme qui facilitent la création des composants nécessaires à l'accès externe, tels que les contrôleurs d'entrée. Minikube est livré avec le contrôleur d'entrée Nginx, et il nous suffit de l'activer et de le configurer.

minikube addons enable ingress

Maintenant, avec une seule commande, nous allons créer un contrôleur d'entrée Nginx qui fonctionnera dans notre cluster de minikube:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

Étape 7 - Configuration d'Ingress

Nous devons maintenant configurer le contrôleur d'entrée Nginx pour accepter les requêtes hello-quarkus.











Enfin, nous devons appliquer cette configuration.

kubectl apply -f ingress.yml

Puisque nous faisons tout cela sur notre ordinateur, nous ajoutons simplement l'adresse IP de notre nœud au fichier / etc / hosts pour acheminer les requêtes http vers notre minikube vers l'équilibreur de charge NGINX.

192.168.99.100 hello-quarkus.info

Voilà, maintenant notre service minikube est accessible de l'extérieur via le contrôleur d'entrée Nginx.

Eh bien, c'était facile, non? Ou pas vraiment?

Lancer sur OpenShift (conteneurs prêts pour le code)

Voyons maintenant comment tout est fait sur Red Hat OpenShift Container Platform (OCP).



Comme pour le minikube, nous choisissons un schéma avec un cluster OpenShift à nœud unique sous la forme de Code Ready Containers (CRC). Il s'appelait autrefois minishift et était basé sur le projet OpenShift Origin, mais il s'agit maintenant d'un CRC et est construit sur OpenShift Container Platform de Red Hat.



Ici, désolé, nous ne pouvons nous empêcher de dire: "OpenShift est génial!"



Au départ, nous pensions écrire que le développement sur OpenShift n'est pas différent du développement sur Kubernetes. Et en fait, il en est ainsi. Mais en écrivant cet article, nous nous sommes souvenus du nombre de mouvements inutiles que vous devez effectuer lorsque vous n'avez pas OpenShift, et donc, encore une fois, c'est merveilleux. Nous adorons quand tout est facile, et comme c'est facile par rapport à minikube, notre exemple est déployé et exécuté sur OpenShift, en fait, cela nous a incité à écrire ce post.



Passons en revue le processus et voyons ce que nous devons faire.



Donc, dans l'exemple du minikube, nous avons commencé avec Docker ... Stop, nous n'avons plus besoin d'installer Docker sur la machine.



Et nous n'avons pas besoin de git local.

Et Maven n'est pas nécessaire.

Et vous n'avez pas à créer une image de conteneur avec vos mains.

Et il n'est pas nécessaire de rechercher un référentiel d'images de conteneurs.

Et vous n'avez pas besoin d'installer un contrôleur d'entrée.

Et vous n'avez pas non plus besoin de configurer l'entrée.



Vous comprenez, non? Vous n'avez besoin d'aucun des éléments ci-dessus pour déployer et exécuter notre application sur OpenShift. Et le processus lui-même ressemble à ceci.

Étape 1 - Lancement de votre cluster OpenShift

Nous utilisons des conteneurs Code Ready de Red Hat, qui est essentiellement le même Minikube, mais uniquement avec un cluster OpenShift à nœud unique à part entière.

crc start

Étape 2 - Construire et déployer l'application sur le cluster OpenShift

C'est à cette étape que la simplicité et la commodité d'OpenShift se manifestent dans toute sa splendeur. Comme pour toutes les distributions Kubernetes, nous avons de nombreuses façons d'exécuter une application sur un cluster. Et, comme dans le cas de KUK, nous choisissons délibérément le plus simple.



OpenShift a toujours été conçu comme une plate-forme pour créer et exécuter des applications conteneurisées. La création de conteneurs a toujours fait partie intégrante de cette plate-forme, il existe donc de nombreuses ressources Kubernetes supplémentaires pour les tâches associées.



Nous utiliserons le processus OpenShift Source 2 Image (S2I), qui dispose de plusieurs façons différentes de prendre notre source (code ou binaires) et de la transformer en une image de conteneur qui s'exécute sur un cluster OpenShift.



Pour cela, nous avons besoin de deux choses:

• Notre code source dans le référentiel git
• Image du constructeur sur la base de laquelle la construction sera effectuée.

Il existe de nombreuses images de ce type, maintenues à la fois par Red Hat et au niveau de la communauté, et nous utiliserons l'image OpenJDK, puisque je construis une application Java.



Vous pouvez démarrer la génération S2I à la fois à partir de la console graphique OpenShift Developer et à partir de la ligne de commande. Nous utiliserons la commande new-app pour lui indiquer où obtenir l'image du générateur et notre code source.

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

Ca y est, notre application a été créée. Ce faisant, le processus S2I a fait les choses suivantes:

• Création d'un module de construction de service pour toutes sortes de choses liées à la création de l'application.
• Création de la configuration OpenShift Build.
• Téléchargement de l'image du générateur dans le registre Docker interne d'OpenShift.
• Cloné "Hello World" dans le référentiel local.
• J'ai vu qu'il y avait un pom maven là-dedans et j'ai donc compilé l'application en utilisant maven.
• Création d'une nouvelle image de conteneur contenant l'application Java compilée et mise en place de cette image dans le registre de conteneurs interne.
• Création d'un déploiement Kubernetes avec des spécifications de pod, un service, etc.
• Lancement du déploiement de l'image du conteneur.
• Suppression du build-pod de service.

Il y a beaucoup de choses dans cette liste, mais l'essentiel est que toute la construction se déroule exclusivement dans OpenShift, le registre Docker interne est à l'intérieur d'OpenShift et le processus de construction crée tous les composants Kubernetes et les exécute dans le cluster.



Si vous suivez visuellement le lancement de S2I dans la console, vous pouvez voir comment le module de construction est lancé pendant la construction.







Jetons maintenant un œil aux logs du pod builder: tout d'abord, il montre comment maven fait son travail et télécharge les dépendances pour construire notre application java.







Une fois la génération maven terminée, la génération de l'image de conteneur est lancée, puis cette image générée est poussée vers le référentiel interne.







Voilà, le processus d'assemblage est terminé. Assurez-vous maintenant que les pods et services de notre application s'exécutent dans le cluster.

oc get service

C'est tout. Et juste une équipe. Il suffit d'exposer ce service pour un accès externe.

Étape 3 - Exposez le service pour un accès externe

Comme dans le cas de KUK, sur la plateforme OpenShift, notre «Hello World» a également besoin d'un routeur pour diriger le trafic externe vers un service au sein du cluster. OpenShift rend cela très facile. Tout d'abord, le composant de routage HAProxy est installé dans le cluster par défaut (vous pouvez le changer pour le même NGINX). Deuxièmement, il existe des ressources spéciales et hautement configurables appelées Routes, qui ressemblent aux objets Ingress dans le bon vieux Kubernetes (en fait, les Routes d'OpenShift ont fortement influencé la conception des objets Ingress, qui peuvent désormais être utilisés dans OpenShift) , mais pour notre "Hello World", et dans presque tous les autres cas, la Route standard sans configuration supplémentaire nous suffit.



Pour créer un FQDN routable pour "Hello World" (oui, OpenShiift a son propre DNS pour le routage par nom de service), nous exposons simplement notre service:

oc expose service quarkus-hello-world

Si vous regardez la route nouvellement créée, vous pouvez y trouver le FQDN et d'autres informations de routage:

oc get route

Enfin, nous accédons à notre service depuis le navigateur:

Maintenant, c'était vraiment facile!

Nous aimons Kubernetes et tout ce que la technologie nous permet de faire, et nous aimons aussi la simplicité et la légèreté. Kubernetes a été conçu pour rendre les conteneurs distribués et évolutifs incroyablement faciles à utiliser, mais sa simplicité ne suffit plus pour déployer des applications. Et c'est là qu'OpenShift entre en jeu, qui suit le rythme et propose des Kubernetes, axés principalement sur le développeur. Beaucoup d'efforts ont été investis pour personnaliser la plate-forme OpenShift spécifiquement pour le développeur, y compris la création d'outils tels que S2I, ODI, portail de développement, OpenShift Operator Framework, intégration IDE, catalogues de développeur, intégration Helm, surveillance et bien d'autres.



Nous espérons que cet article vous a été intéressant et utile. Et vous pouvez trouver des ressources supplémentaires, du matériel et d'autres éléments utiles pour le développement sur la plateforme OpenShift sur le portail Red Hat Developers .