Comment créer des services flexibles pour un cluster CoreOS avec des fichiers d’unités de flotte

Les installations CoreOS exploitent un certain nombre d’outils pour faciliter la gestion des services de clustering et des services contenus dans Docker. Alors que + etcd + est impliqué dans la liaison entre les nœuds distincts et dans la fourniture d’une zone pour les données globales, la plupart des tâches de gestion et d’administration de services actuelles impliquent de travailler avec le démon + flotte +.

Dans un https://www.digitalocean.com/community/tutorials/how-to-use-fleet-and-fleetctl-to-manage-your-coreos-cluster[previous guide (précédent), nous avons examiné l’utilisation de base du Commande + fleetctl + pour manipuler les services et les membres du cluster. Dans ce guide, nous avons brièvement abordé les fichiers d’unité utilisés par le parc pour définir les services, mais il s’agit d’exemples simplifiés permettant de fournir un service fonctionnel permettant d’apprendre + fleetctl +.

Dans ce guide, nous explorerons en profondeur les fichiers d’unités `flotte + 'pour apprendre à les créer, ainsi que certaines techniques permettant de rendre vos services plus robustes en production.

Pour terminer ce didacticiel, nous supposerons que vous avez un cluster CoreOS configuré comme décrit dans notre https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on. -digitalocean [guide de regroupement]. Cela vous laissera avec trois serveurs nommés en tant que tels:

Bien que la majeure partie de ce didacticiel se concentre sur la création de fichiers d’unité, ces machines seront utilisées ultérieurement pour démontrer les effets de la planification de certaines directives.

Nous supposerons également que vous avez lu notre guide sur how to use flottectl. Vous devez avoir une connaissance pratique de + fleetctl + afin de pouvoir soumettre et utiliser ces fichiers unités avec le cluster.

Une fois ces conditions remplies, poursuivez avec le reste du guide.

Étant donné que l’aspect gestion des services de + flotte + repose principalement sur les systèmes initiaux + systemd + de chaque système local, les fichiers unitaires + systemd + sont utilisés pour définir les services.

Bien que les services constituent de loin le type d’unités le plus souvent configuré avec CoreOS, il existe en réalité d’autres types d’unités pouvant être définis. Ce sont un sous-ensemble de ceux disponibles dans les fichiers unitaires conventionnels + systemd +. Chacun de ces types est identifié par le type utilisé comme suffixe de fichier, comme + example.service +:

Bien que ces options soient toutes disponibles, les unités de service seront utilisées le plus souvent. Dans ce guide, nous ne parlerons que de la configuration des unités de service.

Les fichiers d’unité sont de simples fichiers texte se terminant par un point et l’un des suffixes ci-dessus. A l’intérieur, ils sont organisés par sections. Pour + flotte +, la plupart des fichiers d’unité auront le format général suivant:

Les en-têtes de section et tout le reste dans un fichier unité sont sensibles à la casse. La section + [Unit] + est utilisée pour définir des informations génériques sur une unité. Les options communes à tous les types d’unité sont généralement placées ici.

La section + [Service] + est utilisée pour définir les directives spécifiques aux unités de service. La plupart (mais pas la totalité) des types d’unités ci-dessus ont des sections associées pour des informations spécifiques au type d’unité. Consultez la page de manuel generic systemd pour des liens vers les différents types d’unités et obtenir plus d’informations.

La section + [X-Fleet] + est utilisée pour définir les exigences de planification de l’unité à utiliser avec + flotte +. A l’aide de cette section, vous pouvez exiger que certaines conditions soient remplies pour qu’une unité soit programmée sur un hôte.

Pour cette section, nous allons commencer avec une variante du fichier d’unité décrit dans notre https://www.digitalocean.com/community/tutorials/how-to-create-and-run-a-service-on-a-coreos -cluster [guide de base sur l’exécution de services sur CoreOS]. Le fichier s’appelle + apache.1.service + et ressemblera à ceci:

Nous commençons par la section + [Unit] +. Ici, l’idée de base est de décrire l’unité et d’établir les informations de dépendance. Nous commençons par un ensemble d’exigences. Nous avons utilisé des exigences strictes pour cet exemple. Si nous voulions que «+ flotte » tente de démarrer des services supplémentaires, sans nous arrêter en cas d'échec, nous aurions pu utiliser la directive ` Wants +` à la place.

Ensuite, nous listons explicitement ce que la commande des exigences devrait être. Ceci est important pour que les services prérequis soient disponibles quand ils sont nécessaires. C’est aussi la façon dont nous lançons automatiquement le service d’annonce de sidekick, etcd que nous allons créer.

Pour la section + [Service] +, nous désactivons le délai de démarrage du service. La première fois qu’un service est exécuté sur un hôte, le conteneur devra être extrait du registre Docker, ce qui compte pour le délai d’expiration du démarrage. La valeur par défaut est 90 secondes, ce qui prend généralement assez de temps, mais avec des conteneurs plus complexes, cela peut prendre plus de temps.

Nous définissons ensuite le killmode sur none. Ceci est utilisé car le mode kill normal (groupe de contrôle) provoque parfois l’échec des commandes de suppression de conteneur (en particulier lorsqu’il est tenté par l’option + - rm + de Docker). Cela peut causer des problèmes lors du prochain redémarrage.

Nous extrayons le fichier d’environnement afin d’avoir accès aux variables + COREOS_PUBLIC_IPV4 + et, si la mise en réseau privée a été activée lors de la création, aux variables d’environnement + COREOS_PRIVATE_IPV4 +. Celles-ci sont très utiles pour configurer les conteneurs Docker afin qu’ils utilisent les informations de leur hôte spécifique.

Les lignes + ExecStartPre + sont utilisées pour supprimer les fichiers restants des exécutions précédentes afin de s’assurer que l’environnement d’exécution est propre. Nous utilisons + = - + sur les deux premiers pour indiquer que + systemd + devrait ignorer et continuer si ces commandes échouent. Pour cette raison, Docker tentera de supprimer et de supprimer les conteneurs précédents, mais ne craindra rien s’il n’en trouve aucun. Le dernier pré-démarrage est utilisé pour s’assurer que la version la plus récente du conteneur est en cours d’exécution.

La commande de démarrage réelle amorce le conteneur Docker et le lie à l’interface IPv4 publique de la machine hôte. Cela utilise les informations du fichier d’environnement et facilite le changement d’interfaces et de ports. Le processus est exécuté au premier plan car le conteneur se fermera si le processus en cours se termine. La commande d’arrêt tente d’arrêter le conteneur en douceur.

La section + [X-Fleet] + contient une condition simple qui oblige + flotte + à planifier le service sur un ordinateur qui n’exécute pas déjà un autre service Apache. C’est un moyen facile de rendre un service hautement disponible en forçant les services en double à démarrer sur des ordinateurs distincts.

Maintenant que nous avons une bonne idée de ce qu’il faut garder à l’esprit lors de la création d’un service principal, nous pouvons commencer à rechercher un service conventionnel «d’accompagnement». Ces services de sidekick sont associés à un service principal et servent de point externe pour enregistrer des services avec + etcd +.

Ce fichier, comme il a été référencé dans le fichier d’unité principale, s’appelle + apache-discovery.1.service + et ressemble à ceci:

Nous commençons le service sidekick à peu près de la même manière que nous avons fait le service principal. Nous décrivons l’objectif de l’unité avant de passer aux informations sur les dépendances et à la logique de commande.

Le premier nouvel élément ici est la directive + BindsTo = +. Cette directive amène cette unité à suivre les commandes de démarrage, d’arrêt et de redémarrage envoyées à l’unité répertoriée. En gros, cela signifie que nous pouvons gérer ces deux unités en manipulant l’unité principale une fois que les deux sont chargées dans + flotte +. Il s’agit d’un mécanisme à sens unique. Le contrôle du sidekick n’affectera donc pas l’unité principale.

Pour la section + [Service] +, nous avons à nouveau source le fichier + / etc / environment + car nous avons besoin des variables qu’il contient. La directive + ExecStart = + dans cette instance est essentiellement un court script + bash +. Il tente de se connecter aux principaux services à l’aide de l’interface et du port exposés.

Si la connexion aboutit, la commande + etcdctl + est utilisée pour définir une clé à l’adresse IP publique de la machine hôte dans + / services / apache + dans + etcd +. La valeur de ceci est un objet JSON contenant des informations sur le service. La clé est configurée pour expirer dans 30 secondes, donc si cette unité tombe en panne de manière inattendue, les informations de service périmées ne seront pas laissées dans + etcd +. Si la connexion échoue, la clé est immédiatement supprimée car il est impossible de vérifier si le service est disponible.

Cette boucle comprend une commande de veille de 20 secondes. Cela signifie que toutes les 20 secondes (avant le délai d’expiration de la clé + etcd + de 30 secondes), cette unité vérifie de nouveau si l’unité principale est disponible et réinitialise la clé. Cela actualise essentiellement la durée de vie de la clé afin qu’elle soit considérée comme valide pendant 30 secondes supplémentaires.

Dans ce cas, la commande d’arrêt entraîne simplement un retrait manuel de la clé. Cela entraînera la suppression de l’enregistrement de service lorsque la commande d’arrêt de l’unité principale est reflétée sur cet appareil en raison de la directive + BindsTo = +.

Pour la section + [X-Fleet] +, nous devons nous assurer que cette unité est démarrée sur le même serveur que l’unité principale. Bien que cela ne permette pas à l’unité de faire un rapport sur la disponibilité du service sur les ordinateurs distants, il est important que la directive + BindsTo = + fonctionne correctement.

Bien que les fichiers d’unités + flotte + 'ne soient pour la plupart pas différents des fichiers d’unités classiques + systemd + `, il existe des capacités et des pièges supplémentaires.

La différence la plus évidente est l’ajout d’une section appelée + [X-Fleet] + qui peut être utilisée pour indiquer à + ​​flotte + de prendre des décisions de planification. Les options disponibles sont:

Ces directives supplémentaires offrent à l’administrateur plus de flexibilité et de puissance pour définir la manière dont les services doivent être exécutés sur les machines disponibles. Celles-ci sont évaluées avant de les transmettre à l’instance + systemd + d’une machine spécifique pendant l’étape + flottectl load +.

Cela nous amène à la prochaine étape à prendre en compte lorsque vous travaillez avec des unités liées dans + flotte +. L’utilitaire + fleetctl + n’évalue pas les exigences de dépendance en dehors de la section + [X-Fleet] + du fichier d’unité. Cela pose des problèmes intéressants lorsque vous travaillez avec des unités associées dans + flotte +.

Cela signifie que, bien que l’outil + flottectl + effectue l’étape nécessaire pour que l’unité cible se trouve dans l’état souhaité, en passant par la soumission, le chargement et le processus de démarrage selon les besoins en fonction de la commande donnée, il ne le fera pas pendant les dépendances de l’unité.

Donc, si votre unité principale et votre unité sidekick sont soumises, mais pas chargées, dans + flotte +, tapez + fleetctl start main.service + chargera puis tentera de démarrer l’unité + main.service +. Cependant, étant donné que l’unité + sidekick.service + n’est pas encore chargée et que + fleetctl + n’évaluera pas les informations de dépendance pour amener les unités de dépendance tout au long du processus de chargement et de démarrage, l’unité + main.service + échouera. . En effet, une fois que l’instance + systemd + de la machine traite l’unité + main.service +, elle ne pourra plus trouver le + sidekick.service + lorsque it évalue les dépendances. L’unité + sidekick.service + n’a jamais été chargée sur la machine.

