L’écosystème Docker: magasins de découverte de services et de configurations distribuées

Les conteneurs constituent une solution élégante pour ceux qui cherchent à concevoir et à déployer des applications à grande échelle. Alors que Docker fournit la technologie de conteneurisation proprement dite, de nombreux autres projets aident à développer les outils nécessaires au démarrage et à la communication appropriés dans l'environnement de déploiement.

L'une des technologies de base sur laquelle de nombreux environnements Docker s'appuient est la découverte de services. La découverte de services permet à une application ou à un composant de découvrir des informations sur leur environnement et leurs voisins. Cela est généralement implémenté sous la forme d'un magasin clé-valeur distribué, qui peut également servir d'emplacement plus général pour dicter les détails de la configuration. La configuration d'un outil de découverte de service vous permet de séparer votre configuration d'exécution du conteneur réel, ce qui vous permet de réutiliser la même image dans plusieurs environnements.

Dans ce guide, nous aborderons les avantages de la découverte de services dans un environnement Docker en cluster. Nous nous concentrerons principalement sur les concepts généraux, mais fournirons des exemples plus spécifiques, le cas échéant.

L'idée de base de la découverte de service est que toute nouvelle instance d'une application devrait pouvoir identifier par programme les détails de son environnement actuel. Cela est nécessaire pour que la nouvelle instance puisse «se connecter» à l'environnement d'application existant sans intervention manuelle. Les outils de découverte de services sont généralement implémentés sous la forme d'un registre accessible de manière globale, qui stocke des informations sur les instances ou les services en cours d'exploitation. La plupart du temps, afin de rendre cette configuration tolérante aux pannes et évolutive, le registre est réparti entre les hôtes disponibles dans l'infrastructure.

Bien que le but principal des plates-formes de découverte de services soit de fournir des informations de connexion pour lier des composants, elles peuvent être utilisées plus généralement pour stocker tout type de configuration. De nombreux déploiements exploitent cette possibilité en écrivant leurs données de configuration dans l'outil de découverte. Si les conteneurs sont configurés pour qu'ils sachent rechercher ces informations, ils peuvent modifier leur comportement en fonction de ce qu'ils trouvent.

Chaque outil de découverte de service fournit une API que les composants peuvent utiliser pour définir ou récupérer des données. De ce fait, pour chaque composant, l'adresse de découverte de service doit être codée en dur dans l'application / le conteneur même ou fournie sous forme d'option au moment de l'exécution. En règle générale, le service de découverte est implémenté en tant que magasin de valeurs-clés accessible à l'aide de méthodes http standard.

Le fonctionnement d’un portail de découverte de services est que chaque service, lorsqu’il est mis en ligne, s’enregistre lui-même auprès de l’outil de découverte. Il enregistre toutes les informations dont un composant associé pourrait avoir besoin pour utiliser le service fourni. Par exemple, une base de données MySQL peut enregistrer l'adresse IP et le port sur lequel le démon est en cours d'exécution, ainsi que le nom d'utilisateur et les informations d'identification nécessaires pour se connecter.

Lorsqu'un utilisateur de ce service passe en ligne, il peut interroger le registre de découverte de service pour obtenir des informations sur un noeud final prédéfini. Il peut ensuite interagir avec les composants nécessaires en fonction des informations trouvées. Un bon exemple de ceci est un équilibreur de charge. Il peut trouver tous les serveurs dorsaux dont il a besoin pour alimenter le trafic en interrogeant le portail de découverte de services et en ajustant sa configuration en conséquence.

Cela supprime les détails de la configuration des conteneurs eux-mêmes. L’un des avantages est que les conteneurs de composants sont plus flexibles et moins liés à une configuration spécifique. Un autre avantage est qu’il est simple de faire réagir vos composants à de nouvelles instances d’un service associé, ce qui permet une reconfiguration dynamique.

L'un des principaux avantages d'un système de découverte de services distribué dans le monde entier est qu'il peut stocker tout autre type de données de configuration dont vos composants pourraient avoir besoin au moment de l'exécution. Cela signifie que vous pouvez extraire encore plus de configuration du conteneur et dans l'environnement d'exécution supérieur.

En règle générale, pour que cela fonctionne plus efficacement, vos applications doivent être conçues avec des valeurs par défaut raisonnables qui peuvent être remplacées au moment de l'exécution en interrogeant le magasin de configuration. Cela vous permet d'utiliser le magasin de configuration de la même manière que les indicateurs de ligne de commande. La différence est qu’en utilisant un magasin accessible globalement, vous pouvez offrir les mêmes options à chaque instance de votre composant sans travail supplémentaire.

L'une des fonctions des magasins de clé-valeur distribués dans les déploiements Docker qui pourraient ne pas apparaître initialement est le stockage et la gestion de l'appartenance à un cluster. Les magasins de configuration sont l’environnement idéal pour suivre l’appartenance à un hôte au profit des outils de gestion.

Certaines des informations pouvant être stockées sur des hôtes individuels dans un magasin clé-valeur distribué sont les suivantes:

Ces informations ne vous intéressent probablement pas lorsque vous utilisez une plate-forme de découverte de services dans des circonstances normales, mais elles fournissent un emplacement aux outils de gestion pour interroger ou modifier les informations relatives au cluster lui-même.

La détection d'échec peut être mise en œuvre de plusieurs manières. Le problème est de savoir si, en cas de défaillance d'un composant, le service de découverte sera mis à jour pour refléter le fait qu'il n'est plus disponible. Ce type d'informations est essentiel pour minimiser les défaillances d'applications ou de services.

