La découverte de service ne peut pas obtenir une définition appropriée sans la reconnaissance d'un réseau informatique existant. Un réseau informatique définit les protocoles de communication nécessaires pour que les périphériques réseau partagent les ressources disponibles via ses nœuds de réseau. Ce partage de ressources implique à la fois des périphériques réseau et des services prédéfinis sur ce réseau.
La solution de contournement à la découverte ou à la détection automatique de ces périphériques et services réseau sous un réseau informatique est une définition viable de la découverte de service. Pour que la découverte de service sous un réseau informatique configuré soit complète, elle aura besoin de l'assistance d'un protocole réseau appelé Service Discovery Protocol (SDP). Avec ces protocoles, les utilisateurs et les administrateurs du réseau n'ont pas besoin de s'appuyer sur leurs compétences en configuration réseau pour faire avancer les choses.
Étant donné que la découverte de service communique avec des agents logiciels sur un réseau informatique, ses protocoles de communication doivent adhérer à un langage réseau commun pour empêcher l'intervention continue de l'utilisateur chaque fois que l'exécution d'une étape critique est nécessaire.
Conceptualiser la découverte de services dans un environnement de production
Traditionnellement, le développement d'applications adoptait une approche monolithique. Cette approche a ensuite été remaniée en faisant en sorte qu'une seule application existe sous forme de petites pièces synchronisées travaillant vers un objectif commun. Ce concept définit l'utilité des microservices dans lesquels des composants séparés travaillent vers un objectif d'application unique. Les applications SaaS ou d'entreprise sont privilégiées pour cette approche du développement d'applications.
Une application définie par de petits composants facilite l'élimination des bogues et l'identification et le remplacement d'un composant d'application qui n'est pas entièrement fonctionnel. Étant donné que ces composants sont destructibles, leur déploiement dans un environnement de production les relie à un service réseau qui s'identifie aux emplacements des composants et aux autres services qui leur sont associés.
Cette configuration automatique des instances de service aux composants d'application de production décompose la définition de la découverte de service.
Outils populaires de découverte de services open source pour Linux
L'évolution de l'architecture des microservices et sa contribution au développement d'applications modernes ont fait de la découverte de services un incontournable. Lorsqu'un nouveau composant d'application est déployé, la découverte de service élimine toute latence entre l'application et les autres points de terminaison de service. Si vous envisagez de faciliter certaines fonctionnalités de découverte de services via des microservices, vous devez vous familiariser avec ces outils open source.
Consul
En plus de répondre à l'objectif de découverte de service, Consul est un outil efficace pour surveiller et configurer les paramètres de production d'un réseau. Il crée un magasin de données peer-to-peer et des clusters dynamiques via la bibliothèque de Serf. Pour cette raison, cet outil de découverte de service est hautement distribué.
Consul se présente comme un magasin clé-valeur pour configurer et gérer un environnement de production. Serf existe en tant que protocole de potins qui gère efficacement des éléments tels que la détection des pannes dans les clusters créés. Un protocole de consensus gère la cohérence du système dans cet environnement de production via Raft.
Caractéristiques principales du consul
- Pourvu qu'il existe une interface d'application telle que MySQL, DNS ou HTTP ; services peuvent s'enregistrer facilement et automatiquement. Il est également facile de détecter et d'encapsuler d'autres services externes nécessaires au bon fonctionnement de l'environnement réseau de configuration.
- Cet outil offre une prise en charge étendue de la configuration DNS. Cela rend le processus d'intégration DNS transparent.
- Sous réserve qu'un cluster configuré présente des problèmes d'intégrité, Consul effectuera effectivement une vérification de l'état de ce cluster et enregistrera les résultats du diagnostic dans un journal envoyé à l'opérateur réseau concerné.
- La fonctionnalité de stockage clé/valeur de Consul est efficace pour signaler les fonctionnalités et effectuer des configurations dynamiques.
- Cet outil fonctionne avec les API HTTP pour stocker et récupérer des données clé/valeur définies et confinées dans un magasin clé/valeur distribué.
Configuration du cluster Consul
Ce guide aura une idée pratique sur la réalisation de la découverte de services via un cluster Consul en utilisant plusieurs nœuds.
Prérequis
- Cette configuration sera plus productive si vous avez accès à trois serveurs Linux.
- Vos trois serveurs doivent avoir certains ports spécifiés ouverts. Ils sont 8300 pour TCP, 8301 pour TCP &UDP, 8302 pour TCP &UDP, 8400 pour TCP, 8500 pour TCP et 8600 pour TCP &UDP. Selon les serveurs que vous utilisez, par exemple AWS, GCP ou Azure, vos balises de pare-feu et de groupes de sécurité doivent être correctement configurées afin que les ports mentionnés puissent communiquer facilement.
Configuration du cluster Consul
Puisque nous utilisons trois serveurs, nous allons implémenter un cluster Consul à trois nœuds. Nous pouvons donner à ces nœuds les noms consul-1, consul-2 et consul-3. Les étapes suivantes nous mèneront à un cluster Consul entièrement fonctionnel.
Installation et configuration de Consul sur les trois nœuds définis
Les étapes 1 à 3 s'appliquent à tous les nœuds Consul définis.
Étape 1 :Sur chaque terminal serveur, naviguez dans le répertoire bin et utilisez la commande applicable à votre distribution Linux pour télécharger le binaire Linux Consul. Ce dernier lien met en évidence les procédures d'installation pour d'autres gestionnaires de packages Linux.
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install consul
Étape 2 : Les répertoires suivants doivent être créés. Faites attention aux chemins de répertoire.
sudo mkdir -p /etc/consul.d/scripts sudo mkdir /var/consul
Étape 3 : Parmi les trois serveurs, choisissez-en un et exécutez la commande suivante sur son terminal pour créer votre secret Consul. Le secret généré doit être enregistré dans un fichier texte.
consul keygen
Étape 4 : Vos trois serveurs doivent avoir le fichier de configuration suivant. Créez-le comme indiqué ci-dessous.
sudo vi /etc/consul.d/config.json
Remplissez le fichier config.json créé ci-dessus avec les données suivantes. Sur ce fichier, la valeur "encrypt" doit être remplacée par la valeur secrète Consul que vous avez générée à l'étape 3. De plus, la valeur "start_join" doit contenir les adresses IP respectives des trois serveurs que vous avez choisi d'utiliser.
{
"bootstrap_expect": 3,
"client_addr": "0.0.0.0",
"datacenter": "Us-Central",
"data_dir": "/var/consul",
"domain": "consul",
"enable_script_checks": true,
"dns_config": {
"enable_truncate": true,
"only_passing": true
},
"enable_syslog": true,
"encrypt": "generated_Consul_key_value",
"leave_on_terminate": true,
"log_level": "INFO",
"rejoin_after_leave": true,
"server": true,
"start_join": [
"server-1_IP",
"server-2_IP",
"server-3_IP"
],
"ui": true
} Création du service Consul
Tous nos trois nœuds ou serveurs doivent passer par les étapes suivantes.
Étape 1 : Créer un fichier Systemd
sudo vi /etc/systemd/system/consul.service
Une fois le fichier créé, remplissez-le avec les données suivantes.
[Unit] Description=Consul Startup process After=network.target [Service] Type=simple ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/' TimeoutStartSec=0 [Install] WantedBy=default.target
Étape 2 : Effectuer un rechargement sur les démons système
sudo systemctl daemon-reload
Amorçage et démarrage du cluster
Pour lancer le service Consul sur le premier serveur ou consul-1, exécutez la commande suivante sur son terminal.
sudo systemctl start consul
Pour lancer le service Consul sur les deux autres serveurs, consul-2 et consul-3, vous devez exécuter la même commande sur leurs terminaux de système d'exploitation respectifs.
sudo systemctl start consul
Sur chacun des trois serveurs, vous pourrez noter leurs statuts de cluster respectifs en exécutant la commande suivante sur chacun de leurs terminaux.
/usr/local/bin/consul members
Pour savoir si la configuration de votre cluster Consul a réussi, la sortie que vous recevez en exécutant la commande ci-dessus doit présenter certaines similitudes avec la suivante.
[fosslinux@consul-1 ~]$ /usr/local/bin/consul members Node Address Status Type Build Protocol DC Segment consul-1 10.128.0.7:8301 alive server 1.2.0 2 us-central <all> consul-2 10.128.0.8:8301 alive server 1.2.0 2 us-central <all> consul-3 10.128.0.9:8301 alive server 1.2.0 2 us-central <all>
Accéder à l'interface utilisateur Consul
Si votre version installée de Consul est 1.20 ou ultérieure, elle est fournie avec un composant d'interface utilisateur Consul intégré. Cette interface utilisateur Consul est basée sur le Web, et pour y accéder sur votre navigateur, vous devez respecter la règle de syntaxe d'URL suivante.
http://<your-consul-server-IP-address>:8500/ui
Un exemple d'implémentation de la règle de syntaxe d'URL ci-dessus ressemblera à ce qui suit :
http://46.129.162.98:8500/ui
Pratique du Consul
L'inconvénient de l'utilisation de Consul est lorsqu'il s'agit de gérer les complexités inhérentes aux systèmes distribués configurés avec lui. Ce problème est général et dépend de l'architecture de ces systèmes. Cela n'a rien à voir avec l'aspect performance du Consul.
Un autre avantage de travailler avec Consul est qu'il dispose de toutes les bibliothèques nécessaires, ce qui évite aux utilisateurs de définir et d'utiliser des bibliothèques tierces. Nous pouvons comparer la conceptualisation de Consul au Sidecar OSS de Netflix. Ici, les clients non-Zookeeper restent détectables puisqu'ils peuvent s'enregistrer sur le système.
L'importance de l'outil de découverte de services Consul a attiré des entreprises réputées telles que SendGrid, Percolate, DigitalOcean, Outbrain et EverythingMe.
etc.
L'outil de découverte de service Etcd offre une fonctionnalité de magasin de clé/valeur décrite de la même manière dans Consul et Zookeeper. C'était un composant clé de CoreOS avant le statut de dépréciation du système d'exploitation. Le langage de programmation Go a joué un rôle clé dans son développement. Il utilise également Raft comme moyen de gérer les protocoles de consensus.
Il est rapide et fiable dans la fourniture d'API basées sur JSON et HTTP. Cette disposition fonctionnelle est complétée par des requêtes et des notifications push. Dans un cadre pratique, le cluster défini ou créé hébergera cinq ou sept nœuds. En plus de la découverte de services, les architectures de microservices qui implémentent Etcd dans leurs conteneurs bénéficieront également de l'enregistrement de ces services.
Sous l'enregistrement du service, Etcd gère l'écriture de la paire clé-valeur nécessaire. Sous découverte de service, Etcd gère la lecture de la paire clé-valeur créée.
Pour que d'autres applications créées puissent communiquer avec Etcd, elles doivent adhérer à un protocole de projet confd. Ce protocole crée des fichiers de configuration statiques à partir des informations stockées par Etcd. Dans ce cadre, il incombe aux clients de gérer les échecs de connexion viables et de créer une reconnexion via d'autres instances de service viables.
Les entreprises de premier plan qui ont Etcd sur leur CV incluent CloudGear, Headspace, Red Hat, Kubernetes, Apptus, Zenreach, Cloud Foundry et Google. Le support communautaire croissant d'Etcd améliore l'expérience des développeurs sur la plate-forme de cet outil de découverte de services.
Configurer Etcd
La capacité d'Etcd à stocker et à récupérer des configurations n'est pas sa seule caractéristique principale en tant que magasin clé-valeur open source. Les clusters Etcd créés ont un minimum de problèmes de défaillance de nœud en raison de leur haute disponibilité. Ses valeurs stockées sont récupérées par les clients via REST/gRPC.
Prérequis
Les exigences suivantes rendront votre expérience de mise en place du cluster Etcd plus fructueuse.
- Avoir accès à trois serveurs Linux fonctionnels
- Vos trois choix de serveur doivent être configurés avec des noms d'hôte valides.
- Pour une communication peer-to-peer et des demandes client efficaces, les ports 2380 et 2379 de vos serveurs doivent être activés à partir des règles de pare-feu du système.
Configuration du cluster Etcd sur votre machine Linux
La configuration du cluster Etcd ne devrait pas vous donner de maux de tête car elle est relativement simple, en particulier avec l'approche d'amorçage statique. Pour que vous réussissiez à démarrer avec cette approche, vous devez mémoriser les adresses IP de votre nœud. Ce guide d'installation couvrira toutes les étapes dont vous pourriez avoir besoin pour créer avec succès des clusters de serveurs Linux puisque nous avons affaire à une configuration multinœud.
Pour qu'etcd fonctionne en tant que service, nous devrons également configurer les fichiers systemd. Ce qui suit n'est qu'un exemple de la relation entre le nom d'hôte et l'adresse IP que nous utiliserons dans ce guide de configuration.
etcd-1 : 10.128.0.7 etcd-2 : 10.128.0.8 etcd-3 : 10.128.0.9
Si vous disposez des privilèges administratifs nécessaires, vous pouvez modifier les noms d'hôte de vos serveurs pour refléter vos préférences personnalisables.
Il est temps de passer à la configuration du cluster etcd.
Les trois nœuds
Les étapes successives suivantes s'appliquent aux trois nœuds de serveur.
Étape 1 : Sur chaque terminal serveur, accédez au répertoire src avec la commande suivante :
cd /usr/local/src
Étape 2 : Lorsque vous faites référence aux versions de Github, vous devriez pouvoir récupérer la dernière version d'etcd. Assurez-vous de télécharger sa dernière version stable.
sudo wget "https://github.com/coreos/etcd/releases/download/v3.3.9/etcd-v3.3.9-linux-amd64.tar.gz"
Étape 3 : Dans cette étape, nous allons décompresser le binaire etcd téléchargé.
sudo tar -xvf etcd-v3.3.9-linux-amd64.tar.gz
Étape 4 : Le processus de décompression devrait produire des fichiers etcd et etcdctl. Ces extractions sont des exécutables etcd. Utilisez la commande suivante pour les déplacer vers le répertoire bin local.
sudo mv etcd-v3.3.9-linux-amd64/etcd* /usr/local/bin/
Étape 5 : Puisque nous voulons qu'un utilisateur etcd exécute le service etcd, vous devrez créer un utilisateur, un groupe et des dossiers etcd.
sudo mkdir -p /etc/etcd /var/lib/etcd groupadd -f -g 1501 etcd useradd -c "etcd user" -d /var/lib/etcd -s /bin/false -g etcd -u 1501 etcd chown -R etcd:etcd /var/lib/etcd
Étape 6 : Assurez-vous que vous disposez des privilèges d'utilisateur root lorsque vous effectuez les actions suivantes.
ETCD_HOST_IP=$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)
ETCD_NAME=$(hostname -s) La séquence de commandes ci-dessus définit deux variables d'environnement. La première variable d'environnement récupère l'adresse IP du serveur et la seconde associe cette adresse IP à un nom d'hôte.
Etcd a maintenant besoin d'un fichier de service systemd.
cat << EOF > /lib/systemd/system/etcd.service
Après avoir créé ce fichier de service, remplissez-le pour qu'il ressemble à celui ci-dessous.
[Unit]
Description=etcd service
Documentation=https://github.com/etcd-io/etcd
[Service]
User=etcd
Type=notify
ExecStart=/usr/local/bin/etcd \\
--name ${ETCD_NAME} \\
--data-dir /var/lib/etcd \\
--initial-advertise-peer-urls http://${ETCD_HOST_IP}:2380 \\
--listen-peer-urls http://${ETCD_HOST_IP}:2380 \\
--listen-client-urls http://${ETCD_HOST_IP}:2379,http://127.0.0.1:2379 \\
--advertise-client-urls http://${ETCD_HOST_IP}:2379 \\
--initial-cluster-token etcd-cluster-1 \\
--initial-cluster etcd-1=http://10.142.0.7:2380,etcd-2=http://10.142.0.8:2380,etcd-3=http://10.142.0.9:2380 \\
--initial-cluster-state new \\
--heartbeat-interval 1000 \\
--election-timeout 5000
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF La partie « –listen-client-urls » de ce fichier doit être remplacée par les trois adresses IP de serveur utilisées. Selon les serveurs de configuration, les valeurs « –name », « –listen-peer-urls », « –initial-advertise-peer-urls » et « –listen-client-urls » seront différentes. Quant aux variables ETCD_HOST_IP et ETCD_NAME, leurs valeurs d'entrée sont automatisées et remplacées par le système.
Amorcer le cluster etcd
Les configurations ci-dessus des étapes 1 à 6 doivent s'appliquer à vos trois serveurs. Ensuite, la prochaine étape consistera à démarrer et à activer le service etcd que nous venons de créer. Cet effort devrait s'appliquer aux trois nœuds. Le serveur 1 assumera la fonctionnalité d'un nœud d'amorçage. Une fois que le service etcd est opérationnel, il sélectionne automatiquement un nœud en tant que leader. Vous n'avez donc pas à vous soucier d'être impliqué dans la configuration de ce nœud leader.
systemctl daemon-reload systemctl enable etcd systemctl start etcd.service systemctl status -l etcd.service
Vérification de l'état du cluster etcd
L'utilitaire etcdctl que nous avons extrait plus tôt après le téléchargement du binaire etcd est responsable de l'initiation de l'interaction avec le cluster etcd. Vos trois nœuds doivent avoir cet utilitaire dans le répertoire /usr/local/bin.
Les vérifications système suivantes s'appliquent à tous les nœuds de cluster et ne sont pas limitées à un nœud spécifique. La première vérification consiste à déterminer l'état de santé de votre cluster.
etcdctl cluster-health
Vous pouvez également contrôler et vérifier le statut d'appartenance d'un nœud de cluster pour déterminer s'il a le statut de leader.
etcdctl member list
Par défaut, vous accéderez explicitement aux fonctionnalités d'etcd v2 via etcdctl. C'est son association par défaut. Si vous souhaitez accéder à etcd v3 et ses fonctionnalités, utiliser la variable « ETCDCTL_API=3 » est une option viable. Pour implémenter cette variable, configurez-la en tant que variable d'environnement. Vous pouvez également transmettre la variable à chaque fois que vous utilisez la commande etcdctl.
Essayez de créer et de vérifier les paires clé-valeur suivantes.
ETCDCTL_API=3 etcdctl put name5 apple ETCDCTL_API=3 etcdctl put name6 banana ETCDCTL_API=3 etcdctl put name7 orange ETCDCTL_API=3 etcdctl put name8 mango
Pour accéder à la valeur name7, exécutez la commande suivante.
ETCDCTL_API=3 etcdctl get name7
Grâce à l'utilisation de plages et de préfixes, il est possible de répertorier toutes les clés comme illustré ci-dessous :
ETCDCTL_API=3 etcdctl get name5 name8 # lists range name5 to name8 ETCDCTL_API=3 etcdctl get --prefix name # lists all keys with name prefix
Apache Zookeeper
Ce service peut être décrit comme centralisé, distribué et cohérent. Le langage de programmation Java est responsable de sa création. Apache Zookeeper peut gérer efficacement les changements de cluster via le protocole Zab. Son rôle précédent consistait à maintenir les composants du cluster logiciel dans le monde Apache Hadoop.
Ici, le stockage des données se fait soit sur une arborescence, soit dans un système de fichiers, soit dans un espace de noms hiérarchique. Lorsqu'un client est connecté à ce réseau, les nœuds continuent d'exister. En revanche, lorsqu'une déconnexion du réseau se produit ou qu'il y a un problème avec le réseau configuré, les nœuds disparaissent. Lorsqu'un problème de panne de réseau ou d'équilibrage de charge survient, il appartient aux clients de le résoudre. Lorsqu'Apache Zookeeper enregistre un nouveau service, les clients reçoivent des notifications liées à ces services.
La cohérence du système Zookeeper ne le protège pas des défaillances potentielles du système. Certaines plates-formes peuvent avoir des problèmes pour enregistrer les services nécessaires ou même rencontrer des erreurs lors de la mise en œuvre des fonctions de service de lecture et d'écriture. D'autre part, Apache Zookeeper continue d'être une application robuste et établie avec un support de bibliothèque étendu qui profite à sa communauté d'utilisateurs dynamique et à ses clients en pleine croissance.
Les entreprises de premier plan qui s'associent à Apache Zookeeper incluent Apache Software Foundation, Luxoft, Solr, Reddit, Rackspace, Spero Solutions, F5 Networks, Cloudera, eBay et Yahoo!
Configurer Apache Zookeeper
Apache Zookeeper est parfait pour gérer diverses charges de travail distribuées en raison de son adaptation fonctionnelle en tant qu'outil de coordination distribué.
Prérequis
- Vous avez besoin de trois machines virtuelles (VM). Le nombre de VM à utiliser peut être supérieur à 3, mais ce nombre doit être impair pour un cluster à haute disponibilité.
- Les ports 2181, 2888 et 3888 doivent être activés via les tables IP du système serveur pour que les connexions entrantes des VM s'effectuent via ces ports. Ces ports sont responsables de la communication d'Apache Zookeeper.
Les personnes travaillant sous des fournisseurs de cloud comme AWS doivent avoir des points de terminaison ou des groupes de sécurité activés pour qu'Apache Zookeeper fonctionne avec ces ports.
L'installation et la configuration d'Apache Zookeeper
Vos trois VM devraient bénéficier des étapes suivantes :
Étape 1 : Mise à jour du serveur
sudo yum -y update
Étape 2 : Installation Java. Ignorez cette étape si Java est déjà installé.
sudo yum -y install java-1.7.0-openjdk
Étape 3 : Utilisez la commande "wget" pour télécharger Zookeeper.
wget http://mirror.fibergrid.in/apache/zookeeper/zookeeper-3.5.2-alpha/zookeeper-3.5.2-alpha.tar.gz
Étape 4 : Décompressez l'application Apache Zookeeper dans le répertoire /opt.
sudo tar -xf zookeeper-3.5.2-alpha.tar.gz -C /opt/
Étape 5 : Accédez au répertoire de l'application Apache Zookeeper et renommez-le en
cd /opt
sudo mv zookeeper-* zookeeper
Étape 6 : Dans le répertoire /opt/zookeeper/conf, nous devrons travailler avec un fichier appelé zoo.cfg. Créez ce fichier et remplissez-le avec les données de configuration suivantes.
tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=5 syncLimit=2 server.1=<ZooKeeper_IP/hostname>:2888:3888 server.2=<ZooKeeper_iP/hostname>:2888:3888 server.3=<ZooKeeper_iP/hostname>:2888:3888
Vos trois serveurs Zookeeper sont représentés par le serveur 1, le serveur 2 et le serveur 3. La variable « ZooKeeper_IP » doit être remplacée par les adresses IP de vos trois serveurs ou les noms d'hôte résolubles de ces adresses IP identifiables.
Étape 7 : Le fichier zoo.cfg que nous avons créé et rempli pointe vers un répertoire de données appelé lib, qui contient également un autre répertoire appelé zookeeper. Nous devons créer ce répertoire car il n'existe pas encore.
sudo mkdir /var/lib/zookeeper
Étape 8 : Dans le répertoire créé ci-dessus, créez un fichier myid.
sudo touch /var/lib/zookeeper/myid
Étape 9 : Ce fichier myid contiendra des numéros uniques pour identifier chaque serveur Apache Zookeeper.
Pour le serveur Zookeeper 1
sudo sh -c "echo '5' > /var/lib/zookeeper/myid"
Pour le serveur Zookeeper 2
sudo sh -c "echo '6' > /var/lib/zookeeper/myid"
Pour le serveur Zookeeper 3
sudo sh -c "echo '7' > /var/lib/zookeeper/myid"
Configuration du service Apache Zookeeper
Pour démarrer et arrêter Zookeeper, nous devrons utiliser des scripts. Cependant, l'exécution de ces scripts en tant que service permet de mieux les gérer. Nous devrons ouvrir le fichier zkServer.sh.
sudo vi /opt/zookeeper/bin/zkServer.sh
Le fichier ouvert sous "#!/usr/bin/env" le remplit avec les données suivantes.
# description: Zookeeper Start Stop Restart # processname: zookeeper # chkconfig: 244 30 80
Sur le même fichier zkServer.sh, tracez le live « #use POSTIX interface, symlink… ». Remplacez et substituez les variables qui succèdent à cette ligne par ces valeurs.
ZOOSH=`readlink $0` ZOOBIN=`dirname $ZOOSH` ZOOBINDIR=`cd $ZOOBIN; pwd` ZOO_LOG_DIR=`echo $ZOOBIN`
Le service Zookeeper a maintenant besoin d'un lien symbolique.
sudo ln -s /opt/zookeeper/bin/zkServer.sh /etc/init.d/zookeeper
Le menu de démarrage doit accueillir Zookeeper.
sudo chkconfig zookeeper on
Vos trois serveurs doivent être redémarrés avec la commande suivante. Exécutez-le sur leurs terminaux respectifs.
sudo init 6
Une fois les serveurs redémarrés, leur gestion se fera sans effort grâce aux séquences de commandes suivantes.
sudo service zookeeper status sudo service zookeeper stop sudo service zookeeper start sudo service zookeeper restart
Lorsque la commande de vérification de l'état de Zookeeper s'exécute, la sortie du terminal doit ressembler à ce qui suit.
/bin/java ZooKeeper JMX enabled by default Using config: /opt/zookeeper/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: leader
L'un des trois serveurs se voit attribuer le mode leader et les deux autres conservent le mode suiveur.
Remarque finale
La découverte de service sert deux objectifs importants :la haute disponibilité et la détection des pannes. Avec plus de fonctionnalités en file d'attente, une implémentation d'infrastructure ne peut être complète sans reconnaître et configurer des outils de découverte de services tels que Consul, Etcd et Apache Zookeeper. Ces outils sont open-source et fondamentalement efficaces dans leurs fonctionnalités de prestation de services. Par conséquent, vous ne rencontrerez aucun obstacle en essayant de tester ou d'implémenter un mécanisme de découverte de service simple sur vos systèmes Linux.