Docker compose

27 novembre 2015 littlewing 1 commentaire

Me voilà avec mes images docker réalisées. Maintenant, il faut les lier entre elles et packager le tout.

J’ai choisi d’utiliser docker-compose. c’est l’outil standard fourni par docker. Sa principale lacune est que cet outil ne s’exécute que localement. En gros, on ne pourra pas utiliser docker-compose pour exécuter de manière distribuée les différents containers (ex. la base de données sur un nœud, le serveur web sur un autre,…). Pour mon POC je n’ai pas trop besoin de ça et, il faut le dire, j’ai un peu la flemme d’installer des softs comme kubernetes.

Je ne décrirai pas l’installation. C’est beaucoup mieux fait ici.

Je mettrai prochainement le code sur github. Je pense que le code sera mis à jour ultérieurement. Il se peut donc que certains exemples de cet articles soient obsolètes.

Définition des différents composants

J’ai trois composants :

une instance rabbitmq qui réceptionne des messages via le protocole MQTT
elasticsearch qui stocke les différents évènements et les mets à disposition
un programme s’appuyant sur spark-streaming qui se connecte à rabbitmq , transforme les évènements réceptionnés et les envoient dans elasticsearch.

La spécification des différents composants se fait par un fichier docker-compose.yml qui est dans le répertoire racine.

Je spécifie les images que je souhaite construire, les ports exposés et les variables d’environnement

Le fichier docker-compose.yml

elasticsearch:
  build: ./elasticsearch-marvel
  ports: 
    - "9200:9200"
    - "9300:9300"
  environment:
    HOSTNAME: 127.0.0.1

rabbitmq:
  build: ./rabbitmq-mqtt
  ports:
    - "1883:1883"
    - "15672:15672"
    - "5672:5672"
    
iot-etl:
  build: ./iot-etl

elasticsearch:

build: ./elasticsearch-marvel

ports:

- "9200:9200"

- "9300:9300"

environment:

HOSTNAME: 127.0.0.1

rabbitmq:

build: ./rabbitmq-mqtt

ports:

- "1883:1883"

- "15672:15672"

- "5672:5672"

iot-etl:

build: ./iot-etl

elasticsearch

J’ai surchargé l’image officielle d’elasticsearch en ajoutant un fichier de configuration personnalisé et en installant le plugin shield et marvel. Voici le dockerfile:

FROM elasticsearch:1.7

EXPOSE 9200 9300
ADD install_plugins /usr/share/elasticsearch/setup
RUN ls -al /usr/share/elasticsearch/setup/license.zip
RUN /usr/share/elasticsearch/bin/plugin install file:///usr/share/elasticsearch/setup/license.zip
RUN /usr/share/elasticsearch/bin/plugin install file:///usr/share/elasticsearch/setup/marvel-agent.zip

ADD config/elasticsearch.yml /usr/share/elasticsearch/config/

FROM elasticsearch:1.7

EXPOSE 9200 9300

ADD install_plugins /usr/share/elasticsearch/setup

RUN ls -al /usr/share/elasticsearch/setup/license.zip

RUN /usr/share/elasticsearch/bin/plugin install file:///usr/share/elasticsearch/setup/license.zip

RUN /usr/share/elasticsearch/bin/plugin install file:///usr/share/elasticsearch/setup/marvel-agent.zip

ADD config/elasticsearch.yml /usr/share/elasticsearch/config/

Rabbitmq

Ici j’ai souhaité ajouter deux utilisateurs au démarrage du container

FROM rabbitmq:3-management

ENV RABBITMQ_DEFAULT_USER user
ENV RABBITMQ_DEFAULT_PASS password
EXPOSE 1883

# activation mqtt
RUN rabbitmq-plugins enable rabbitmq_mqtt

# Add script to create default users / vhosts
ADD init.sh /init.sh

# Set correct executable permissions
RUN chmod +x /init.sh

CMD ["/init.sh"]

FROM rabbitmq:3-management

ENV RABBITMQ_DEFAULT_USER user

ENV RABBITMQ_DEFAULT_PASS password

EXPOSE 1883

# activation mqtt

RUN rabbitmq-plugins enable rabbitmq_mqtt

# Add script to create default users / vhosts

ADD init.sh /init.sh

# Set correct executable permissions

RUN chmod +x /init.sh

CMD ["/init.sh"]

La configuration se fait dans le fichier init.sh

#!/bin/sh

( sleep 10 ; \

rabbitmqctl add_user guest  ; \
rabbitmqctl add_user user password  ; \
rabbitmqctl clear_password guest ;\
rabbitmqctl set_user_tags guest administrator ; \
rabbitmqctl set_user_tags user administrator ; \
rabbitmqctl set_permissions -p / guest ".*" ".*" ".*" ; \
rabbitmqctl set_permissions -p / user ".*" ".*" ".*" ; \
rabbitmqctl list_permissions -p /
) &amp;    
rabbitmq-server $@

#!/bin/sh

