Comment configurer Consul dans un environnement de production sur Ubuntu 14.04

Introduction

Consul est un système distribué, hautement disponible, conscient des centres de données, de découverte de services et de configuration. Il peut être utilisé pour présenter des services et des nœuds dans une interface flexible et puissante qui permet aux clients d'avoir toujours une vue à jour de l'infrastructure dont ils font partie.

Consul offre de nombreuses fonctionnalités différentes utilisées pour fournir des informations cohérentes et disponibles sur votre infrastructure. Cela inclut des mécanismes de découverte de services et de nœuds, un système de balises, des contrôles de santé, des routines d'élection basées sur le consensus, un stockage clé/valeur à l'échelle du système, et plus encore. En utilisant Consul au sein de votre organisation, vous pouvez facilement intégrer un niveau sophistiqué de conscience dans vos applications et services.

Dans notre dernier guide, nous avons fourni une démonstration rapide de certaines fonctionnalités de consul. Dans ce guide, nous allons commencer à créer une configuration consul prête pour la production qui peut être utilisée pour commencer à implémenter la découverte de services pour votre infrastructure.

Prérequis et objectifs

Dans cette série, nous allons mettre en place un système de serveurs capables de communiquer entre eux et de maintenir des informations de service, des pools de stockage clé/valeur, et d'autres détails pour les machines clientes. Les premières étapes pour rendre notre système prêt pour la production auront lieu dans ce guide, alors que nous installons le logiciel et automatisons une partie de notre configuration.

La documentation de Consul recommande d'avoir soit 3 soit 5 serveurs Consul fonctionnant dans chaque centre de données pour éviter la perte de données en cas de défaillance d'un serveur. Les serveurs Consul sont le composant qui fait le gros du travail. Ils stockent des informations sur les services et des informations clé/valeur. Un nombre impair de serveurs est nécessaire pour éviter les problèmes de blocage lors des élections.

À part les serveurs Consul, d'autres machines peuvent exécuter des agents Consul. Les agents Consul sont très légers et se contentent de transmettre les requêtes aux serveurs. Ils offrent une méthode pour isoler vos serveurs et déchargent la responsabilité de connaître les adresses des serveurs aux agents eux-mêmes.

Pour que nous puissions mettre en œuvre certains des mécanismes de sécurité dans un guide ultérieur, nous devons nommer toutes nos machines au sein d'un seul domaine. C'est afin que nous puissions émettre un certificat SSL générique à une date ultérieure.

Les détails de nos machines sont ici :

Nom d'hôte	Adresse IP	Rôle
server1.example.com	192.0.2.1	bootstrap serveur consul
server2.example.com	192.0.2.2	serveur consul
server3.example.com	192.0.2.3	serveur consul
agent1.example.com	192.0.2.50	client consul

Nous utiliserons des serveurs Ubuntu 14.04 64 bits pour cette démonstration, mais n'importe quel serveur Linux moderne devrait fonctionner tout aussi bien. Une fois la configuration terminée, vous devriez avoir un système en place qui vous permettra d'ajouter facilement des services, des vérifications et des nœuds.

Connectez-vous à vos machines en tant qu'utilisateur root pour compléter les étapes de ce guide.

Téléchargement et installation de Consul

Si vous n'avez pas déjà installé Consul dans le guide d'introduction initial à Consul, vous devrez le faire maintenant. Nous allons installer Consul en tant qu'application au niveau du système sur chacune des quatre machines que nous configurons.

Avant d'examiner la demande du consul, nous devons obtenir unzip pour extraire l'exécutable. Mettez à jour le cache des packages du système local, puis installez le package en utilisant apt :

apt-get update
apt-get install unzip

Maintenant, nous pouvons procéder à l'obtention du programme consul. La page du projet consul fournit des liens de téléchargement vers des packages binaires pour Windows, OS X et Linux.

Allez à la page ci-dessus et faites un clic droit sur le système d'exploitation et l'architecture qui représentent vos serveurs. Dans ce guide, puisque nous utilisons des serveurs 64 bits, nous utiliserons le lien « amd64 » sous « linux ». Sélectionnez « copier l'adresse du lien » ou toute autre option similaire que votre navigateur propose.

Dans votre terminal, accédez au répertoire /usr/local/bin, où nous allons garder l'exécutable. Tapez wget suivi d'un espace, puis collez l'URL que vous avez copiée depuis le site :

