Confd, mieux livrer la configuration de ses jobs aux services exploitation

Les services d’exploitation n’apprécient guère que les paramètres des tâches batch y soient directement attachés et encore moins si ces paramètres sont en dur dans les jobs. Heureusement pour ce qui est de Talend, il n’en est pas question ! Talend offre en effet la possibilité de stocker les paramètres dans des fichiers de type clés / valeurs. La solution ETL sait aussi générer ces fichiers à partir des éléments renseignés dans les variables de contexte. Dans la version Entreprise il est même possible de modifier et surcharger les valeurs des variables de contexte via le Talend Administration Center.
Chez Synaltic, nous avons aussi l’habitude de stocker les variables de contexte dans une base de données, ou via un fichier de propriétés. C’est une bonne pratique mais même en procédant de la sorte, les services d’exploitation pourraient trouver à redire !
Bien entendu l’objectif principal des services d’exploitation est d’éviter que les développeurs aient accès à la production. Ils ne doivent avoir ni l’accès aux machines, ni l’accès aux bases de données, en encore moins à leur fichier de configuration ! De plus, il est encore moins question de connaître le chemin de ces fichiers de configuration, les adresses des machines, ou les mots de passe de production ! Les environnements doivent être isolés.
Pour améliorer cette bonne pratique il convient alors d’avoir une solution qui permette de distinguer la gestion des paramètres de leur utilisation. Cette solution doit faciliter :

le cloisonnement entre développeurs et exploitation,
la livraison,
et standardiser et généraliser la gestion des paramètres.

Et ça tombe bien Confd, répond à toutes ces caractéristiques !
Confd est une solution très légère pour la gestion de configuration. Elle se focalise principalement sur :

la conservation des fichiers de configuration « locaux » toujours à jour (synchronisés) en s’appuyant sur des données issues d’un stockage fiable généralement de type clés / valeurs,
le rechargement des applications pour la prise en compte des nouvelles valeur de configuration.

Comme évoqué, son principal avantage est sa légèreté mais son second gros avantage est sa versatilité. Confd peut gérer les paramètres via de nombreux types de stockage.
En voilà la liste :

etcd
consul
vault
environment variables
redis
zookeeper
cynamodb
rancher
ssm (AWS Simple Systems Manager Parameter Store)

Généralement Confd gère sa configuration depuis le répertoire /etc/confd et plus particulièrement depuis le fichier /etc/confd/confd.toml. Toutefois il est possible de préciser en paramètres un fichier de configuration via le flag -config-file.
Les options de configuration de Confd sont les suivantes :

