Monitoring des containers : l’art du bon outillage
Inutile de s’en tenir aux outils de monitoring traditionnels pour les containers. Leur vision ne sera que partielle. L’heure est à identifier le bon outil.
Les applications - si on peut encore les appeler ainsi - sont si dynamiques et malléables lorsqu'elles sont composées de microservices et de containers qu’elles n’ont plus rien à voir avec ces designs monolithiques que l’on connait. Cependant, quelle que soit l'architecture, le support IT doit rester fidèle à sa mission : rapidement identifier et corriger tout problème en production.
Sauf que généralement, le DSI et autres équipes opérationnelle sont certes équipées pour le monitoring et le support d’applications monolithiques, mais très peu pour les microservices.
Isolation et portabilité du container
Pour les plus aguerris au support des VM, le container semble être un pas en arrière. Une VM comprend tout ce dont l'application a besoin pour fonctionner : l’OS, la pile logicielle et, parfois, même les données. En packageant des fonctions ou des services, l'administrateur capture et stocke facilement les systèmes. Si une modification pose problème, il peut revenir à une version antérieure, en conservant la fonctionnalité pendant que l'équipe effectue l'analyse des causes profondes du problème.
Les containers partagent certaines parties de l'OS et ne comprennent que les parties, de la fonction ou du microservice, nécessaires pour fonctionner. Les containers ont besoin du même OS sous-jacent lorsqu'ils migrent, ce qui n'est pas le cas des VM.
Les containers incluent suffisamment d’éléments contextuels pour être très portables, mais conservent un avantage en termes d'efficacité par rapport aux machines virtuelles. Ils ne transportent pas une copie complète du système d'exploitation. L'approche de Virtuozzo est un moyen d'y parvenir. Par exemple, si une fonction nécessite un niveau de patch spécifique, ce dernier est conservé dans le container, alors que l’OS lui-même est toujours partagé par plusieurs containers.
Ainsi, il est possible de remplacer de nombreuses VM par un équivalent container – celui-ci sera beaucoup plus économe en ressources. La capacité de basculer vers un container précédent fait des containers une méthode de déploiement viable et précieuse.
Outils de monitoring et de gestion des containers
Avec le bon outillage, les départements IT peuvent garder les containers en bonne santé sans avoir à se basculer sur des versions précédentes. Les outils de gestion des containers arrivent à maturité et cela est lié à l'évolution des processus DevOps.
Kubernetes - et ses nombreuses variantes commerciales – dispose de fonctions de monitoring des containers ainsi si que la possibilité de redémarrer, d'arrêter et de remplacer les containers défaillants. La plateforme open source embarque également des outils pour rendre les containers disponibles aux autres containers.
Certains fournisseurs, comme Oracle, IBM, Red Hat avec OpenShift et CoreOS et Canonical (en particulier en association avec son outil DevOps, Juju), ont intégré Kubernetes à leur offre.
La plupart des plateformes de cloud public ont des services d'orchestration de containers, et ici, Kubernetes est également très présent. AWS propose Elastic Container Service et EKS. De son côté, Microsoft tient à disposition Azure Container Service et Google, son Kubernetes Engine.
Monitoring, analyse et remédiation
Voici les fonctions qu’un orchestrateur de containers doit contenir :
- Monitoring : L'orchestrateur doit permettre aux utilisateurs de vérifier si les containers fonctionnent dans les limites de la politique convenue. Ce type de données de monitoring doit être présenté sous une forme facile à consulter, de préférence par le biais d'une interface graphique.
- Automatisation : Les orchestrateurs doivent, au besoin, pouvoir provisionner / fournir de façon constante et répétée des containers sur différentes plateformes.
- Remédiation : il s’agit de la capacité d'arrêter, de redémarrer, de remplacer des containers qui fonctionnent en dehors des limites de la politique convenue.
- Analyse des causes profondes : le monitoring des containers permet d'identifier un problème. Les systèmes « containerisés » sont complexes, de sorte que les outils qui identifient rapidement la source du problème sont très recherchés.
- Intégration dans d'autres systèmes : la containerisation est la partie aval d'un processus DevOps complet. Le système d'orchestration doit donc fonctionner avec l'ensemble d'outils DevOps de l'entreprise.
- Nettoyage du système: Tout en surveillant la santé et la conformité des containers, un orchestrateur doit également identifier les zombies, c'est-à-dire les containers inutilisés qui sont encore opérationnels. Il peut soit alerter les administrateurs, soit stopper les containers si nécessaire.