Utiliser Docker pour développer une application Spark

Utiliser Docker pour développer une application Spark

Docker, la solution de conteneurisation qui a changé notre manière de développer nos applications depuis quelques années, apporte aussi des avantages lors du développement d’une application Spark.

Nous allons voir comment grâce à elle, nous allons pouvoir aisément :

  • Répliquer un environnement sécurisé sous Kerberos ;
  • Anticiper les montées de versions de l’écosystème Hadoop/Spark ;
  • Changer l’orchestrateur Spark pour utiliser Kubernetes et ainsi généraliser la conteneurisation.

Accélérer le développement

Lorsque nous avons commencé le développement de nos applications Spark, chaque développeur devait installer Apache Hadoop et Apache Spark sur son poste de travail et les configurer pour que l’application puisse démarrer et se connecter à notre cluster Spark de développement. Cette tâche était fastidieuse, car elle nécessitait en outre de configurer les droits utilisateurs pour accéder au système de fichiers Hadoop.

Passer celles-ci sous Docker a permis de s’affranchir de cette contrainte, mais également d’avoir à disposition un environnement qui puisse être modulé pour tester différentes versions de Spark/Hadoop, afin de prévoir nos montées de versions dans les applications mais également sur le cluster.

La configuration étant complètement dynamique, elle permet de tester les applications dans un environnement complètement fermé, en ayant soit :

  • Un mini cluster Spark géré par Docker ;
  • Un cluster plus important sur un environnement de développement par exemple.

Dans le premier cas, un container Docker lancera un cluster pseudo-distribué avec un seul nœud. L’application, qui aura lancé son driver dans un autre container Docker, viendra alors s’y connecter. Dans le deuxième cas, les exécuteurs seront lancés de manière classique sur un cluster YARN. Cette configuration nécessite de devoir spécifier au lancement un certain nombre de ports de communication vers le driver, car ceux-ci sont par défaut définis de manière aléatoire. Or, la séparation des réseaux entre la machine hôte et le container Docker (l’un des principes de Docker) empêche cette attribution aléatoire.

 

Tester un environnement sécurisé

Lors des développements d’une application Spark, il arrive un moment où celle-ci est déployée dans un environnement plus sécurisé. En effet, un développeur sur son poste en local ou sur un environnement de développement n’utilise pas nécessairement un environnement sécurisé. Un cluster Hadoop/Spark de ce type repose en général sur l’utilisation de Kerberos, ce qui amène une contrainte supplémentaire.  Kerberos est un protocole d’authentification qui peut être utilisé dans l’écosystème Hadoop pour sécuriser les échanges entre les différents éléments d’un cluster. L’application doit d’abord s’authentifier auprès de Kerberos, avant de pouvoir utiliser les ressources du cluster.

C’est dans ce cadre que nous avons mis en place un environnement complet Spark/Yarn/Hadoop/HBase dans Docker qui utilise Kerberos. Un container aura alors le rôle du serveur d’authentification Kerberos.

Avec un environnement répliquant la configuration qui serait utilisée en production, il est alors possible de vérifier que chaque application fonctionne correctement avec Kerberos. Le cas échéant, cela a permis de corriger le code incompatible et de vérifier que celui-ci fonctionnait avec ou sans Kerberos.

Un cluster Hadoop complètement indépendant, c’est également l’occasion de tester le cloisonnement des données. Il est en effet possible de lancer deux applications avec un utilisateur chacun, et de vérifier que ceux-ci ne peuvent accéder qu’à leurs données.

 

La production avec Kubernetes

Aujourd’hui, nous utilisons Docker principalement comme outil de développement, mais la conteneurisation est tout à fait possible dans un environnement de production, notamment grâce aux solutions tels que Docker Swarm ou Kubernetes par exemple.

Kubernetes est la solution d’orchestration de container conçue à l’origine par Google. La solution est très orientée production (redémarrage automatique, scalabilité automatique…), ce qui fait pencher la balance en sa faveur. La solution commence à être intégrée dans de plus en plus d’outils et notamment Spark.

Depuis la version 2.3 de Spark, Kubernetes peut être utilisé comme orchestrateur à la place de YARN. Au lieu d’avoir une application Spark dont les exécuteurs seront démarrés sur des nœuds YARN, chaque exécuteur est un noeud du cluster Kubernetes. Le driver est également démarré en mode serveur et géré par le cluster directement.

On voit ici l’avantage d’une telle solution. L’application et ces exécuteurs Spark sont alors tous gérés par Kubernetes, permettant de rationaliser les outils de déploiement et d’avoir un suivi amélioré grâce aux outils proposés par l’écosystème Kubernetes, notamment Dashboard, l’interface web de gestion de Kubernetes, qui est bien plus complète que celle de YARN.

 

L’utilisation de Docker semble aux premiers abords une contrainte dans un écosystème centré sur Spark, mais comme nous avons pu le voir, avec une configuration adaptée, celui-ci nous permet de tester tous les cas d’usage : sécurité, montée de version, mutualisation des environnements, …

Sa prise en charge par un nombre grandissant d’outils comme Spark permet de rassurer et de le voir utilisé dans de plus en plus d’applications.