Talend Open Studio : centralisation et sécurisation des variables de contexte

Dans Talend Open Studio (TOS), la suite logicielle open-source pour l’intégration des données, on utilise des variables de contexte pour le paramétrage des connexions aux bases de données, aux fichiers et environnements correspondant aux différents contextes d’exécution dans le référentiel. À travers un simple exemple de fenêtre « Bonjour », je vais vous expliquer comment centraliser et sécuriser les valeurs de ces variables.

Lors du déploiement du Job, les valeurs des variables de contexte préalablement définies par le développeur sont exportées en tant que fichiers de propriétés dont le chemin est généralement codé en dur dans le Job. Ces fichiers sont cependant accessibles sur le système de fichiers et, donc, non sécurisés.ETL, Talend, tutoriels

Figure 1 – Jobs et variables de contexte du Job

Fonctionnalité initiale avec les fichiers de propriétés de contexte

Le chargement du contexte d’exécution est configuré dans le lanceur lors de la construction (ou build) du Job. La balise --context= permet d’accéder au fichier de propriété du contexte contenant les clés (key) et valeurs (value) des variables dans le dossier import/monprojet/import_0_1/contexts. Il y a donc un ensemble de fichiers pour chaque Job déployé. Exemple :

#!/bin/sh
cd `dirname $0`
 ROOT_PATH=`pwd`
 java -Xms256M -Xmx1024M -cp $ROOT_PATH/../lib/mysql-connector-java-5.1.30-bin.jar:$ROOT_PATH/../lib/dom4j-1.6.1.jar:$ROOT_PATH:$ROOT_PATH/../lib/systemRoutines.jar::$ROOT_PATH/../lib/userRoutines.jar::.:$ROOT_PATH/contextes03_0_1.jar: tutorial.contextes03_0_1.Contextes03  --context=DEV "$@"

Fonctionnalité avec le composant tContextload

Certains utilisent le chargement des variables avec le composant tContextload au début de l’exécution du Job.

Il est alors alimenté soit par un fichier, soit par une requête SQL et (pourquoi pas?) un service web. Il faut alors définir les paires « key/value » dans le fichier ou la table de base de données.

Figure 2 – Job et schéma du composant tContextLoad

Là encore les informations d’accès au fichier ou à la base de données sont soit codées en dur, soit des variables de contexte. Pour centraliser les valeurs des variables de contextes, on peut utiliser soit une variable de contexte alimentée par le script du lanceur, soit un chemin ou une requête SQL identique entre les environnements d’exécution. Les informations ne sont pas paramétrables ou, si elles le sont, elles restent tout de mêmes lisibles, donc non sécurisées.

Deux avantages:

• les informations des données pour la production peuvent être totalement isolées des informations de développement ou de validation.
• les informations sont centralisées

TOS et le chargement de contexte implicite

Je vous propose maintenant d’aller plus loin dans l’utilisation du chargement des variables de contexte et leur sécurisation.

Le Studio propose, dans les propriétés du Job, de charger implicitement les valeurs des variables de contexte à partir d’un fichier ou d’une connexion à une base de données. Plus besoin de mettre un sous-Job initialisant le chargement des variables de contexte dans chaque Job.

Figure 3 – Configuration des propriétés du Job pour le chargement implicite des variables de contextes

Une autre fonctionnalité intéressante est la possibilité de définir ce chargement de ces valeurs pour l’ensemble du projet dans les préférences de celui-ci. Cela fonctionne alors sur le même principe que la gestion des logs et des statistiques. On systématise ainsi le chargement implicite qui, dès lors, sera automatiquement configuré dès la création de tout nouveau Job.

Figure 4 – Configuration des propriétés du projet pour le chargement implicite des variables de contextes

Le filtre Query Condition est défini dans notre exemple avec un contexte par défaut DEV.

En effet, nous allons construire (build) notre Job sans définir de contexte d’exécution :

• Il n’y a pas de dossier monprojet/monjob/contexts créé et donc de fichier .properties contenant les valeurs.
• Il n’y a pas non plus de --context dans le lanceur
• il faut donc alimenter la(les) variable(s) utilisée(s) par le filtre dans le lanceur avec le paramètre --context_param

voici un exemple du lanceur mon_job_run.sh:

#!/bin/sh
cd `dirname $0`
 ROOT_PATH=`pwd`
 java -Xms256M -Xmx1024M -cp $ROOT_PATH/../lib/mysql-connector-java-5.1.30-bin.jar:$ROOT_PATH/../lib/dom4j-1.6.1.jar:$ROOT_PATH:$ROOT_PATH/../lib/systemRoutines.jar::$ROOT_PATH/../lib/userRoutines.jar::.:$ROOT_PATH/contextes03_0_1.jar: tutorial.contextes03_0_1.Contextes03  --context_param Context=PROD "$@"

Effectuons un test à partir de la console :

Figure 5 – Test de notre Job avec chargement implicite des variables de contexte

La fenêtre retranscrit bien les valeurs attendues pour le contexte PROD. Aucunes de ces informations ne sont accessibles en-dehors de la table CONTEXT_ETL_CONFIG de notre base de données.

Ayant activé l’affichage des opérations dans le paramétrage du chargement implicite, nous pouvons remarquer que le Job va charger toutes les variables disponibles avec le filtre mais n’utilisera que celles qui lui sont propres.

Si vous utilisez un fichier de paramétrage au lieu de la connexion à une base de données, vous aurez un fichier unique, mais il faudra donner à sa variable de contexte le chemin relatif par rapport au lanceur ../conf/param.conf. Ce chemin sera alors codé en dur.

Afin de sécuriser nos fichiers, nous avons utilisé pour nos besoins la solution en logiciel libre Puppet Master. Il s’agit d’une solution de gestion de configuration permettant de valider un fichier par rapport à sa définition dans Puppet. Seule une demande à l’administrateur Puppet permet de modifier le fichier (nouvelles valeurs, nouveaux paramètres, etc.). Puppet validera et poussera toujours le fichier ainsi défini selon la planification demandée — quelques minutes avant le lancement du Job par exemple.

Il est donc possible de déployer en PROD avec le fichier de DEV et de définir les valeurs de PROD et de planifier la vérification du fichier dans Puppet.

Conclusion

• Nous avons vu évoluer le paramétrage de nos Jobs depuis des fichiers de configuration dispersés vers une centralisation des paramètres avec le chargement de contexte.
• Nous avons ensuite centralisé le chargement de contexte avec le contexte implicite dans les Jobs ou dans le projet dans un but de simplification des développements, du déploiement et de la maintenances des paramètres.
• Enfin, nous avons sécurisé les données des variables de contexte utilisées soit en base de données, soit dans un fichier, avec l’outil de contrôle et de gestion de configuration Puppet Master (merci à Christophe Imbaud du département Infrastructure de Savoir-Faire Linux pour cette contribution). 😉

Il faut donc réfléchir en amont à l’architecture des Jobs ou traitements déployés et leur sécurisation avant de démarrer votre projet, mais ceci est autre sujet… à suivre!