( sleep 10 ; \

rabbitmqctl add_user guest ; \

rabbitmqctl add_user user password ; \

rabbitmqctl clear_password guest ;\

rabbitmqctl set_user_tags guest administrator ; \

rabbitmqctl set_user_tags user administrator ; \

rabbitmqctl set_permissions -p / guest ".*" ".*" ".*" ; \

rabbitmqctl set_permissions -p / user ".*" ".*" ".*" ; \

rabbitmqctl list_permissions -p /

) &

rabbitmq-server $@

Spark

Enfin mon code scala qui exécute SPARK est packagé sous qui la forme d’un JAR qui contient toutes les dépendances.

Le dockerfile correspondant

FROM java:openjdk-8-jdk
RUN wget -cqO /tmp/iot-etl-allinone.jar http://URL/iot-etl-1.0-20151127.123518-6-allinone.jar
CMD ["java","-jar","/tmp/iot-etl-allinone.jar"]

FROM java:openjdk-8-jdk

RUN wget -cqO /tmp/iot-etl-allinone.jar http://URL/iot-etl-1.0-20151127.123518-6-allinone.jar

CMD ["java","-jar","/tmp/iot-etl-allinone.jar"]

Je ne décrirai pas le code ici. Peut-être dans un futur article.

Construction

docker-compose build

1	docker-compose build

Exécution

docker-compose up

1	docker-compose up

Atom derrière un proxy d’entreprise

19 novembre 2015 littlewing Laisser un commentaire

Je n’ai pas trop d’inspiration en ce moment….

J’ai néanmoins une petite manipulation utile si vous utilisez l’éditeur atom en entreprise. Dans ma boite, il y a un proxy. Pour télécharger les packages et thèmes il est nécessaire de paramétrer les URLS du proxy.

Voici la manipulation :

Créer un fichier .apmrc dans le répertoire $HOME/.atom ou c:/Users/monutilisateur/.atom sous windows avec le contenu suivant :

strict-ssl = false
http_proxy = http://user:password@host:port/
https_proxy = http://user:password@host:port/
proxy = http://user:password@host:port/

strict-ssl = false

http_proxy = http://user:password@host:port/

https_proxy = http://user:password@host:port/

proxy = http://user:password@host:port/

Redémarrer atom et dorénavant, vous pouvez télécharger les packages à travers le proxy.

Créer une image docker d’elasticsearch avec marvel préinstallé

23 octobre 2015 littlewing Laisser un commentaire

Je fais suite à un précédent post sur elasticsearch et docker.

Il existe déjà des images docker pré configurées avec elasticsearch et marvel. Cependant, il n’en existe pas d’officielles et celle qu’il y a ne me conviennent pas trop.

J’ai décidé de créer une image se basant sur une archive de marvel pré-téléchargée.

Dans un répertoire, j’ai ajouté un répertoire install_plugins avec le zip de marvel installé ( je pourrai installer ensuite les plugins shield et license)

Voici le contenu du fichier Dockerfile:

FROM elasticsearch
 MAINTAINER alexandre &lt;&gt;
 ENV HOSTNAME 127.0.0.1
 EXPOSE 9200 9300
 ADD install_plugins /usr/share/elasticsearch/setup
 RUN /usr/share/elasticsearch/bin/plugin -i marvel -u file:///usr/share/elasticsearch/setup/marvel-latest.zip

FROM elasticsearch

MAINTAINER alexandre <>

ENV HOSTNAME 127.0.0.1

EXPOSE 9200 9300

ADD install_plugins /usr/share/elasticsearch/setup

RUN /usr/share/elasticsearch/bin/plugin -i marvel -u file:///usr/share/elasticsearch/setup/marvel-latest.zip

Ma configuration SBT

15 octobre 201515 octobre 2015 littlewing Laisser un commentaire

SBT est l’outil standard de build de l’écosystème scala ( et pas que… ).

Afin de « l’acclimater » à la vie en entreprise, j’ai du faire quelques modifications. Elles sont adaptées pour les configurations des développeurs utilisant:

maven
un référentiel partagé (nexus, artifactory)

Pour info, j’ai souhaité déplacer le cache ivy dans un autre répertoire. Par défaut, c’est dans le répertoire $HOME/.ivy.

Créer le fichier sbt.boot.properties dans le répertoire $SBT_HOME/bin

...
[scala][/scala]

version: ${sbt.scala.version-auto}
[boot]
directory: ${sbt.boot.directory-${sbt.global.base-${user.home}/.sbt}/boot/}

[app]
org: ${sbt.organization-org.scala-sbt}
name: sbt
version: ${sbt.version-read(sbt.version)[0.13.5]}
class: ${sbt.main.class-sbt.xMain}
components: xsbti,extra
cross-versioned: ${sbt.cross.versioned-false}

[ivy]
ivy-home: d:/emplacement_du_cache_ivy
[repositories]
local
maven-local: file:///d:/referentiel_local_maven
sihm-proxy: http://monreferentiel/nexus/content/groups/public

...

[scala][/scala]

