Développé par HashiCorp, Consul est un projet récent constitué d’un ensemble de composants qui fournissent des fonctionnalités de découverte et de configuration de services, à l’échelle d’une infrastructure. Le “Service Discovery” est une idée générale, qui tend à se développer dans les conceptions de systèmes d’informations, non seulement en raison d’architectures orientées services et microservices, mais aussi dans les environnements de calculs de plus en plus dynamiques, voire éphémères, à l’instar d’un EC2 ou d’un Azure.

Il combine les fonctionnalités suivantes :

Service Discovery : Les clients Consul enregistrent des services comme une base de données ou une API. D’autres clients peuvent ainsi utiliser Consul afin de découvrir l’emplacement de ces services via des requêtes DNS ou REST.
HealthCheck : Les Clients Consul publient des HealhChecks associés aussi bien à des applications, du plus simple (Etat de la base de données, Réponse valide du Web Service) au plus complexe (Nombre d’utilisateurs/sessions actives, temps de réponse moyen des requêtes), mais aussi à des états des machines (Consommation Mémoire, utilisation CPU). Ces informations servent à la fois au monitoring du cluster ainsi qu’au système de découverte afin d’éviter de router des requêtes vers des nœuds inaccessibles.
Key/Value Store : Les applications peuvent utiliser Consul comme un système de stockage clé/valeur hiérarchique au travers d’une simple API REST.
Multi Datacenter capabilities : Consul fournit de facto le support multiple Datacenter, évitant ainsi l’intégration d’une couche d’abstraction supérieure.

Comment ça marche ?

Consul est construit autour d’un exécutable, l’Agent, qui est utilisable au travers de deux configurations, les ‘Serveurs’ et les ‘Clients’:

L’agent est un daemon qui s’exécute sur tous les membres du cluster Consul. Un agent peut s’exécuter en mode ‘Client’ ou ‘Serveur’. Tous les agents exposent les interfaces DNS et REST. Ils sont aussi responsables de l’exécution des HealhChecks et maintiennent la synchronisation des services. Clients

Les Clients sont des agents dont les seuls rôles sont de faire suivre les requêtes aux Serveurs et de participer au ‘LAN GOSSIP’. Ils ne consomment donc que peu de ressources locales et réseaux.

Au nombre minimum de trois par Datacenter, les Serveurs ont la charge de participer à la gestion du consensus au travers de l’algorithme RAFT (RAFT quorum), monitorer l’état du cluster, faire suivre les requêtes aux leaders et aux autres datacenters, répondre aux requêtes et participer aux échanges du ‘WAN GOSSIP’.

Le GOSSIP Protocol, aussi appeler Epidemic Protocol, est la pièce maitresse des échanges d’information au sein du cluster Consul.

On peut facilement illustrer son fonctionnement par l’analogie de diffusion d’une rumeur.

Explication : Toutes les heures, un ensemble de collègues se retrouve autour de la machine à café. Ils se regroupent en petits groupes aléatoires et partagent la dernière rumeur.

Au début de la journée, Alice échange avec Bob une nouvelle rumeur à propos de Charlie. A la réunion suivante, Bob va partager cette information avec David, tandis qu’Alice fera de même avec Eve.

On peut grossièrement dire qu’à chaque réunion, le nombre de personnes informées de la rumeur a doublé, jusqu’à atteindre l’ensemble des personnes présentes.

La robustesse de ce protocole réside dans sa diffusion de l’information. En effet, si David n’a pas compris ce que Bob lui a dit, il sera informé lors d’une des réunions suivantes.

Dans Consul, ce protocole se décline en deux formes :

LAN : Il a pour but de diffuser l’information dans un même datacenter au travers de tous les nœuds présents.
WAN : Celui-ci est réservé uniquement aux nœuds en mode ‘Serveur’, afin de partager les informations de leur datacenter avec tous les autres Serveurs présents dans le cluster et ainsi propager la liste des applications et leur état dans tous les datacenters.

Nos serveurs consul seront définis par leur adresse IP uniquement, mais aussi référencés par un label :

Note:

Il convient que les serveurs soient déclarés dans le DNS ou que les entrées soit référencés dans le fichier /etc/hosts de chaque serveurs.