cd /usr/local/bin
wget https://dl.bintray.com/mitchellh/consul/0.3.0_linux_amd64.zip

Maintenant, nous pouvons extraire le paquet binaire en utilisant la commande unzip que nous avons installée précédemment. Nous pouvons ensuite supprimer le fichier compressé :

unzip *.zip
rm *.zip

Vous devriez maintenant avoir la commande consul disponible sur tous vos serveurs.

Créer le répertoire et la structure système nécessaires

Nous pouvons facilement essayer Consul de manière non structurée en utilisant la commande consul. Cela vous permettra de tester certaines fonctionnalités. Nous avons fait cela dans le dernier guide pour nous familiariser avec le logiciel.

Cependant, nous allons tenter de mettre en place un système plus fiable et plus facile à gérer, donc nous allons créer une certaine structure pour faire fonctionner cela. Complétez les étapes suivantes sur chacun de vos ordinateurs (serveurs et clients).

La première chose dont nous devrions nous occuper est de créer un utilisateur spécifique à notre tâche. Il s'agit d'un cas standard de séparation des privilèges des utilisateurs, nous exécuterons donc nos processus consul avec un utilisateur dédié.

Créez l'utilisateur maintenant en tapant :

adduser consul

Vous pouvez ignorer toutes les invites (Vous voudrez peut-être définir un mot de passe. Sinon, il se plaindra) si vous le souhaitez.

Ensuite, nous allons créer la hiérarchie de configuration qui contiendra les différentes configurations que nous utiliserons en fonction de la manière dont nous voulons démarrer le service. Pour faciliter cela, nous allons créer un répertoire parent consul.d dans la structure de configuration /etc et mettre des sous-répertoires appelés bootstrap, server et client sous celui-ci sur chaque système :

mkdir -p /etc/consul.d/{bootstrap,server,client}

Nous pouvons mettre nos configurations dans chacun de ces dossiers plus tard. Chaque serveur utilisera probablement, au maximum, deux de ces répertoires, mais nous créerons la structure pour la cohérence sur chaque hôte.

Nous devons également créer un emplacement où Consul peut stocker des données persistantes entre les redémarrages. Nous allons créer un répertoire à /var/consul à cet effet et le donner à l'utilisateur consul afin qu'il puisse gérer les données :

mkdir /var/consul
chown consul:consul /var/consul

Avec cette structure en place, nous devrions être en mesure de commencer à créer nos fichiers de configuration.

Création de la configuration Bootstrap

La première configuration que nous devons créer est pour le démarrage du cluster. Ce n'est pas un événement très courant puisqu'il est seulement nécessaire pour créer le cluster initialement. Cependant, nous allons créer le fichier de configuration afin que nous puissions recommencer rapidement en cas de panne complète du cluster.

Vous pouvez mettre ce fichier de configuration sur un seul de vos serveurs consul, ou sur tous pour vous donner plus d'options pour le démarrage. Nous ne le mettrons que sur server1 pour cette démonstration.

Les fichiers de configuration sont stockés en JSON simple, donc ils sont assez faciles à gérer. Créez le premier fichier dans le sous-répertoire bootstrap :

nano /etc/consul.d/bootstrap/config.json

Dans ce fichier, nous pouvons commencer par spécifier que lorsque cette configuration est utilisée, Consul doit démarrer en tant que serveur en mode bootstrap :

{
    "bootstrap": true,
    "server": true
}

Nous devrions également spécifier le centre de données où notre cluster sera situé. Cela peut être n'importe quel nom qui vous aide à identifier l'emplacement physique du cluster. Consul est conscient des centres de données et ces désignations vous aideront à organiser vos différents clusters par centre de données.

Nous pouvons également indiquer le répertoire de données que nous avons créé à /var/consul. Consul l'utilisera pour stocker des informations sur l'état du cluster :

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul"
}

Ensuite, nous voulons implémenter un certain chiffrement pour le protocole Whisper que Consul utilise. Il a cette fonctionnalité intégrée en utilisant un système de secret partagé. Le secret doit être une chaîne codée en base 64 de 16 bits. Pour obtenir une valeur appropriée pour cette valeur, nous allons quitter temporairement le fichier.

Dans le terminal, nous pouvons utiliser la commande consul pour générer une clé de la longueur et du codage nécessaires. Tapez :