version: ${sbt.scala.version-auto}

[boot]

directory: ${sbt.boot.directory-${sbt.global.base-${user.home}/.sbt}/boot/}

[app]

org: ${sbt.organization-org.scala-sbt}

name: sbt

version: ${sbt.version-read(sbt.version)[0.13.5]}

class: ${sbt.main.class-sbt.xMain}

components: xsbti,extra

cross-versioned: ${sbt.cross.versioned-false}

[ivy]

ivy-home: d:/emplacement_du_cache_ivy

[repositories]

local

maven-local: file:///d:/referentiel_local_maven

sihm-proxy: http://monreferentiel/nexus/content/groups/public

Dans le fichier sbt.bat j’ai ajouté au début le fichier suivant :

set SBT_OPTS=-Dsbt.boot.properties=sbt.boot.properties

1	set SBT_OPTS=-Dsbt.boot.properties=sbt.boot.properties

Elasticsearch avec Docker

9 octobre 2015 littlewing Laisser un commentaire

Comme évoqué dans un précédent article, j’ai décidé de me mettre (modestement) à Docker. Comme je devais utiliser elasticsearch pour un projet, j’ai dit pourquoi pas utiliser l’image docker. Voici les actions que j’ai réalisé et le (petit) problème vite résolu.

Installation

Que du simple et du basique. elastic.co fournit une image officielle.

$ docker pull elasticsearch

1	$ docker pull elasticsearch

Problème de binding réseau

Si je démarre l’instance de manière classique, j’ai un petit soucis de binding réseau. En effet, l’instance Docker positionne le hostname à 172.17.0.1 et … ça occasionne quelques soucis lors de l’appel à mon cluster (ex.: timeout, impossibilité de joindre le cluster, catastrophe nucléaire,…).

Si on exécute la requête suivante : http://localhost:9200/_nodes/process?pretty on obtient :

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "22UAJOAUSK6931WBFBvZtQ" : {
      "name" : "Blind Faith",
      "transport_address" : "inet[<strong>/172.17.0.1:9300]</strong>",
      "host" : "710b5c9bff05",
      "ip" : "172.17.0.1",
      "version" : "1.7.2",
      "build" : "e43676b",
      "http_address" : "inet[/<strong>172.17.0.1:9200</strong>]",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 1,
        "max_file_descriptors" : 1048576,
        "mlockall" : false
      }
    }
  }
}

{

"cluster_name" : "elasticsearch",

"nodes" : {

"22UAJOAUSK6931WBFBvZtQ" : {

"name" : "Blind Faith",

"transport_address" : "inet[<strong>/172.17.0.1:9300]</strong>",

"host" : "710b5c9bff05",

"ip" : "172.17.0.1",

"version" : "1.7.2",

"build" : "e43676b",

"http_address" : "inet[/<strong>172.17.0.1:9200</strong>]",

"process" : {

"refresh_interval_in_millis" : 1000,

"id" : 1,

"max_file_descriptors" : 1048576,

"mlockall" : false

}

Bref, ça ne le fait pas. Pour pouvoir utiliser cette image sans avoir à créer ma propre image, j’ai donc positionné les variables HOSTNAME, es.network.bind_host et es.network.host au démarrage de la machine.

docker run -i -t -d --name elasticsearch -p 9200:9200 \
-e HOSTNAME=127.0.0.1 elasticsearch -Des.network.bind_host=0.0.0.0 \
-Des.network.host=127.0.0.1

docker run -i -t -d --name elasticsearch -p 9200:9200 \

-e HOSTNAME=127.0.0.1 elasticsearch -Des.network.bind_host=0.0.0.0 \

-Des.network.host=127.0.0.1

Maintenant j’ai la configuration suivante :

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "0g0flJVhQ8qtH7fRFqywvQ" : {
      "name" : "Sweetface",
      "transport_address" : "inet[/127.0.0.1:9300]",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1",
      "version" : "1.7.2",
      "build" : "e43676b",
      "http_address" : "inet[/127.0.0.1:9200]",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 1,
        "max_file_descriptors" : 1048576,
        "mlockall" : false
      }
    }
  }
}

{

"cluster_name" : "elasticsearch",

"nodes" : {

"0g0flJVhQ8qtH7fRFqywvQ" : {

"name" : "Sweetface",

"transport_address" : "inet[/127.0.0.1:9300]",

"host" : "127.0.0.1",

"ip" : "127.0.0.1",

"version" : "1.7.2",

"build" : "e43676b",

"http_address" : "inet[/127.0.0.1:9200]",

"process" : {

"refresh_interval_in_millis" : 1000,

"id" : 1,

"max_file_descriptors" : 1048576,

"mlockall" : false

}

Extraire les données d’une base de données relationnelle avec Spark

7 octobre 2015 littlewing Laisser un commentaire

Me voila en train de tester Apache Spark.

Pour info, Spark est un projet libre du consortium Apache qui a le vent en poupe depuis quelques temps. Il permet entre autres de réaliser des opérations de type Map Reduce en mémoire

Je souhaite automatiser le chargement de données dans ELASTIC SEARCH et faire au passage un petit map reduce sur les données en entrée.

Voici ce que j’ai fait pour extraire les données d’une base relationnelle ORACLE via JDBC. Bien évidemment, ça fonctionne avec toutes les autres SGBDR accessibles via JDBC.

Configuration de Spark

J’utilise le mode « autonome » de spark, c.-à.d sans cluster hadoop.

Pour l’instant, je n’utilise que les modules streaming et sql.

Au préalable , il faut configurer la variable d’environnement SPARK_CLASSPATH et ajouter le chemin vers le driver JDBC

Je n’ai pas téléchargé la distribution car j’utilise spark au travers des librairies utilisées dans mon programme.

Développement

J’ai décidé d’utiliser le langage SCALA pour développer mon module. Pourquoi SCALA me direz vous ? Parce que ça fait quelques années que je me dis que je dois m’y mettre ( peut être est-ce trop tard ….) et que selon plusieurs commentaires que j’ai pu avoir au DEVOXX, SCALA est clairement plus adapté aux traitements réalisés par SPARK

Dépendances

Voici la configuration de mon ~~pom.xml~~ build.sbt :

scalacOptions ++= Seq("-feature", "-language:postfixOps","-language:existentials")

libraryDependencies &lt;&lt;= scalaVersion { scala_version =&gt;
  val sparkVersion = "1.5.1"
  Seq(
    "org.scalatest" %% "scalatest" % "2.2.5" % "test",
    "org.scalamock" %% "scalamock-scalatest-support" % "3.2" % "test",
    "junit" % "junit" % "4.11" % "test",
    "org.apache.spark" %% "spark-streaming" % sparkVersion,
    "org.apache.spark" %% "spark-sql" % sparkVersion,
    "org.apache.spark" %% "spark-core" % sparkVersion,
    "com.typesafe" % "config" % "1.3.0",
    "com.oracle.weblogic" % "ojdbc7" % "12.1.3-0-0"
  )
}

scalacOptions ++= Seq("-feature", "-language:postfixOps","-language:existentials")

libraryDependencies <<= scalaVersion { scala_version =>

val sparkVersion = "1.5.1"

Seq(

"org.scalatest" %% "scalatest" % "2.2.5" % "test",

"org.scalamock" %% "scalamock-scalatest-support" % "3.2" % "test",

"junit" % "junit" % "4.11" % "test",

"org.apache.spark" %% "spark-streaming" % sparkVersion,

"org.apache.spark" %% "spark-sql" % sparkVersion,

"org.apache.spark" %% "spark-core" % sparkVersion,

"com.typesafe" % "config" % "1.3.0",

"com.oracle.weblogic" % "ojdbc7" % "12.1.3-0-0"

)

}

Pour l’exemple, voici une classe « fourre tout » qui montre le chargement de Spark ainsi que l’extraction des données

/**
 * Classe démontrant l'extration des données d'une base de données sous la forme d'un dataframe
 */
object RDDTest {

  def main(args: Array[String]) {
    // configuration
    val sparkconf = new SparkConf().setAppName("dao").setMaster("local[2]")
    // chargement du contexte
    val sparkContext = SparkContext.getOrCreate(sparkconf)
    /*
    enregistrement du dialecte oracle pour pallier a un bug sur les NUMERIC
         */

    JdbcDialects.registerDialect(new OracleDialect())
    // chargement du contexte SPARK SQL
    val sqlcontext = new SQLContext(sparkContext)


    // lecture des données
    val data = sqlcontext.read.format("jdbc")
           .options(Map("url" -&gt; "jdbc:oracle:thin:@host:1521/schema",
      "dbtable" -&gt; "(SELECT col1,col2 FROM table)",
      "user" -&gt; "user",
      "password" -&gt; "pwd")).load()

    println("data.collectAsList()=" + data.collectAsList())

  }
}

/**

* Classe démontrant l'extration des données d'une base de données sous la forme d'un dataframe

object RDDTest {

def main(args: Array[String]) {

// configuration

val sparkconf = new SparkConf().setAppName("dao").setMaster("local[2]")

// chargement du contexte

val sparkContext = SparkContext.getOrCreate(sparkconf)

enregistrement du dialecte oracle pour pallier a un bug sur les NUMERIC

JdbcDialects.registerDialect(new OracleDialect())

// chargement du contexte SPARK SQL

val sqlcontext = new SQLContext(sparkContext)

// lecture des données

val data = sqlcontext.read.format("jdbc")

.options(Map("url" -> "jdbc:oracle:thin:@host:1521/schema",

"dbtable" -> "(SELECT col1,col2 FROM table)",

"user" -> "user",

"password" -> "pwd")).load()

println("data.collectAsList()=" + data.collectAsList())

}

Problèmes rencontrés

Gestion des champs numériques

Comme évoqué ci-dessus, j’ai eu un bug sur la gestion des NUMERIC ,

IllegalArgumentException: requirement failed: Overflowed precision

1	IllegalArgumentException: requirement failed: Overflowed precision

Comme moyen de contournement, j’ai (après quelques recherches sur le net) opté pour surcharger le dialecte JDBC:

class OracleDialect extends JdbcDialect {
  override def canHandle(url: String): Boolean = url.startsWith("jdbc:oracle")

  override def getCatalystType(sqlType: Int, typeName: String, size: Int, md: MetadataBuilder): Option[DataType] = {
    if (sqlType == Types.NUMERIC &amp;&amp; typeName == "NUMBER" &amp;&amp; size == 0) Some(LongType) else None
  }
}

class OracleDialect extends JdbcDialect {

override def canHandle(url: String): Boolean = url.startsWith("jdbc:oracle")

override def getCatalystType(sqlType: Int, typeName: String, size: Int, md: MetadataBuilder): Option[DataType] = {

if (sqlType == Types.NUMERIC && typeName == "NUMBER" && size == 0) Some(LongType) else None

}

et enregistré le dialecte à l’exécution

 JdbcDialects.registerDialect(new OracleDialect())

1	JdbcDialects.registerDialect(new OracleDialect())

Présence du binaire winutils.exe sur windows 7 64bits

Si comme moi vous avez le bug référencé sur le JIRA du projet, il suffit de télécharger le binaire winutils.exe, puis de positionner la variable d’environnement au démarrage en mettant le bon chemin ( attention, il faut un sous répertoire « bin’ .

System.setProperty("hadoop.home.dir", "d:\\winutil\\")

1	System.setProperty("hadoop.home.dir", "d:\\winutil\\")

And now, something completely different

Outre les difficultés liées à l’apprentissage simultané de plusieurs technologies, on y arrive. Le projet est bien documenté.

Maintenant, je vais créer plusieurs indicateurs et faire un chargement dans Elasticsearch. Je décrirai ça dans un prochain article

Comment customiser une image Docker

9 septembre 201515 septembre 2015 littlewing Laisser un commentaire

Je suis actuellement en train de me mettre sur Docker. En résumé (Wikipedia le fait mieux que moi), Docker est une solution libre de virtualisation qui optimise le déploiement des applications en virtualisation un peu tout l’OS, la base de données, le serveur d’application et soyons fous le poste de développeur.

Au Devoxx 2015, c’était le sujet Hype du moment.

J’ai décidé de me lancer sur ce sujet car je suis en train d’expérimenter quelques technos (MQTT entre autres) et les installations m’exaspèrent…

Bon voila mon problème, pour faire un POC, j’ai voulu installer rabbitmq et ajouter quelques configurations supplémentaires

Activation du plugin mqtt
Activation de la console d’administration
Paramétrage d’un utilisateur pouvant accéder à la console

Pré requis

vérifier que docker est bien installé sur votre poste.

docker pull hello-world

1	docker pull hello-world

Perso, j’utilise pour cela Debian (what else ) 8.0.

Construction de l’image

$ mkdir rabbitmq-mqtt 
$ touch Dockerfile

1 2	$ mkdir rabbitmq-mqtt $ touch Dockerfile

Dans le fichier Dockerfile

FROM rabbitmq:3-management
MAINTAINER Votre serviteur &lt;alexandre@test&gt; 
ENV RABBITMQ_DEFAULT_USER user
ENV RABBITMQ_DEFAULT_PASS password
EXPOSE 18883
RUN rabbitmq-plugins enable rabbitmq_mqtt

FROM rabbitmq:3-management

MAINTAINER Votre serviteur <alexandre@test>

ENV RABBITMQ_DEFAULT_USER user

ENV RABBITMQ_DEFAULT_PASS password

EXPOSE 18883

RUN rabbitmq-plugins enable rabbitmq_mqtt

En résumé, j’utilise l’image Docker officielle rabbitmq, j’ajoute deux variables d’environnement spécifiant les utilisateurs et je lance une commande permettant d’activer le support de mqtt

Ensuite, il suffit de construire l’image dans le répertoire crée

$ docker build -t alexandre/rabbitmq-mqtt .

1	$ docker build -t alexandre/rabbitmq-mqtt .

Sending build context to Docker daemon 3.072 kB
Sending build context to Docker daemon
Step 0 : FROM rabbitmq:3-management
---&gt; 327b803301e9
Step 1 : MAINTAINER Votre serviteur &lt;alexandre@test&gt;
---&gt; Using cache
---&gt; f660ca254f19
Step 2 : ENV RABBITMQ_DEFAULT_USER user
---&gt; Using cache
---&gt; e54a1a4ea60f
Step 3 : ENV RABBITMQ_DEFAULT_PASS password
---&gt; Using cache
---&gt; 44050e7fc3a2
Step 4 : RUN rabbitmq-plugins enable rabbitmq_mqtt
---&gt; Using cache
---&gt; bdd369338fec
Successfully built bdd369338fec

Sending build context to Docker daemon 3.072 kB

Sending build context to Docker daemon

Step 0 : FROM rabbitmq:3-management

---> 327b803301e9

Step 1 : MAINTAINER Votre serviteur <alexandre@test>

---> Using cache

---> f660ca254f19

Step 2 : ENV RABBITMQ_DEFAULT_USER user

---> Using cache

---> e54a1a4ea60f

Step 3 : ENV RABBITMQ_DEFAULT_PASS password

---> Using cache

---> 44050e7fc3a2

Step 4 : RUN rabbitmq-plugins enable rabbitmq_mqtt

---> Using cache

---> bdd369338fec

Successfully built bdd369338fec

Et voilà, il ne reste plus qu’à exécuter un container basé sur cette image

$ docker run --rm -p 8080:15672  alexandre/rabbitmq-mqtt

1	$ docker run --rm -p 8080:15672 alexandre/rabbitmq-mqtt

Conclusion

on peut voir que l’ajout de fonctionnalités supplémentaires est assez facile avec docker. L’exemple est volontairement simpliste. Il existe également docker-compose qui permet de faire la même chose ( et + encore) en étant beaucoup plus puissant dans la gestion des dépendances

Premiers pas avec Cassandra

21 juillet 201524 juillet 2015 littlewing Laisser un commentaire

Lors de la conférence BIG DATA PARIS 2015, j’ai rencontré l’éditeur de la base NoSQL CASSANDRA (DATASTAX). J’ai pu échanger avec eux sur leur solution et les avantages.
Il y a pas mal de choses qui m’ont séduites:

Le mode colonne
L’interfaçage CQL qui ressemble un peu au SQL
L’UPDATE qui gère l’insertion si la ligne n’existe pas
La scalabilité linéaire
L’interface graphique du OpsCenter
Leur documentation que je trouve bien foutue

Après avoir eu les yeux qui ont brillé, le retour à la réalité m’ a permis de voir que pas mal de restrictions existaient:

Certaines briques permettant l’intégration ( apache camel, logstash,…) ne permettent pas de se connecter à cassandra. Il faut le faire via leur API
Datastax ne fournit pas une solution de reporting intégrée comme mongodb. On peut utiliser JasperReports pour cela.
On ne peut pas générer automatiquement une colonne via le mode d’interfaçace CQL. On peut néanmoins contourner le problème via une MAP
…

Bref, plein de petits détails qui je pense vont à mon avis être oublié dès lors que je maitriserai un peu plus la technologie.

Je ne vais pas mettre d’exemple dans cet article car je n’ai pas encore trop de matière. Je le ferais sans doute dans un prochain article.

Si vous voulez en savoir un peu plus, allez sur leur site, c’est très bien expliqué.

Créer des batchs avec JAVABATCH – JSR352

8 juillet 20158 juillet 2015 littlewing Laisser un commentaire

Je suis actuellement en train de tester la JSR 352 ( ou JAVA BATCH). Cette API est une des nouveautés de la spécification JAVA EE 7. Elle permet ( entre autres ) de lancer des BATCHS depuis un serveur JEE.

Mais vous allez me dire : il y a SPRING BATCH ! Oui, JAVA BATCH est une standardisation de JAVA BATCH avec l’ intégration du moteur dans un serveur JEE. D’ailleurs, SPRING BATCH est désormais compatible avec cette API.

Ce dernier offre la possibilité de contrôler l’état des jobs à travers l’outil d’administration du serveur via le JOB REPOSITORY.

Pour ceux qui connaissent SPRING BATCH et le monde chatoyant des ETL, le concept de la JSR 352 sera assez simple à appréhender :

Un batch est spécifié avec un job qui a plusieurs steps qui sont découpés en étapes de lecture, de transformation et de chargement (ETL).

Avantages

Les principaux avantages à faire tourner les batchs dans un contexte JEE ( si si il y en a ) sont les suivants :

On peut utiliser l’outillage du serveur pour monitorer les jobs
On dispose de toute la stack JEE (CDI, JPA, JTA,JAX-RS,…) pour développer des batchs
Un batch peut être déclenché de plusieurs manières (script, service REST,…)
Par rapport aux solutions ETL du marché, on peut avoir des tests unitaires, de la qualimétrie de code avec SONARQUBE,…

Inconvénients

C’est une V1. Il y a encore des choses à améliorer ( gestion des properties par ex)

Définition d’un job

Le job se définit par un fichier XML

    <job id="myJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
  <properties>
        <property name="DATE" value="#{jobParameters['DATE']}"/>
    </properties>

    <step id="extract-all-stats">
        <chunk item-count="2">
            <reader ref="myReader">
                <properties>
                    <property name="PROP" value="#{partitionPlan['PROP']}"/>
                </properties>
            </reader>
            <writer ref="myWriter">
            </writer>
        </chunk>
        <partition>
            <mapper ref="myPartitionMapper">
            </mapper>
        </partition>
    </step>
</job>

</properties>

</properties>

</reader>

</writer>

</chunk>

</mapper>

</partition>

</step>

</job>

Les références des différents élements font appel aux références des beans CDI développés. Dans mon exemple, je n’ai pas utilisé de processor car je ne devais pas transformer les données. J’ai cependant eu besoin de séparer les différents traitements en les parallélisant dans des partitions. Pour déterminer les données de chaque partition, j’ai utilisé un mapper.

Le reader

@Named
@Dependent
public class MyReader extends AbstractItemReader {

    @Inject
    JobContext jobContext;
    @Inject
    StepContext stepContext;

    @Inject
    @BatchProperty(name = "PROP")
    String service;

    @Override
    public void open(Serializable serializable) throws Exception {
   // charge toutes les données
    }

    @Override
    public Object readItem() throws Exception {
// lit les données chargées
    }
}

@Named

@Dependent

public class MyReader extends AbstractItemReader {

@Inject

JobContext jobContext;

@Inject

StepContext stepContext;

@Inject

@BatchProperty(name = "PROP")

String service;

@Override

public void open(Serializable serializable) throws Exception {

// charge toutes les données

}

@Override

public Object readItem() throws Exception {

// lit les données chargées

}

On voir dans l’exemple que l’injection se fait par CDI. Il faut spécifier le scope Dependent pour que les beans soient accessibles dans le contexte BATCH.

La récupération des données se fait via la méthode open(). Logiquement , on doit récupérer toutes les données à ce moment. Ca peut être problématique avec des très grosses volumétries . Dans ce cas on pourra privilégier le lazy loading.

La lecture de chaque item (ex. une ligne ) se fait dans la méthode readItem(). L’une des choses que je trouve un peu dommage dans l’API BATCH est le manque de générique. En effet, ça aurait été un peu plus « sympa » d’avoir une classe AstractItemReader<T> qui paramètre la méthode readItem().

Le writer

De la même manière on spécifie le writer

@Named
@Dependent
public class MyWriter extends AbstractItemWriter {
    @Override
    public void writeItems(List&lt;Object&gt; list) throws Exception {
        for (Object current : list) {
            // ecriture des differents items
        }
    }
}

@Named

@Dependent

public class MyWriter extends AbstractItemWriter {

@Override

public void writeItems(List<Object> list) throws Exception {

for (Object current : list) {

// ecriture des differents items

}

Sur l’utilisation de la méthode writeItems(), j’ai la même remarque que pour la méthode readItem() . Un peu de générique, ça n’aurait pas été du luxe….

Le mapper

@Named
@Dependent
public class MyPartitionMapper implements PartitionMapper {
    @Inject
    JobContext jobContext;

    @Override
    public PartitionPlan mapPartitions() throws Exception {
        PartitionPlan partitionPlan = new PartitionPlanImpl();
        Properties[] props = new Properties[TAILLE];
        int i = 0;
        // @TODO voir pour un stream
        for (String current : LISTE) {
            if (current != null) {
                props[i] = new Properties();
                props[i].setProperty("PROP", current);

                ++i;
            }
        }
        partitionPlan.setPartitions(props.length);
        partitionPlan.setPartitionProperties(props);
        return partitionPlan;
    }
}

@Named

@Dependent

public class MyPartitionMapper implements PartitionMapper {

@Inject

JobContext jobContext;

@Override

public PartitionPlan mapPartitions() throws Exception {

PartitionPlan partitionPlan = new PartitionPlanImpl();

Properties[] props = new Properties[TAILLE];

int i = 0;

// @TODO voir pour un stream

for (String current : LISTE) {

if (current != null) {

props[i] = new Properties();

props[i].setProperty("PROP", current);

++i;

}

partitionPlan.setPartitions(props.length);

partitionPlan.setPartitionProperties(props);

return partitionPlan;

}

La propriété « PROP » définie dans le fichier XML et utilisée dans le reader est définie pour chaque partition. Les différentes partitions sont stockées dans un partitionPlan.

Démarrage du batch

Le batch peut se démarrer de la manière suivante

JobOperator jobOperator = BatchRuntime.getJobOperator();
Properties jobProperties = new Properties();
jobProperties.setProperty("DATE", "2015-07-08");
jobOperator.start("myJob", jobProperties);

JobOperator jobOperator = BatchRuntime.getJobOperator();

Properties jobProperties = new Properties();

jobProperties.setProperty("DATE", "2015-07-08");

jobOperator.start("myJob", jobProperties);

Ce code peut être appelé depuis une servlet, un service REST …..

Monitoring

Pour suivre l’exécution du batch on peut utiliser les outils du serveur d’applications. Sous glassfish on peut utiliser la commande asadmin.

asadmin list-batch-jobs -l

1	asadmin list-batch-jobs -l

JOBNAME           APPNAME                INSTANCECOUNT  INSTANCEID  EXECUTIONID  BATCHSTATUS  STARTTIME                      ENDTIME                        EXITSTATUS
myJob  myProject  137            817         817          COMPLETED    Wed Jul 08 00:00:01 CEST 2015  Wed Jul 08 00:00:01 CEST 2015  COMPLETED
myJob  myProject  137            811         811          COMPLETED    Tue Jul 07 10:51:42 CEST 2015  Tue Jul 07 10:51:42 CEST 2015  COMPLETED
myJob  myProject  137            805         805          COMPLETED    Tue Jul 07 00:00:01 CEST 2015  Tue Jul 07 00:00:02 CEST 2015  COMPLETED
myJob  myProject  137            799         799          COMPLETED    Mon Jul 06 15:58:42 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            793         793          COMPLETED    Mon Jul 06 15:58:42 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            787         787          COMPLETED    Mon Jul 06 15:58:42 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            781         781          COMPLETED    Mon Jul 06 15:58:42 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            775         775          COMPLETED    Mon Jul 06 15:58:41 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            769         769          COMPLETED    Mon Jul 06 15:58:41 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED
myJob  myProject  137            763         763          COMPLETED    Mon Jul 06 15:58:41 CEST 2015  Mon Jul 06 15:58:43 CEST 2015  COMPLETED

JOBNAME APPNAME INSTANCECOUNT INSTANCEID EXECUTIONID BATCHSTATUS STARTTIME ENDTIME EXITSTATUS

myJob myProject 137 817 817 COMPLETED Wed Jul 08 00:00:01 CEST 2015 Wed Jul 08 00:00:01 CEST 2015 COMPLETED

myJob myProject 137 811 811 COMPLETED Tue Jul 07 10:51:42 CEST 2015 Tue Jul 07 10:51:42 CEST 2015 COMPLETED

myJob myProject 137 805 805 COMPLETED Tue Jul 07 00:00:01 CEST 2015 Tue Jul 07 00:00:02 CEST 2015 COMPLETED

myJob myProject 137 799 799 COMPLETED Mon Jul 06 15:58:42 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 793 793 COMPLETED Mon Jul 06 15:58:42 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 787 787 COMPLETED Mon Jul 06 15:58:42 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 781 781 COMPLETED Mon Jul 06 15:58:42 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 775 775 COMPLETED Mon Jul 06 15:58:41 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 769 769 COMPLETED Mon Jul 06 15:58:41 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

myJob myProject 137 763 763 COMPLETED Mon Jul 06 15:58:41 CEST 2015 Mon Jul 06 15:58:43 CEST 2015 COMPLETED

On peut également utiliser les beans JMX pour monitorer les jobs.

Conclusion

La stack JSR 352 est assez simple à utiliser. Elle est certes perfectible ( absence de générique, gestion des propriétés assez compliquée de prime abord) mais fait le boulot.

Par rapport aux autres solutions (spring batch) elle permet la supervision des batchs via les outils du serveur d’application et peut facilement s’intégrer dans une application JAVAEE.

Un client libre pour Google Drive

3 juin 2015 littlewing 2 commentaires

Grive ne fonctionnant plus sur ma distribution Debian jessie, je me suis mis en tête de développer un client similaire. Vu que j’ai fait LV2 JAVA, je suis en train de réaliser ce client en JAVA.

Mon objectif , assez modeste j’en conviens, est de réaliser un client en ligne de commande ( oui je sais Python c’est 100 fois mieux pour ça et java ça pue c’est pas beau etc ) qui permette d’être lancé via un script ou par CRON.

Licence

Ce programme est disponible sur GITHUB sous licence GNU GPLv3.

J’ai encore un doute sur l’attribution de la licence car l’ API GOOGLE est soumise à licence APACHE. Je ne sais pas si je peux faire une distinction entre mon code et les librairies que j’utilise ( si vous avez une info à ce sujet, n’hésitez pas 🙂 )

Création d’un exécutable

Je ne publie pas de binaires pour l’instant car l’utilisation gratuite de l’API est limitée . Par contre, j’expliquerai comment le construire.

Composants utilisés

MAVEN pour la compilation
JDK8
API JAVA GOOGLE API
GUAVA
POWERMOCK/MOCKITO
JUNIT

Fonctionnalités couvertes

Pour l’instant, le programme n’est pas utilisable en l’état. Je ne gère que le téléchargement des fichiers récents dans un répertoire. Il me manque la suppression des fichiers en local, dans drive et l’upload des fichiers.

Je dois aussi blinder mon code avec des tests basés sur powermock et mockito.

La suite dans un prochain épisode 🙂

Définition des différents composants

elasticsearch

Rabbitmq

Spark

Construction

Exécution

Installation

Problème de binding réseau

Configuration de Spark

Développement

Dépendances

Problèmes rencontrés

Gestion des champs numériques

Présence du binaire winutils.exe sur windows 7 64bits

And now, something completely different

Pré requis

Conclusion

Avantages

Inconvénients

Définition d’un job

Le reader

Le writer

Le mapper

Démarrage du batch

Monitoring

Conclusion

Licence

Création d’un exécutable

Composants utilisés

Fonctionnalités couvertes

Catégories

Méta

Étiquettes