Gestion de la configuration des conteneurs

Si vous déployez dans plus d'un environnement/région/cloud/client, vous rencontrerez inévitablement le problème de la gestion de la configuration.

Alors que tous vos déploiements (ou juste certains) peuvent partager le même code source, certaines parties, telles que la configuration (paramètres, mots de passe) diffèrent d'un déploiement à l'autre et doivent être gérées différemment.

Dans cet article, j'essaierai d'offrir quelques conseils à ce sujet. Cet article traite principalement des déploiements de conteneurs.

Unification de la base de code

Avant d'aborder la gestion de la configuration, parlons de l'unification des bases de code. Le problème est le suivant : la base de code doit généralement viser à coalescer en une seule version. Bien sûr, à tout moment, vous aurez plusieurs versions de votre base de code - la version DEV avec de toutes nouvelles fonctionnalités, la version TEST avec du code de test supplémentaire, la version PROD, et ainsi de suite. Et c'est fine parce que, dans cet exemple, les changements se regroupent en une seule version au fil du temps. Plusieurs branches DEV deviennent une branche TEST et ainsi de suite.

Le problème commence lorsque nous avons plusieurs versions à l'étape finale de notre pipeline de déploiement. Par exemple, le client ABC a demandé une fonctionnalité particulière XYZ, et il existe maintenant deux versions de la base de code PROD - avec la fonctionnalité XYZ et sans elle. Cette situation est problématique car elle double immédiatement nos délais de construction et notre consommation de ressources. Bien sûr, il n'y a parfois aucun moyen d'y remédier. Cependant, supposons que vous ayez de telles divergences persistantes entre les bases de code. Dans ce cas, il peut être intéressant de rechercher si vous pouvez les regrouper en une seule version - dans ce scénario, la fonctionnalité XYZ est activée ou non au démarrage.

Cela dit, passons à la gestion de la configuration.

 

Gestion de la configuration

Qu'est-ce que nous voulons ?

 * Ne pas stocker toutes les configurations possibles dans un seul conteneur ( pour une part, ce n'est pas sûr, et pour une autre part, nous avons toujours besoin de choisir la configuration à appliquer).
 * Ne pas construire un conteneur pour chaque configuration (simplifie le pipeline CD)

Nous devons transmettre la configuration (paramètres, secrets, ...) lors du démarrage d'InterSystems IRIS et l'appliquer à notre application.

 

Transmission de la configuration

Il existe plusieurs façons de transmettre la configuration au démarrage.

Les variables d'environnement

Simple et rapide. Dans le cas où vous souhaitez tout stocker dans une seule variable, utilisez JSON pour la sérialisation. N'oubliez pas par ailleurs que Windows a une limite de 32K caractères pour les variables d'environnement (mégaoctets sous Linux). Pour récupérer une variable d'environnement, utilisez $SYSTEM.Util.GetEnviron("ENV_VAR\NAME"). Le principal avantage est la facilité de mise en œuvre. Vérifiez également votre outil CD - il a généralement un minimum de support des variables d'environnement pendant l'exécution du pipeline, parfois avec un support des secrets pour plus de sécurité.

Les fichiers de montage

La configuration peut être un fichier de montage au démarrage. L'avantage est qu'il n'y a pas de limite de longueur. L'inconvénient est que toutes les offres en nuage ne prennent pas en charge les fichiers de montage, et même si c'est le cas, la gestion des fichiers peut s'avérer plus délicate que celle des variables d'environnement. Sachez que les fichiers peuvent toujours être récupérés à partir des anciennes couches d'un conteneur, même s'ils ont été supprimés à une couche ultérieure.

Fusion du CPF

Les paramètres du système peuvent être transmis via le Fichier de fusion de configuration. Ainsi que ses fonctionnalités intégrées. Inconvénient : Le fichier de fusion CPF ne traite pas les paramètres au niveau de l'application.

Les secrets de Docker/CSP

Docker peut monter un secret sous une forme de fichier à l'intérieur d'un conteneur. Les offres en nuage proposent souvent une fonctionnalité similaire. Utilisez-la à la place des fichiers ordinaires pour améliorer la sécurité.

 

Traitement de la configuration

Bien, vous avez passé la configuration à l'intérieur d'un conteneur. Que faire maintenant ?

%ZSTART

%ZSTART est votre code personnalisé, exécuté au démarrage du système. Il ressemble à ceci :

SYSTEM
    try {
        new $namespace
        set $namespace = "USER"
        // apply configuration
        set $namespace = "%SYS"
    } catch ex {
        zn "%SYS"
        do ex.Log()
    }
    quit 1

Il est essentiel de noter que %ZSTART doit être testé complètement - car InterSystems IRIS ne démarrera pas (ou se comportera de manière erratique) si la routine %ZSTART renvoie une erreur.

Vous êtes maintenant prêt à appliquer vos paramètres.

La manière dont vous stockez/appliquez les paramètres au niveau de l'application dépend naturellement de l'application, mais les paramètres par défaut du systèmeSystem Default Settings sont disponibles si vous utilisez l'interopérabilité. Même si vous n'utilisez pas de productions interopérables, vous pouvez toujours utiliser les paramètres par défaut du système car ils sont disponibles pour tout le monde (tant que l'interopérabilité est activée dans un espace de noms).

Pour créer un nouveau paramètre, exécutez :

Set setting = ##class(Ens.Config.DefaultSettings).%New()
Set setting.ProductionName = production
Set setting.ItemName = itemname
Set setting.HostClassName = hostclassname
Set setting.SettingName = settingname
Set setting.SettingValue = settingvalue
Set setting.Description = description
Set sc = setting.%Save()

Et pour récupérer les paramètres, appelez :

set sc = ##class(Ens.Config.DefaultSettings).%GetSetting(production, itemname, hostclassname, "", settingname, .settingvalue)
set settingvalue = ##class(Ens.Director).GetProductionSettingValue(production, settingname, .sc)

Les hôtes d'interopérabilité reçoivent leurs paramètres automatiquement au démarrage du travail de l'hôte commercial.

 

Summary

Making your application configurable when deploying to more than one server is essential. It can be pretty easy at the early part of the development cycle, but the costs rise with each hardcoded URL. InterSystems IRIS offers several tools you can use to configure the state of your application at startup.

 

How do you manage multiple deployments?