consul keygen

X4SYOinf2pTAcAHRhpj7dA==

Copiez la valeur qui est générée et rouvrez le fichier de configuration :

nano /etc/consul.d/bootstrap/config.json

Utilisez la chaîne copiée comme valeur pour le paramètre encrypt :

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA=="
}

Enfin, nous ajouterons quelques informations supplémentaires pour spécifier le niveau de journalisation et pour indiquer que nous voulons utiliser syslog pour la journalisation :

{
    "bootstrap": true,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true
}

Enregistrez et fermez le fichier lorsque vous avez terminé.

Créer la configuration du serveur régulier

Maintenant que nous avons notre configuration de démarrage complète, nous pouvons l'utiliser comme base pour notre configuration générale du serveur. La configuration du serveur sera utilisée une fois que le cluster sera démarré.

Commencez par copier le fichier bootstrap depuis server1 dans le sous-répertoire server sur cette machine pour l'éditer :

cp /etc/consul.d/bootstrap/config.json /etc/consul.d/server

Ouvrez le fichier pour apporter les modifications nécessaires :

nano /etc/consul.d/server/config.json

Pour commencer, nous devons désactiver le drapeau bootstrap puisque cette configuration est destinée aux configurations non-bootstrap.

La seule autre chose que nous devons modifier pour la configuration du serveur est de spécifier les adresses IP des autres serveurs que ce nœud doit tenter de rejoindre au démarrage. Cela permet de se joindre automatiquement, afin que nous n'ayons pas à rejoindre manuellement le cluster après le démarrage de notre serveur :

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.2", "192.0.2.3"]
}

Le paramètre encrypt doit être le même pour tous les participants du système, donc le fait de copier le fichier a déjà pris en charge cette exigence pour nous. Gardez cela à l'esprit lors de la création de nouvelles configurations.

Enregistrez le fichier lorsque vous avez terminé.

Vous devriez copier le contenu de ce fichier de configuration sur les autres machines qui agiront en tant que serveurs consul. Placez-les dans un fichier à /etc/consul.d/server/config.json exactement comme vous l'avez fait sur le premier hôte.

La seule valeur que vous devez modifier sur les autres hôtes est les adresses IP auxquelles il doit tenter de se connecter. Vous devez vous assurer qu'il tente de se connecter au premier serveur au lieu de sa propre IP. Par exemple, le deuxième serveur dans notre exemple aurait un fichier qui ressemble à ceci :

{
    "bootstrap": false,
    "server": true,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.3"]
}

Enregistrez et fermez les fichiers que vous avez créés lorsque vous avez terminé.

Création de la configuration du client

Maintenant, nos configurations de serveur sont toutes terminées. Nous pouvons nous concentrer sur la mise en marche de notre machine cliente avec une configuration appropriée.

Ouvrez un fichier de configuration dans le sous-répertoire client sur la machine cliente :

nano /etc/consul.d/client/config.json

Nous utiliserons à nouveau une configuration précédente comme base pour notre nouvelle configuration. Copiez le contenu de l'un des fichiers du serveur dans ce fichier.

Nous commencerons par supprimer toute mention du paramètre bootstrap puisque cela ne s'applique qu'aux configurations serveur et en changeant le paramètre server à false.

Ensuite, nous allons ajouter un paramètre spécifiant l'emplacement du répertoire de l'interface web. Nous allons bientôt acquérir les fichiers nécessaires pour cela. L'emplacement où ils résideront est /home/consul/dist.

Enfin, nous voulons ajuster le paramètre start_join pour lister tous nos serveurs :

{
    "server": false,
    "datacenter": "nyc2",
    "data_dir": "/var/consul",
    "ui_dir": "/home/consul/dist",
    "encrypt": "X4SYOinf2pTAcAHRhpj7dA==",
    "log_level": "INFO",
    "enable_syslog": true,
    "start_join": ["192.0.2.1", "192.0.2.2", "192.0.2.3"]
}

Enregistrez et fermez le fichier lorsque vous avez terminé.

Téléchargement des fichiers de l'interface Web

Maintenant que nous avons configuré le client pour servir l'interface web, nous devons acquérir les fichiers réels qui nous permettront de le faire.

Sur le site du consul, faites un clic droit sur le lien vers l'interface web du consul et sélectionnez « copier l'emplacement du lien » ou toute autre option similaire que vous avez.

