Configuration côté client dans votre pod OpenShift ou Kubernetes

Lors de la préparation d'un atelier présentant la puissance d'OpenShift on Azure (ARO) aux développeurs axés sur .NET Core, nous nous sommes efforcés de nous aligner sur la méthodologie des applications à 12 facteurs. Plus précisément, règle numéro trois – Configuration .

Étant donné qu’une application est susceptible de varier d’un déploiement à l’autre (environnements de développeur, mise en place, production, assurance qualité, etc.), ses configurations peuvent être stockées sous forme de constantes dans la base de code. Sonnez les cloches d’alarme, c’est une violation flagrante de la stricte séparation de la configuration et du code.

Notre objectif était de prendre une application standard à trois niveaux contenant une interface Web React / Redux, l’interface Web principale .NET Core, en tant que middleware, et un niveau de données pris en charge par MongoDB et guide le développeur dans son déploiement vers OpenShift. Lors du déploiement du serveur frontal, nous souhaitions extraire des données de configuration (telles que des URL d'API ou des ID client d'un fournisseur OAuth) à l'intérieur du projet OpenShift. Notre équipe était habituée à extraire ces configurations des variables d'environnement de la base de code, mais ne l'avait pas encore fait à partir d'un conteneur exécutant un serveur Nginx hébergeant un site frontal JavasScript.

Suivant les modèles existants impliquant l'utilisation de Dockerfiles et diverses versions configurations, nous avons continué à courir dans les murs avec le modèle de script bash. Le problème était que ces modèles ne considéraient pas que les pods OpenShift étaient intrinsèquement immuables et qu'il n'existait aucune méthode viable pour ajouter ou mettre à jour des configurations sur les pods pendant ou après le déploiement. Cette immuabilité découle de l'importance d'assurer la sécurité et les performances de démarrage du pod.

En relisant la documentation ConfigMap on m'a rappelé la fonctionnalité incluse pour consommer des variables d'environnement provenant de volumes persistants . . J’ai créé un objet ConfigMap avec un fichier ‘configurations.js’ en tant que contenu pouvant être ajouté à n’importe quel volume de mon conteneur au démarrage de Pod. Cela m'a permis de placer le fichier 'configurations.js' dans un sous-dossier du dossier 'html' par défaut de Nginx contenant des ressources statiques et de le référencer à partir de 'index.html', permettant ainsi à JavaScript côté client d'extraire les variables d'environnement spécifiées dans ConfigMap. . Idéalement, il est possible de créer une carte ConfigMap unique pour chaque environnement du système frontal, en alignement avec la troisième règle de la méthodologie de l'application à 12 facteurs.

Voyons comment procéder:
Commençons par créer une nouvelle configuration. carte avec nos valeurs de configuration dans un fichier .js

Cliquez ensuite sur "Ajouter à l'application"

. ] Et ajoutez le chemin de montage de notre application côté client Nginx et sélectionnez notre application

Mettez ensuite à jour le point d'entrée de votre application, index.html avec un lien vers le fichier

Relancez notre version et notre valeur est disponible pour notre code côté client JavaScript

Cette méthode était beaucoup plus facile que l’approche de script bash et suit les meilleures pratiques OpenShift et Kubernetes. J'espère que ce message aidera quelqu'un qui travaille à déployer son frontal JavaScript à partir d'OpenShift ou de Kubernetes.