De nombreuses plates-formes de découverte de services permettent de définir des valeurs avec un délai d'attente configurable. Le composant peut définir une valeur avec un délai d'expiration et envoyer une requête ping au service de découverte à intervalles réguliers pour réinitialiser le délai d'expiration. Si le composant échoue et que le délai est atteint, les informations de connexion de cette instance sont supprimées du magasin. La durée du délai d'expiration dépend en grande partie de la rapidité avec laquelle l'application doit réagir à une défaillance d'un composant.

Cela peut également être accompli en associant un conteneur «d'assistance» simple à chaque composant, dont la seule responsabilité est de vérifier régulièrement l'état du composant et de mettre à jour le registre en cas de panne. Le problème avec ce type d'architecture est que le conteneur d'assistance pourrait tomber, ce qui entraînerait des informations incorrectes dans le magasin. Certains systèmes résolvent ce problème en définissant des vérifications de l'état dans l'outil de découverte de service. De cette façon, la plateforme de découverte elle-même peut vérifier périodiquement si les composants enregistrés sont toujours disponibles.

Une amélioration clé du modèle de découverte de service de base est celle de la reconfiguration dynamique. Bien que la découverte de service normale vous permette d'influencer la configuration initiale des composants en vérifiant les informations de découverte au démarrage, la reconfiguration dynamique implique de configurer vos composants pour réagir aux nouvelles informations du magasin de configuration. Par exemple, si vous implémentez un équilibreur de charge, une vérification de l'intégrité des serveurs dorsaux peut indiquer qu'un membre du pool est en panne. L'instance en cours d'exécution de l'équilibreur de charge doit être informée et doit pouvoir ajuster sa configuration et la recharger pour en tenir compte.

Cela peut être mis en œuvre de différentes manières. L’exemple d’équilibrage de charge étant l’un des principaux cas d’utilisation de cette capacité, il existe un certain nombre de projets qui se concentrent exclusivement sur la reconfiguration d’un équilibreur de charge lorsque des modifications de configuration sont détectées. L'ajustement de la configuration HAProxy est commun en raison de son omniprésence dans l'espace d'équilibrage de charge.

Certains projets sont plus flexibles en ce qu'ils peuvent être utilisés pour déclencher des modifications dans tout type de logiciel. Ces outils interrogent régulièrement le service de découverte et, lorsqu'une modification est détectée, utilisent des systèmes de modèles pour générer des fichiers de configuration qui intègrent les valeurs trouvées sur le point de terminaison de la découverte. Une fois le nouveau fichier de configuration généré, le service concerné est rechargé.

Ce type de reconfiguration dynamique nécessite davantage de planification et de configuration pendant le processus de construction, car tous ces mécanismes doivent exister dans le conteneur du composant. Cela rend le conteneur de composants lui-même responsable du réglage de sa configuration. Déterminer les valeurs nécessaires pour écrire dans le service de découverte et concevoir une structure de données appropriée pour une consommation aisée est un autre défi que ce système nécessite, mais les avantages et la flexibilité peuvent être substantiels.

Une des préoccupations de nombreuses personnes lorsqu’ils se renseignent pour la première fois sur le stockage de configuration accessible de manière globale est, à juste titre, la sécurité. Est-il vraiment acceptable de stocker les informations de connexion dans un emplacement accessible globalement?

La réponse à cette question dépend en grande partie de ce que vous choisissez de placer dans le magasin et du nombre de couches de sécurité que vous jugez nécessaires pour protéger vos données. Presque toutes les plateformes de découverte de services permettent de chiffrer les connexions avec SSL / TLS. Pour certains services, la confidentialité peut ne pas être très importante et placer le service de découverte sur un réseau privé peut s'avérer satisfaisant. Cependant, la plupart des applications bénéficieraient probablement d'une sécurité supplémentaire.

Il existe différentes manières de résoudre ce problème et différents projets proposent leurs propres solutions. Un des projets consiste à continuer à autoriser un accès ouvert à la plateforme de découverte, mais à chiffrer les données qui y sont écrites. Le consommateur d'application doit disposer de la clé associée pour déchiffrer les données trouvées dans le magasin. Les autres parties ne pourront pas accéder aux données non chiffrées.

Pour une approche différente, certains outils de découverte de service implémentent des listes de contrôle d'accès afin de diviser l'espace clé en zones séparées. Ils peuvent ensuite désigner la propriété ou l'accès aux zones en fonction des exigences d'accès définies par un espace clé spécifique. Ceci établit un moyen facile de fournir des informations à certaines parties tout en les gardant privées des autres. Chaque composant peut être configuré pour avoir uniquement accès aux informations dont il a explicitement besoin.

Maintenant que nous avons abordé certaines des fonctionnalités générales des outils de découverte de services et des magasins de clés-valeurs distribués à l’échelle mondiale, nous pouvons mentionner quelques-uns des projets liés à ces concepts.

Certains des outils de découverte de service les plus courants sont:

Certains autres projets qui étendent la découverte de services de base sont les suivants:

La découverte de services et les magasins de configuration globale permettent aux conteneurs Docker de s’adapter à leur environnement actuel et de se connecter aux composants existants. Il s'agit d'une condition préalable essentielle pour assurer une évolutivité et un déploiement simples et mains libres en permettant aux composants de suivre et de répondre aux changements dans leur environnement.

Dans lesnext guide, nous discuterons des moyens par lesquels les conteneurs et les hôtes Docker peuvent communiquer avec des configurations réseau personnalisées.