Gardez vos poissons au chaud: architecture pilotée par les événements sur OpenShift

Typiquement, l'idée d'orchestration de conteneurs est associée à DevOps, et bien que les services informatiques aient rapidement adopté la technologie pour OPS, la partie développement a été mal comprise et sous-estimée. Avec la gamme d'outils OpenShift à la disposition des développeurs, il est temps de livrer sur le principe de DevOps et de redonner de l'énergie aux développeurs.

Les codeurs aiment coder, mais la plupart préfèrent passer plus de temps à construire des trucs sympas qu'à les gaspiller sur passe-partout. C’est pourquoi nous utilisons des frameworks. Par exemple, lorsque nous démarrons un projet, nous voulons y aller directement au lieu d'apprendre à configurer un cluster Elasticsearch.

Les grandes organisations vous demandent de créer des tickets informatiques et d'attendre le provisionnement, qui peut être un obstacle majeur. Parfois, c'est parce que l'informatique est très occupée. Parfois, c'est parce qu'ils ne savent pas comment approvisionner ces choses, et parfois c'est parce qu'ils sont préoccupés par la sécurité.

L'autre aspect important de l'adoption de conteneurs est que les programmeurs peuvent avoir l'impression qu'ils doivent tout apprendre sur Docker ou utiliser une langue différente de celle qu'ils connaissent. .

Pour cet exercice, nous n'allons pas construire un monde bonjour simple, exécuter un microservice sur un scénario de type OpenShift car cela n'illustrerait pas ces points. Nous allons créer une application sophistiquée avec beaucoup de pièces mobiles qui offre une vraie valeur. Nous allons montrer à quel point il est facile de le faire avec OpenShift, et le jour 1.

Cas d'utilisation

Pour cette démo, nous utilisons une ferme piscicole avec des réservoirs de plus en plus. La température de l'eau dans les réservoirs doit rester dans une fourchette sûre, surtout en hiver. Si la température descend en dessous d'un certain point, cela endommagera le poisson.

Les réservoirs sont équipés de thermostats connectés à Internet qui contrôlent les radiateurs. Nous utiliserons les relevés du thermostat pour garantir une efficacité maximale et identifier les premiers signes de défaillance.

L'efficacité est calculée par le taux d'augmentation de la température lorsqu'un chauffe-eau se met en marche. À des fins de démonstration, nous supposerons qu'une augmentation d'un degré par seconde est notre norme. (Dans le monde réel, ce ne serait pas vrai, car les réservoirs bouilliraient en quelques secondes, mais c'est ainsi que nous pouvons voir les changements rapidement dans la démo.)

Figure 1 – Infrastructure

Flux de données

1. La passerelle transmet les relevés de température à notre application via un service REST
2. Le service transfère les relevés dans une file de messages
3. Le le service du processeur consommera les messages et calculera l'efficacité actuelle pour chaque appareil
4. Il publiera ensuite les enregistrements d'efficacité dans une deuxième file d'attente, et les exposera sous forme de métrique qui sera surveillée en temps réel
5. Nous ' ll surveillera également les relevés de température bruts et les présentera dans un tableau de bord
6. Enfin, des alertes seront générées le cas échéant et publiées dans une autre file d'attente de messages pour être envoyées de manière appropriée

Figure 2 – Architecture

A Et bien sûr, tout fonctionnera sur OpenShift.

Environnement

Nous avons besoin d'un cluster OpenShift sur la version 4 ou plus récente. En effet, nous allons utiliser des opérateurs pour faciliter l'approvisionnement de notre middleware. Une installation vanilla est assez bonne, car vous pouvez l'exécuter sur un seul nœud, et maintenant vous pouvez même utiliser Conteneurs CodeReady qui vous permettent d'exécuter OpenShift sur votre machine de développement.

Vous pouvez également utiliser licences d'évaluation et déployez un cluster de test sur AWS, qui vous donnera accès au stockage, à la mise à l'échelle à la demande, etc., tous prêts à l'emploi.

Kafka

Kafka est logiciel de traitement de flux. Pour ceux qui proviennent de systèmes classiques pilotés par les événements, vous pouvez le considérer comme une file d'attente de messages, mais cela fait beaucoup plus que cela. Ce qui nous intéresse, ce sont les analyses de streaming en temps réel, les calculs de fenêtre coulissante.

Pour calculer notre efficacité, nous devons comparer deux relevés de température consécutifs, et sans Kafka, vous auriez besoin de maintenir un état dans une sorte de cache, ce qui nous obligera à faire plus de codage, et c'est précisément ce que nous essayons d'éviter. Kafka est également évolutif. Consultez cet article pour une introduction à Kafka Streams.

La version entreprise de Kafka est fournie par Red Hat sous le nom AMQ Streams un projet en aval de l'open-source initiative Strimzi. Il vient avec une intégration transparente avec l'écosystème OpenShift.

Prometheus

Figure 3 – Exemple de tableau de bord Grafana

Prometheus sera utilisé comme surveillance métrique système. Il se connecte à vos services à un intervalle donné, élimine les données que vous souhaitez regarder et les stocke dans une base de données chronologiques. Vous pouvez ensuite lui donner des règles et il générera des alertes et les publiera sur un point de terminaison de votre choix ou enverra un e-mail ou d'autres notifications. Nous installerons également Grafana qui est l'outil de visualisation standard pour Prometheus, et vous pouvez importer des tableaux de bord de communauté pour des outils couramment utilisés comme Spring Boot et Kafka. OpenShift utilise Prometheus en interne pour surveiller le cluster.

Spring Boot et Spring Cloud Streams

Pour nos microservices, nous allons commencer avec une simple application Spring Boot et ajouter quelques modules qui faciliteront les choses: [19659035] Actuateur: fournissez un point de terminaison de contrôle d'intégrité à surveiller par OpenShift, et associez-le au module Prometheus pour exposer toutes nos mesures de service internes comme le temps de réponse, les détails de la JVM, etc., ainsi que certaines mesures personnalisées pour surveiller notre température et notre efficacité.

Figure 4 – Sortie de l'actionneur Spring Boot Prometheus

• Spring Cloud Stream: fournit une abstraction pour les flux Kafka. Il est similaire à Spring Data pour les bases de données relationnelles dans la mesure où il gère la connexion à Kafka, sérialise et dé-sérialise les messages, etc. Il s'intègre également au module actionneur afin que nous puissions regarder nos mesures d'intégration dans Grafana et configurer des règles dans Prometheus. Regardez cette vidéo pour une introduction à Spring Cloud Streams avec Kafka.

Opérateurs

À ce stade, nous devons installer nos trois middlewares sur OpenShift. Dans la version 4 et plus récente, la plate-forme entière est construite autour du concept des opérateurs . À un niveau de base, les opérateurs sont des applications régulières qui gèrent les cycles de vie des autres applications. Ils s'assurent que tous les composants d'une application sont correctement configurés et surveillent les modifications de configuration pour prendre les mesures appropriées dans OpenShift. Pour notre objectif immédiat, vous pouvez les considérer comme des installateurs de piles d'applications complexes.

Figure 5 – OpenShift Operators Catalog

OpenShift's Le catalogue des opérateurs est accessible directement à partir de l'interface utilisateur et vous pouvez choisir dans la liste des logiciels sélectionnés, installer et créer des instances de ces applications. Il ne nécessite aucune connaissance de l'infrastructure sous-jacente et ils sont livrés avec des valeurs par défaut de production afin que vous n'ayez rien à personnaliser au début.

Figure 6 – Grafana Custom Ressource

Pour ce faire, vous créez une ressource personnalisée, qui est la représentation abstraite de l'infrastructure d'une application, au format YAML.

Présentation du code

Service de thermostat

Je voulais un solution low-code, et si possible, je ne voulais pas en savoir trop sur Kafka. Tout ce que je veux faire, c'est produire des messages et les vider dans un sujet, puis les consommer à l'autre extrémité et produire un autre message en conséquence.

Figure 7 – Service d'admission

Ce service Spring Boot Rest standard prend un message de la passerelle IOT, l'enveloppe dans un message standard Spring Integration et l'envoie à la sortie, qui est liée à nos températures sujet. Nous ajoutons ensuite la configuration pour indiquer à Spring où se trouve notre cluster Kafka, et à quel sujet envoyer le message et le laisser faire tout le gros du travail. Nous n'avons écrit aucun code spécifique à Kafka – Spring mettra ce sujet à notre disposition via un bean Source que nous pouvons câbler automatiquement.

[19659002] Figure 8 – Configuration de Spring Cloud Stream

Service de processeur

Figure 9 – Fonction de processeur

Ici, nous exploitons l'abstraction de Kafka pour les flux, et nous créons une fonction simple qui prend les messages du sujet des températures en entrée, augmente l'enregistrement avec l'efficacité calculée et l'envoie à notre sujet d'efficacité.

Figure 10 – Spring Cloud Stream Processor Config

Ici, nous déclarons que nous avons une fonction de processeur et configurons Spring pour lier son entrée et sa sortie à des sujets Kafka spécifiques. Par convention, functionName-in-x pour les entrées et functionName-out-x pour les sorties. Dans ce cas, nous avons utilisé quelques API spécifiques à Kafka avec KStream parce que nous voulons tirer parti de la capacité de Kafka à effectuer des calculs basés sur le temps.

Nous voulons également suivre les données de température et d'efficacité et les exposer en tant que mesures à Prométhée, donc nous ajoutons nos deux consommateurs en conséquence:

• tempGauge : Consomme les messages de température bruts du sujet des températures
• efficientGauge : Consomme le message augmenté du sujet des efficacités

Alors tout ce que nous vous devez câbler automatiquement le MeterRegistry mis à notre disposition par Spring Actuator et mettre à jour les valeurs métriques avec la lecture des rubriques de chaque appareil.

Gardez à l'esprit qu'à ce stade , nous n'avons ajouté aucun code lié à Docker ou à OpenShift.

La démo

Pour plus de commodité, nous avons créé un Helm Chart qui installera automatiquement pour vous tous les composants de l'application, en supposant que vous ayez installé le Opérateurs comme décrit dans les étapes précédentes.

Les instructions pour installer la démo sont disponibles dans le référentiel git Fichier README .

Si vous souhaitez uniquement exécuter la démo, vous pouvez ignorer les deux sections suivantes et cliquez ici pour regarder la démo qui commence à 21:50 de notre webinaire Moderniser les applications avec Red Hat OpenShift sur AWS .

Après la l'installation est terminée, vous pouvez accéder aux interfaces utilisateur Prometheus, Grafana et Alertmanager en cliquant sur les liens de la page Networking> Routes de la console OpenShift.

Figure 11 – Page Routes d'Openhift

Prométhée devrait afficher les trois services en cours de fonctionnement sur la page Cibles.

Figure 12 – Poste de cibles Prometheus -Install

Déploiements manuels avec Source-2-Image (S2I)

Nous avons utilisé Helm pour tout installer pour gagner du temps, mais nous aurions pu déployer l'application manuellement à la place. Les applications sur Kubernetes s'exécutent à l'intérieur de pods, qui gèrent un ou plusieurs conteneurs, et les conteneurs exécutent des images Docker. OpenShift fournit un moyen facile de regrouper et d'exécuter des applications sans aucune modification de code si vous utilisez l'un des environnements d'exécution standard.

Ouvrez la perspective développeur dans la console Web OpenShift, cliquez sur ajouter, pointez sur l'emplacement de votre code sur Git, choisissez un runtime, et c'est tout. OpenShift configurera automatiquement un certain nombre de choses pour vous:

• OpenShift utilisera une fonctionnalité appelée S2I ou Source-to-image pour créer une image Docker directement à partir de votre code source. S2I clone votre code à partir d'un dépôt git – public ou privé, explique comment compiler et empaqueter votre application, et l'enveloppe dans une image Docker qui sait déjà comment exécuter votre code. Par exemple, s'il s'agit d'un projet Java, il détectera une configuration maven ou groovy et emballera votre application dans un fichier Jar. Dans le cas de Spring Boot, utilisez une image Java11 Docker pour démarrer le serveur Web. Si vous utilisez NodeJS, il exécutera l'installation de npm et le démarrage de npm, et même l'exécution des applications React est désormais disponible.

Vous pouvez coder votre application comme vous le savez déjà – assurez-vous simplement d'utiliser les normes et conventions de l'industrie, que vous êtes probablement déjà.

Figure 13 – Deploy Service

Figure 14 – Déploiement depuis Git

1. OpenShift crée un DeploymentConfig, qui décrit comment nous voulons que notre application soit déployée. Dans ce cas, une seule instance, avec un conteneur, un processeur standard et une allocation de mémoire. Il le configurera également pour que l'application soit automatiquement redéployée lorsque nous transmettrons une nouvelle version.
2. Il crée ensuite un service, qui expose notre application au reste du cluster afin que d'autres services puissent lui parler à l'aide d'OpenShift. DNS interne.
3. Enfin, il crée une Route, qui expose l'application en dehors du cluster et lui donne une URL publique. Dans ce cas, il a également mappé un port HTTP standard au port 8080 par défaut que Spring utilise pour le serveur Web. Quand tout est dit et fait, nous avons une URL publique que nous pouvons ouvrir dans un navigateur. Vous pouvez trouver le lien généré pour votre service en accédant à la page Networking> Routes de la console Web OpenShift.

Pour installer cette démonstration manuellement, ajoutez les trois services présents dans le référentiel git de cette façon. Vous devez vous assurer que vous allez dans les options avancées de git et entrez le nom du sous-répertoire contenant le service dans le champ C ontext Dir .

Manual le déploiement de Kafka et Grafana est très simple en utilisant la fonction Opérateur> Opérateur installé dans la console OpenShift, mais Prometheus est un peu plus impliqué. Je consacrerai un article de blog à ce sujet plus tard.

Exécution de la simulation

Des instructions complètes pour installer et exécuter le simulateur sont disponibles dans le référentiel git Fichier README .

Le simulateur utilise un client Spring Boot REST pour envoyer des enregistrements de température au service de thermostat à l'aide du point de terminaison / temperature-records. Par défaut, il génère un message d'augmentation d'un degré toutes les secondes pour pond_1 ce qui représente une efficacité de 100% à des fins de démonstration.

• Clonez le référentiel git sur votre machine locale
• Accédez au thermostat -simulator directory
• Exécutez le simulateur avec Maven: mvn spring-boot: run -Dspring-boot.run.jvmArguments = ”- Dsimulator.url = [thermostat service url in openshift] / temperature-records”

Vous devriez voir les enregistrements de température imprimés sur la console. Vous pouvez vérifier que les enregistrements sont consommés en accédant aux journaux de pods dans la console OpenShift, pour le service de thermostat et le service de processeur de température.

Figure 15 – Journaux de service REST

Figure 16 – Journaux de service du processeur

Vous pouvez également consulter le tableau de bord Températures dans le Grafana Interface utilisateur, qui devrait montrer une efficacité de ~ 100% pour l'étang 1.

Figure 17 – Grafana Dashboard 100%

Maintenant, nous pouvons exécuter un deuxième simulateur à 100%. Dans un terminal séparé:

