Comment utiliser Fleetctl pour gérer votre cluster CoreOS

Les sections de base de la plupart des fichiers d’unité sont les suivantes:

Si le type a des options spécifiques, une section du type associé est autorisée. Le type de section + Service + est de loin le plus courant. Cette section est utilisée pour définir des attributs spécifiques au type. Pour les unités + Service +, cela implique généralement de définir les commandes de démarrage et d’arrêt, ainsi que les commandes de pré et post-démarrage ou d’arrêt pouvant effectuer les actions associées.

Le format général d’un fichier unité sera:

Pour débuter avec ce tutoriel, nous vous donnerons un fichier unité à utiliser. Ceci est extrait de la page CoreOS à titre d’exemple. Sur l’une de vos machines CoreOS, tapez:

A l’intérieur, tapez notre exemple de fichier de service:

Voyons rapidement ce que cela fait.

Dans la section + [Unit] +, une description est définie et nous indiquons + systemd + que ce service ne peut être exécuté qu’après le démarrage de l’unité + docker.service +. En effet, notre unité dépend de Docker pour fonctionner.

Dans la section + [Service] +, nous désactivons le délai d’attente de démarrage, puis nous configurons certaines actions à exécuter avant de démarrer le service. + ExecStartPre + est exécuté avant l’action principale + ExecStart +. Si ceux-ci sont appelés avec + = - +, cela signifie que l’action peut échouer et ne pas affecter l’achèvement du service. Cela est nécessaire car nos actions de pré-démarrage suppriment essentiellement tout service en cours d’exécution. Cela échouera si aucun ne peut être trouvé et nous ne voulons pas que cela empêche notre service de démarrer car il s’agit simplement d’une procédure de nettoyage.

La dernière action de pré-démarrage extrait l’image de base busybox qui sera utilisée pour exécuter nos commandes. Comme cela est nécessaire, nous n’utilisons pas la syntaxe + = - +. Nous commençons ensuite un conteneur avec cette image avec une boucle infinie qui affiche «Hello World» une fois par seconde. L’action stop arrête simplement ce conteneur.

Ce sera juste assez pour vous permettre de démarrer. Si vous souhaitez plus d’informations sur la manière de développer des fichiers de flotte, consultez https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-corecore-cluster-with-fleet- unit-files [notre guide sur les fichiers d’unités de flotte].

Le démarrage d’un service comporte plusieurs étapes. Le fichier de service doit être chargé dans + flotte + pour qu’il soit au courant de l’unité. Il doit ensuite être programmé sur une machine spécifique en dehors du cluster. Il peut alors être démarré. Il existe des commandes pour chacune d’elles avec + fleetctl +, les commandes responsables des dernières étapes effectuant également les précédentes si nécessaire.

Vous pouvez utiliser la commande + submit + pour soumettre votre fichier d’unité dans + flotte +. Cela fera simplement que + flotte + lira le contenu du fichier en mémoire, le rendant disponible pour d’autres actions.

Votre fichier + hello.service + est maintenant connu sous le nom + flotte +. Pour voir les fichiers d’unité qui ont été soumis, vous pouvez taper:

Comme vous pouvez le constater, le fichier d’unité est présent, mais n’a pas été planifié sur aucun hôte ni démarré.

Pour voir le contenu d’un fichier d’unité que + flotte + connaît, vous pouvez taper:

Cela vous permettra de voir le fichier actuel que + flotte + connaît.

Une fois votre unité soumise, l’étape suivante consiste à la planifier sur une machine. La planification de l’unité implique le moteur + flotte + qui examine l’unité pour décider de la meilleure machine du cluster à laquelle transmettre l’unité. Cela dépendra des conditions de la section + [X-Fleet] + de l’unité, ainsi que du volume de travail actuel de chaque machine du cluster. Une fois l’unité programmée, elle a été transmise à la machine spécifique et chargée dans l’instance locale + systemd +.

Utilisez la commande + load + pour charger et planifier l’unité:

Si vous n’aviez pas chargé manuellement votre appareil auparavant, il sera automatiquement chargé dans le cadre de ce processus en recherchant le nom de fichier approprié dans le répertoire actuel.

Maintenant, si nous vérifions nos fichiers d’unités, nous pouvons voir qu’ils ont été chargés. Nous pouvons même voir sur quelle machine il est programmé:

C’est aussi notre première occasion d’extraire la commande + list-units +. Cette commande est utilisée pour afficher toutes les unités en cours ou programmées et leurs statuts:

Pour réellement démarrer une unité, vous pouvez utiliser la commande + start +. Ceci démarrera l’unité sur la machine sur laquelle elle a été chargée en exécutant les commandes de démarrage définies dans le fichier d’unité:

Une fois encore, nous devrions vérifier le + list-unit-files:

Dans la sortie ci-dessus, nous pouvons voir que le service a été lancé. La colonne + DSTATE + indique «l’état souhaité» et la colonne «+ STATE +» indique l’état actuel. Si ces deux éléments correspondent, cela signifie généralement que l’action a abouti.

Nous devrions également regarder à nouveau «+ list-units +»:

Cela nous donne des informations sur l’état + systemd +. Il est collecté directement à partir du démon local. Il s’agit donc d’une meilleure image de la façon dont le système local voit l’état du service. La colonne + ACTIVE + est un état généralisé de l’unité, tandis que + SUB + est une description plus détaillée.

Chacune des commandes ci-dessus a une commande compagnon qui inverse l’état.

Par exemple, pour arrêter l’exécution d’un service, utilisez la commande + stop +. Cela fera que l’instance + systemd + de la machine locale exécutera les commandes d’arrêt définies dans l’unité:

Comme vous pouvez le constater, le service est revenu à l’état + chargé +. Cela signifie qu’il est toujours chargé dans + systemd + de la machine, mais qu’il n’est pas en cours d’exécution. Nous pouvons confirmer que ici:

Pour retirer l’unité du système de cette machine, tout en la gardant disponible dans + flotte +, vous pouvez + décharger + l’unité. Si l’unité est actuellement active, elle sera arrêtée avant d’être déchargée:

Si nous vérifions l’état, nous pouvons voir qu’il est maintenant marqué comme inactif. De plus, aucune machine cible n’est répertoriée:

Si nous voulons supprimer complètement l’unité de + flotte + , nous pouvons utiliser la commande + destroy + . Cela arrêtera et déchargera l’unité si nécessaire, puis supprimera l’unité de `+ flotte +:

Si vous modifiez un fichier d’unité, vous devez détruire l’unité actuelle dans + flotte + avant de le soumettre / de le redémarrer.

Vous avez déjà vu certaines des méthodes pour obtenir des informations sur le statut des unités.

Par exemple, nous avons expliqué comment + list-units + listera toutes les unités actuellement programmées sur une machine:

Le + list-unit-files s fournit une liste de all unités que` + flotte + `connaît. Il donne également des informations sur l’état souhaité et réel:

Pour des informations plus spécifiques sur une unité démarrée, il existe quelques autres commandes. La commande + status + renvoie le résultat + systemctl status + pour le service sur l’hôte qui exécute l’unité:

Comme vous pouvez le constater, nous devons enfin vérifier que la sortie de notre unité est en cours de production.

De même, si vous souhaitez voir l’entrée de journal du service disponible sur la machine associée, vous pouvez utiliser la commande + journal +:

Par défaut, cela affichera les 10 dernières lignes. Vous pouvez ajuster ceci en ajoutant un paramètre + - lines +, comme ceci:

Vous pouvez également utiliser le paramètre + -f +, qui signifie «suivre». Cela se comporte de la même manière que + tail -f + en ce sens qu’il continuera à transmettre les dernières entrées du journal: