HCS construit une couche application frontale flexible avec NGINX

Une agence gouvernementale nationale aux Pays-Bas avec un éventail diversifié de parties prenantes et d’utilisateurs souhaitait déplacer ses flux de travail des processus papier vers une infrastructure numérique moderne. Cela permettrait à l’agence d’agir plus rapidement et de simplifier la vie de ses utilisateurs et de ses employés.

Le défi ? L’agence a permis à chaque localité participante d’élaborer des processus et des exigences quelque peu uniques. Au départ, l’agence avait déployé de gros efforts pour créer une application monolithique complète avec de nombreuses personnalisations. Le premier effort a échoué sous le poids de l’hyper-personnalisation – « la mort par mille exigences ». HCS Company , un cabinet de conseil informatique néerlandais spécialisé dans les technologies open source et Red Hat®, a été sollicité pour essayer de nouvelles façons de numériser les processus de l'agence avec une approche différente.

Reconstruire Simple: Micro-front-ends, conteneurs et microservices composables

L'équipe DevOps de l'agence a travaillé sur le projet avec Benoit Schipper, Lead Site Reliability Engineer (SRE) chez HCS. Ensemble, ils ont commencé par examiner plus en profondeur le problème qu’ils cherchaient à résoudre. Les utilisateurs, qu'il s'agisse de fonctionnaires du gouvernement, d'avocats, de comptables ou de citoyens ordinaires, doivent se connecter à l'application de l'agence, vérifier l'état d'un projet ou d'un processus et télécharger un PDF. Benoit et son équipe ont décidé de construire une fondation simple comme point de départ de la solution. Benoit explique : « Nous avons étudié la question et nous nous sommes dit : « Créons quelque chose de très générique, et pour toute demande spéciale, nous pouvons construire à partir de cette base générique » ». L’équipe DevOps souhaitait également pérenniser les fondations, en garantissant l’évolutivité à la fois au sein de l’infrastructure existante et pour les emplacements et applications supplémentaires qui pourraient s’avérer nécessaires à l’avenir.

Benoit et son équipe ont élaboré ce futur et sont arrivés à une nouvelle architecture de très petits (micro) frontaux qui peuvent être composés de différentes applications mappées à de petits services distincts (microservices) dans le back-end. « Nous avons opté pour les microservices car avec cette architecture, nous sommes prêts à passer au cloud et à évoluer lorsque cela devient très important », explique Benoit. « Nous avons séparé le puzzle en pièces plus petites que nous avons pu assembler. »

La première décision concernant la mise en œuvre a été de passer des serveurs Microsoft Windows dans un environnement dédié à un environnement basé sur des conteneurs dans le cloud, plus adapté aux microservices composables et flexibles. L’équipe a choisi Red Hat OpenShift® comme plateforme de conteneurs.

Il y avait deux facteurs forts en faveur d’OpenShift. Tout d’abord, la longue expérience de RedHat en matière de collaboration avec les gouvernements a facilité l’obtention de l’approbation gouvernementale pour la conception. Deuxièmement, OpenShift comprend de nombreux outils et applications conçus pour faciliter la construction et la maintenance de microservices et d’architectures de microservices, notamment :

• Red Hat Ceph® Storage – Un service de stockage blob accessible via une API compatible S3
• Red Hat AMQ Broker – Un service de bus de messages pour la gestion de la charge de travail et de l'état des application et la mise en file d'attente des travailleurs
• Prise en charge intégrée et certifiée de Kubernetes – Important pour une meilleure pérennité si HCS et l'agence déterminent que Kubernetes est le bon outil pour l'orchestration des conteneurs

De Windows à Linux, .Net Core et NGINX Open Source

Le passage aux conteneurs impliquait de remplacer l'ancien back-end .Net de l'agence, qui fonctionnait sur des serveurs Windows. Heureusement, la transition vers .Net Core , une version de .Net optimisée pour les conteneurs, s’est faite facilement. Un avantage supplémentaire est que les développeurs de l’agence peuvent continuer à coder dans les langages et frameworks application Windows qu’ils connaissent.

L'équipe DevOps a créé un ensemble de base d'API REST pour accéder aux services backend .Net Core. Les API sont le ciment qui maintient ensemble les fonctionnalités et la logique de application et les micro-front-ends. Pour l’environnement front-end, l’équipe a choisi AngularJS en raison de sa large acceptation parmi les organisations gouvernementales en tant que framework JavaScript robuste et fiable avec une communauté forte.

Pour créer une couche de routage cohérente pour le trafic et les appels API dans les deux sens entre le front-end et le back-end, l'équipe a exploré diverses options avant de se décider pour NGINX Open Source en raison de sa polyvalence. Les pages du site Web de l'agence sont construites à la volée en tant que micro-front-ends en intégrant des éléments de contenu et en utilisant la même logique CSS pour « habiller » plusieurs services back-end. Pour l’utilisateur, tout semble se passer au sein de la même application, « mais en réalité nous utilisons du proxying intelligent et des réécritures avec NGINX. Pour remplir l’écran avec les informations appropriées pour le front-end, nous faisons des appels API back-end via NGINX », explique Benoit.

Pour exposer l' application à l'Internet public, Benoit a déployé une instance F5 NGINX Plus comme serveur Web et proxy inverse sur une machine virtuelle exécutée dans la DMZ de l'agence. Il explique pourquoi NGINX Plus est la solution idéale : « Nous avions besoin de TLS 1.3 et voulions avancer rapidement. C'était abordable par rapport aux appareils dédiés et nous pouvions facilement ajouter des licences ».

Benoit souligne que pour l'agence, « NGINX fonctionne comme un serveur Web, un proxy et une passerelle API de base pour notre couche application . C’est vraiment un couteau suisse™ qui peut presque tout faire. C’est pour ça qu’on l’utilise. Par exemple, pour récupérer un PDF téléchargé, les utilisateurs sélectionnent le PDF dont ils ont besoin parmi les documents téléchargés sur leur compte et l' application de livraison PDF envoie une demande au service de récupération PDF back-end attaché au magasin d'objets Ceph. Ceph renvoie l’URL unique de l’emplacement du PDF dans le magasin d’objets, sur lequel l’utilisateur clique pour le visualiser ou le télécharger.

Étant donné que l’ application est essentielle à la mission, l’équipe a conçu une architecture de haute disponibilité active-active avec toutes les applications exécutées dans au moins deux clusters. Cela fournit une redondance pour tous les services, micro-front-ends et API, garantissant qu'ils continuent de fonctionner en cas de panne dans l'un des clusters.

Pour améliorer les performances et activer un plan de contrôle pour les applications composées couvrant plusieurs services, l'équipe utilise le bus de messages AMQ Broker pour configurer les rubriques et les files d'attente pour les services. « Donc, s’il est possible d’exécuter quelque chose en arrière-plan, nous le faisons en arrière-plan », explique Benoit. « Si un message arrive et que certaines données de méthode doivent être ajustées, nous avons des auditeurs qui peuvent traiter quelque chose ou trouver les travailleurs pour exécuter le processus. » Pour garantir un état cohérent pour les utilisateurs sur les différents clusters, l’équipe a conservé son infrastructure de base de données Microsoft SQL Server hautement disponible existante pour maintenir l’état du pod et activer la persistance des sessions.

Concevoir pour l'observabilité, l'évolutivité et la flexibilité

Pour l’observabilité, Benoit a recommandé Grafana comme tableau de bord cloud natif. Pour obtenir les métriques NGINX, l’équipe DevOps exploite l’ exportateur NGINX Prometheus dans un side-car associé à chaque pod. L'exportateur récupère les métriques de couche 4 du module NGINX Open Source Stub Status et de l'API NGINX Plus , associe chacune d'elles à une chaîne, crée une paire clé-valeur et envoie la paire dans Prometheus . À partir de là, la paire est publiée sur une instance Grafana distincte qui est exposée uniquement aux développeurs et aux équipes DevOps. « C'est incroyable. Je peux créer des tableaux de bord et collecter des métriques en un seul endroit sur toutes mes instances NGINX Open Source et NGINX Plus. L'équipe DevOps est aux commandes. « Ils peuvent voir ce qui fonctionne et recevoir des alertes en cas de problèmes », explique Benoit.

L’équipe utilise également les métriques pour la gestion des performances de l’ application. Prometheus génère des alertes pour les exceptions et les connexions non gérées dans les applications, ce qui signale qu'il n'y a pas assez de travailleurs en cours d'exécution. Benoit a lié les métriques à la fonctionnalité de mise à l'échelle automatique dans OpenShift. Il explique : « J’ai configuré la configuration NGINX pour un certain nombre de travailleurs et calculé la RAM et le CPU requis. Si les choses deviennent trop chargées par rapport à cette base de référence, OpenShift s'adapte automatiquement et m'envoie une alerte.

Lorsqu’un test de pénétration a indiqué que les applications n’utilisaient pas une politique de sécurité du contenu (CSP) forte, l’équipe a pu configurer NGINX Open Source et NGINX Plus avec des politiques d’application en ligne de la CSP. Ils ont également mis en place une configuration personnalisée pour extraire les informations de journalisation JSON de la plate-forme de conteneurs et les envoyer à la plate-forme de journalisation Splunk pour l'analyse historique et la conservation des enregistrements.

Améliorer l'expérience des développeurs

Pour les développeurs front-end utilisant Google Analytics et Lighthouse , HCS a permis d'inclure les contrôles Lighthouse dans le pipeline de l'agence, codés dans les configurations NGINX. « Nous avons rapidement constaté que nous pouvions réaliser des gains de performances significatifs en passant à la bibliothèque de compression GZIP », explique Benoit, et le résultat est une amélioration de 60 % de la latence des application .

De plus, avec la nouvelle architecture, les développeurs sont désormais en contact direct avec les utilisateurs finaux car ils disposent d’une visibilité très détaillée sur leur comportement en temps réel. « La boucle de rétroaction est beaucoup plus rapide, et si quelque chose se produit et doit être modifié, nous pouvons le mettre en production en une journée seulement. « C’est très rapide pour les gouvernements, là où les changements prenaient auparavant des mois, voire des années », explique Benoit. « Pour nos développeurs, c'est le jour et la nuit. »

La pile technologique

• Back-end – .Net Core
• Front-end – AngularJS
• Mise en réseau (serveur Web, proxy inverse, passerelle API, contrôleur d'entrée, équilibreur de charge global) – NGINX Open Source , NGINX Plus , F5 BIG‑IP , HAProxy (sur OpenShift)
• Base de données – Microsoft SQL Server , Red Hat Ceph Storage , InfluxDB pour les données Lighthouse
• CI/CD – Azure DevOps
• Infrastructure – Red Hat OpenShift , conteneurs Linux
• Messagerie – Broker Red Hat AMQ (open source Active MQ)
• Observabilité et métriques – Grafana , Prometheus
• Journalisation – Splunk

Commencer

Vous souhaitez reproduire les excellents résultats de ce projet en construisant votre pile technologique sur NGINX Plus ? Commencez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .