Comment configurer un cluster Mesosphere prêt pour la production sur Ubuntu 14.04

Introduction

Mesosphere est un système qui combine un certain nombre de composants afin de gérer efficacement la création de clusters des serveurs et des déploiements hautement disponibles au-dessus d’une couche de système d’exploitation existante. Contrairement aux systèmes comme CoreOS, Mesosphere n’est pas un système d’exploitation spécialisé mais plutôt un ensemble de paquets.

Dans ce guide, nous allons découvrir comment configurer un cluster hautement disponible dans Mesosphere. Cette configuration nous permettra de nous doter d’une fonctionnalité de basculement dans le cas où l’un de nos nœuds maîtres tomberait en panne, ainsi qu’un pool de serveurs esclaves qui gère les tâches planifiées.

Au cours de ce guide, nous utiliserons des serveurs Ubuntu 14.04.

Conditions prélables et objectifs

Avant de suivre ce guide, il est fortement recommandé de revoir notre introduction à Mesosphere. Il s’agit d’un excellent moyen pour vous de vous familiariser avec les composants dont le système est composé et de vous aider à identifier de quoi chaque unité est responsable.

Au cours de ce tutoriel, nous utiliserons six serveurs Ubuntu. Cela satisfait à la recommandation Apache Mesos qui préconise l’utilisation d’au moins trois maîtres dans un environnement de production. Cela permet également d’avoir un pool de trois serveurs de travail ou esclaves, qui se verront attribués du travail lorsque les tâches seront envoyées au cluster.

Les six serveurs avec lesquels nous travaillerons utiliserons zookeeper pour suivre le serveur maître leader actuel. La couche Mesos, intégré au-dessus, offrira une synchronisation et une manipulation des ressources distribuées Elle est responsable de la gestion du cluster. Marathon, le système d’init distribué du cluster, est utilisé pour planifier des tâches et travailler manuellement sur les serveurs esclaves.

Dans le cas de ce guide, nous supposerons que nos machines ont la configuration suivante :

Ubuntu 14.04 devrait être installé sur chacune de ces machines. Vous devriez compléter les éléments de configuration de base répertoriés dans notre guide de configuration du serveur initial Ubuntu 14.04.

Une fois que vous aurez terminé les deux étapes ci-dessus, poursuivez la lecture de ce guide.

Installer Mesosphere sur les serveurs

La première étape pour faire fonctionner votre cluser consiste à installer le logiciel. Heureusement, le projet Mesosphere conserve un dépôt Ubuntu avec des packages à jour faciles à installer.

Ajouter les dépôts Mesosphere à vos hôtes

Sur tous les hôtes (maîtres et esclaves), suivez les étapes suivantes.

Tout d’abord, ajoutez le dépôt Mesosphere à votre liste de sources. Pour suivre ce processus, la clé du projet Mesosphere devra être téléchargée à partir du serveur de clés Ubuntu, puis l’URL applicable de notre version Ubuntu développée. Le projet vous offre un moyen pratique de le faire :

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
CODENAME=$(lsb_release -cs)
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list

Installer les composants nécessaires

Une fois le dépôt Mesosphere ajouté à votre système, vous devez mettre à jour votre cache de package local pour avoir accès à votre nouveau composant :

sudo apt-get -y update

Ensuite, vous devez installer les packages nécessaires. Les composants dont vous avez besoin dépendront du rôle de l’hôte.

Pour vos hôtes maîtres, vous avez besoin du package de méta mesosphere. Cela inclut les applications zookeeper, mesos, marathon et chronos :

sudo apt-get install mesosphere

Pour vos hôtes slave, vous avez uniquement besoin du package mesos, qui extrait également zookeeper comme dépendance :

sudo apt-get install mesos

Configurer les informations de connexion de Zookeeper pour Mesos

Dans un premier temps, nous allons configurer nos informations de connexion à zookeeper. Il s’agit de la couche sous-jacente qui permet à tous vos hôtes de se connecter aux bons serveurs maîtres, c’est pourquoi il est logique de commencer ici.

Nos serveurs maîtres seront les seuls membres de notre cluster zookeeper, mais l’intégralité de nos serveurs devront être configurés pour pouvoir communiquer en utilisant le protocole. Le fichier qui définit cela est le suivant /etc/mesos/zk.

Sur tous vos hôtes, procédez à l’étape suivante. Ouvrez le fichier avec les privilèges root :

sudo nano /etc/mesos/zk

À l’intérieur, vous trouverez l’URL de connexion configurée par défaut pour accéder à une instance locale. Cela ressemble à ce qui suit :

zk://localhost:2181/mesos

Vous devez la modifier afin qu’elle pointe vers nos trois serveurs maîtres. Pour cela, vous devez remplacer localhost par l’adresse IP de notre premier maître Mesos. Nous pouvons ensuite ajouter une virgule après la spécification du port et reproduire le format pour ajouter nos deuxième et troisième maîtres à la liste.

Dans notre guide, les adresses IP de nos maîtres sont les suivantes : 192.0.2.1, 192.168.2.2 et 192.168.2.3. En utilisant ces valeurs, notre fichier ressemblera à ce qui suit :

zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/mesos

La ligne doit commencer par zk:// et se terminer par /mesos. Entre deux sont spécifiées les adresses IP de vos serveurs maîtres et les ports zookeeper (2181 par défaut).

Enregistrez et fermez le fichier lorsque vous avez terminé.

Utilisez cette même saisie dans chacun de vos maîtres et esclaves. Cela aidera chaque serveur individuel à se connecter aux bons serveurs maîtres et pouvoir ainsi communiquer avec le cluster.

Paramétrer la configuration de Zookeeper des serveurs maîtres

Sur vos serveurs master, nous devrons procéder à une configuration supplémentaire de zookeeper.

La première étape consiste à configurer un numéro d’identification unique, de 1 à 255 pour chacun de vos serveurs maîtres. Il se trouve dans le fichier /etc/zookeeper/conf/myid. Maintenant, ouvrez-le :

sudo nano /etc/zookeeper/conf/myid

Supprimez toutes les informations qui se trouvent dans ce fichier et remplacez-les par un seul numéro, de 1 à 255. Le numéro attribué à chacun de vos serveurs maîtres doit être unique. Par souci de simplicité, il est plus facile de commencer par 1 et de progresser. Dans notre guide, nous utiliserons 1, 2 et 3.

Notre premier serveur contiendra uniquement ce qui suit dans le fichier :

1

Enregistrez et fermez le fichier lorsque vous avez terminé. Procédez ainsi sur chacun de vos serveurs maîtres.

Ensuite, nous devons modifier notre fichier de configuration zookeeper pour cartographier nos ID zookeeper sur les hôtes en tant que tel. Vous aurez ainsi la garantie que le service est bien en capacité de résoudre correctement chaque hôte à partir du système d’ID qu’il utilise.

Maintenant, ouvrez le fichier de configuration zookeeper :

sudo nano /etc/zookeeper/conf/zoo.cfg

Dans ce fichier, vous devrez cartographier chaque ID sur un hôte. La spécification de l’hôte inclura deux ports. Le premier servira à communiquer avec le leader. Le second se chargera des élections au moment où un nouveau leader sera nécessaire. Les serveurs zookeeper sont identifiés par le terme « server » suivi d’un point et de leur numéro d’ID.

Dans notre guide, nous utiliserons les ports par défaut pour chaque fonction et nos ID vont de 1 à 3. Notre fichier ressemblera à ce qui suit :

server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888

Ajoutez ces mêmes cartographies dans chacun des fichiers de configuration de vos serveurs maîtres. Enregistrez et fermez chaque fichier lorsque vous avez terminé.

Avec cela, notre configuration zookeeper est achevée. Nous pouvons commencer à nous concentrer sur Mesos et Marathon.

Configurer Mesos sur les serveurs maîtres

Ensuite, nous allons configurer Mesos sur les trois serveurs maîtres. Suivez ces étapes sur chacun de vos serveurs maîtres.

Modifier le Quorum pour refléter la taille de votre cluster

Tout d’abord, nous devons ajuster le quorum nécessaire à la prise de décision. Il déterminera le nombre d’hôtes nécessaires pour que le cluster soit en état de fonctionnement.

Le quorum doit être configuré de manière à ce que plus de 50 pour cent des membres maîtres soient présents pour prendre des décisions. Cependant, il nous faut également établir une certaine tolérance de défaillance dans le cas où, si tous nos maîtres ne sont pas présents, le cluster puisse toujours fonctionner.

Nous disposons de trois maîtres. Par conséquent, le seul réglage qui satisfait à ces deux exigences est un quorum de deux. Étant donné que la configuration initiale suppose un réglage de serveur unique, le quorum est actuellement défini à un.

Ouvrez le fichier de configuration du quorum :

sudo nano /etc/mesos-master/quorum

Remplacez la valeur par « 2 » :

2

Enregistrez et fermez le fichier. Procédez ainsi sur chacun de vos serveurs maîtres.

Configurer le nom d’hôte et l’adresse IP

Nous allons ensuite spécifier le nom de l’hôte et l’adresse IP de chacun de nos serveurs maîtres. Pour le nom de l’hôte, nous utiliserons l’adresse IP afin que nos instances n’aient pas de difficultés à se résoudre correctement.

Pour nos serveurs maîtres, l’adresse IP doit être placée dans ces fichiers :

• /etc/mesos-master/ip
• /etc/mesos-master/hostname

Tout d’abord, ajoutez l’adresse IP individuelle de chaque nœud maître dans le fichier /etc/mesos-master/ip. N’oubliez pas de la modifier sur chaque serveur afin qu’elle corresponde à la valeur applicable :

echo 192.168.2.1 | sudo tee /etc/mesos-master/ip

Maintenant, nous pouvons copier cette valeur sur le fichier du nom de l’hôte :

sudo cp /etc/mesos-master/ip /etc/mesos-master/hostname

Procédez ainsi sur chacun de vos serveurs maîtres.

Configurer Marathon sur les serveurs maîtres

Maintenant que Mesos est configuré, nous pouvons procéder à la configuration de l’implémentation du système init en cluster de Mesosphere.

Marathon s’exécutera sur chacun de nos hôtes maîtres. Cependant, seul le serveur maître principal pourra planifier des tâches. Les autres instances de Marathon transmettront les requêtes de manière transparente sur le serveur maîtres.

Tout d’abord, nous devons à nouveau configurer le nom de l’hôte pour l’instance de Marathon de chaque serveur. Encore une fois, nous utiliserons l’adresse IP dont nous disposons déjà dans un fichier. Nous pouvons la copier dans l’emplacement du fichier dont nous avons besoin.

Cependant, la structure du répertoire de configuration de Marathon dont nous avons besoin n’est pas automatiquement créée. Nous allons devoir créer le répertoire pour pouvoir ensuite y copier le fichier :

sudo mkdir -p /etc/marathon/conf
sudo cp /etc/mesos-master/hostname /etc/marathon/conf

Ensuite, nous devons définir la liste des maîtres zookeeper auxquels Marathon se connectera pour obtenir des informations et une planification. Il s’agit de la même chaîne de connexion zookeeper que nous avons utilisée pour Mesos afin que nous puissions tout simplement y copier le fichier. Nous devons le placer dans un fichier appelé master :

sudo cp /etc/mesos/zk /etc/marathon/conf/master

Notre service Marathon pourra ainsi se connecter au cluster Mesos. Cependant, nous souhaitons également que Marathon stocke ses propres informations dans zookeeper. Pour cela, nous utiliserons l’autre fichier de connexion zookeeper comme base et modifierons tout simplement le point final.

Tout d’abord, copiez le fichier dans l’emplacement zookeeper de Marathon :

sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk

Ensuite, ouvrez le fichier dans votre éditeur :

sudo nano /etc/marathon/conf/zk

Le point final est la seule partie que nous ayons besoin de modifier. Nous allons remplacer /mesos par /marathon :

zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/marathon

C’est tout ce qu’il faut faire pour configurer Marathon.

Configurer les règles d’init des services et redémarrer les services

Ensuite, nous allons redémarrer les services de serveurs maîtres pour utiliser les paramètres qui nous avons configurés.

Tout d’abord, nous allons nous assurer que nos serveurs maîtres exécutent uniquement le processus maître Mesos et non pas le processus esclave. Nous pouvons arrêter tout processus esclave actuellement en cours d’exécution (cela peut échouer mais ce n’est pas un problème car il s’agit uniquement de vérifier que le processus est arrêté). Nous pouvons également que le serveur ne commence pas avec le processus esclave au démarrage en créant un fichier de remplacement :

sudo stop mesos-slave
echo manual | sudo tee /etc/init/mesos-slave.override

Maintenant, il ne reste plus qu’à redémarrer zookeeper, qui configurera nos élections maîtresses. Nous pouvons ensuite démarrer nos processus Mesos maître et Marathon :

sudo restart zookeeper
sudo start mesos-master
sudo start marathon

Pour obtenir un pic dans ce que vous venez juste de configurer, consultez l’un de nos serveurs maîtres notre navigateur web au port 5050 :

http://192.168.2.1:5050

Vous devriez voir l’interface principale de Mesos. Vous serez éventuellement informé que vous êtes redirigé vers le master actif en fonction de si vous vous êtes connecté au leader ou pas. Dans tous les cas, l’écran ressemblera à ce qui suit :

Il s’agit d’une vue de votre cluster actuel. Vous n’y voyez pas grand-chose car il n’y a aucun nœud esclave disponible et aucune tâche a été démarrée.

Nous avons également configuré Marathon, le contrôleur de tâches longue durée de Mesosphere. Il sera disponible sur le port 8080 sur l’un de vos maîtres :

Nous allons brièvement voir comment utiliser ces interfaces une fois que nous avons configuré nos esclaves.

Configurer les serveurs esclaves

Maintenant que nous avons configuré nos serveurs maîtres, nous pouvons commencer à configurer nos serveurs esclaves.

Nous avons déjà configuré nos esclaves avec les informations de connexion zookeeper de nos serveurs maîtres. Les esclaves eux-mêmes n’exécutent pas leurs propres instances zookeeper.

Nous pouvons arrêter tout processus zookeeper qui fonctionne actuellement sur nos nœuds esclaves et créer un fichier de remplacement afin qu’il ne démarre pas automatiquement lorsque le serveur redémarre :

sudo stop zookeeper
echo manual | sudo tee /etc/init/zookeeper.override

Ensuite, nous voulons créer un autre fichier de remplacement pour s’assurer que le processus maître Mesos ne commence pas sur nos serveurs esclaves. Nous allons également nous assurer qu’il est actuellement arrêté (il se peut que cette commande échoue si le processus est déjà arrêté. Ceci n’est pas un problème) :

echo manual | sudo tee /etc/init/mesos-master.override
sudo stop mesos-master

Ensuite, nous devons configurer l’adresse IP et le nom de l’hôte, tout comme nous l’avons fait pour nos serveurs maîtres. Cela implique la mise en place de l’adresse IP de chaque nœud dans un fichier, cette fois sous le répertoire /etc/mesos-slave. Nous utiliserons également le nom de l’hôte pour accéder facilement aux services via l’interface web :

echo 192.168.2.51 | sudo tee /etc/mesos-slave/ip
sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname

Encore une fois, utilisez l’adresse IP de chaque serveur esclave pour la première commande. Cela garantira qu’elle est bien liée à la bonne interface.

Maintenant, nous avons tous les éléments pour démarrer nos esclaves Mesos. Il nous suffit juste d’activer le service :

sudo start mesos-slave

Procédez ainsi sur chacune de vos machines esclaves.

Pour voir si vos esclaves s’enregistrent avec succès dans votre cluster, revenez à l’un de vos serveurs maîtres au port 5050 :

http://192.168.2.1:5050

Maintenant, vous devriez voir le nombre d’esclaves actifs afficher « 3 » dans l’interface :

Vous pouvez également voir que les ressources disponibles dans l’interface ont été mises à jour pour refléter les ressources pooled dans vos machines esclaves :

Pour obtenir de plus amples informations sur chacune de vos machines, vous pouvez cliquer sur le lien « Slaves » en haut de l’interface. Ceci nous donnera un aperçu de la contribution en ressources de chaque machine, ainsi que les liens vers une page de chaque esclave :

Démarrer des services sur Mesos et Marathon

Marathon est l’utilitaire Mesosphere permettant de planifier les tâches de longue durée. Il est facile de penser que Marathon est le système init pour un cluster Mesosphere car il prend en charge les services de démarrage et d’arrêt, tout en planifiant les tâches et en s’assurant que les applications remontent si elles descendent.