Sur le client, utilisez su pour devenir l'utilisateur consul. Nous allons configurer le répertoire web dans le répertoire personnel de l'utilisateur consul.

su consul
cd ~

Maintenant, tapez wget, suivi d'un espace et collez le lien que vous avez copié pour le téléchargement de l'interface web. Au moment de la rédaction, cela ressemblera à ceci :

wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip

Décompressez le fichier téléchargé et supprimez le fichier zip :

unzip *.zip
rm *.zip

Cela créera un répertoire appelé dist dans votre répertoire personnel. C'est le répertoire que nous avons indiqué au paramètre de l'interface web dans le fichier de configuration.

Avant de continuer, vous devriez quitter la session de l'utilisateur consul pour revenir à la session root :

exit

Créer un script Upstart

Nous avons maintenant nos fichiers de configuration en place. Ensuite, nous pouvons nous concentrer sur la création d'un script upstart afin que nos instances de consul soient automatiquement lancées au démarrage et redémarrées en cas de problème.

Puisque le démarrage initial d'un cluster n'est pas quelque chose que nous aurons à faire souvent (la plupart du temps, le cluster lui-même persistera et un seul nœud pourra devoir être redémarré et rejoindre le cluster), nous ne prendrons pas en compte le démarrage initial dans le script de démarrage. Nous vous montrerons comment compléter ce processus manuellement sous peu.

Notre script d'initialisation sera similaire sur nos serveurs et sur le client. Sur l'un des serveurs consul, créez un fichier dans le répertoire /etc/init pour contenir votre configuration consul :

nano /etc/init/consul.conf

Nous allons copier le contenu de ce fichier sur les autres serveurs, puis l'utiliser également comme base pour notre configuration client. Dans ce fichier, la première tâche consiste à créer une description du processus. Sur nos serveurs, nous utiliserons :

description "Consul server process"

Ensuite, nous spécifions les conditions dans lesquelles le processus commencera. Pour ce service, nous voulons que le service commence lorsque le système de fichiers local est monté et lorsque l'interface réseau publique est en fonctionnement.

Nous voulons également spécifier quand le processus doit s'arrêter. En utilisant les niveaux d'exécution standard de Linux, nous pouvons lui dire d'arrêter le processus chaque fois qu'il n'est pas dans l'un des modes de fonctionnement normaux (arrêter le processus lors de l'arrêt ou du redémarrage du serveur) :

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

Nous pouvons indiquer au système d'initialisation de redémarrer le processus s'il venait à se terminer de manière inattendue. Nous voulons également spécifier l'utilisateur et le groupe sous lesquels le processus doit s'exécuter. N'oubliez pas que nous avons créé l'utilisateur et le groupe consul pour isoler le processus :

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

Enfin, nous devons fournir la commande réelle que nous voulons exécuter. Il s'agira simplement de la commande consul exécutée en mode agent. Nous passerons le répertoire contenant nos spécifications de configuration du serveur en tant qu'argument à la commande :

description "Consul server process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/server

Enregistrez le fichier lorsque vous avez terminé.

Copiez le contenu de ce fichier dans un fichier appelé /etc/init/consul.conf sur chacun de vos serveurs ainsi que sur le client.

Sur le client, nous devons modifier légèrement le fichier. Nous devrions changer la description pour faire référence au fait qu'il s'agit d'une machine cliente. Nous devons également modifier le répertoire de configuration qui est transmis à la commande consul elle-même.

Le fichier final devrait ressembler à quelque chose comme ceci :

description "Consul client process"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

respawn

setuid consul
setgid consul

exec consul agent -config-dir /etc/consul.d/client

Enregistrez et fermez le fichier lorsque vous avez terminé.

Démarrage d'un cluster

Maintenant, nous avons tout en place pour mettre en place rapidement un cluster Consul. Le processus est relativement simple.

Sur un serveur qui contient le fichier de configuration bootstrap (server1 dans notre cas), utilisez su pour passer brièvement à l'utilisateur consul. Nous pouvons ensuite appeler consul et passer le répertoire bootstrap comme argument :

su consul
consul agent -config-dir /etc/consul.d/bootstrap

Le service devrait démarrer et occuper la fenêtre du terminal. En mode bootstrap, ce serveur s'élira lui-même comme leader, créant une base pour former le cluster.

Sur vos autres serveurs Consul, en tant que root, démarrez le service Consul que nous venons de créer avec le script Upstart en tapant :

start consul

Ces serveurs se connecteront au serveur initialisé, complétant ainsi le cluster. À ce stade, nous avons un cluster de trois serveurs, dont deux fonctionnent normalement et un qui est en mode bootstrap, ce qui signifie qu'il peut prendre des décisions exécutives sans consulter les autres serveurs.

Ce n'est pas ce que nous voulons. Nous voulons que chacun des serveurs soit sur un pied d'égalité. Maintenant que le cluster est créé, nous pouvons éteindre l'instance Consul initialisée puis rejoindre le cluster en tant que serveur normal.

Pour ce faire, appuyez sur CTRL-C dans le terminal du serveur démarré :

CTRL-C

Maintenant, retournez dans votre session root et démarrez le service consul comme vous l'avez fait avec le reste des serveurs :

exit
start consul

Cela entraînera le serveur précédemment démarré en bootstrap à rejoindre le cluster avec des privilèges non élevés, mettant le cluster dans son état final.

Maintenant que le cluster est entièrement opérationnel, les machines clientes peuvent se connecter. Sur la machine cliente, effectuez la même procédure en tant que root :

start consul

Le client se connectera au cluster en tant que client. Vous pouvez voir les membres du cluster (serveurs et clients) en demandant à Consul ses membres sur n'importe quelle machine :

consul members

Node     Address             Status  Type    Build  Protocol
server3  192.0.2.3:8301  alive   server  0.3.0  2
server2  192.0.2.2:8301  alive   server  0.3.0  2
server1  192.0.2.1:8301  alive   server  0.3.0  2
agent1   192.0.2.50:8301    alive   client  0.3.0  2

Connexion à l'interface Web

Nous avons configuré notre machine cliente pour héberger une interface web du cluster. Cependant, celle-ci est servie sur l'interface locale, ce qui signifie qu'elle n'est pas accessible pour nous en utilisant l'interface publique de la machine.

Pour accéder à l'interface web, nous allons créer un tunnel SSH vers la machine cliente qui contient les fichiers de l'interface. Consul sert l'interface HTTP sur le port 8500. Nous allons faire passer notre port local 8500 par tunnel vers le port 8500 de la machine cliente. Sur votre ordinateur local, tapez :

ssh -N -f -L 8500:localhost:8500 root@192.0.2.50

Cela se connectera à la machine distante, créera un tunnel entre notre port local et le port distant, puis mettra la connexion en arrière-plan.

Dans votre navigateur web local, vous pouvez maintenant accéder à l'interface web de Consul en tapant :

http://localhost:8500

Cela vous donnera la page UI web par défaut :

Vous pouvez utiliser cette interface pour vérifier l'état de vos serveurs et obtenir un aperçu de vos services et de votre infrastructure.

Lorsque vous avez terminé d’utiliser l’interface Web, vous pouvez fermer le tunnel SSH. Recherchez le numéro de PID du processus en utilisant la commande ps et grep pour chercher le numéro de port que nous avons transféré :

ps aux | grep 8500

1001      5275  0.0  0.0  43900  1108 ?        Ss   12:03   0:00 ssh -N -f -L 8500:localhost:8500 root@192.241.170.60
1001      5309  0.0  0.0  13644   948 pts/7    S+   12:12   0:00 grep --colour=auto 8500

Le numéro surligné dans la sortie ci-dessus (sur la ligne contenant la commande de tunnel que nous avons utilisée) est le numéro de pid que nous recherchons. Nous pouvons ensuite le transmettre à la commande kill pour fermer le tunnel :

kill 5275

Conclusion

Vous devriez maintenant avoir un moyen stable de gérer vos membres du consul. Le cluster consul peut être initialisé et démarré rapidement et facilement. Des nœuds supplémentaires peuvent être configurés rapidement en copiant les fichiers de configuration (configuration du consul et script upstart) des serveurs existants.

Bien que nous ayons maintenant notre environnement Consul configuré de manière à nous permettre de gérer facilement nos services, nous n'avons pas encore entièrement sécurisé nos communications. Dans le prochain guide, nous nous concentrerons sur la façon de configurer la validation des certificats SSL afin de chiffrer et de valider les communications RPC de nos membres.