Je vous suggère de lire la transcription du rapport d'Alexander Sigachev sur la découverte de services dans les systèmes distribués en utilisant Consul comme exemple.
Service Discovery a été créé pour qu'à un coût minime, vous puissiez connecter une nouvelle application à notre environnement existant. Grâce à Service Discovery, nous pouvons séparer au maximum un conteneur Docker ou un service virtuel de l'environnement dans lequel il s'exécute.
Je souhaite la bienvenue à tout le monde ! Je m'appelle Alexander Sigachev, je travaille chez Inventos. Et aujourd'hui, je vais vous présenter un concept tel que Service Discovery. Examinons la découverte de services en utilisant Consul comme exemple.
Quels problèmes la découverte de services résout-elle ? Service Discovery a été créé pour qu'à un coût minime, vous puissiez connecter une nouvelle application à notre environnement existant. Grâce à Service Discovery, nous pouvons séparer au maximum un conteneur Docker ou un service virtuel de l'environnement dans lequel il s'exécute.
À quoi cela ressemble-t-il? Dans un exemple classique sur le web, c’est le front-end qui accepte la demande de l’utilisateur. Ensuite, il l'achemine vers le backend. Dans cet exemple, cet équilibreur de charge équilibre deux backends.
Nous voyons ici que nous lançons une troisième instance de l'application. Par conséquent, lorsque l'application démarre, elle s'enregistre auprès de Service Discovery. Service Discovery informe l'équilibreur de charge. Load-balancer change automatiquement sa configuration et le nouveau backend est mis en service. De cette manière, des backends peuvent être ajoutés ou, au contraire, exclus du travail.
Qu'est-ce qu'il est pratique de faire d'autre avec Service Discovery ? Service Discovery peut stocker les configurations nginx, les certificats et une liste de serveurs backend actifs.
Service Discovery vous permet également de détecter les pannes et de détecter les pannes. Quels sont les schémas possibles pour détecter les pannes ?
- Cette application que nous avons développée informe automatiquement Service Discovery qu'elle est toujours fonctionnelle.
- Service Discovery, pour sa part, interroge l'application pour vérifier sa disponibilité.
- Ou nous utilisons un script ou une application tiers qui vérifie la disponibilité de notre application et informe Service Discovery que tout va bien et peut fonctionner, ou, à l'inverse, que tout va mal et que cette instance de l'application doit être exclue de l'équilibrage.
Chacun des schémas peut être utilisé en fonction du logiciel que nous utilisons. Par exemple, nous venons de commencer à développer un nouveau projet, nous pouvons alors facilement fournir un schéma lorsque notre application notifie Service Discovery. Ou nous pouvons connecter que Service Discovery vérifie.
Si nous avons hérité de l'application ou si elle a été développée par quelqu'un d'autre, la troisième option convient lorsque nous écrivons un gestionnaire, et tout cela entre automatiquement dans notre travail.
Ceci est un exemple. L'équilibreur de charge sous la forme de nginx est redémarré. Il s'agit d'un utilitaire facultatif fourni avec Consul. Ceci est un modèle de consul. Nous décrivons la règle. Nous disons que nous utilisons un modèle (Golang Template Engine). Lorsque des événements se produisent, lorsque des notifications indiquant que des modifications ont eu lieu, il est régénéré et la commande « reload » est envoyée à Service Discovery. L'exemple le plus simple est lorsque nginx est reconfiguré par un événement et redémarré.
Qu'est-ce que Consul ?
-
Tout d’abord, il s’agit de Service Discovery.
-
Il dispose d'un mécanisme de contrôle de disponibilité - Health Checking.
-
Il dispose également d'un magasin KV.
-
Et il repose sur la possibilité d’utiliser Multi Datacenter.
A quoi peut bien servir tout cela ? Dans le KV Store, nous pouvons stocker des exemples de configurations. Vérification de la santé, nous pouvons vérifier le service local et en informer. Multi Datacenter est utilisé pour qu'une carte de services puisse être construite. Par exemple, Amazon dispose de plusieurs zones et achemine le trafic de la manière la plus optimale afin qu'il n'y ait pas de requêtes inutiles entre les centres de données, qui sont facturés séparément du trafic local et, par conséquent, ont moins de latence.
Comprenons un peu les termes utilisés dans Consul.
- Consul est un service écrit en Go. L'un des avantages d'un programme Go est 1 fichier binaire que vous venez de télécharger. Lancé de n’importe où et vous n’avez aucune dépendance.
- Ensuite, à l'aide des clés, nous pouvons démarrer ce service soit en mode client, soit en mode serveur.
- De plus, l'attribut « datacenter » vous permet de définir un indicateur auquel le centre de données appartient à ce serveur.
- Consensus – basé sur le protocole du radeau. Si quelqu'un est intéressé, vous pouvez en savoir plus à ce sujet sur le site Web du Consul. Il s'agit d'un protocole qui permet de déterminer le leader et de déterminer quel argent est considéré comme valide et accessible.
- Gossip est un protocole qui permet l'interaction entre les nœuds. De plus, ce système est décentralisé. Au sein d'un centre de données, tous les nœuds communiquent avec leurs voisins. Et, par conséquent, les informations sur l'état actuel se transmettent. On peut dire que ce sont des ragots entre voisins.
- LAN Gossip – échange de données local entre voisins au sein du même centre de données.
- WAN Gossip - utilisé lorsque nous devons synchroniser des informations entre deux centres de données. Les informations circulent entre les nœuds marqués comme serveur.
- RPC – vous permet d'exécuter des requêtes via un client sur un serveur.
Description du RPC. Disons que Consul s'exécute en tant que client sur une machine virtuelle ou un serveur physique. Nous le contactons localement. Et puis le client local demande des informations au serveur et est synchronisé. Selon les paramètres, les informations peuvent être récupérées depuis le cache local, ou peuvent être synchronisées avec le leader, avec le serveur maître.
Ces deux schémas présentent des avantages et des inconvénients. Si nous travaillons avec un cache local, alors c'est rapide. Si nous travaillons avec des données stockées sur le serveur, cela prend plus de temps, mais nous obtenons des informations plus pertinentes.
Si vous représentez cela graphiquement, alors c'est l'image du site. Nous voyons que nous avons trois maîtres en marche. L'un d'entre eux est marqué d'un astérisque en tant que leader. Dans cet exemple, trois clients échangent des informations localement entre eux via UDP/TCP. Et les informations entre les centres de données sont transférées entre les serveurs. Ici, les clients interagissent les uns avec les autres localement.
Quelle API Consul fournit-il ? Afin d'obtenir des informations, Consul dispose de deux types d'API.
Il s'agit de l'API DNS. Par défaut, Consul s'exécute sur le port 8600. Nous pouvons configurer le proxy de requête et fournir un accès via une résolution locale, via un DNS local. Nous pouvons interroger par domaine et recevoir des informations sur l'adresse IP en réponse.
API HTTP - ou nous pouvons demander localement des informations sur un service spécifique sur le port 8500 et recevoir une réponse JSON, quelle adresse IP possède le serveur, quel hôte, quel port est enregistré. Et des informations supplémentaires peuvent être transmises via un jeton.
De quoi avez-vous besoin pour exécuter Consul ?
Dans la première option, en mode développeur, nous indiquons le drapeau indiquant qu'il s'agit du mode développeur. L'agent démarre en tant que serveur. Et il exécute toute la fonction indépendamment sur une seule machine. Pratique, rapide et pratiquement aucun réglage supplémentaire n'est requis pour le premier démarrage.
Le deuxième mode est le lancement en production. C'est là que le démarrage devient un peu compliqué. Si nous n’avons pas de version du consul, alors il faut mettre en bootstrap la première machine, c’est-à-dire cette machine qui assumera les responsabilités de leader. Nous l'élevons, puis nous élevons la deuxième instance du serveur, en lui transmettant les informations où se trouve notre maître. Nous élevons le troisième. Après avoir installé trois machines, nous le redémarrons en mode normal sur la première machine à partir du bootstrap en cours d'exécution. Les données sont synchronisées et le cluster initial est déjà opérationnel.
Il est recommandé d'exécuter trois à sept instances en mode serveur. Cela est dû au fait que si le nombre de serveurs augmente, le temps de synchronisation des informations entre eux augmente. Le nombre de nœuds doit être impair pour garantir le quorum.
Comment les bilans de santé sont-ils fournis ? Nous écrivons une règle de vérification sous forme de Json dans le répertoire de configuration Consul. La première option est la disponibilité du domaine google.com dans cet exemple. Et nous disons que cette vérification doit être effectuée à intervalles de 30 secondes. De cette façon, nous vérifions que notre nœud a accès au réseau externe.
La deuxième option consiste à vérifier vous-même. Nous utilisons curl régulier pour appeler localhost sur le port spécifié à intervalles de 10 secondes.
Ces contrôles sont résumés et envoyés à Service Discovery. En fonction de la disponibilité, ces nœuds sont soit exclus, soit apparaissent dans la liste des machines disponibles et fonctionnant correctement.
Consul fournit également une interface utilisateur, qui est lancée avec un indicateur séparé et sera disponible sur la machine. Cela vous permet d'afficher des informations et vous pouvez également apporter des modifications.
Dans cet exemple, l'onglet « Service » est ouvert. Il est montré que trois services fonctionnent, l'un d'eux est Consul. Nombre de contrôles effectués. Et il existe trois centres de données dans lesquels se trouvent les machines.
Ceci est un exemple de l'onglet Nœuds. Nous voyons qu'ils ont des noms composés impliquant des centres de données. Il montre également quels services sont en cours d'exécution, c'est-à-dire que nous voyons qu'aucune balise n'a été définie. Ces balises supplémentaires peuvent fournir des informations que le développeur peut utiliser pour spécifier des paramètres supplémentaires.
Vous pouvez également transmettre des informations à Consul sur l'état des disques et la charge moyenne.
des questions
Question : Nous avons un conteneur Docker, comment l'utiliser avec Consul ?
Réponse : Il existe plusieurs approches pour le conteneur Docker. L’une des plus courantes consiste à utiliser un conteneur Docker tiers responsable de l’enregistrement. Au démarrage, un socket docker lui est transmis. Tous les événements d’enregistrement et de dépublication de conteneurs sont enregistrés dans Consul.
Question : Donc Consul lui-même démarre le conteneur Docker ?
Réponse : Non. Nous utilisons un conteneur Docker. Et lors de la configuration, nous indiquons - écoutez telle ou telle socket. C'est à peu près la même chose que la façon dont nous travaillons avec un certificat, lorsque nous téléchargeons des informations sur l'endroit et ce que nous avons.
Question : Il s'avère qu'à l'intérieur du conteneur Docker que nous essayons de connecter à Service Discovery, il devrait y avoir une sorte de logique capable d'envoyer des données à Consul ?
Réponse : Pas vraiment. Quand il démarre, nous transmettons les variables via la variable d'environnement. Disons le nom du service, le port du service. Le registre écoute ces informations et les saisit dans Consul.
Question : J'ai une autre question sur l'interface utilisateur. Nous avons déployé l'UI, par exemple, sur un serveur de production. Et la sécurité ? Où sont stockées les données ? Est-il possible d’accumuler des données d’une manière ou d’une autre ?
Réponse : Dans l'interface utilisateur, il existe des données de la base de données et de Service Discovery. Nous définissons nous-mêmes les mots de passe dans les paramètres.
Question : Est-ce que cela peut être publié sur Internet ?
Réponse : Par défaut, Consul démarre sur localhost. Pour publier sur Internet, vous devrez installer une sorte de proxy. Nous sommes responsables de nos propres règles de sécurité.
Question : Fournit-il des données historiques prêtes à l'emploi ? Il est intéressant de regarder les statistiques sur les bilans de santé. Vous pouvez également diagnostiquer les problèmes si le serveur tombe souvent en panne.
Réponse : Je ne suis pas sûr qu'il y ait des détails sur les contrôles.
Question : L'état actuel n'est pas aussi important que la dynamique.
Réponse : Pour analyse – oui.
Question : Est-il préférable de ne pas utiliser le menu fixe Service Discovery pour Consul ?
Réponse : Je ne recommanderais pas de l’utiliser. Le but du rapport est de présenter ce qu'est un tel concept. Historiquement, il a fait son chemin, selon moi, jusqu'à la 1ère version. Il existe désormais des solutions plus complètes, par exemple Kubernetes, qui a tout cela sous le capot. Dans le cadre de Kubernetes Service Discovery, il est inférieur à Etcd. Mais je ne le connais pas aussi bien que Consul. Par conséquent, j'ai décidé de créer Service Discovery en utilisant Consul comme exemple.
Question : Le schéma avec un serveur leader ne ralentit-il pas le démarrage de l'application dans son ensemble ? Et comment le Consul détermine-t-il un nouveau leader si celui-ci ment ?
Réponse : Ils ont décrit tout un protocole. Si vous êtes intéressé, vous pouvez le lire.
Question : Consul agit pour nous comme un serveur à part entière et toutes les demandes transitent par lui ?
Réponse : Il ne fait pas office de serveur à part entière, mais prend en charge une zone spécifique. Il se termine généralement par service.consul. Et puis on continue logiquement. Nous n'utilisons pas de noms de domaine en production, mais plutôt l'infrastructure interne, qui est généralement cachée derrière la mise en cache du serveur si nous travaillons avec DNS.
Question : Autrement dit, si nous voulons accéder à une base de données, dans tous les cas, nous allons d'abord demander à Consul de trouver cette base de données, n'est-ce pas ?
Réponse : Oui. Si nous travaillons avec DNS, cela fonctionne de la même manière que sans Consul lorsque nous utilisons des noms DNS. En règle générale, les applications modernes n'extraient pas le nom de domaine à chaque requête, car nous avons installé Connect, tout fonctionne et dans un avenir proche, nous ne l'utilisons pratiquement pas. Si la connexion est interrompue, alors oui, nous demandons à nouveau où se trouve notre base et y allons.
— Chat utilisateur Hashicorp : Consul, Nomad, Terraform
PS Concernant les contrôles de santé. Consul, comme Kubernetes, utilise le même système pour vérifier l'état de survie d'un service en fonction de l'état du code.
200 OK for healthy
503 Service Unavailable for unhealthySources:
Source: habr.com