Les plates-formes telles que Kubernetes, Nomad ou toute plate-forme en tant que service (Paas) hébergée dans le cloud offrent une variété de fonctionnalités puissantes. De la mise à l'échelle des charges de travail à la gestion des secrets en passant par les stratégies de déploiement, ces orchestrateurs de charges de travail sont optimisés pour aider à faire évoluer l'infrastructure de différentes manières.  Mais les opérateurs doivent-ils toujours payer le prix d’une évolutivité maximale ? Parfois, le coût de la complexité et de l’abstraction dépasse leurs avantages. De nombreux constructeurs en viennent plutôt à s’appuyer sur des architectures de déploiement radicalement simples pour faciliter la gestion. Deux serveurs privés virtuels derrière un équilibreur de charge constituent une pile considérablement plus simple à gérer par rapport à un cluster tentaculaire de microserveurs répartis sur une flotte d'hôtes de conteneurs. Cela peut commencer à porter ses fruits lorsqu’il y a moins de pièces mobiles à déboguer lorsque des problèmes surviennent ou à mettre à niveau lorsque vient le temps de les maintenir.  La base de nombreuses distributions Linux modernes est   , et elle est dotée d'un ensemble solide de fonctionnalités souvent comparables aux orchestrateurs de conteneurs ou aux systèmes PaaS. Dans cet article, nous explorerons comment vous pouvez exploiter les dernières fonctionnalités de systemd pour acquérir de nombreuses capacités de ces autres grands systèmes sans les problèmes de gestion et dynamiser n'importe quel serveur   ordinaire pour en faire une plate-forme d'applications très performante. systemd Linux  Une introduction à systemd  Sur un seul hôte, l'écriture d'un fichier systemd   est un moyen idéal pour exécuter un processus géré. La plupart du temps, vous n'avez même pas besoin de modifier l'application : systemd prend en charge une variété de types de services différents et peut s'adapter en conséquence. .service  Par exemple, considérons ce simple   qui définit comment exécuter un service Web simple : .service   [Unit] Description=a simple web service [Service] ExecStart=/usr/bin/python3 -m http.server 8080  N'oubliez pas les valeurs par défaut des services systemd :   doit être un chemin absolu, les processus ne doivent pas passer en arrière-plan et vous devrez peut-être définir les variables d'environnement requises avec l'option   . ExecStart= Environment=  Lorsqu'il est placé dans un fichier comme   , cela crée un service que vous pouvez contrôler avec   : /etc/systemd/system/webapp.service systemctl    démarrera le processus. systemctl start webapp    affichera si le service est en cours d'exécution, sa disponibilité et la sortie de   et   , ainsi que l'ID du processus et d'autres informations. systemctl status webapp stderr stdout    mettra fin au service. systemctl stop webapp  De plus, toutes les sorties imprimées sur   et   seront agrégées par journald et accessibles via le journal système (avec   ) ou ciblées spécifiquement à l'aide de l'indicateur   : stderr stdout journalctl --unit   journalctl --unit webapp  Étant donné que journald effectue une rotation et gère son stockage par défaut, la collecte des journaux via le journal est une bonne stratégie pour gérer le stockage des journaux.  Le reste de cet article explorera les options permettant d’améliorer un service comme celui-ci.  Secrets    prennent en charge la possibilité d'injecter en toute sécurité   : des valeurs extraites de banques de données sécurisées et exposées aux charges de travail en cours d'exécution. Les données sensibles telles que les clés API ou les mots de passe nécessitent un traitement différent de celui des variables d'environnement ou des fichiers de configuration pour éviter toute exposition involontaire. Les orchestrateurs de conteneurs comme Kubernetes des secrets  L'    systemd prend en charge le chargement de valeurs sensibles à partir de fichiers sur le disque et leur exposition aux services en cours d'exécution de manière sécurisée. Comme les plates-formes hébergées qui gèrent les secrets à distance, systemd traitera   différemment des valeurs telles que les variables d'environnement pour garantir leur sécurité. option LoadCredential= les informations d'identification  Pour injecter un secret dans un service systemd, commencez par placer un fichier contenant la valeur secrète dans un chemin du système de fichiers. Par exemple, pour exposer une clé API à une unité   , créez un fichier dans   pour conserver le fichier lors des redémarrages ou dans   pour éviter de conserver le fichier de manière permanente (le path peut être arbitraire, mais systemd traitera ces chemins   comme valeurs par défaut). Dans les deux cas, le fichier doit avoir des autorisations restreintes à l'aide d'une commande telle que   . .service /etc/credstore/api-key /run/credstore/api-key credstore chmod 400 /etc/credstore/api-key  Sous la section   du fichier   , définissez l'option   et transmettez-lui deux valeurs séparées par deux points (   ) : le nom de l'identifiant et son chemin. Par exemple, pour appeler notre fichier   « jeton », définissez l'option de service systemd suivante : [Service] .service LoadCredential= : /etc/credstore/api-key   LoadCredential=token:/etc/credstore/api-key  Lorsque systemd démarre votre service, le secret est exposé au service en cours d'exécution sous un chemin du formulaire   où   est une variable d'environnement renseignée par systemd. Le code de votre application doit lire chaque secret défini de cette manière pour une utilisation dans des bibliothèques ou du code nécessitant des valeurs sécurisées telles que des jetons API ou des mots de passe. Par exemple, en Python, vous pouvez lire ce secret avec un code comme celui-ci : ${CREDENTIALS_DIRECTORY}/token ${CREDENTIALS_DIRECTORY}   from os import environ from pathlib import Path credentials_dir = Path(environ["CREDENTIALS_DIRECTORY"]) with Path(credentials_dir / "token").open() as f: secret = f.read().strip()  Vous pouvez ensuite utiliser la variable   avec le contenu de votre secret pour toutes les bibliothèques pouvant nécessiter un jeton API ou un mot de passe. secret  Redémarre  Une autre capacité des orchestrateurs comme   est la possibilité de   automatiquement une charge de travail qui est tombée en panne. Que ce soit en raison d'une erreur d'application non gérée ou d'une autre cause, le redémarrage des applications défaillantes est une fonctionnalité très utile qui constitue souvent la première ligne de défense lors de la conception d'une application résiliente. Nomad redémarrer  L'     systemd contrôle si systemd redémarrera automatiquement un processus en cours d'exécution. Il existe plusieurs valeurs potentielles pour cette option, mais pour les services de base, le paramètre   est bien adapté pour satisfaire la plupart des cas d'utilisation. option Restart= on-failure  Un autre paramètre à prendre en compte lors de la configuration du redémarrage automatique est       , qui dicte la durée pendant laquelle systemd attendra avant de redémarrer le service. En règle générale, cette valeur doit être personnalisée pour éviter de redémarrer les services défaillants dans une boucle serrée et de consommer potentiellement trop de temps CPU consacré au redémarrage des processus. Une valeur courte qui n'attend pas   longtemps comme   est généralement suffisante. l' option RestartSec= trop 5s  Des options telles que   qui acceptent des périodes de durée ou des valeurs basées sur le temps peuvent analyser une variété de formats comme   ou   en fonction de vos besoins. Consultez   pour plus d’informations. RestartSec= 5min 10s 1hour le manuel de systemd.time  Enfin, deux autres options dictent l'agressivité avec laquelle systemd tentera de redémarrer les unités en panne avant d'abandonner.   et   contrôleront la fréquence à laquelle une unité est autorisée à démarrer dans une période de temps donnée. Par exemple, les paramètres suivants : StartLimitIntervalSec= StartLimitBurst=   StartLimitBurst=5 StartLimitIntervalSec=10  Il permettra uniquement à une unité d'essayer de démarrer un maximum de 5 fois sur une période de 10 secondes. Si le service configuré tente de démarrer une sixième fois dans un délai de 10 secondes, systemd cessera de tenter de redémarrer l'unité et la marquera comme   . failed  En combinant tous ces paramètres, vous pouvez inclure les options suivantes pour votre unité   afin de configurer les redémarrages automatiques : .service   [Unit] StartLimitBurst=5 StartLimitIntervalSec=10 [Service] Restart=on-failure RestartSec=1  Cette configuration redémarrera un service s'il échoue (c'est-à-dire s'il se ferme de manière inattendue, par exemple avec un code de sortie différent de zéro) après avoir attendu une seconde et cessera de tenter de redémarrer le service s'il tente de démarrer plus de cinq fois au cours du parcours. de 10 secondes.  Durcissement des services  L’un des principaux avantages de l’exécution dans un conteneur est le sandboxing de sécurité. En segmentant un processus d'application du système d'exploitation sous-jacent, il est beaucoup plus difficile de transformer les vulnérabilités susceptibles d'être présentes dans le service en une véritable compromission. Les environnements d'exécution comme Docker y parviennent grâce à une combinaison de groupes de contrôle et d'autres primitives de sécurité.  Vous pouvez activer plusieurs options systemd pour appliquer des restrictions similaires qui peuvent aider à protéger un hôte sous-jacent contre un comportement imprévisible de la charge de travail :    peut restreindre l'accès en écriture aux chemins système sensibles tels que   et   .   énumère toutes les options disponibles, mais d'une manière générale, définir cette option sur   est une valeur par défaut raisonnable pour protéger ces chemins de système de fichiers. ProtectSystem= /boot /usr La documentation de cette option full    peut définir les répertoires   ,   et   en lecture seule avec le paramètre en   ou, lorsqu'il est défini sur   , les monter dans le système de fichiers du service en tant que répertoires vides. À moins que votre application ait un besoin spécifique d'accéder à ces répertoires, définir cette valeur sur   peut renforcer le système en toute sécurité contre tout accès illégitime à ces répertoires. ProtectHome= /home /root /run/user read-only true true    conserve un   et   distincts pour le service configuré afin que les fichiers temporaires de ce service et des autres processus restent privés. À moins qu’il n’y ait une raison impérieuse pour que les processus partagent des informations via des fichiers temporaires, il s’agit d’une option utile à activer. PrivateTmp= /tmp /var/tmp      de renforcer un service en garantissant que le processus exécuté ne peut pas élever ses privilèges. Si vous n'êtes pas sûr de la possibilité d'utiliser d'autres options de renforcement, c'est généralement l'une des moins problématiques à activer. NoNewPrivileges= est un autre moyen sûr et simple    est une ressource utile pour explorer les différentes options qui s'appliquent aux charges de travail exécutables telles que les services. La page de manuel de systemd.exec  Lectures complémentaires  Les   sont complètes et utiles pour découvrir toutes les options disponibles pour exécuter vos propres applications. Que vous exécutiez un service persistant comme un serveur Web ou une unité   périodique pour remplacer une tâche cron, la documentation systemd peut vous offrir des conseils utiles. pages de manuel du projet systemd .timer

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Micro-DevOps avec Systemd : boostez n'importe quel serveur Linux ordinaire

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps