ETL

Installare Carte come servizio su Linux

Carte è un semplice servizio web utile per l’esecuzione remota delle trasformazioni ETL realizzate con Pentaho Data Integration (AKA Kettle). Delle potenzialità ho già discusso in questo articolo.

pentahoDI

In questo tutorial descrivo i passi per installarlo ed utilizzarlo su un sistema operativo Linux based.

Prerequisiti

  • Sistema operativo Linux installato
  • JDK 1.6 o superiore

Installazione Carte

1. Scaricare il pacchetto da sourceforge

cd /opt
wget http://softlayer-ams.dl.sourceforge.net/project/pentaho/Data%20Integration/5.0.1-stable/pdi-ce-5.0.1.A-stable.zip

2. Unzip

unzip pdi-ce-5.0.1.A-stable.zip

3. Creare il file configuration.xml in /opt/data-integration/

<slave_config>
<slaveserver>
  <name>192.168.1.3</name>
  <hostname>192.168.1.3</hostname>
  <port>8086</port>
</slaveserver>
</slave_config>

4. Utilizzare nohup per permettere l’esecuzione dell’applicazione anche a valle della disconnessione dal terminale ssh

nohup sh carte.sh configuration.xml &

5. Da un web browser collegarsi all’indirizzo (nel mio caso) http://192.168.1.3:8086, ed inserire le credenziali di default per accedere che sono

  • username = cluster
  • password = cluster

Configurazione Repository

1. Creare la cartella nascosta kettle sotto la root

cd /root
mkdir .kettle

2. In tale cartella creare il file repositories.xml con tutti i tag sufficienti e necessari alla configurazione della connessione al meta-database delle trasformazioni.

<?xml version="1.0" encoding="UTF-8"?>
<repositories>
  <connection>
    <name>pdidb</name>
    <server>192.168.1.3</server>
    <type>POSTGRESQL</type>
    <access>Native</access>
    <database>pdidb</database>
    <port>5432</port>
    <username>osdbms</username>
    <password>Encrypted 2beebc2bb44ca8788bf10ad75da9be18b</password>
    <servername/>
    <data_tablespace/>
    <index_tablespace/>
    <attributes>
      <attribute><code>FORCE_IDENTIFIERS_TO_LOWERCASE</code><attribute>N</attribute></attribute>
      <attribute><code>FORCE_IDENTIFIERS_TO_UPPERCASE</code><attribute>N</attribute></attribute>
      <attribute><code>IS_CLUSTERED</code><attribute>N</attribute></attribute>
      <attribute><code>PORT_NUMBER</code><attribute>5432</attribute></attribute>
      <attribute><code>PRESERVE_RESERVED_WORD_CASE</code><attribute>N</attribute></attribute>
      <attribute><code>QUOTE_ALL_FIELDS</code><attribute>N</attribute></attribute>
      <attribute><code>SUPPORTS_BOOLEAN_DATA_TYPE</code><attribute>Y</attribute></attribute>
      <attribute><code>SUPPORTS_TIMESTAMP_DATA_TYPE</code><attribute>Y</attribute></attribute>
      <attribute><code>USE_POOLING</code><attribute>N</attribute></attribute>
    </attributes>
  </connection>
  <repository>
  <id>KettleDatabaseRepository</id>
    <name>1000</name>
    <description>PDIDB</description>
    <connection>pdidb</connection>
  </repository>
</repositories>

3. Modificare il configuration.xml per indicare la presenza del repository

<slave_config>
<slaveserver>
  <name>192.168.1.3</name>
  <hostname>192.168.1.3</hostname>
  <port>8086</port>
</slaveserver>
<repository>
  <name>1000</name>
    <username>admin</username>
    <password>admin</password>
</repository>
</slave_config>

Modificare le credenziali di default

1. Generare una password da riga di comando utilizzando l’utility encr.sh

cd /opt/data-integration/
sh encr.sh -carte tuaPassword
OBF:1mpsdfsg323fsdmeww3356gfdf7

2. Editare il file kettle.pwd

nano /opt/data-integration/pwd/kettle.pwd

sostituendo la stringa ottenuta al punto precedente con quella esistente dopo

cluster:

Workaround

Criptazione password accesso repository

Probabilmente esistono altri metodi, ma essendo il tempo tiranno e trattandosi di un workaround, ho preferito prendere per buona questa soluzione che comunque è funzionale.

1. Avviare Spoon da un client con shell grafica installata

2. Collegarsi al repository

3. Dal menu Strumenti -> Repository, seleziona la voce Esplora

4. Dal pannello Security seleziona l’utente admin e modificare la password facendola coincidere con quella dell’utente dbms con la quale ci si connette al repository

5. Copiare dal file repositories.xml la password criptata nella definizione della connessione in configuration.xml

<slave_config>
<slaveserver>
  <name>192.168.1.3</name>
  <hostname>192.168.1.3</hostname>
  <port>8086</port>
</slaveserver>
<repository>
  <name>1000</name>
    <username>admin</username>
    <password>Encrypted 2beebc2bb44ca8788bf10ad75da9be18b</password>
</repository>
</slave_config>

Avviare Carte al boot del sistema operativo

1. Editare il file rc.local

nano /etc/rc.local

2. Aggiungere le seguenti righe alla fine

cd /opt/data-integration
sh carte.sh configuration.xml & exit

In alternativa è possibile definire uno script in etc/init.d e successivamente aggiungerlo al corretto runlevel, ma ho avuto diversi problemi nella definizione di una strategia per stoppare il servizio di Carte (cosa che a quanto so può farsi via API da JAVA ma… è un altro post).
La premessa è che ovviamente non esiste uno script sh per farlo e/o fornito nel bundle.
Ho provato con la scrittura del pid in un file, in fase di start, e successiva lettura durante la fase di stop per killare il processo. Tuttavia, dopo aver “sbattuto la testa” ho compreso che il pid salvato era quello del processo sh che avvia lo script per il lancio di Carte.

Stoppare Carte uccidendo l’istanza java giusta

Può capitare che si abbia la necessità di riavviare l’istanza del database dove risiede il repository. Tale operazione, ovviamente, fa perdere la connessione a Carte con il risultato che ogni chiamata remota non viene gestita.

Se sulla macchina Linux dove stiamo lavorando è presente anche Apache Tomcat (ovvero altri programmi che usano Java) all’avvio, dopo aver svolto le operazioni nel punto precedente, avrò due (ovvero n) istanze java, una lanciata dal servizio Tomcat e l’altra dallo script che avvia Carte.

L’unica strategia possibile per stoppare carte “a caldo” che ho trovato è la seguente:

1. Salvare il pid dello script all’avvio sostituendo in /etc/rc.local

sh carte.sh configuration.xml & exit

con

sh carte.sh configuration.xml & echo $$ > carte.pid & exit

2. Trovare il processo java con il pid più prossimo rispetto a quello salvato

ps -C java -o pid

3. Fare un kill del processo java

kill -9 <pid>

Sicuramente un esperto di script bash sa fare di meglio.

Chiunque avanzi una soluzione alternativa è benvenuto.

AGGIORNAMENTO DEL 15/12/2016

Meglio tardi che mai. La soluzione per riavviare Carte come servizio la trovi a questo articolo.