Comment configurer Consul dans un environnement de production sur Ubuntu 14.04

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

Consul fournit de nombreuses fonctionnalités différentes qui sont 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 marquage, des vérifications de l’état, des routines d’élection basées sur un consensus, un stockage clé / valeur à l’échelle du système, etc. En tirant parti de consul au sein de votre organisation, vous pouvez facilement créer un niveau sophistiqué de sensibilisation dans vos applications et services.

Dans notre https://www.digitalocean.com/community/tutorials/an-inintroduction-to-using-consul-a-service-discovery-system-on-ubuntu-14-04 (dernier guide), nous avons fourni un rapide démonstration de certaines fonctionnalités du consul. Dans ce guide, nous allons commencer à créer une configuration consul prête pour la production, pouvant être utilisée pour démarrer la mise en œuvre de la découverte de service pour votre infrastructure.

Dans cette série, nous allons mettre en place un système de serveurs qui pourront communiquer entre eux et gérer les informations de service, les pools de stockage de clé / valeur et d’autres détails pour les ordinateurs clients. Les premières étapes pour préparer notre système à la production auront lieu dans ce guide, lors de l’installation du logiciel et de l’automatisation de certaines de nos configurations.

La documentation consul vous recommande d’exécuter 3 ou 5 * serveurs * consul dans chaque centre de données afin d’éviter la perte de données en cas de défaillance du serveur. Les serveurs Consul sont la composante qui fait le gros du travail. Ils stockent des informations sur les services et les informations clé / valeur. Un nombre impair de serveurs est nécessaire pour éviter les problèmes d’impasse pendant les élections.

Outre les serveurs consul, d’autres machines peuvent exécuter * des agents consul *. Les agents Consul sont très légers et transmettent simplement les demandes aux serveurs. Ils fournissent une méthode d’isolation de vos serveurs et évitent aux agents eux-mêmes de connaître les adresses des serveurs.

Pour pouvoir implémenter certains des mécanismes de sécurité dans un guide ultérieur, nous devons nommer toutes nos machines dans un même domaine. C’est pour que nous puissions émettre un certificat SSL générique ultérieurement.

Les détails de nos machines sont ici:

Nous allons utiliser des serveurs Ubuntu 14.04 64 bits pour cette démonstration, mais tout serveur Linux moderne devrait fonctionner de la même manière. Une fois la configuration terminée, vous devez disposer d’un système vous permettant d’ajouter facilement des services, des contrôles et des nœuds.

Connectez-vous à vos ordinateurs en tant qu’utilisateur root pour effectuer les étapes décrites dans ce guide.

Si vous n’avez pas déjà installé consul dans link: [la première introduction au guide consul], vous devrez le faire maintenant. Nous installerons consul en tant qu’application au niveau du système sur chacune des quatre machines que nous configurons.

Avant de regarder dans l’application consul, nous devons obtenir + unzip + pour extraire l’exécutable. Mettez à jour le cache du paquet de systèmes locaux, puis installez le paquet en utilisant + apt +:

Nous pouvons maintenant obtenir le programme de consul. La page du projet consul fournit des liens de téléchargement vers des packages binaires pour Windows, OS X et Linux.

Accédez à la page ci-dessus et cliquez avec le bouton droit sur le système d’exploitation et l’architecture qui représente vos serveurs. Dans ce guide, comme nous utilisons des serveurs 64 bits, nous utiliserons le lien «amd64» sous «linux». Sélectionnez «Copier l’emplacement du lien» ou toute autre option similaire fournie par votre navigateur.

Dans votre terminal, accédez au répertoire + / usr / local / bin, où nous conserverons l’exécutable. Tapez + wget + et un espace, puis collez l’URL que vous avez copiée à partir du site:

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é:

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

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 essayer de mettre en place un système plus fiable, plus facile à gérer. Nous allons donc créer une structure pour que cela fonctionne. Effectuez les étapes suivantes sur chacun de vos ordinateurs (serveurs et clients).

La première chose à faire est de créer un utilisateur spécifique à notre tâche. Ceci est un cas standard de séparation des privilèges utilisateur, nous allons donc exécuter nos processus consul avec un utilisateur dédié.

Créez maintenant l’utilisateur en tapant:

