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

Logo TalendDans 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

Job et utilisation des variables
Les variables de contexte du Job
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.

Job utilisant le tContextLoad

Schéma du composant tContextLoad
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.

Configuration des propriétés du Job pour le chargement implicite des variables de contextes
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.

Configuration des propriétés du projet pour le chargement implicite des variables de contextes
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 :

Test de notre Job avec chargement implicite des variables de contexte
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!

Talend et Savoir-faire Linux : un partenariat visionnaire pour vos projets BI et «Big Data»

TalendL’éditeur Talend, chef de file de l’intégration de données dans le monde du logiciel libre, sera de nouveau présent, cette année, au Salon du BI et de l’analytique qui a lieu mercredi prochain à Montréal. En compagnie de Jim Battista, je serai heureux de vous accueillir à notre kiosque conjoint afin de vous éclairer sur les outils et solutions d’analytique qu’ensemble, nous proposons.

À l’ère des données massives, en effet, le partenariat entre un éditeur comme Talend et un intégrateur comme Savoir-faire Linux est complémentaire. Dans cette entrevue vidéo réalisée à notre bureau de Montréal il y a quelques semaines, Pete Chamberlin et Jim Battista décrivent les avantages d’un tel partenariat dans le contexte du « Big Data » :

La vidéo est sous-titrée en français ➚  cc  ➚ English subtitles available

Plomberie et câblage: une plate-forme unifiée

Comme le font souvent remarquer les professionnels, les données massives ne sont pas vraiment une nouveauté. Ce qui les rend très « tendance », aujourd’hui, c’est que l’apparition de l’infonuagique et de la mobilité en ont fait exploser la masse et la portée, tant ce ce qui concerne les produits que les utilisateurs. En tirer un avantage concurrentiel n’est pas une mince affaire, mais grâce notamment aux technologies ouvertes comme Talend, il est devenu beaucoup moins coûteux de se lancer dans l’aventure.

Talend est reconnu comme visionnaire de quatre Magic Quadrant de Gartner : Data Integration (DI), Data Quality (DQ), Enterprise Service Bus (ESB) et Master Data Management (MDM). Talend développe en fait des outils permettant de collecter et de standardiser tous les type de données afin de les intégrer dans de puissants outils d’analyse. Le succès de sa plate-forme unifiée provient de ces capacités, complémentaires à la qualité de données, de standardisation et de traitement cognitif de l’information, incluant le MDM et le temps réel, qui permettent d’ajuster les outils d’analyse en fonction du contexte et de la stratégie de chaque entreprise.

« Nous décrivons parfois notre plate-forme technologique comme la plomberie et le câblage électrique fournissant des données à l’environnement Big Data de Hadoop et permettant d’en extraire, de les intégrer en-dehors de la plate-forme de données massives afin que des partenaires, comme Savoir-faire Linux, disposent des moyens d’accès aux données dont ils ont besoin pour créer des outils d’analyse appropriés. Ensemble, nous offrons une grande valeur à nos clients. » – Pete Chamberlin (Talend)

L’intégration au service de votre stratégie

Pour être plus précis, voici un peu l’étendue de notre rôle de partenaire :

  • Aide aux choix technologiques et à l’acquisition des compétences nécessaires à l’utilisation de la plate-forme ;
  • Accompagnement dans la gestion de projets d’intégration des données DI-MDM-ESB ;
  • Infrastructure Hadoop et Openstack ;
  • Integration Java des interfaces Web ;
  • Intégration dans un portail d’analyse (exemple: Liferay) ;
  • Mise en œuvre des outils de référence (ex: JasperReport) et d’analytique (ex: SpagoBI, Pentaho) ;
  • Gestion des données inter-applicative comme la gestion de projet, la facturation et la paie ;

Jim et moi serons heureux d’en discuter avec vous et de vous présenter la plate-forme ainsi que quelques exemples d’exploitation concrets lors du salon, si vous y participez. Sinon, n’hésitez pas à m’écrire directement ou me téléphoner au poste 308 pour me faire part de vos besoins.