Comment résoudre les problèmes courants avec vos serveurs CoreOS

CoreOS introduit un certain nombre de technologies intéressantes facilitant la création de systèmes distribués. Cependant, ces outils peuvent ne pas être familiers aux nouveaux utilisateurs et avoir leurs propres excentricités. L’un des principaux problèmes est qu’il existe de nombreuses couches d’abstraction au travail et qu’il peut être difficile d’identifier le problème.

Dans ce guide, nous allons passer en revue certaines procédures de dépannage de base pour travailler avec les hôtes CoreOS, les conteneurs Docker qu’ils exécutent et les outils de gestion de services qui rassemblent certaines des pièces disparates.

L’un des problèmes les plus courants rencontrés par les utilisateurs nouveaux et expérimentés de CoreOS lorsqu’un cluster ne parvient pas à apparaître correctement est un fichier cloud-config non valide.

CoreOS nécessite qu’un fichier de configuration cloud soit transmis à votre serveur lors de sa création. Il utilise les informations contenues dans ce fichier pour s’amorcer et initier ou rejoindre un cluster existant. Il démarre également les services essentiels et peut configurer les bases du système, telles que les utilisateurs et les groupes.

Quelques points à vérifier avec votre fichier cloud-config:

Vous pouvez uniquement transmettre le fichier cloud-config lors de la création de la machine. Si vous vous êtes trompé, détruisez l’instance du serveur et recommencez (avec un nouveau jeton, dans la plupart des cas).

Une fois que vous êtes à peu près certain que le fichier cloud-config est correct, vous devez ensuite vous connecter à l’hôte pour vous assurer que le fichier a été traité correctement.

Cela devrait être facile dans la plupart des cas car, sur DigitalOcean, vous devez ajouter des clés ssh au serveur lors de la création. Cela signifie que vous pouvez généralement SSH sur le serveur pour résoudre les problèmes sans problème.

Une fois que vous êtes connecté, vous devez vérifier si votre cloud-config a été traité correctement.

Si vous devez poursuivre le débogage, vous découvrirez rapidement que CoreOS contient une installation de base très minimale. Comme tous les logiciels doivent être exécutés dans des conteneurs, il n’inclut même pas certains des programmes utilitaires les plus élémentaires.

Heureusement, les développeurs CoreOS apportent une solution élégante à ce problème. En utilisant le script «toolbox» inclus dans chaque hôte, vous pouvez démarrer un conteneur Fedora avec un accès aux systèmes hôte. À l’intérieur de ce conteneur, vous pouvez installer tous les utilitaires nécessaires au débogage de l’hôte.

Pour le démarrer, utilisez simplement la commande + toolbox +:

Cela va extraire la dernière image de Fedora et vous déposer dans une ligne de commande dans le conteneur. Si vous effectuez quelques vérifications rapides, vous réaliserez que vous avez accès au réseau du système hôte:

Vous avez également un accès complet aux processus de l’hôte:

Vous pouvez installer tous les outils dont vous avez besoin dans cet environnement. Par exemple, nous pouvons installer + htop +, un clone supérieur avec des fonctionnalités supplémentaires, en utilisant le gestionnaire de paquets Fedora:

Ceci affichera le moniteur de processus avec tous les processus de l’hôte chargés.

Pour quitter l’environnement du conteneur, tapez «exit» ou appuyez sur + CTRL -] + trois fois plus vite. Vous serez replacé dans la session shell de l’hôte.

Les services que vous exécutez sont un autre domaine que vous devrez peut-être résoudre. Parce que nous disposons de + flotte + et + flottectl + pour gérer nos services à l’échelle du cluster, nos premières étapes peuvent être effectuées sur n’importe lequel des serveurs de notre cluster.

Nous devrions commencer par nous faire une idée de la santé de vos services, à la fois du point de vue de + flotte +, et des hôtes individuels affectés à l’exécution de chaque service. L’outil + flottectl + nous donne des commandes pour obtenir facilement ces informations.

Tout d’abord, voyez comment + flotte + voit l’état du service en tapant:

Cela vous donnera un aperçu de tous les services que + flotte + connaît. Cette sortie contient des informations très importantes. Nous allons jeter un coup d’oeil.

Comme vous pouvez le constater, de nombreuses informations peuvent vous aider à résoudre un problème.

Cependant, ce n’est pas le seul endroit important à vérifier. Il est important de réaliser qu’il arrive parfois que + flotte + ne soit pas d’accord avec l’instance locale + systemd + de la machine concernant l’état d’un service. Cela peut se produire pour diverses raisons, par exemple si une unité démarre ou arrête une autre unité en interne.

Pour obtenir des informations sur l’état de chaque service, issues de l’instance + systemd + de l’hôte qui exécute ce service, utilisez plutôt la commande + list-units +:

Ici, nous pouvons voir que tous les services sont répertoriés comme étant en cours d’exécution. Ceci est en désaccord avec les informations affichées par + list-unit-files. En effet, chacun des services + apache lance le service` + apache-discovery` associé sans informer + flotte +. Ce n’est pas une erreur, mais peut créer une confusion sur l’état actuel d’un service.

Pour obtenir des informations complémentaires sur l’un des services, vous pouvez utiliser + flottectl + pour accéder aux informations + systemctl status + et + journalctl -u + du système hôte. Il suffit de taper:

Ou lisez le journal en tapant:

Cela peut fournir de bonnes informations sur la raison pour laquelle vos services échouent. Par exemple, si votre fichier d’unité a déclaré une dépendance indisponible, cela s’afficherait ici (cela peut se produire si la dépendance n’a pas encore été chargée dans + flotte +).

Une erreur que vous pouvez rencontrer lorsque vous exécutez certaines de ces commandes est la suivante:

Cela indique que vous n’avez pas transféré votre agent utilisateur ssh lorsque vous vous êtes connecté à cet hôte. Afin que + flotte + obtienne des informations sur les autres machines du cluster, il se connecte à l’aide des informations d’identification SSH que vous conservez sur votre ordinateur local.

Pour ce faire, vous devez exécuter un agent ssh sur votre ordinateur local et ajouter votre clé privée. Vous pouvez le faire sur votre ordinateur local en tapant:

Une fois que votre agent ssh a eu accès à votre clé privée, vous devez vous connecter à votre hôte CoreOS avec l’option + -A + pour forward cette information:

Cela permettra à la machine sur laquelle vous êtes en mode SSH d’utiliser vos informations d’identification pour établir des connexions avec les autres machines du cluster. C’est ce qui vous permet de lire les informations + systemd + des membres du cluster distant. Il vous permet également de ssh directement aux autres membres.

Bien que vous puissiez obtenir de nombreux éléments d’information de grande qualité en n’utilisant que + fleetctl +, vous devez parfois vous adresser à l’hôte responsable de l’exécution du service pour résoudre les problèmes.

Comme nous l’avons indiqué ci-dessus, cela est facile lorsque vous avez transféré vos informations SSH lors de la connexion. Depuis l’hôte auquel vous vous êtes connecté, vous pouvez “sauter” vers d’autres machines en utilisant + fleetctl +. Vous pouvez spécifier un ID d’ordinateur ou simplement le nom du service. Le processus + flottectl + est suffisamment intelligent pour savoir à quel hôte vous faites référence:

Cela vous donnera une connexion ssh à l’hôte affecté à l’exécution de ce service. Un service doit être à l’état «chargé» ou «lancé» pour que cela fonctionne.

À partir de là, vous aurez accès à tous les outils de dépannage locaux. Par exemple, vous pouvez accéder à l’ensemble plus complet d’indicateurs + journalctl + qui ne sont peut-être pas disponibles via la commande + fleetctl journal +:

À ce stade, vous souhaiterez peut-être résoudre les problèmes liés à Docker. Pour voir la liste des conteneurs en cours d’exécution, tapez:

Nous pouvons voir qu’un seul conteneur est en cours d’exécution. L’ID de conteneur en surbrillance est utile pour de nombreuses autres opérations Docker.

Si votre service ne parvient pas à démarrer, votre conteneur ne sera pas en cours d’exécution. Pour voir une liste de tous les conteneurs, y compris ceux qui ont quitté / échoué, passez l’indicateur + -a +:

Pour voir le conteneur last qui a été démarré, quel que soit son état, vous pouvez utiliser l’indicateur + -l + à la place:

Une fois que vous avez l’ID de conteneur du conteneur que vous recherchez, vous pouvez commencer à enquêter au niveau de Docker. Tout d’abord, vous pouvez afficher les journaux:

Cela vous donnera les informations de journal pouvant être collectées à partir du conteneur. Cela devrait fonctionner que le conteneur soit en cours d’exécution ou non. Si le conteneur a été exécuté de manière interactive (avec les indicateurs + -i + et + -t + et une session shell), l’intégralité de la session sera disponible dans les journaux.

Vous pouvez obtenir une liste des processus en cours pour tout conteneur actif en tapant:

Voici quelques-unes des procédures que vous pouvez utiliser pour résoudre les problèmes liés à vos clusters CoreOS. Celles-ci devraient vous aider à localiser les problèmes que vous pourriez rencontrer avec votre fichier de configuration en cloud et à dépanner la capacité de vos machines à mettre en cluster et à démarrer les services correctement. La détection des problèmes liés aux conteneurs et services Docker est un autre domaine que nous avons abordé.

Une des choses les plus importantes à garder à l’esprit est que le débogage devient beaucoup plus facile à mesure que vous avez plus d’informations sur votre système. Il est utile de bien comprendre le rôle de chaque composant et la manière dont ils interagissent pour aider le système à fonctionner. Si vous vous retrouvez perdu en essayant de dépister un problème, il peut être utile de vous rappeler les bases de CoreOS.