Vous pouvez ignorer toutes les invites (vous pouvez éventuellement définir un mot de passe. Sinon, vous vous plaindrez si vous le souhaitez.

Ensuite, nous allons créer la hiérarchie de configuration qui hébergera les différentes configurations que nous utiliserons en fonction de la manière dont nous voulons démarrer le service. Pour rendre cela facile, nous allons créer un répertoire + consul.d + parent dans la structure de configuration + / etc + et y placer des sous-répertoires appelés + bootstrap +, + server + et + client + :

Nous pourrons mettre nos configurations dans chacune d’elles plus tard. Chaque serveur utilisera probablement au maximum deux de ces répertoires, mais nous allons créer 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. À cette fin, nous allons créer un répertoire dans + / var / consul + et le donner à l’utilisateur + consul + afin qu’il puisse gérer les données:

Avec cette structure en place, nous devrions pouvoir commencer à concevoir nos fichiers de configuration.

La première configuration que nous devons créer est destinée à amorcer le cluster. Ce n’est pas un événement très courant car il n’est nécessaire que pour la création initiale du cluster. Cependant, nous allons créer le fichier de configuration afin de pouvoir redémarrer rapidement en cas de panne complète du cluster.

Vous pouvez placer ce fichier de configuration sur un seul de vos serveurs consul ou sur l’ensemble d’entre eux pour vous donner davantage d’options pour l’amorçage. Nous ne le placerons que sur + server1 + pour cette démonstration.

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

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:

Nous devrions également spécifier le centre de données dans lequel notre cluster vivra. Cela peut être n’importe quel nom qui vous aide à identifier l’emplacement physique du cluster. Consul est sensible aux centres de données et ces désignations vous aideront à organiser vos différents clusters par centre de données.

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

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

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

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

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

Enfin, nous ajouterons des informations supplémentaires pour spécifier le niveau de journalisation et indiquer si vous souhaitez utiliser syslog pour la journalisation:

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant que notre configuration d’amorçage est terminée, nous pouvons l’utiliser comme base pour la configuration générale de notre serveur. La configuration du serveur sera utilisée une fois le cluster démarré.

Commencez par copier le fichier d’amorçage de + server1 + dans le sous-répertoire du serveur de cette machine pour le modifier:

Ouvrez le fichier pour effectuer les modifications nécessaires:

Pour commencer, nous devons désactiver l’indicateur d’amorçage, car cette configuration est destinée à des configurations autres que l’amorçage.

La seule autre chose que nous devons modifier pour la configuration du serveur consiste à spécifier les adresses IP de l’autre serveur auxquelles ce nœud doit tenter de se connecter lors du démarrage. Cela prend en charge la jointure automatique, de sorte que nous n’ayons pas à joindre manuellement le cluster après le démarrage de notre serveur:

Le paramètre + encrypt + _ doit être identique pour tous les participants du système. La copie du fichier a donc déjà pris en compte cette exigence pour nous. Gardez cela à l’esprit lors de la création de nouvelles configurations.

Enregistrez le fichier lorsque vous avez terminé.

Vous devez copier le contenu de ce fichier de configuration sur les autres ordinateurs qui serviront de serveurs consul. Placez-les dans un fichier + / etc / consul.d / server / config.json + comme vous l’avez fait dans le premier hôte.

La seule valeur que vous devez modifier sur les autres hôtes est l’adresse IP à laquelle il doit tenter de se connecter. Assurez-vous qu’il tente de se connecter au premier serveur au lieu de sa propre adresse IP. Par exemple, le deuxième serveur de notre exemple aurait un fichier qui ressemblerait à ceci:

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

Nos configurations de serveur sont maintenant complètes. Nous pouvons nous concentrer sur l’installation de notre machine cliente avec une configuration appropriée.

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

Nous allons à nouveau utiliser une configuration précédente comme base de notre nouvelle configuration. Copiez le contenu d’un des fichiers du serveur dans ce fichier.

Nous allons commencer par supprimer toute mention du paramètre + bootstrap + car cela s’applique uniquement aux configurations de serveur et en définissant le paramètre + server + sur false.

Ensuite, nous allons ajouter un paramètre spécifiant l’emplacement du répertoire de l’interface Web. Nous allons acquérir les fichiers nécessaires pour cela dans un peu. Leur lieu de résidence est + / home / consul / dist +.

Enfin, nous souhaitons ajuster le paramètre + start_join + pour répertorier tous nos serveurs:

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant que nous avons configuré le client pour servir l’interface utilisateur Web, nous devons acquérir les fichiers qui nous permettront de le faire.

Sur le site Web du consul, cliquez avec le bouton droit de la souris sur l’interface utilisateur Web consul et sélectionnez "Copier l’emplacement du lien" ou toute autre option similaire.

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 +.

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 d’écrire ces lignes, cela ressemblera à ceci:

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

Cela créera un répertoire appelé + dist + dans votre répertoire personnel. C’est le répertoire vers lequel nous avons indiqué le paramètre Web UI dans le fichier de configuration.

Avant de continuer, vous devez quitter la session de l’utilisateur consul pour revenir à la session racine:

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

L’amorçage d’un cluster n’étant pas quelque chose que nous devrons souvent faire (la plupart du temps, le cluster lui-même persistera et un seul nœud devra peut-être être redémarré et rejoindre le cluster), nous ne prendrons pas en compte l’amorçage dans le script de démarrage. Nous allons vous montrer comment effectuer manuellement ce processus sous peu.

Notre script de démarrage 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 la configuration de votre consul:

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

Ensuite, nous spécifions les conditions dans lesquelles le processus va démarrer. Pour ce service, nous voulons qu’il commence lorsque le système de fichiers local est monté et que l’interface de réseau public est en cours d’exécution.

Nous voulons également spécifier quand le processus doit s’arrêter. En utilisant les standard Linux runlevels, nous pouvons lui dire d’arrêter le processus lorsqu’il ne se trouve pas dans l’un des modes de fonctionnement normaux (arrêter le processus lors d’un arrêt ou d’un redémarrage le serveur):

Nous pouvons dire au système init de redémarrer le processus s’il meurt 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:

Enfin, nous devons fournir la commande à exécuter. Ce sera simplement la commande + consul + exécutée en mode agent. Nous allons passer dans le répertoire contenant les spécifications de configuration de notre serveur en tant qu’argument de la commande:

Enregistrez le fichier lorsque vous avez terminé.

Copiez le contenu de ce fichier dans un fichier nommé + / etc / init / consul.conf + sur chacun de vos serveurs et du client.

Sur le client, nous devons modifier le fichier juste un peu. Nous devrions changer la description pour faire référence au fait qu’il s’agit d’un ordinateur client. Nous devons également changer le répertoire de configuration qui est passé dans la commande + consul + réelle.

Le fichier de fin devrait ressembler à ceci:

Enregistrez et fermez le fichier lorsque vous avez terminé.

Nous avons maintenant tout mis en place pour qu’un groupe de consul soit rapidement opérationnel. Le processus est relativement simple.

Sur un serveur contenant le fichier de configuration d’amorçage (dans notre cas), utilisez + su + pour passer brièvement à l’utilisateur consul. Nous pouvons ensuite appeler consul et passer comme argument le répertoire d’amorçage:

Le service devrait démarrer et occuper la fenêtre du terminal. En mode bootstrap, ce serveur choisira lui-même comme chef de file, créant ainsi une base pour la formation du cluster.

Sur les autres serveurs de consul, en tant que root, démarrez le service consul que nous venons de créer avec le script upstart en tapant:

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

Ce n’est pas ce que nous voulons. Nous voulons que tous les serveurs soient sur un pied d’égalité. Maintenant que le cluster est créé, nous pouvons arrêter l’instance de consul démarrée, puis entrer à nouveau dans le cluster en tant que serveur normal.

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

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

Ainsi, le serveur précédemment démarré rejoindra le cluster avec des privilèges non élevés, ce qui amènera le cluster à son état final.

Maintenant que le cluster est complètement opérationnel, les ordinateurs clients peuvent se connecter. Sur la machine cliente, suivez la même procédure en tant que root:

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 laquelle des machines:

Nous avons configuré notre ordinateur client pour héberger une interface Web vers le cluster. Cependant, cela est servi sur l’interface locale, ce qui signifie qu’elle ne nous est pas accessible via l’interface publique de la machine.

Pour accéder à l’interface utilisateur Web, nous allons créer un tunnel SSH vers la machine client contenant les fichiers de l’interface utilisateur. Consul sert l’interface HTTP sur le port 8500. Nous allons canaliser notre port local 8500 vers le port 8500 de la machine cliente. Sur votre ordinateur local, tapez:

Cela va se connecter à la machine distante, créer un tunnel entre notre port local et le port distant, puis mettre la connexion en arrière-plan.

Dans votre navigateur Web local, vous pouvez maintenant accéder à l’interface Web de consul en tapant:

Cela vous donnera la page d’interface utilisateur Web par défaut:

image: https: //assets.digitalocean.com/articles/consul_intro/consul_default.png [page de renvoi de l’interface Web de Consul]

Vous pouvez utiliser cette interface pour vérifier la santé de vos serveurs et obtenir une vue d’ensemble de vos services et de votre infrastructure.

Lorsque vous avez fini d’utiliser l’interface Web, vous pouvez fermer le tunnel SSH. Recherchez le numéro de pid du processus à l’aide de la commande + ps + et de + grep + pour rechercher le numéro de port que nous avons transféré:

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

Vous devriez maintenant avoir un moyen stable de gérer les membres de votre consul. Le groupe consul peut être démarré et démarré rapidement et facilement. Des nœuds supplémentaires peuvent être configurés rapidement en copiant les fichiers de configuration (consul config et script de mise à jour) des serveurs existants.

Bien que notre environnement de consul soit maintenant configuré de manière à nous permettre de gérer facilement nos services, nous n’avons pas encore complètement sécurisé nos communications. Dans le next guide, nous allons nous concentrer sur la manière de configurer Validation du certificat SSL afin de chiffrer et valider les communications RPC de nos membres.