Hardware & Software

OS : CentOS 8
Cpu : 2 vCpu
Ram : 2 Go
HDD : 40 Go

Nomage et IP :

consul001 : 192.168.1.101
consul002 : 192.168.1.102
consul003 : 192.168.1.103

Nous devrons installer Consul sur les trois nœuds.

Installation du package “yum-config-manager” pour gérer vos dépôts.

$ sudo yum install -y yum-utils

Utilisez “yum-config-manager” pour ajouter le dépôt Linux officiel de HashiCorp.

$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

Installation du package Consul

$ sudo yum -y install consul

Pour vérifier que “Consul” est correctement installé, lancez “consul -v” sur le système.

# consul -v
Consul v1.9.0
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Créer un répertoire pour stocker les données.

# mkdir -p /opt/consul 
# chown -R consul:consul /opt/consul 
# chmod -R 775 /opt/consul

Les communications Gossip sont chiffrées avec une clé symétrique, puisque les communications se font entre les nœuds par UDP. Tous les agents doivent avoir la même clé.

Vous pouvez créer la clé de chiffrement via le Consul CLI même si aucun agent Consul n'est encore en cours d'exécution.

Générer le secret du consul sur le premier nœud.

# consul keygen
cEYFheESgzjhgUHKhvzUGK==

Consul peut utiliser TLS pour vérifier l'authenticité des serveurs et des clients. Pour activer TLS, Consul exige que tous les agents disposent de certificats signés par une seule autorité de certification (CA).

Commencez par créer le RootCA sur votre instance d'administration, en utilisant le Consul CLI.

$ consul tls ca create
==> Saved consul-agent-ca.pem
==> Saved consul-agent-ca-key.pem

Créez ensuite un ensemble de certificats, un pour chaque agent consul.

Vous devez maintenant choisir un nom pour votre centre de données principal, afin que les certificats soient nommés correctement.

Tout d'abord, pour vos serveurs consuls, utilisez la commande suivante pour créer un certificat pour chaque serveur. Le nom du fichier s'incrémente automatiquement.

$ consul tls cert create -server -dc oowy-dc-1-<nœud>

Vous trouverez ci-dessous un exemple pour le nœud “consul01” ⇒ “oowy-dc-1-consul01”.

$ consul tls cert create -server -dc oowy-dc-1-consul01
==> WARNING: Server Certificates grants authority to become a
    server and access all state in the cluster including root keys
    and all ACL tokens. Do not distribute them to production hosts
    that are not server nodes. Store them as securely as CA keys.
==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
==> Saved oowy-dc-1-consul01-server-consul-0.pem
==> Saved oowy-dc-1-consul01-server-consul-0-key.pem

Utilisez la commande suivante avec le drapeau -client pour créer des certificats clients. Le nom du fichier s'incrémente automatiquement.

$ consul tls cert create -client -dc oowy-dc-1-consul01

Vous trouverez ci-dessous un exemple pour le centre de données “oowy-dc-1-consul01” :

$ consul tls cert create -client -dc oowy-dc-1-consul01
==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
==> Saved oowy-dc-1-consul01-client-consul-0.pem
==> Saved oowy-dc-1-consul01-client-consul-0-key.pem

Vous devez distribuer le certificat CA, “consul-agent-ca.pem”, à chacun des agents consuls ainsi que le certificat spécifique à l'agent et la clé privée.

Vous trouverez ci-dessous un exemple de SCP qui enverra le certificat CA, le certificat de l'agent et la clé privée à l'adresse IP que vous aurez spécifiée, et le placera dans le répertoire “/etc/consul.d/”.

$ scp consul-agent-ca.pem oowy-dc-1-consul<NUM>-<server/client>-consul-<cert-number>.pem oowy-dc-1-consul<NUM>-<server/client>-consul-<cert-number>-key.pem <USER>@consul<NUM>.oowy.lan:/etc/consul.d/

Consul utilise des listes de contrôle d'accès (ACL) pour sécuriser l'UI, l'API, le CLI et le catalogue Consul, y compris l'enregistrement des services et des agents. Lorsque vous sécurisez votre centre de données, vous devez d'abord configurer les ACL.