Pour éviter cette situation lorsque vous travaillez avec des unités associées, vous pouvez démarrer les services manuellement en même temps, sans vous fier à la directive + BindsTo = + pour placer le sidekick dans un état actif:

Une autre option consiste à s’assurer que l’unité de sidekick est au moins chargée lors de l’exécution de l’unité principale. L’étape de chargement est celle où une machine est sélectionnée et le fichier d’unité est soumis à l’instance locale + systemd +. Cela garantira que les dépendances sont satisfaites et que la directive + BindsTo = + sera capable de s’exécuter correctement pour faire apparaître la deuxième unité:

Gardez cela à l’esprit au cas où vos unités liées ne répondent pas correctement à vos commandes + fleetctl +.

L’un des concepts les plus puissants lorsque vous travaillez avec + fleet + sont les modèles d’unités.

Les modèles d’unité reposent sur une fonctionnalité de + systemd + appelée «instances». Ce sont des unités instanciées créées au moment de l’exécution en traitant un fichier d’unité modèle. Le fichier modèle est pour la plupart très similaire à un fichier unité standard, avec quelques petites modifications. Cependant, ceux-ci sont extrêmement puissants lorsqu’ils sont utilisés correctement.

Les fichiers modèles peuvent être identifiés par le signe + @ + dans leur nom de fichier. Alors qu’un service conventionnel prend cette forme:

Un fichier modèle peut ressembler à ceci:

Lorsqu’une unité est instanciée à partir d’un modèle, son identificateur d’instance est placé entre les suffixes + @ + et + .service +. Cet identifiant est une chaîne unique sélectionnée par l’administrateur:

Le nom d’unité de base est accessible depuis le fichier d’unités à l’aide du spécificateur +% p +. De même, l’identifiant d’instance donné est accessible avec +% i +.

Vous devriez avoir une bonne compréhension de la façon de créer des fichiers unité pour + flotte + à ce stade. En tirant parti de certaines des fonctionnalités dynamiques disponibles dans les fichiers d’unité, vous pouvez vous assurer que vos services sont distribués de manière homogène, proches de leurs dépendances, et enregistrer des informations utiles avec + etcd +.

Dans un guide plus récent, nous expliquerons comment configurer vos conteneurs à utiliser les informations que vous enregistrez avec + etcd +. Cela peut aider vos services à acquérir une connaissance pratique de votre environnement de déploiement actuel afin de transmettre les demandes aux conteneurs appropriés dans le backend.