1. Exécutez le simulateur avec Maven: mvn spring-boot: run -Dspring-boot.run.jvmArguments = ”- Dsimulator.id = pond-2 -Dsimulator.url = [thermostat service url in openshift] / temperature-records "
2. Allez à Grafana et sélectionnez pond-2 dans le tableau de bord Températures en haut
3. Notez que l'efficacité est à ~ 100%

À ce stade, il convient de noter que nous n'avons pas configuré quoi que ce soit à Kafka. Spring Cloud Stream a automatiquement créé et configuré les sujets pour nous. Si vous devez régler ces paramètres, vous pouvez utiliser les ressources personnalisées de l'opérateur pour créer les rubriques à l'avance et spécifier le partage et les autorisations dans le fichier YAML.

Simulons maintenant une panne sur l'étang-2. Pour ce faire, nous modifions simplement le taux d'augmentation de la température à un degré toutes les 1,5 secondes en définissant la propriété simulator.rate sur 1500 dans notre simulateur.

1. Arrêtez le simulateur sur le deuxième terminal
2. Exécutez le simulateur avec Maven: mvn spring-boot: run -Dspring-boot.run.jvmArguments = ”- Dsimulator.id = pond-2 -Dsimulator.rate = 1500 -Dsimulator.url = [thermostat service url in openshift] / temperature-records”

L'eau chauffe maintenant plus lent qu'auparavant, ce qui réduit l'efficacité à ~ 66% (1 / 1,5). Cela se reflétera presque instantanément sur le tableau de bord.

Figure 18 – Grafana Dashboard 66%

Vous devriez voir une nouvelle alerte sur le Page Alertes Prometheus (actualisez la page car Prometheus n'affiche pas d'alertes en temps réel). L'état initial de l'alerte indiquera PENDING (jaune) puis passera à FIRING (rouge) après une minute. En effet, nous avons configuré l'alerte pour qu'elle ne se déclenche qu'après une minute de condition afin d'éviter les fausses alarmes. Lorsque l'alerte se déclenche, des notifications seront envoyées à la destination choisie à l'intervalle configuré.

Figure 19 – Alerte Prométhée en attente

Figure 20 – Prometheus Alert Firing

Enfin, rétablissons l'efficacité en arrêtant le simulateur et en le redémarrant avec le taux normal:

1. Stop le simulateur sur le deuxième terminal
2. Exécutez le simulateur avec Maven: mvn spring-boot: run -Dspring-boot.run.jvmArguments = ”- Dsimulator.id = pond-2 -Dsimulator.url = [thermostat service url in openshift] / temperature- records "

Le statut d'alerte devrait redevenir vert sur Prometheus après quelques secondes.

Considérations relatives à la production

Que devez-vous faire si vous souhaitez déployer votre solution dans un environnement de production?

• l'environnement de production est le même que l'environnement de test pour éviter le classique "ça marche dans mon enviro nment ». Étant donné que tout dans OpenShift est un fichier de configuration YAML, vous pouvez copier les fichiers dans votre projet pour contrôler efficacement la source de votre infrastructure d'application. Déplacez ces fichiers vers votre cluster de prod et déployez votre application. Vous pouvez avoir une branche par environnement avec différentes configurations et vous n'avez pas besoin d'expliquer au service informatique comment exécuter vos tâches.

Figure 21 – DeploymentConfig Thermostat Service