backend (string) – Le mode de stockage (backend) (« etcd »)
client_cakeys (string) – le fichier CA key
client_cert (string) – le fichier cert client.
client_key (string) – le fichier key client.
confdir (string) – le chemin du répertoire de configuration de Confd (« /etc/confd »)
interval (int) – L’intervalle de temps pour interroger le stockage en secondes. (600)
log-level (string) – le niveau de traces (« info »)
nodes (array of strings) – la liste des nœuds pour le stockage. ([« http://127.0.0.1:4001 »])
noop (bool) – Activer ou non le mode noop. Traiter toutes les ressource du modèles; garder la cible à jour.
prefix (string) – Préfixe du chemin d’accès pour les clés (« / »)
scheme (string) – la forme des URI du backend (« http » or « https »)
srv_domain (string) – Nom de domaine de la ressource.
srv_record (string) – Enregistrement du serveur à rechercher pour les backends. Exemple: _etcd-client._tcp.example.com.
sync-only (bool) – sync without check_cmd and reload_cmd.
watch (bool) – Activer ou non le support watch.

Aussi Confd est en mesure de gérer et générer plusieurs fichiers de configuration rangés dans divers dossiers de votre système.

Installation Confd

L’installation de Confd est assez simple : c’est une archive que l’on récupère et déploie dans le répertoire par défaut d’installation ou bien là où on le souhaite.

Téléchargement de l’archive

$ wget https://github.com/kelseyhightower/confd/releases/download/<<Version>>/confd-<<Version>>-linux-amd64

Le déploiement est alors le suivant par exemple :
mkdir -p /opt/confd/bin mv confd-<<Version>>-linux-amd64 /opt/confd/bin/confd chmod +x /opt/confd/bin/confd export PATH="$PATH:/opt/confd/bin"

A noter que vous pourriez très bien procéder via Docker. Dans mon cas et pour les tests, j’ai privilégié un tout autre répertoire où j’organise mes tests et petits développements. J’ai créé un répertoire tests qui ressemble à ceci :
├── conf │ └── confd.toml ├── conf.d │ ├── myconfig.toml │ └── myTalendJobSample.toml ├── templates │ ├── myconfig.conf.tmpl │ └── myTalendJobSample.conf.tmpl ├── batchs │ └── myTalendJobSample └── batchs-config ├── myconfig.conf └── myTalendJobSample.conf

conf porte la configuration de Confd
conf.d porte la configuration de génération de mes fichiers de configuration pour les batchs
templates porte les modèle de fichier de configuration à générer
batchs : pour y poser les jobs Talend
batchs-config : dossier dans lequel je viens générer les fichiers de configuration des jobs

Configuration Confd

Pour ce qui est de la configuration de Confd lui même, l’option qui a surtout été retenu c’est que le backend pour le stockage des variables serait Zookeeper. La configuration de Confd est ici la suivante :
backend = "zookeeper" confdir = "<<Répertoire de déploiement>>/confd/tests" log-level = "info" interval = 600 nodes = [ "127.0.0.1:2181" ] noop = false prefix = "/" scheme = "http"

Création des variable via Zookeeper

Zookeeper est déployé. Sa configuration s’opère via le client zkCli.sh ou pour les besoins de cet article nous avons trouvé Zoonanigator. Zookeeper peut alors prendre un autre visage.
Ainsi voilà ce à quoi ressemble le job exemple : une connexion vers une base de données pour un export vers un fichier.

Nous retrouvons donc dans Zookeeper les mêmes variables de contexte :

Création d’un modèle pour la configuration du Job

Dans le dossier où nous sont rangés les modèles nous créons le fichier templates/myTalendJobSample.conf.tmpl. Il a renferme le contenu suivant :
# Connexion Base de données Foodmart foodmart_demo_Database ={{getv "/myTalendJobSample/foodmart_demo/Database"}} foodmart_demo_Login ={{getv "/myTalendJobSample/foodmart_demo/Login"}} foodmart_demo_Password ={{getv "/myTalendJobSample/foodmart_demo/Password"}} foodmart_demo_Server ={{getv "/myTalendJobSample/foodmart_demo/Server"}} foodmart_demo_Port ={{getv "/myTalendJobSample/foodmart_demo/Port"}} foodmart_demo_AdditionalParams ={{getv "/myTalendJobSample/foodmart_demo/AdditionalParams"}} # Chemins output ={{getv "/myTalendJobSample/paths/output"}}

Configuration génération fichier cible pour le Job

Maintenant nous devons indiquer à Confd à comment générer le fichier cible à partir du modèle. C’est ce que nous faisons en créant le fichier conf.d/myTalendJobSample.toml ayant pour contenu :
[template] src = "myTalendJobSample.conf.tmpl" dest = "<<Répertoire de déploiement>>/tests/batchs-config/myTalendJobSample.conf" keys = [ "/myTalendJobSample/foodmart_demo/Database", "/myTalendJobSample/foodmart_demo/Login", "/myTalendJobSample/foodmart_demo/Password", "/myTalendJobSample/foodmart_demo/Server", "/myTalendJobSample/foodmart_demo/Port", "/myTalendJobSample/foodmart_demo/AdditionalParams", "/myTalendJobSample/paths/output", ]
Ici, notez que vous devez bien spécifier les clés à prendre en compte depuis votre backend. Cela signifie que vous pourriez très bien générer un autre fichier de configuration avec ces mêmes clés ou avec d’autres.

Lancement de Confd

Lançons à présent Confd.
confd -config-file conf/confd.toml

Il démarre et vérifie à intervalle régulier tout changement ayant lieu sur les modèles, sur la configuration des fichiers à générer, sur les clés et valeurs contenus dans le backend.
On notera donc des traces du type :
2017-09-29T07:34:40+02:00 ccharly.altic.org confd[31998]: INFO <<Répertoire de déploiement>>/tests/batchs-config/myTalendJobSample.conf has md5sum a1451ad6dd007f0184d6d24ca80a800a should be 7a798e17e376869ea78a68117a982fa5 2017-09-29T07:34:40+02:00 <>.<>.<> confd[31998]: INFO Target config <<Répertoire de déploiement>>/tests/batchs-config/myTalendJobSample.conf out of sync 2017-09-29T07:34:40+02:00 <>.<>.<> confd[31998]: INFO Target config <<Répertoire de déploiement>>/tests/batchs-config/myTalendJobSample.conf has been updated

Résultat : fichier de paramétrage du job est généré

Le fichier est généré tel que nous l’attendons vers <<Répertoire de déploiement>>/tests/batchs-config/myTalendJobSample.conf

# Connexion Base de données Foodmart foodmart_demo_Database =foodmart_demo foodmart_demo_Login =<> foodmart_demo_Password = foodmart_demo_Server =localhost foodmart_demo_Port =3306 foodmart_demo_AdditionalParams = # Chemins output =/tmp

Exécution du job

Bien entendu nous avions fait attention à charger le contexte, donc le fichier de configuration généré, via le chargement implicite.

Nous pouvons exécuter notre job !

Conclusion

En conclusion, il est à noter que Confd peut être utilisé pour la configuration de toutes vos applications. Pour les jobs Talend, il facilite le processus de livraison entre développeurs et exploitation car il étanchéifie les connaissances des chemins et autres mots de passe, par exemple. Dans la mesure où Confd s’appuie sur des backends tolérant à la panne, il y aura peu de chance que le fichier de configuration ne soit pas mis à jour tel qu’attendu. Une dernière chose : la configuration même de vos fichiers de paramétrage à générer via Confd peut être livrée via votre mécanisme d’intégration continue, de même que pour la création des clés au sein du backend associé à Confd !