Ce message a été écrit parce que notre personnel a eu de nombreuses conversations avec des clients sur le développement d'applications sur Kubernetes et les spécificités d'un tel développement sur OpenShift.
Nous partons généralement de 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, axés sur un public cible particulier. 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 sortie comme "Écoutez, peu importe où vous exécutez le code, sur OpenShift ou sur AKS, sur EKS, sur certains Kubernetes personnalisés, oui sur n'importe quel Kubernetes (appelons-le KUK en abrégé) "C'est vraiment simple, là-bas et là-bas."
Ensuite, nous avons prévu de prendre le "Hello World" le plus simple et de l'utiliser pour montrer ce qui est commun et quelles sont les différences entre la CMC et la 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 que nous ne réalisons tout simplement pas comment il s'est développé et s'est transformé en une plateforme incroyable qui est devenue bien plus qu'une simple distribution Kubernetes. Nous avons tendance à tenir pour acquis la maturité et la simplicité d'OpenShift, tout en négligeant sa magnificence.
En général, le moment est venu de se repentir activement, 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 le plus objectivement possible (enfin, sauf parfois en montrant un personnel rapport au sujet). Si vous êtes intéressé par un avis purement subjectif sur cette question, alors vous pouvez le lire . Et dans cet article, nous nous en tiendrons aux faits et uniquement aux faits.
Clusters
Ainsi, notre "Hello World" a besoin de clusters. Disons simplement "non" à tous les clouds publics, afin de ne pas payer pour les serveurs, les registres, les réseaux, le transfert de données, etc. En conséquence, nous choisissons un cluster simple à un nœud sur (pour KUK) et (pour un cluster OpenShift). Ces deux options sont vraiment faciles à installer, mais nécessitent beaucoup de ressources sur votre ordinateur portable.
Montage sur KUK-e
Alors, allons-y.
Étape 1 - Construire notre image de conteneur
Commençons par déployer notre "Hello World" sur minikube. Cela nécessitera :
- 1. Docker installé.
- 2. Git installé.
- 3. Maven installé (en fait, ce projet utilise le binaire mvnw, vous pouvez donc vous en passer).
- 4. En fait, la source elle-même, c'est-à-dire cloner le dépôt
La première étape consiste à créer un projet Quarkus. N'ayez pas peur si vous n'avez jamais utilisé Quarkus.io - c'est facile. Vous sélectionnez simplement les composants que vous souhaitez utiliser dans le projet (RestEasy, Hibernate, Amazon SQS, Camel, etc.), puis Quarkus lui-même, sans aucune de votre participation, configure l'archétype maven et met le tout sur github. Autrement dit, littéralement un clic de souris - et vous avez terminé. C'est pourquoi nous aimons Quarkus.
Le moyen le plus simple de créer notre "Hello World" dans une image conteneurisée consiste à utiliser les extensions quarkus-maven pour Docker, qui effectueront tout le travail nécessaire. 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 des commandes maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Et 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 exécutée dans l'environnement d'exécution du conteneur.
./mvnw -X clean package -Dquarkus.container-image.build=true
En fait, c'est tout, vous pouvez maintenant exécuter le conteneur avec la commande docker run, après avoir mappé notre service sur le port 8080 afin qu'il soit accessible.
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 - Soumettre notre conteneur au référentiel d'images de conteneurs
Pour l'instant, 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, nous devons la placer dans un autre référentiel. Kubernetes n'a pas ces fonctionnalités, nous allons donc utiliser dockerhub. Parce que, premièrement, c'est gratuit, et deuxièmement, (presque) tout le monde le fait.
C'est aussi très simple, et seul un compte dockerhub est nécessaire ici.
Donc, nous installons dockerhub et y envoyons notre image.
Étape 3 - Démarrer Kubernetes
Il existe de nombreuses façons de mettre en place une configuration kubernetes pour exécuter notre "Hello World", mais nous utiliserons la plus simple d'entre elles, car nous sommes de telles personnes ...
Tout d'abord, nous démarrons le cluster minikube :
minikube start
Étape 4 - Déploiement de notre image de conteneur
Nous devons maintenant convertir notre code et notre image de conteneur en configuration kubernetes. En d'autres termes, nous avons besoin d'un pod et d'une définition de déploiement pointant vers notre image de conteneur sur dockerhub. L'un des moyens les plus simples de procéder consiste à 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 dit à notre COOK 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 minikube et créera un déploiement qui téléchargera notre image de conteneur et exécutera un 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 y a plusieurs façons ici. Par exemple, vous pouvez utiliser la commande expose pour créer automatiquement les composants Kubernetes appropriés tels que les services et les points de terminaison. En fait, c'est ce que nous allons faire en exécutant la commande expose 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 expose.
Lorsque nous exposons et créons les composants nécessaires à l'exécution de notre service, nous devons, entre autres, pouvoir nous connecter de l'extérieur au service hello-quarkus qui se trouve à l'intérieur de notre réseau défini par logiciel. Et 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, écrire type=Équilibreur de charge, nous initialisons automatiquement l'équilibreur de charge du cloud public pour se connecter à notre cluster Kubernetes. Ceci, bien sûr, est formidable, mais vous devez comprendre qu'une telle configuration sera étroitement 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 type=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 l'équilibreur de charge NGINX dans notre cluster.
Étape 6 - Configurer un équilibreur de charge
minikube dispose d'un certain nombre de fonctionnalités de plate-forme qui facilitent la création des composants dont vous avez besoin pour l'accès externe, tels que les contrôleurs d'entrée. Minikube est livré avec le contrôleur d'entrée Nginx, et tout ce que nous avons à faire est 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 à l'intérieur de notre cluster minikube :
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Étape 7 - Configurer l'entrée
Nous devons maintenant configurer le contrôleur d'entrée Nginx pour accepter les requêtes hello-quarkus.
Et enfin, nous devons appliquer cette configuration.
kubectl apply -f ingress.yml
Puisque nous faisons tout cela sur notre propre machine, nous ajoutons simplement l'adresse IP de notre nœud au fichier /etc/hosts pour diriger les requêtes http vers notre minikube vers l'équilibreur de charge NGINX.
192.168.99.100 hello-quarkus.info
Ça y est, maintenant notre service minikube est disponible de l'extérieur via le contrôleur d'entrée Nginx.
Eh bien, c'était facile, non ? Ou pas tellement ?
Exécuter sur OpenShift (conteneurs prêts pour le code)
Et maintenant, voyons comment tout cela se passe sur Red Hat OpenShift Container Platform (OCP).
Comme dans le cas de minikube, nous choisissons un schéma avec un cluster OpenShift à nœud unique sous la forme de Code Ready Containers (CRC). Il s'appelait auparavant minishift et était basé sur le projet OpenShift Origin, mais maintenant c'est CRC et construit sur la plate-forme de conteneur OpenShift de Red Hat.
Ici, désolé, nous ne pouvons pas 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, c'est comme ça. Mais en train d'écrire ce billet, on s'est souvenu du nombre de mouvements inutiles qu'il faut faire quand on n'a pas OpenShift, et donc, encore une fois, c'est beau. Nous aimons que les choses soient simples, et la facilité avec laquelle il est possible de déployer et d'exécuter notre exemple sur OpenShift par rapport à minikube est ce qui nous a inspiré pour écrire cet article.
Passons en revue le processus et voyons ce que nous devons faire.
Donc dans l'exemple minikube, nous avons commencé avec Docker… Attendez, nous n'avons plus besoin de Docker installé sur la machine.
Et nous n'avons pas besoin d'un git local.
Et Maven n'est pas nécessaire.
Et vous n'avez pas besoin de créer une image de conteneur à la main.
Et vous n'avez pas besoin 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.
Est-ce que tu comprends? Pour déployer et exécuter notre application sur OpenShift, rien de ce qui précède n'est nécessaire. Et le processus lui-même est le suivant.
Étape 1 - Démarrage de votre cluster OpenShift
Nous utilisons Code Ready Containers de Red Hat, qui est essentiellement le même Minikube, mais uniquement avec un cluster Openshift complet à nœud unique.
crc start
Étape 2 - Créer 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 plusieurs façons d'exécuter une application sur un cluster. Et, comme dans le cas de KUK, nous choisissons spécifiquement le plus simple.
OpenShift a toujours été conçu comme une plate-forme pour créer et exécuter des applications conteneurisées. La construction de conteneurs a toujours fait partie intégrante de cette plate-forme, il existe donc un tas de ressources Kubernetes supplémentaires pour les tâches correspondantes.
Nous utiliserons le processus Source 2 Image (S2I) d'OpenShift, qui propose plusieurs façons différentes de prendre notre source (code ou binaires) et de la transformer en une image conteneurisée qui s'exécute sur un cluster OpenShift.
Pour cela, nous avons besoin de deux choses :
- Notre code source dans le dépôt git
- Builder-image, sur la base de laquelle l'assemblage sera effectué.
Il existe de nombreuses images de ce type, maintenues à la fois par Red Hat et par la communauté, et nous utiliserons l'image OpenJDK, eh bien, puisque je construis une application Java.
Vous pouvez exécuter une génération S2I à la fois depuis la console graphique OpenShift Developer et depuis la ligne de commande. Nous utiliserons la commande new-app, en lui indiquant où obtenir l'image du constructeur et notre code source.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Ça y est, notre application est créée. Ce faisant, le processus S2I a effectué les choses suivantes :
- Création d'un module de construction de service pour toutes sortes de choses liées à la construction de l'application.
- Création d'une configuration OpenShift Build.
- J'ai téléchargé l'image du générateur dans le registre interne du docker OpenShift.
- Cloné "Hello World" dans le référentiel local.
- J'ai vu qu'il y avait un maven pom là-dedans et j'ai donc compilé l'application avec maven.
- Création d'une nouvelle image de conteneur contenant l'application Java compilée et mise de cette image dans le registre de conteneurs interne.
- Création d'un déploiement Kubernetes avec des spécifications pour un pod, un service, etc.
- Lancement de l'image du conteneur de déploiement.
- Service build-pod supprimé.
Il y a beaucoup sur cette liste, mais l'essentiel est que toute la construction se déroule exclusivement dans OpenShift, le registre Docker interne se trouve dans OpenShift et le processus de construction crée tous les composants Kubernetes et les exécute sur le cluster.
Si vous surveillez visuellement le lancement de S2I dans la console, vous pouvez voir comment le module de génération est lancé pendant la génération.
Et maintenant, jetons un coup d'œil aux journaux du pod de construction : premièrement, vous pouvez voir comment maven fait son travail et télécharge les dépendances pour construire notre application java.
Une fois la construction maven terminée, la construction de l'image du conteneur est lancée, puis cette image construite est envoyée au référentiel interne.
Tout, le processus d'assemblage est terminé. Vérifions maintenant que les pods et les services de notre application ont démarré dans le cluster.
oc get service
C'est tout. Et une seule équipe. Tout ce que nous avons à faire est d'exposer ce service pour un accès extérieur.
Étape 3 - exposer le service pour un accès depuis l'extérieur
Comme dans le cas de KUK, sur la plate-forme OpenShift, notre "Hello World" a également besoin d'un routeur pour diriger le trafic externe vers un service à l'intérieur du cluster. Dans OpenShift, cela rend les choses très faciles. Premièrement, le composant de routage HAProxy est installé dans le cluster par défaut (il peut être changé pour le même NGINX). Deuxièmement, il existe des ressources spéciales et hautement configurables appelées Routes, qui rappellent les 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 nous suffit sans configuration supplémentaire.
Pour créer un FQDN routable pour "Hello World" (oui, OpenShiift a son propre DNS pour le routage par noms 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
Et enfin, nous accédons à notre service depuis le navigateur :
Mais maintenant c'était vraiment facile !
Nous aimons Kubernetes et tout ce que cette technologie 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 mettre les applications en production aujourd'hui. C'est là qu'OpenShift entre en jeu, en suivant l'évolution du temps et en proposant des Kubernetes centrés sur les développeurs. De nombreux 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, Developer Portal, OpenShift Operator Framework, intégration IDE, catalogues de développeurs, 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, des matériaux et d'autres choses utiles pour développer sur la plate-forme OpenShift sur le portail .
Source: habr.com