• Vous voulez vous assurer que tous ces composants évolueront. Pour les choses qui sont gérées par des opérateurs comme Kafka, les configurations par défaut sont généralement un bon point de départ, mais vous pouvez le bricoler et trouver ce qui vous convient.
• Pour vos propres services, OpenShift gardera un œil sur vos modules et remplacer ceux qui meurent pour une raison ou une autre. C'est une bonne idée d'avoir au moins deux réplicas dans prod afin que vous en ayez toujours un en cours tandis qu'OpenShift en amorce un nouveau.
• Spring Boot est également livré avec des valeurs par défaut de qualité production, et parce que nous n'avons pas écrit beaucoup de code sur tous, et les services sont apatrides, vous pouvez les faire monter et descendre très facilement et en toute sécurité. Si vous avez suivi l'étape supplémentaire de création de votre propre opérateur, vous pouvez le configurer de sorte que vos services et votre cluster Kafka soient synchronisés. Ou, rééquilibrez les données, exécutez des sauvegardes, etc. (Voir le champ Répliques: 1 dans la capture d'écran précédente. Modifiez-les en 2 ou plus.)
• Sur la plupart des clusters, Surveillance et journalisation d'OpenShift est installé hors de la boîte, mais si ce n'est pas le cas, il y a un opérateur pour cela. Surveillance des clusters vous donne accès au cluster interne Prometheus / Grafana et permet à votre NOC de surveiller votre application le jour 2.
• Journalisation des clusters mettra en place un cluster Elasticsearch et un Kibana GUI et diffusez automatiquement vos journaux d'application dans un index où ils peuvent être organisés, recherchés et analysés, etc. C'est utile lorsque vous souhaitez dépanner des conditions particulières ou faire des autopsies si un pod meurt.
• Si vous voulez faire du bleu / Déploiements verts, versioning, authentification, test A / B, etc., il existe un produit appelé Service Mesh dans OpenShift qui vous permet de les configurer facilement sans toucher à votre code. Il y a un opérateur pour cela bien sûr – c'est un peu plus avancé mais pas hors de portée pour le développeur de tous les jours non plus.

Figure 22 – Service Mesh

• Rappelez-vous que lorsque vous créez vos applications autour de Kafka, vous pouvez facilement ajouter de nouvelles fonctionnalités en cours de route? Un des compagnons d'AMQ Streams est Fuse Online, un produit Red Hat qui vous permet de créer des intégrations autour de Kafka sans avoir à écrire une seule ligne de code.

Figure 23 – Fuse en ligne

Par exemple, nous pouvons l'utiliser pour consommer notre rubrique d'alertes et envoyer des notifications AWS SNS. Ou nous pouvons installer un cluster Elasticsearch à l'aide de l'opérateur et y enregistrer nos métriques pour créer des rapports exécutifs et même faire de l'apprentissage automatique.

Conclusion

Nous avons créé une application assez complexe avec très peu de code ou une connaissance des technologies sous-jacentes. Nous avons utilisé un cadre Java familier, et grâce à son intégration étroite avec OpenShift et à l'utilisation d'autres technologies natives d'OpenShift, nous avons pu relier les choses ensemble.

En tant que développeur, je peux maintenant me voir offrir mon espace de projet dans le Cluster OpenShift et créer mon environnement de développement idéal. Je peux configurer des clusters et les supprimer en un instant – je ne suis pas obligé de changer la façon dont je code ou de me renseigner sur Docker ou Kubernetes, et je n'ai codé que la partie qui fournit réellement une valeur commerciale. De plus, je suis en mesure de décrire mon infrastructure d'application dans des fichiers yml, je n'ai donc pas à l'expliquer au service informatique ni à gérer les configurations conflictuelles de différents groupes.

Et grâce aux nombreux outils OpenShift disponibles pour faire face aux problèmes de production, je n'ai pas besoin de faire cuire toutes ces choses dans mon code, donc c'est beaucoup plus facile à maintenir, plus léger et plus encore pour

À propos de l'auteur

Matthieu Rethers est un architecte de solution senior avec l'équipe de gestion des API chez Perficient. Issu d'un environnement d'architecte Java, Matthieu est devenu un spécialiste des micro-services, en mettant l'accent sur l'architecture Cloud et l'orchestration des conteneurs. Cette unité commerciale aide les équipes de développement à moderniser et à accélérer la livraison de logiciels grâce à l'adoption de Red Hat Openshift.

Plus de contenu de cet auteur