Pour activer les ACL, ajoutez la configuration qui suit au fichier de configuration “consul.hcl” et choisissez une politique par défaut “allow” (autoriser tout le trafic sauf si explicitement refusé) ou “deny” (refuser tout le trafic sauf si explicitement autorisé).

# nano /etc/consul.d/consul.hcl
...
...
acl = {
  enabled = true
  default_policy = "allow"
  enable_token_persistence = true
}

acl - Section de déclaration des ACL
enabled - Active les ACL
default_policy - La politique par défaut contrôle le comportement d'un jeton lorsqu'il n'y a pas de règle correspondante.
enable_token_persistence - Lorsque des jetons réels sont définis à l'aide de l'API, ils sont persistant sur le disque et rechargés lorsqu'un agent redémarre.

Après avoir ajouté la configurations sur tout les nœuds, relancer le service consul.

# systemctl restart consul

Bootstrap de la configuration avec la commande “consul acl bootstrap”.

[root@consul01 consul.d]# consul acl bootstrap
AccessorID:       20c334a0-1f5c-5c9e-f213-8220f76aaf16
SecretID:         48479ac6-2a25-59a6-296b-deb23df45bd6
Description:      Bootstrap Token (Global Management)
Local:            false
Create Time:      2020-11-25 17:28:05.021651138 +0100 CET
Policies:
   00000000-0000-0000-0000-000000000001 - global-management

Note:

Cela permettra de rendre le jeton de bootstrap du consul. Vous aurez besoin du SecretID pour toutes les demandes ultérieures d'API du Consul (y compris CLI et UI). Veillez à sauvegarder le SecretID.

Initier la variable CONSUL_MGMT_TOKEN sur un nœud consul.

$ export CONSUL_HTTP_TOKEN="<Token SecretID from previous step>"
$ export CONSUL_MGMT_TOKEN="<Token SecretID from previous step>"

Créer un fichier de politique des nœuds (node-policy.hcl) avec un accès en écriture pour les actions liées aux nœuds et un accès en lecture pour les actions liées aux services.

agent_prefix "" {
  policy = "write"
}
node_prefix "" {
  policy = "write"
}
service_prefix "" {
  policy = "read"
}
session_prefix "" {
  policy = "read"
}

Générez la politique ACL pour les nœuds consul avec le fichier de politique nouvellement créé.

 consul acl policy create \
> -token=${CONSUL_MGMT_TOKEN} \
>   -name node-policy \
>   -rules @node-policy.hcl
ID:           79160351-b49d-1cca-03a9-6fb51b598733
Name:         node-policy
Description:  
Datacenters:  
Rules:
agent_prefix "" {
  policy = "write"
}
node_prefix "" {
  policy = "write"
}
service_prefix "" {
  policy = "read"
}
session_prefix "" {
  policy = "read"
}

Créez le jeton des nœud avec la politique nouvellement créée.

# consul acl token create \
>   -token=${CONSUL_MGMT_TOKEN} \
>   -description "node token" \
>   -policy-name node-policy
AccessorID:       34890689-2cac-317d-99ed-b062f1b4fd6f
SecretID:         9fd1f309-f93a-dc2e-dd9b-2d02d7c0ed91
Description:      node token
Local:            false
Create Time:      2020-11-25 19:33:16.522181604 +0100 CET
Policies:
   79160351-b49d-1cca-03a9-6fb51b598733 - node-policy

Sur tous les serveurs consuls, ajoutez le jeton de nœud.

# consul acl set-agent-token \
>   -token="48479ac6-2a25-59a6-296b-deb23df45bd6" \
>   agent "9fd1f309-f93a-dc2e-dd9b-2d02d7c0ed91"
ACL token "agent" set successfully

Pour la partie agent : modifier le fichier de configuration “hcl” en adaptant les paramètres dans “/etc/consul.d/consul.hcl”

# nano /etc/consul.d/consul.hcl

Dans l'optique de configuration de notre cluster “consul”, voici un point de départ pour la configuration de base du serveur Consul :

