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)
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.
Le problème est qu’il faut avoir un certificat valide pour l’url de la machine où se trouve le registry.
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.
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.
Il est possible de récupérer des info sur le contenu du registry avec GET
Ex : GET http://localhost:5000/v2/_catalog
docker build --pull --no-cache -t localhost:5000/${JOB_BASE_NAME} ${WORKSPACE}
docker push localhost:5000/${JOB_BASE_NAME}
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
Le but va être d’utiliser le format parquet qui est plus performant au niveau de la compression.
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
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
Terminer le crossmatch : Il faut trouver le moyen de mapper un Dataset