19 Septembre 2016

Installation de Jenkins

J’ai créé une image avec Jenkins et le client docker préinstallé ici Pour utiliser cette image il faut tout d’abord créer un volume

docker volume create --name jenkins

Puis on lance Jenkins :

docker run -p 8888:8080 -p 50000:50000 -v jenkins:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock --name jenkins -d nyanloutre/docker-in-jenkins

On peut ensuite créer des jobs pour compiler des Dockerfile, les images résultantes se trouveront sur l’hôte. Plus tard il faudra utiliser un registry (serivce de stockage d’image)

Exemple de commande de build :

docker build --pull --no-cache -t nyanloutre/spark-proxy .

De cette façon à chaque build on s’assure d’avoir la dernière version de nginx et on n’utilise pas le cache de sorte à ce qu’il n’y ai pas de problèmes (Du type un apt-get update qui ne s’execute pas car en cache). Le cache pourrais par contre se être très utile dans le cas où certaines étapes de la compilation sont très longue (du style compilation d’un programme dans le Dockerfile)

Il est possible ensuite d’éxécuter la build une fois par jour pour que l’image soit actualisée avec un cron job du type H H * * * c’est à dire une fois par jour. L’utilisation des H évite si on à plusieurs images qui doivent être construitent que tout arrive en même temps.

Pour la suite nous utiliserons un registry local sur lequel seront envoyé les images. Ce registry servira lors du déploiement des service pour servir les images. Il faudra voir de quelle façon mettre à jour les service en cas de mise à jour de l’image (ex: le service spark-proxy ets en route et l’image vient d’être actualisée par Jenkins, la propagation aux service est-elle automatique ?)

Il faudra aussi trouver une solution à l’utilisation de Jenkins sur un swarm. Pour le moment Jenkins est executé en local car en cas d’utilisation dans un swarm il faut pouvoir assurer la persistence des données (si le service est relocalisé on pert les données, en cas de crash d’une machine par exemple) donc voir comment utiliser un service de stockage distribué et comment l’implémenter (pour le moment swarm ne propose aucune solution en natif mais des solution existent)

Installation d’un registry

Une image officielle est disponible ici elle permet de déployer très rapidement un registry, cependant il n’est pas sécurisé par défaut et les différents serveurs Docker n’accepterons pas d’installer depuis ce serveur.

Instructions

Le problème est qu’il faut avoir un certificat valide pour l’url de la machine où se trouve le registry.

Solution temporaire

Il suffit de démarer le registry en service et de mapper le port 5000. On peut y accéder ensuite depuis tous les noeuds sur l’url localhost:5000, les noeuds pensent que le registry est local et lui font confiance. Attention cependant car le port 5000 est mappé vers l’extérieur et n’importe qiu ayant accès au réseau peut donc modifier les images contenues dans le registry.

Autentification

Il est possible de rajouter un mot de passe pour l’accès au registry (connexion avec --with-registry-auth lors de la création des services). Pour simplifier les opération dans le contexte des tests nous ne mettrons pas en place de mot de passe.

API http

Il est possible de récupérer des info sur le contenu du registry avec GET

Ex : GET http://localhost:5000/v2/_catalog

Exemple de script que Jenkins lance pour compiler une image

docker build --pull --no-cache -t localhost:5000/${JOB_BASE_NAME} ${WORKSPACE}
docker push localhost:5000/${JOB_BASE_NAME}

Utilisation du registry

Spark master

docker service create --name spark-master --network spark-net localhost:5000/spark /usr/spark-2.0.0/bin/spark-class org.apache.spark.deploy.master.Master

HDFS Namenode

docker service create --name hdfs-namenode -e CORE_CONF_fs_defaultFS=hdfs://hdfs-namenode:8020 -e CLUSTER_NAME=test -e CORE_CONF_hadoop_http_staticuser_user=root -e HDFS_CONF_dfs_webhdfs_enabled=true -e HDFS_CONF_dfs_permissions_enabled=false --network spark-net localhost:5000/hadoop-namenode

Proxy Nginx

docker service create --name spark-proxy --network spark-net -p 8080:8080 -p 50070:50070 localhost:5000/spark-proxy

Modification programme crossmatch pour enregistrer au format parquet

Le but va être d’utiliser le format parquet qui est plus performant au niveau de la compression.

Différences de temps

Sauvegarde en RDD

real    1m15.295s
user    0m7.904s
sys     0m0.388s

real    0m49.102s
user    0m7.604s
sys     0m0.352s

real    0m58.932s
user    0m7.728s
sys     0m0.384s

min/avg/max = 49.102s/61,11s/1m15.295s

Sauvegarde en Parquet

real    0m39.392s
user    0m13.188s
sys     0m0.464s

real    0m39.100s
user    0m12.088s
sys     0m0.532s

real    0m41.130s
user    0m12.168s
sys     0m0.456s

min/avg/max = 39.100s/39,874s/41.130s

A faire

Terminer le crossmatch : Il faut trouver le moyen de mapper un Dataset vers un JavaPairRDD Actuellement il faudrais juste trouver comment obtenir les indices des colonne à partir des noms et ça devrais être bon.