data_dir = "/opt/consul"
client_addr = "0.0.0.0"
ui = true
node_name = "consul001"
datacenter = "DC1"
bind_addr = "192.168.1.101"
advertise_addr = "192.168.1.101"
retry_join = ["192.168.1.101", "192.168.1.102", "192.168.1.103"]
log_level = "INFO"
enable_syslog = true
encrypt = "pzDVYxESgPSkPhBFudHU5w=="
ca_file = "/etc/consul.d/consul-agent-ca.pem"
cert_file = "/etc/consul.d/oowy-dc-1-consul<NUM>-server-consul-0.pem"
key_file = "/etc/consul.d/oowy-dc-1-consul<NUM>-server-consul-0-key.pem"
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true

Certaines valeurs contiennent des caractères de remplacement variables, tandis que les autres ont des valeurs par défaut raisonnables.

Vous devez remplacer les valeurs suivantes dans votre propre configuration de serveur Consul en vous basant sur l'exemple :

node_name : il s'agit d'un label unique pour le nœud ; dans notre cas, il s'agira respectivement de consul001, consul002 et consul003.
data_dir : chemin absolu vers le répertoire des données du consul ; assurez-vous que ce répertoire est accessible en écriture par l'utilisateur du processus consul.
bind_addr : L'adresse à laquelle doivent être envoyées les communications internes du cluster. Il s'agit d'une adresse IP qui doit être accessible par tous les autres nœuds du cluster. Par défaut, il s'agit de “0.0.0.0”, ce qui signifie que Consul se liera à toutes les adresses de la machine locale et annoncera l'adresse IPv4 privée au reste du cluster.
advertise_addr : défini à l'adresse que vous préférez que les serveurs “consul” annoncent aux autres serveurs du cluster et ne doit pas être défini à 0.0.0.0 ; pour ce guide, il doit être défini à l'adresse IP du serveur dans chaque instance du fichier de configuration, ou 192.168.1.101, 192.168.1.102, et 192.168.1.103 respectivement.
retry_join : Cet exemple utilise la méthode retry_join pour joindre les agents du serveur afin de former un cluster ; ainsi, les valeurs pour ce guide seraient 192.168.1.101, 192.168.1.102, et 192.168.1.103 respectivement.

On positionne les droits

# chmod 640 /etc/consul.d/consul.hcl

Maintenant que la partie agent est terminée, nous allons créer un fichier “server.hcl”

# touch /etc/consul.d/server.hcl
# chown --recursive consul:consul /etc/consul.d

Ajouter la config suivante dans le fichier “server.hcl”.

server = true
bootstrap_expect = 3
connect {
  enabled = true
}

Informations :

server - Cet indicateur est utilisé pour contrôler si un agent est en mode serveur ou client.
bootstrap_expect - Cet indicateur indique le nombre de serveurs attendus dans le centre de données (Datacenter). Soit cette valeur ne doit pas être fournie, soit la valeur doit être cohérente pour tous les serveurs du centre de données.

On positionne les droits

# chown --recursive consul:consul /etc/consul.d
# chmod 640 /etc/consul.d/server.hcl

On vérifie la configuration

# consul validate /etc/consul.d/consul.hcl
Configuration is valid!

Pour démarrer notre cluster Consul, il nous suffira de lancer le service consul sur nos trois nœuds.

# systemctl enable consul

# systemctl start consul

Vérifiez le statut de l'agent consul.

