introduction
Initialization est une procédure cruciale qui se trouve au cœur de tout système d'exploitation basé sur Unix pour contrôler le fonctionnement de chaque script et service. Cela est essentiel dans un environnement de serveur, où des problèmes peuvent survenir aux points critiques du démarrage et de l’arrêt, et dans lequel l’optimisation des performances optimales est une priorité.
L’initialisation suit essentiellement ce type de processus:
-
Le serveur démarre
-
Le processusinit s'exécute (généralement en tant que
PID 1
) -
Un ensemble prédéfini de tâches de démarrage à activer en séquence
L'initialisation est responsable de s'assurer que le serveur cloud peut démarrer et s'éteindre proprement.
Certaines distributions avec une fondation Unix utilisent le processus standardinit pour l'initialisation. Dans cet article, nous allons examinerUpstart - un remplacement pratique et puissant qui peut booster les opérations de votre serveur.
Qu'est-ce qui ne va pas avec l'init classique?
L'initialisation traditionnelle suit un processus linéaire: les tâches individuelles se chargent dans une séquence prédéfinie au démarrage du système. Ce n’est pas très utile, surtout dans des situations qui changent rapidement. Pour comprendre pourquoi, imaginez, par exemple, que vous avez modifié l’environnement du serveur en ajoutant un périphérique de stockage supplémentaire.
Le processus d’initialisation n’est pas en mesure de prendre en compte les changements soudains d’environnement, ce qui signifie que votre serveur cloud devra être réinitialisé avant de pouvoir reconnaître le stockage supplémentaire. La détection à la volée est ce qui est nécessaire, bien que ce ne soit pas une capacité de procédure d’initialisation classique.
Le démarrage dans une séquence linéaire prend également du temps, ce qui est particulièrement désavantageux dans un environnement en nuage où un déploiement rapide est essentiel.
Vous pouvez également être préoccupé par l'état de vos tâches après le chargement du système. Malheureusement,init est concerné par la séquence uniquement lorsque vous démarrez ou éteignez.
Les séquences d'amorçage synchrones ne sont plus souhaitables. Un système rigide pourrait supporter les systèmes d’hier, mais aujourd’hui est dynamique.
C’est là queUpstart entre en jeu - une solution à ces problèmes avec des capacités avancées.
Basé sur les événements dereal-time au lieu d'une liste prédéfinie de tâches en séquence, ce démon init de remplacement gère le démarrage et l'arrêt des tâchesand surveille ces processus pendant que le système est en cours d'exécution - la «couverture complète» est la meilleure façon de le décrire.
Ce traitement nouvellement asynchrone élimine le besoin d'une séquence de démarrage rigide. Le traitement en temps réel peut être compliqué à conceptualiser, mais Upstart peut prendre en charge les systèmes les plus complexes et tout garder sous contrôle en utilisant une structure dejobs.
Un aperçu de Upstart
Conçu avec une flexibilité dès le début, le système d’événement Upstart utilise une variété de concepts qui diffèrent des systèmes d’initialisation conventionnels. La solution est installée par défaut sur Red Hat Enterprise Linux (RHEL) 6, ainsi que sur Chrome OS de Google et Ubuntu, bien que des débats récents aient semé la confusion sur le point de savoir si cela va continuer.
Jobs
Dans le monde d'Upstart, les tâches sont des processus de travail, divisés en tâches (avec un objectif) et en tâches de service (pouvant s'exécuter en arrière-plan). Il existe également des tâches abstraites - des processus qui s'exécutent indéfiniment jusqu'à ce qu'ils soient arrêtés par un utilisateur disposant de privilèges administratifs.
Événements
LesEvents, cependant, sont les signaux ou «appels» utilisés pour déclencher une certaine action avec un travail ou un autre événement. Les formes courantes d'événements font référence à la surveillance d'un processus:starting
,started
,stopping
etstopped
.
Événements émetteurs
Le processus de diffusion d'un événement est appelé «émission». Cela est généralement dû à un état de processus ou de travail, bien qu'un administrateur puisse également émettre un événement manuellement en exécutant la commandeinitctl emit <event>
. Vous remarquerez que la commandeinit control
devient incroyablement utile lors de la navigation dans la pléthore d'opérations associées à Upstart.
Écrire votre première configuration de travail
Upstart est connu pour fonctionner correctement sur Ubuntu, alors faites tourner unUbuntu 14.04 Droplet avant de commencer.
Maintenant que vous êtes prêt, il est important de comprendre qu'un fichier de configuration de travail doit respecter trois principes de base pour être valide.
-
Il ne doit pas être vide (un fichier sans contenu)
-
Il ne doit contenir aucune erreur de syntaxe.
-
Il doit contenir au moins un bloc de commande, appeléstanza
Restons basiques pour le moment. Dans un instant, nous allons créer un fichier appelétestjob.conf
dans le répertoire/etc/init
. Dans ce cas, “init” est simplement utilisé comme version abrégée de “initialization”.
Notez l'association de fichier.conf
- indiquant que vous allez écrire unjob configuration file.
Pour les besoins de ce didacticiel, l'éditeur de texte de ligne de commandenano est recommandé. Certaines de ces commandes peuvent nécessiter des privilèges administratifs avecsudo
, donc consultezthis article pour créer un utilisateur approprié.
Pour créer un nouveau fichier de configuration pour notre travail de test, exécutez:
sudo nano /etc/init/testjob.conf
Décrivons maintenant l’objectif. Nous voulons que ce travail soitwrite a message and the current timestamp to a log file.
Il existe deux strophes de base qui peuvent vous aider à définir le but d'un script de travail et qui l'a créé:description
etauthor
. Ecrivez-les comme vos premières lignes du fichier.
description "A test job file for experimenting with Upstart"
author "Your Name"
Désormais, nous souhaitons que ce travail ait lieu une fois que les services et processus système ont déjà été chargés (pour éviter tout conflit), afin que votre ligne suivante incorpore l'événement suivant:
start on runlevel [2345]
Vous vous demandez peut-être ce qu'est un niveau d'exécution. En gros, il s’agit d’une valeur unique qui représente la configuration système actuelle. Le[2345]
fait référence à tous les états de configuration avec un accès Linux général et un réseau, ce qui est idéal pour un exemple de test de base.
Nous ajouterons ensuite le code d'exécution. Cette ligne commence parexec
pour indiquer que les commandes suivantes doivent être exécutées via le shell Bash:
exec echo Test Job ran at `date` >> /var/log/testjob.log
Notez que cette commandeecho
utilise des contre-coups pour exécuterdate
en tant que commande, puis écrire l'intégralité du message dans un fichier journal. Si vous avez écrit le motdate
sans backticks, le mot lui-même serait imprimé à la place de la sortie de la commande.
Enregistrez et fermez ce fichier.
Vous pouvez vérifier que cela fonctionne en démarrant manuellement le travail, mais vérifions d’abord la syntaxe du fichier de configuration:
init-checkconf /etc/init/testjob.conf
Si des problèmes sont détectés, cette commande indiquera le numéro de ligne spécifique et le problème. Cependant, avec le travail de test, vous devriez voir une sortie comme celle-ci:
File /etc/init/testjob.conf: syntax ok
Cette commande peut être utilisée pour contrôler les travaux Upstart et d'autres services d'arrière-plan, tels qu'un serveur Web.
La syntaxe de commande de base est la suivante:
sudo service
Cette syntaxe fonctionne avec ces contrôles de base:
-
redémarrer: cela va arrêter, puis démarrer un service
-
start: cela démarrera un service s'il n'est pas en cours d'exécution
-
stop: cela arrêtera un service s'il est en cours d'exécution
-
status: ceci affichera le statut d'un service
Nous voulons démarrer manuellement notre travail de test, la commande devrait donc ressembler à ceci:
sudo service testjob start
Maintenant, vérifiez le fichiertestjob.log
en exécutant la commande suivante:
cat /var/log/testjob.log
Cette commande lira le fichier dans le shell. vous devriez voir une seule ligne semblable à celle ci-dessous:
Test Job ran at Fri Aug 1 08:43:05 BST 2014
Cela montre que votre tâche de test est configurée et prête à fonctionner.
Redémarrez votre Droplet, puis connectez-vous et relisez le fichier journal:
cat /var/log/testjob.log
Une deuxième ligne du journal devrait afficher un horodatage ultérieur pour confirmer son exécution en tant que tâche Upstart.
Test Job ran at Fri Aug 1 08:44:23 BST 2014
Cela ne fait qu'effleurer la surface de ce que vous pouvez faire avec Upstart. Nous aborderons un exemple détaillé plus tard, mais pour l’instant, passons à une explication des états et des événements du travail.
Etats de travail et événements
Les travaux système résident dans le répertoire/etc/init/
, et les travaux utilisateur résident dans le répertoire d’initialisation de l’utilisateur,~/.init/
.
Les travaux d’utilisateur s’exécutent dans la propre session de l’utilisateur. Ils sont donc également appelés travaux de session. Celles-ci ne s’exécutent pas à l’échelle du système et ne sont pas désignées parPID 1
. Pour les besoins de notre travail de test, nous avons utilisé/etc/init
afin qu'il puisse se charger au démarrage du système.
Quel que soit son type, un travail estalways défini dans un fichier de configuration (.conf) où son nom de fichier doit représenter le service ou la tâche impliqué.
Chacun de ces emplois a un objectif:start
oustop
. Entre ces deux objectifs, se trouve un ensemble d'états de tâche, qui définissent les actions en cours du travail par rapport à l'objectif. Les états importants sont les suivants:
-
en attente: l'état initial du traitement
-
commencer: où un travail est sur le point de commencer
-
pre-start: où la section de pré-démarrage est chargée
-
spawned: où une section de script est sur le point de s'exécuter
-
post-démarrage: où se déroulent les opérations post-démarrage
-
en cours: où le travail est complètement opérationnel
-
pré-arrêt: où se déroulent les opérations pré-arrêt
-
arrêter: où le travail est arrêté
-
tué: où le travail est arrêté
-
post-arrêt: où les opérations post-arrêt ont lieu - à nettoyer
Après l'état post-démarrage, le travail est défini comme étant en cours d'exécution. Il reste en cours d'exécution jusqu'à ce qu'un pré-arrêt soit déclenché, où le travail est prêt à s'arrêter, puis le travail est tué et les procédures de post-arrêtcleanup ont lieu, si elles sont définies.
Vous pouvez afficher la transition d'un travail entre les états en définissant la priorité du journal système Upstart (situé dans le répertoire/var/log/upstart/
) surdebug
avec cette commande:
sudo initctl log-priority debug
N'oubliez pas questates are not events, and events are not states. Les quatre événements (démarrage, début, arrêt et arrêt) sont émis par Upstart, mais les états de la tâche définissent la transition entre les étapes de la vie d’un travail.
Nous sommes maintenant prêts à passer à un exemple plus ciblé qui intègre des éléments de votre toute première configuration en écrivant un travail de service. Cela montrera comment vous pouvez passer des configurations de test en cours d'exécution aux scripts prêts pour la production.
Exemple détaillé: un travail de service
Couvert brièvement dans l'introduction, un travail de service implique la création de scripts de fichiers de configuration permettant aux processus de s'exécuter en arrière-plan. Nous allons configurer unbasic Node.js server à partir de zéro.
Si vous n’êtes pas familier avec Node, c’est un «environnement multiplate-forme pour les applications côté serveur et en réseau» (Wikipedia).
Node.js is a very lightweight package, although it isn’t installed by default on Ubuntu 14.04. Pour commencer, installez-le sur votre serveur cloud.
sudo apt-get install nodejs
Commençons maintenant avec le travail de service. Créez un nouveau fichier de configuration de travail dans/etc/init
appelénodetest.conf
. Nommer le fichier en référence à son objectif est essentiel. Vous pourrez donc reconnaître que ce travail de service concerne un test Node.js.
sudo nano /etc/init/nodetest.conf
Nous traiterons plus tard de l’application Node elle-même, car il est important de comprendre la configuration Upstart au préalable.
Tout d'abord. Commencez par saisir la description du poste et les lignes d’auteur pour définir la configuration.
description "Service for a test node.js server"
author "Your Name"
Nous souhaitons que cette application serveur basée sur un nœud démarre lorsque le serveur est opérationnel et s’arrête lorsqu’il s’arrête normalement. Pour cette raison, assurez-vous de spécifier les deux conditions:
start on filesystem or runlevel [2345]
stop on shutdown
Rappelez-vous les critères de niveau d'exécution de plus tôt? Combiné à l'événementfilesystem
, cela garantira que le travail se charge lorsque le serveur est opérationnel et fonctionne normalement.
Ce sont les bases, mais maintenant cela devient plus compliqué; nous allons utiliser lesstanzas mentionnés précédemment.
Comme il s’agit d’une application serveur, nous allons incorporer un élément de journalisation dans la configuration du travail. Étant donné que nous voulons enregistrer le démarrage et l'arrêt de l'application Node, nous utiliserons trois strophes différentes pour séparer nos actions de service:script
,pre-start script
etpre-stop script
.
Si vous pensez que cela vous semble familier, vous avez absolument raison. Le pré-démarrage et le pré-arrêt sont des états de travail, mais ils fonctionnent également en strophes. Cela signifie que différentes commandes peuvent être exécutées en fonction de l'état du travail.
Cependant, la première strophe à écrire est le script de travail lui-même. Cela obtiendra un ID de processus pour le serveur d'arrière-plan du nœud, puis exécutera le script d'application. Notez l'indentation des commandes à l'intérieur d'une strophe - c'est essentiel pour un formatage correct du point de vue syntaxique.
script
export HOME="/srv"
echo $$ > /var/run/nodetest.pid
exec /usr/bin/nodejs /srv/nodetest.js
end script
Node nécessite la définition d'une variable de répertoire personnel, d'où la raison pour laquelle/srv
est exporté dans la première ligne de la strophe. Ensuite,$$
est utilisé pour obtenir un ID de processus disponible et créer un fichier PID pour notre travail. Une fois que cela est prêt, l’application Node.js est chargée et nous écrirons plus tard.
Il est maintenant temps de se concentrer surpre-start
etpre-stop
, qui seront utilisés pour notre simple journalisation des applications. La date, ainsi qu'un message de démarrage ou d'arrêt seront ajoutés à un fichier journal pour notre travail:
pre-start script
echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script
Notez que la strophe pré-arrêt contient une autre ligne: la suppression du fichier PID dans le cadre de la procédure d'arrêt du serveur (ce que fait pré-arrêt).
pre-stop script
rm /var/run/nodetest.pid
echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script
C’est la configuration complète du travail Upstart qui est triée; voici à nouveau le tout pour référence:
description "Test node.js server"
author "Your Name"
start on filesystem or runlevel [2345]
stop on shutdown
script
export HOME="/srv"
echo $$ > /var/run/nodetest.pid
exec /usr/bin/nodejs /srv/nodetest.js
end script
pre-start script
echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script
pre-stop script
rm /var/run/nodetest.pid
echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script
Enregistrez et fermez le fichier.
Comme indiqué dans la ligneexec
, un script Node.js est exécuté à partir du serveur, créez donc un fichiernodetest.js
à l'emplacement souhaité (/srv/
est utilisé pour cet exemple):
sudo nano /srv/nodetest.js
Comme il s’agit d’un tutoriel Upstart, nous ne passerons pas trop de temps à réviser le code Node.js, bien que voici un aperçu de ce que ce script accomplira:
-
Demander et charger le module HTTP du noeud
-
Créer un serveur Web HTTP
-
Fournissez une réponse d'état 200 (OK) dans l'en-tête.
-
Écrivez «Hello World» comme sortie
-
Écoutez sur le port 8888
Voici le code nécessaire à l'exécution de l'application Node, que vous pouvez copier directement pour gagner du temps:
var http = require("http");
http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World");
response.end();
}).listen(8888);
Après avoir enregistré le fichier Node.js, la dernière chose à vérifier est de savoir si la syntaxe du travail Upstart est valide. Comme d'habitude, exécutez la commande de vérification de la configuration et vous devriez recevoir une confirmation en sortie:
init-checkconf /etc/init/nodetest.conf
File nodetest.conf: syntax ok
Vous avez la configuration de votre tâche, vérifié sa syntaxe et enregistré votre code Node.js. Tout est prêt à fonctionner, alors redémarrez votre Droplet, puis visitezhttp://IP:8888 ou le domaine associé.
Si vous rencontrez «Hello World» dans le coin supérieur gauche de la fenêtre, le travail de service Upstart a fonctionné!
Pour confirmer la journalisation basée sur l'état, lisez le fichier journal prédéfini et vous devriez voir une ligneStarting
horodatée. Arrêter le serveur ou arrêter manuellement la tâche de service écrirait une ligneStopping
dans le journal, que vous pouvez également vérifier si vous le souhaitez.
cat /var/log/nodetest.log
[Sun Aug 17 08:08:34 EDT 2014] Node Test Starting
[Sun Aug 17 08:13:03 EDT 2014] Node Test Stopping
Vous pouvez exécuter les fonctions standard de démarrage, d'arrêt, de redémarrage, etc. commandes de ce service et de tout autre travail Upstart similaire, avec une syntaxe semblable à celle-ci:
sudo service nodetest restart
Conclusion
Ce tutoriel ne fait qu'effleurer la surface du système d'événements Upstart. Vous avez lu le contexte de l'initialisation traditionnelle, découvert pourquoi la solution Open Source Upstart est un choix plus puissant et commencé à écrire vos propres tâches. Maintenant que vous connaissez les bases, les possibilités sont infinies.
Logo du site officiel d'Upstart, copyright designers originaux / Canonical Ltd.