Vous pouvez également ajouter des services et des tâches à Marathon de quelques manières différentes. Nous allons uniquement couvrir les services de base. Les conteneurs Docker seront traités dans un prochain guide.

Démarrer un service via l’interface Web

La manière la plus directe de lancer un service rapidement sur le cluster consiste à ajouter une application par le biais de l’interface Web Marathon.

Tout d’abord, consultez l’interface Web de Marathon sur l’un de vos serveurs maîtres. N’oubliez pas que l’interface de Marathon se trouve sur le port 8080 :

http://192.168.2.1:8080

À partir de là, vous pouvez cliquer sur le bouton « New App » dans le coin supérieur droit. Cela fera apparaître une superposition dans laquelle vous pouvez ajouter des informaions sur votre nouvelle application :

Complétez les champs avec les exigences de votre application. Seules les champs suivants sont obligatoires

• ID : un ID unique que l’utilisateur choisi pour identifier un processus. Vous pouvez utiliser ce que vous voulez, mais il doit être unique.
• Command : il s’agit de la commande réelle que Marathon exécutera réellement. Il s’agit du processus qui sera surveillé et redémarré en cas d’échec.

En utilisant ces informations, vous pouvez configurer un service simple qui imprime simplement « hello » et se met en veille pendant 10 secondes. Nous allons appeler ce « hello » :

Une fois que vous reviendrez à l’interface, le service passera de « Deploying » à « Running » :

Environ toutes les 10 secondes, l’élément « Tasks/Instances » passera de « 1/1 » à « 0/1 » au fur et à mesure que la quantité de mise en veille passe et le service s’arrête. Ensuite, Marathon redémarre automatiquement la tâche. Nous pouvons voir ce processus plus clairement dans l’interface Web de Mesos sur le port 5050 :

http://192.168.2.1:5050

Ici, vous pouvez voir le processus se terminer et être redémarré :

En cliquant sur « Sandbox » et que « stdout » d’une des tâches, vous pouvez voir la sortie « hello » en cours de production :

Démarrage d’un service via l’API

Nous pouvons également soumettre des services via l’API Marathon. Pour cela, il vous faudra y transmettre un objet JSON contenant tous les champs que la superposition contenait.

Il s’agit d’un processus relativement simple. Encore une fois, les seuls champs requis sont id pour l’identificateur de processus et cmd qui contient la commande réelle à exécuter.

Donc, nous devons créer un fichier JSON appelé hello.json avec ces informations :

nano hello.json

À l’intérieur, la spécification minimum devrait ressembler à ce qui suit :

{
  "id": "hello2",
  "cmd": "echo hello; sleep 10"
}

Ce service fonctionnera correctement. Cependant, si nous souhaitons réellement émuler le service que nous avons créé dans l’IU web, nous devons ajouter quelques champs supplémentaires. Ces valeurs seront configurées par défaut dans l’IU web et nous pouvons les répliquer ici :

{
  "id": "hello2",
  "cmd": "echo hello; sleep 10",
  "mem": 16,
  "cpus": 0.1,
  "instances": 1,
  "disk": 0.0,
  "ports": [0]
}

Sauvegardez et fermez le fichier JSON une fois que vous aurez fini.

Ensuite, nous pouvons le soumettre en utilisant l’API Marathon. La cible est l’un de nos services maître de Marathon sur le port 8080 et le point de terminaison est /v2/apps. La charge de données de notre fichier, que nous nous pouvons y lire curl en utilisant la balise -d avec la balsise @ pour indiquer un fichier.

La commande ressemblera à ceci :

curl -i -H 'Content-Type: application/json' -d@hello2.json 192.168.2.1:8080/v2/apps

Si nous regardons l’interface Marathon, nous pouvons voir que l’ajout à bien été effectué. Il semble avoir exactement les mêmes propriétés que notre premier service :

Vous pouvez surveiller et accéder au nouveau service exactement de la même manière que le premier service.

Conclusion

À ce stade, vous devriez avoir un cluster Mesosphere qui fonctionne. Pour le moment, nous avons uniquement abordé la configuration de base. Vous devriez cependant être en mesure de voir les possibilités qu’offre le système Mesosphere.

Dans les futurs guides, nous allons voir comment déployer des conteneurs Docker sur votre cluster et utiliser certains outils plus en profondeur.