# systemctl status consul
● consul.service - Consul Service Discovery Agent
   Loaded: loaded (/etc/systemd/system/consul.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-07-15 20:12:28 CEST; 6min ago
     Docs: https://www.consul.io/
  Process: 1607 ExecStartPre=/bin/chown -R consul:consul /var/run/consul (code=exited, status=0/SUCCESS)
  Process: 1605 ExecStartPre=/bin/mkdir -p /var/run/consul (code=exited, status=0/SUCCESS)
 Main PID: 1608 (consul)
    Tasks: 7 (limit: 12504)
   Memory: 19.0M
   CGroup: /system.slice/consul.service
           └─1608 /usr/local/bin/consul agent -config-file=/etc/consul.d/consul001.json -pid-file=/var/run/consul/consul.pid

Après avoir démarré tous les agents du serveur Consul, vérifions l'état du cluster Consul :

# consul members
Node       Address             Status  Type    Build  Protocol  DC   Segment
consul001  192.168.1.101:8301  alive   server  1.8.0  2         dc1  <all>
consul002  192.168.1.102:8301  alive   server  1.8.0  2         dc1  <all>
consul003  192.168.1.103:8301  alive   server  1.8.0  2         dc1  <all>

Le cluster a l'air bien et les 3 serveurs sont affichés ; assurons-nous d'avoir un leader avant de procéder :

# consul operator raft list-peers
Node       ID                                    Address             State     Voter  RaftProtocol
consul003  08c1c3c7-3327-0c83-f05c-ee1dad84bf3f  192.168.1.103:8300  leader    true   3
consul002  ade016cc-b39d-0394-3d3e-243f4aa0801a  192.168.1.102:8300  follower  true   3
consul001  ee827b2f-c999-db5f-136f-1d80ca28f002  192.168.1.101:8300  follower  true   3

Le résultat ci-dessus montre que consul003 est le chef de file actuel du cluster.

Consul offre une interface d'administration. Pour cela, il vous suffira de vous rendre sur l'IP d'un des noeuds. Exemple : http://<IP_NODE>:8500/

https://learn.hashicorp.com/tutorials/consul/backup-and-restore?in=consul/datacenter-deploy

https://www.hashicorp.com/

https://www.consul.io/downloads.html

https://www.consul.io/docs

https://www.consul.io/docs/agent/options.html

https://learn.hashicorp.com/collections/consul/datacenter-deploy

https://learn.hashicorp.com/tutorials/consul/reference-architecture#recommended-architecture

https://learn.hashicorp.com/tutorials/consul/deployment-guide?in=consul/datacenter-deploy

https://learn.hashicorp.com/tutorials/consul/gossip-encryption-secure

https://learn.hashicorp.com/tutorials/consul/tls-encryption-secure

https://learn.hashicorp.com/collections/consul/security-networking

https://learn.hashicorp.com/tutorials/consul/access-control-setup-production#overview

https://www.consul.io/docs/install/ports

Pour afficher l'aide de consul, utilisez l'option “–help”.

$ consul --help
 Usage: consul [--version] [--help] 
 Available commands are:
     acl            Interact with Consul's ACLs
     agent          Runs a Consul agent
     catalog        Interact with the catalog
     connect        Interact with Consul Connect
     debug          Records a debugging archive for operators
     event          Fire a new event
     exec           Executes a command on Consul nodes
     force-leave    Forces a member of the cluster to enter the "left" state
     info           Provides debugging information for operators.
     intention      Interact with Connect service intentions
     join           Tell Consul agent to join cluster
     keygen         Generates a new encryption key
     keyring        Manages gossip layer encryption keys
     kv             Interact with the key-value store
     leave          Gracefully leaves the Consul cluster and shuts down
     lock           Execute a command holding a lock
     maint          Controls node or service maintenance mode
     members        Lists the members of a Consul cluster
     monitor        Stream logs from a Consul agent
     operator       Provides cluster-level tools for Consul operators
     reload         Triggers the agent to reload configuration files
     rtt            Estimates network round trip time between nodes
     services       Interact with services
     snapshot       Saves, restores and inspects snapshots of Consul server state
     tls            Builtin helpers for creating CAs and certificates
     validate       Validate config files/directories
     version        Prints the Consul version
     watch          Watch for changes in Consul

https://www.consul.io/docs/install/ports

Si le service “firewalld” est activé sur les nœuds du cluster, nous devrons ouvrir les flux nécessaires au bon fonctionnement de la solution.

# firewall-cmd --add-port={8300,8301,8302,8500,8600}/tcp --permanent
# firewall-cmd --add-port={8301,8302,8600}/udp --permanent
# firewall-cmd --reload

Introduction

Comment ça marche ?

L’Agent

Serveur

GOSSIP Protocol

Architecture

Pré-Requis

Installation de Consul

Création des répertoires

Security and Networking

Gossip encryption key

Generate TLS certificates for RPC encryption

Create the Certificates Authority

Create the certificates

Distribute the certificates to agents

Enable Consul ACLs

Paramétrage du cluster : All nodes

Lancement consul

Consul cluster state

Interface d'administration

Backup & Restore

Annexe

URL

Help

Firewall