Architecture d'infrastructure : Conteneurs créant un quatrième plan
Dans l'infrastructure réseau traditionnelle, il existe généralement trois plans architecturaux associés à l'infrastructure réseau : données, contrôle et gestion.
Les définitions exactes de ces éléments peuvent varier en fonction du genre et de la mise en œuvre spécifique de l'infrastructure, mais les archétypes sont en grande partie précis pour la plupart des infrastructures réseau.
- Plan de données
- Parfois appelé chemin de données dans le langage vernaculaire moderne, le plan de données est le chemin par lequel les paquets (données) sont transmis. Le plan de données est responsable de l'acceptation d'un paquet et de sa transmission vers la bonne destination.
- Plan de contrôle
- En général, le plan de contrôle détermine où les données sont transmises. Les protocoles de routage sont de bons exemples de fonctions de plan de contrôle, tout comme la prise de décision d'ordre supérieur qui peut être plus dynamique aujourd'hui. L'implémentation spécifique varie mais peut aller du plan de données transmettant des données au plan de contrôle pour une décision au plan de contrôle observant de manière transparente les données et agissant sur des déclencheurs spécifiques. Les plans de contrôle sont souvent également chargés de surveiller l’état des appareils et de collecter des statistiques.
- Plan de gestion
- Le plan de gestion est le plus visible des trois plans car c'est là que nous interagissons avec le plan de contrôle. Les plans de gestion traditionnels utilisent CLI (interfaces de ligne de commande) tandis que les plans de gestion modernes préfèrent API (interfaces de programmation d'application). Quelle que soit la méthode utilisée, le plan de gestion permet aux opérateurs de définir des politiques qui sont appliquées par le plan de contrôle. Cela inclut des options de configuration telles que des algorithmes d'équilibrage de charge et des politiques d'autorisation/refus basées sur des caractéristiques telles que l'adresse IP et le type d'appareil.
Mais il existe un autre type d’orchestration à l’œuvre, sous le capot et largement invisible pour les opérateurs. Cela n’a rien à voir avec la gestion, si ce n’est qu’il s’agit d’approprier certaines responsabilités aux opérateurs humains.
La distinction ici est que les actions sont déclenchées automatiquement par des modifications apportées à l’environnement pendant l’exécution plutôt que par un événement de déploiement. Mais les informations sur ce qui a changé sont vitales, et cela signifie qu’elles doivent être obtenues quelque part.
Dans un modèle opérationnel traditionnel, ces informations proviennent généralement de tickets de modification ou de demandes. Dans le cas des modèles opérationnels modernes et, en particulier, des conteneurs, ces informations proviennent des registres de services via un mécanisme de découverte.
Registres de services et découverte
La nature des environnements de conteneurs inclut l’hypothèse selon laquelle les adresses IP n’ont pas d’importance pour l’environnement d’application. Mais ils sont importants pour l’infrastructure car les données doivent toujours être acheminées et transférées d’un appareil à un autre afin de parcourir le chemin entre le client et l’application. Dans les environnements modernes, ces adresses IP existent souvent pendant de courtes périodes (la durée de vie d’un conteneur/service).
Considérez ces résultats de DataDog (soulignement ajouté) :
L’adoption rapide des orchestrateurs ( voir fait 4 ) semble conduire les conteneurs vers des durées de vie encore plus courtes, car le démarrage et l’arrêt automatisés des conteneurs entraînent un taux de désabonnement plus élevé. Dans les organisations qui exécutent un orchestrateur, la durée de vie typique d’un conteneur est d’environ 12 heures. Dans les organisations sans orchestration, le conteneur vit en moyenne six jours.
De < https://www.datadoghq.com/docker-adoption >
Imaginez si vous, en tant qu’opérateur, deviez mettre à jour les tables de routage ou les pools d’équilibrage de charge tous les six jours, sans parler de toutes les douze heures. Vous ne feriez pas grand-chose d’autre. Le risque de mauvaise configuration serait important et augmenterait probablement à mesure que vous seriez obligé de fonctionner en mode manuel pour gérer les modifications dans un cluster de conteneurs.
Un registre de services, comme Consul , devient un composant essentiel de votre déploiement de conteneur. Les registres de services gardent une trace des instances et des services ainsi que de leurs adresses IP associées. À cet égard, ils peuvent être comparés à un « DNS pour conteneurs et services ».
Le registre de services suit donc les caractéristiques actuelles des conteneurs du cluster. La découverte est le processus de connexion au registre de services (via l'API ou en s'abonnant à une file d'attente de messages) des instances correspondantes aux adresses IP.
Cela signifie que pour l'infrastructure qui doit acheminer le trafic vers un service ou une instance spécifique à l'intérieur d'un cluster de conteneurs, elle doit pouvoir récupérer une adresse IP. Car même si les conteneurs cachent le réseau à l’application, ils s’appuient toujours sur lui pour transférer les données d’un endroit à un autre.
Le quatrième plan : Orchestration
Cela permet d’introduire une nouvelle couche architecturale dans l’infrastructure qui interagit avec les environnements d’orchestration de conteneurs. Cette couche - la couche d'orchestration - s'intègre à l'environnement du conteneur et utilise des fonctionnalités telles que la découverte de services pour automatiser la découverte de services et d'instances. Cela signifie qu'un équilibreur de charge peut découvrir automatiquement les membres d'un pool et le mettre à jour en permanence en fonction des changements dans l'environnement. Cela allège la charge de travail des opérations consistant à mettre à jour manuellement les pools d'équilibrage de charge - une tâche de plus en plus fastidieuse lorsque les conteneurs vivent en moyenne moins d'une semaine.
Cet avion n'est pas destiné à l'interaction avec les opérateurs. La configuration, la surveillance et l’exploitation s’effectuent toujours via un plan de gestion. L'emplacement d'un registre de services serait configuré via le plan de gestion mais utilisé par le plan d'orchestration pour se connecter et communiquer les modifications au plan de contrôle.
Nous pouvons définir le plan d’orchestration comme suit.
- Le plan d’orchestration est l’un des plans les moins visibles de l’architecture d’infrastructure. L’interaction avec celui-ci s’effectue via le plan de gestion, qui est principalement chargé de pointer le plan d’orchestration vers le registre de services approprié. Sa responsabilité est de mettre à jour les composants dynamiques dans le plan de contrôle pour assurer le bon transfert et la disponibilité des ressources conteneurisées.
Des questions subsistent quant à savoir si ce plan doit être intégré à l'appareil avec les plans de contrôle et de données ou s'il s'agit simplement d'un placage sur le plan de gestion (ce qui modifierait légèrement notre schéma mais n'aurait pas d'impact sur l'interaction entre les plans et les composants). De nombreux appareils traditionnels prennent déjà en charge ce plan émergent en fournissant des extensions qui s'intègrent aux environnements de conteneurs et apportent des modifications via le plan de gestion. Il s’agit d’un bel exemple de refactorisation d’architectures traditionnelles pour étendre les fonctionnalités aux environnements modernes. Mais en fin de compte, ce n’est peut-être pas la solution idéale.
Pourquoi est-ce important ?
Il peut sembler à première vue que l’introduction d’un quatrième avion pour les infrastructures n’a pas d’importance. Après tout, sa fonction est de retirer aux opérateurs une certaine responsabilité pour les tâches fastidieuses. Ça ne peut pas être mal.
Ce n’est pas une mauvaise chose, mais il est important de comprendre que ce passage d’une configuration statique à une configuration dynamique a des conséquences sur certaines des fonctions les plus importantes du plan de contrôle. La criticité de la découverte de services devient telle que sa disponibilité et sa sécurité doivent être un impératif. Il devient en effet le point de défaillance unique sur lequel repose toute votre infrastructure applicative.
Les registres de services sont construits sur les mêmes prémisses que la plupart des applications modernes : ils sont conçus pour gérer les pannes. Vous pouvez vous retrouver dans une situation où l’adresse IP que vous venez de découvrir disparaît avant que vous ne puissiez transférer le trafic vers son instance. La plupart des infrastructures sont capables de retransmettre à ce stade, mais le processus prend du temps. Les microsecondes comptent dans l’économie numérique, c’est pourquoi les options traditionnelles telles que les délais d’attente et les intervalles de découverte feront la différence dans les architectures modernes qui s’appuient sur la découverte. La surveillance devient également beaucoup plus critique, car la capacité à déterminer l’état de santé et la disponibilité le plus rapidement possible peut faire la différence entre un utilisateur satisfait et un utilisateur désengagé. Il s’agit de deux préoccupations de niveau commercial dont chaque membre d’une organisation moderne devrait être conscient et intégrer dans ses propres mesures et attentes.
L'implémentation du plan d'orchestration dans votre infrastructure ainsi que le choix du registre de services deviennent des facteurs importants dans votre processus de décision concernant la technologie que vous utilisez. Réfléchissez bien à vos choix, car ils ont un impact sur la disponibilité et les performances des applications fournies via des architectures basées sur des conteneurs.