Comment configurer un service Linux pour qu’il démarre automatiquement après un crash ou un redémarrage - Partie 1: exemples pratiques

Ce didacticiel explique comment configurer les services système pour qu'ils redémarrent automatiquement après un crash ou un redémarrage du serveur.

L'exemple utilise MySQL, mais vous pouvez appliquer ces principes à d'autres services s'exécutant sur votre serveur, tels que Nginx, Apache ou votre propre application.

Nous couvrons les trois systèmes init les plus courants dans ce tutoriel, alors assurez-vous de suivre celui de votre distribution. (De nombreuses distributions offrent plusieurs options ou permettent l'installation d'un autre système init.)

Vous pouvez également consulterPart 2, the reference article.

Votre système Linux ou Unix en cours d'exécution aura un certain nombre de processus en arrière-plan exécutés à tout moment. Ces processus, également appelésservices oudaemons, peuvent être natifs du système d'exploitation ou s'exécuter dans le cadre d'une application.

Exemples de services du système d'exploitation:

Exemples de démons d'application:

Ces services sont censés fonctionner en permanence pour garantir que nos sites Web, notre courrier, nos bases de données et nos autres applications sont toujours actifs.

En tant qu'administrateurs, nous souhaitons que nos services Linux:

Pourtant, parfois, ces services tombent en panne, rendant nos sites Web ou nos applications indisponibles.

Un redémarrage peut se produire pour plusieurs raisons: il peut s'agir d'un redémarrage planifié, de la dernière étape d'une mise à jour de correctif ou du résultat d'un comportement inattendu du système. Un blocage correspond à ce qui se produit lorsque le processus s’arrête de manière inattendue ou ne répond plus aux demandes des utilisateurs ou des applications.

Le but de cet article est de remettre en marche vos services, même après un crash ou un redémarrage.

Bien qu’il n’y ait pas de substitut à la surveillance et aux alertes continues, les services Linux peuvent être largement auto-réparés en modifiant la façon dont ils sont gérés par les démons de gestion des services, également appelés systèmesinit.

Il n'y a pas qu'un seul moyen de faire cela: tout dépend de la distribution Linux particulière et du démon de gestion de services qui l'accompagne. Les systèmes init par défaut de nombreux systèmes d'exploitation courants sont présentés dans l'introduction ci-dessus.

[.Remarque]##

Nous entrerons plus en détail surrunlevels dansPart 2, mais pour cet article, cela aidera à comprendre que chaque système Linux a quatre niveaux d'exécution de base en commun:

En général, les niveaux d'exécution 2, 3 et 4 signifient les états où Linux a démarré en mode texte multi-utilisateurs, activé par le réseau.

Lorsque nous activons le démarrage automatique d’un service, nous l’ajoutons à un niveau d'exécution.

Dans ce didacticiel en deux parties, nous verrons comment configurer un service Linux pour qu'il démarre automatiquement lorsque le système redémarre ou se bloque.

Cette tranche de la série, Partie 1, sera une analyse rapide de la procédure à suivre dans trois modes initiaux (initialisation) différents:

DansPart 2, nous expliquerons pourquoi nous avons exécuté les commandes et comment elles fonctionnent dans les coulisses. Nous parlerons des scripts de démarrage, des fichiers importants et des paramètres de configuration pour chaque méthode init. Une grande partie de la discussion de la partie 2 peut sembler théorique, mais servira de référence utile pour comprendre les bases.

La première partie ne couvrira que les aspects pratiques de la configuration du redémarrage automatique.

Pour suivre ce didacticiel, vous devrez créer un certain nombre de gouttelettes DigitalOcean (ou créer vos propres serveurs Linux), chacune avec au moins1 GB de RAM. Nous n'entrerons pas dans les détails de la création d'un Droplet, mais vous pouvez trouver plus d'informationshere.

Nous allons utiliser différentes distributions pour nos exemples.

Nous vous conseillons de conserver les droplets après avoir suivi la partie 1 de ce tutoriel, car nous utiliserons la même configuration pourPart 2.

You should not run any commands, queries, or configurations from this tutorial on a production Linux server. Nous allons interrompre les services dans le cadre des tests, et vous ne voudriez pas que votre serveur en direct soit en panne.

Commençons notre discussion avec System V init, le plus ancien système init décrit ici.

Avec System V, la plupart des applications standard que vous pouvez installer, telles que Nginx ou MySQL, serontstart after reboot par défaut, maisNOT start after a crash par défaut. Ils viendront déjà avec leurs propres scripts d'initialisation dans/etc/init.d.

Pour les applications personnalisées, vous devrez créer vos propres scripts d’initialisation et permettre aux services de démarrer automatiquement par vous-même.

La création de votre propre script init dépasse le cadre de cet article, mais vous pouvez vous référer à des exemples de scripts existants pour vous aider à créer le vôtre, si vous en avez besoin. System V utilise Bash pour les scripts d'initialisation.

Cette section est une référence rapide pour vous assurer que votre service est configuré pour démarrer automatiquement.

Liste de contrôle de la configuration

Notez que vous devriez également voir les liens des répertoires/etc/rc3.d à/etc/rc5.d; apprenez-en plus sur ces chiffres lorsque nous discutons derunlevels.

/etc/inittab

Test

Pour tester leur fonctionnement, vous pouvez:

[[step-1 -—- connection-to-your-debian-6-droplet]] == Étape 1 - Connexion à votre droplet Debian 6

Nous allons maintenant passer à travers un exemple pratique, en utilisant MySQL.

Depuis le panneau de configuration de DigitalOcean, créez une goutteDebian 6.0 x64 avec 1 Go de RAM.

Une fois le Droplet initialisé, utilisez SSH pour vous connecter au serveur (les utilisateurs Windows peuvent se connecter à l’aide d’un outil tel que PuTTY).

Dans les instructions suivantes, nous supposons que votre compte dispose des privilèges sudo.

[[step-2 -—- Installing-mysql]] == Étape 2 - Installation de MySQL

Nous utiliserons MySQL comme service de test. Exécutez la commande suivante pour installer le serveur MySQL:

Un écran graphique semblable à celui présenté ci-dessous apparaîtra pour vous demander un nouveau mot de passe root. Fournir que:

Répétez le mot de passe à l'invite suivante:

Appuyez surENTER pour confirmer.

Les lignes défileront au fur et à mesure que MySQL sera installé. Une fois l'installation terminée, exécutez la commande suivante pour renforcer votre installation:

Cela vous demandera le mot de passe root actuel. Appuyez surN pour conserver le même mot de passe. Ensuite, appuyez surY pour supprimer l'utilisateur anonyme, désactiver la connexion root à distance et supprimer la base de données de test. Enfin, appuyez surY pour recharger les tables de privilèges.

Notre installation de MySQL devrait maintenant être complète.

Pour vérifier si le service est en cours d'exécution, exécutez cette commande:

La sortie affichera quelques lignes d’informations, dont l’une indiquant la durée d’exécution du service MySQL (durée de disponibilité).

[[step-3 -—- configuration-mysql-to-auto-start-after-reboot]] == Étape 3 - Configuration de MySQL pour démarrer automatiquement après le redémarrage

Par défaut, MySQL est déjà configuré pour démarrer après un redémarrage.

Vous devriez voir ce lien symbolique vers le script init de MySQL dans le répertoire/etc/rc2.d. Notez que vous devriezNOT essayer de créer ces liens symboliques manuellement; utilisez la commandeupdate-rc.d pour activer et désactiver les services.

Tant qu'il y a un scriptS sous le répertoire de niveau d'exécution par défaut pour le service, init démarrera le service au démarrage du serveur.

Donc, MySQL devrait être en cours d'exécution. Il est maintenant temps de vérifier qu’il démarrera automatiquement au démarrage. Redémarrez la machine avec cette commande:

Une fois le serveur en ligne, connectez-vous avec SSH.

Exécutez à nouveau la commandeservice mysql status. Encore une fois, le service sera affiché comme en cours d'exécution. Cela signifie que le service démarre automatiquement au démarrage du système d'exploitation.

Tous les services ne seront pas comme ça, cependant. Dans ces cas, nous devrons configurer manuellement les services pour un redémarrage automatique. Pour Debian, la commandeupdate-rc.d vous permet d'ajouter (ou de supprimer) des services à démarrer automatiquement au démarrage.

Désactivons le service MySQL et voyons comment le réactiver pour un démarrage automatique. Lançons cette commande pour désactiver MySQL:

Pour tester, redémarrez le serveur.

Connectez-vous à votre serveur avec SSH.

Essayez de vous connecter à MySQL en utilisant l’outil client MySQL:

Vous recevrez ce message:

Réactivez le service:

La sortie sera:

Si vous exécutez un système CentOS avec System V, les commandes utiliserontchkconfig plutôt queupdate-rc.d.

Notez que l'activation du démarrage automatique d'un service au démarrage ne le lance pas automatiquement s'il est arrêté. Pour démarrer MySQL, exécutez cette commande:

[[step-4 -—- configuration-mysql-to-auto-start-after-crash]] == Étape 4 - Configuration de MySQL pour démarrer automatiquement après un crash

Maintenant que notre service fonctionne à nouveau, voyons s’il démarre automatiquement après un crash. Avec System V, il seraNOT apparaître automatiquement par défaut.

Nous imiterons un crash en tuant le processus brusquement. Recherchez son ID de processus en exécutant la commande suivante:

Le résultat sera similaire à ceci:

Les principaux processus qui exécutent MySQL sontmysqld_safe etmysqld. mysqld_safe est le processus parent demysqld.

Dans notre exemple ici, nous pouvons voir qu'ils ont les ID de processus 1167 et 1292 respectivement. Leurs numéros de processus sont surlignés en rouge ci-dessus.

Émulons un crash avec une commandekill -9. Assurez-vous d'utiliser vos propres ID de processus:

Vérifier l'état du service:

La sortie montrera que le service est arrêté:

Maintenant que notre service est tombé en panne, comment pouvons-nous le régler? Bien sûr, nous pouvons le redémarrer, mais ce serait un processus manuel; nous voulons que le redémarrage soit automatique. Pour que MySQL redémarre automatiquement après un crash, nous devons éditer le fichier/etc/inittab.

Nous parlerons plus en détail du fichier/etc/inittab dans la partie 2, mais pour l’instant, comprenons que c’est le premier fichier que l ’init System V lit lors du démarrage.

Entre autres choses,/etc/inittab décide du comportement d'un processus en cas de panne. Pour certains processus, il est prévu de rétablir le service. Nous devons nous assurer que MySQL fait partie de ces services. Commençons par en faire une copie:

Attention: soyez extrêmement prudent lors de l'édition du fichier/etc/inittab. Si vous faites une erreur dans vos commandes ou supprimez une configuration existante, il se peut que le système ne démarre pas lorsque vous le redémarrez.

Ouvrez/etc/inittab avec un éditeur de texte:

A la fin du fichier, ajoutez cette ligne:

/etc/inittab

Alors qu'est-ce qu'on fait ici?

Eh bien, nous mettons une commande dans le fichier/etc/inittab àrespawn lemysqld_safe process quand il plante. Il comporte quatre champs, séparés l'un de l'autre par un signe deux-points (:).

Nous reviendrons sur le fichier/etc/inittab plus en détail dans la partie 2, et verrons comment il aide à démarrer automatiquement MySQL après un crash. Pour l'instant, sauvegardez le fichier et quittez l'éditeur.

Redémarrez le service:

Redémarrez le serveur pour que le changement prenne effet:

Maintenant, répétez les commandes pour localiser les numéros de processus, tuez les processus et vérifiez à nouveau l'état, en commençant parps -ef | grep mysql.

Wait for five minutes environ, puis exécutez la commande:

Vous devriez voir que cette fois, MySQL a démarré automatiquement après le crash.

C'est ça! MySQL va maintenant démarrer automatiquement après un crash du service ou un redémarrage du système.

Upstart est une autre méthode init, introduite pour la première fois dans Ubuntu 6. Il est devenu la valeur par défaut dans Ubuntu 9.10 et a ensuite été adopté dans RHEL 6 et ses dérivés. Le système d’exploitation Google de Google utilise également Upstart.

Bien que la version LTS actuelle d’Ubuntu fonctionne bien (la version 14.04 au moment de la rédaction), elle est supprimée partout au profit de systemd, que nous couvrirons dans la dernière section.

Upstart est meilleur que System V pour la gestion des services système, et il est également facile à comprendre. Cependant, nous ne plongerons pas profondément dans Upstart dans cette partie du tutoriel; il y a unvery good tutorial on Upstart dans la communauté DigitalOcean.

Aujourd'hui, nous allons principalement nous concentrer sur les fichiers de configuration Upstart et voir comment les utiliser pour démarrer automatiquement des services.

Upstart utilise des fichiers de configuration pour contrôler les services. Les fichiers se trouvent dans le répertoire/etc/init. Les fichiers ont un contenu en texte brut avec des sections faciles à lire appeléesstanzas. Chaque strophe décrit un aspect différent du service et son comportement.

Par défaut, la plupart des applications standard que vous pouvez installer, telles que Nginx ou MySQL, serontstart after reboot et aussistart after a crash par défaut, vous n'avez donc rien à faire pour que cela fonctionne. Ils viendront déjà avec leurs propres scripts d'initialisation dans/etc/init.

Pour les applications personnalisées, vous devrez le configurer vous-même. Pour savoir comment créer votre propre script Upstart personnalisé, lisez lesintroductory Upstart tutorial référencés précédemment.

Cette section est une référence rapide pour vous assurer que votre service est configuré pour démarrer automatiquement.

Liste de contrôle de la configuration

(Il n'y en aurait qu'un si vous ou un autre administrateur en aviez un auparavant)

Test

Pour tester leur fonctionnement, vous pouvez:

[[step-1 -—- connection-to-your-ubuntu-14-04-droplet]] == Étape 1 - Connexion à votre droplet Ubuntu 14.04

Nous allons utiliser un serveur Ubuntu 14.04, exécutant MySQL, pour démontrer Upstart.

Créez un droplet avec 1 Go de RAM et choisissezUbuntu 14.04 x64 comme image de base.

Connectez-vous au serveur avec SSH (les utilisateurs Windows peuvent se connecter en utilisant un outil comme PuTTy).

Dans les instructions suivantes, nous supposons que votre compte dispose des privilèges sudo.

[[step-2 -—- Installing-mysql]] == Étape 2 - Installation de MySQL

Nous allons maintenant installer MySQL.

Exécutez la commande suivante pour mettre à jour la liste des packages:

Installez le serveur MySQL:

Créez un nouveau mot de passe root pour MySQL et confirmez-le lorsque vous y êtes invité.

Une fois l'installation terminée, exécutez la commandemysql_secure_installation:

Donnez les mêmes réponses aux invites que lors de l’installation dans Debian (voir la section précédente).

[[step-3 -—- configuration-mysql-to-auto-start-after-reboot]] == Étape 3 - Configuration de MySQL pour démarrer automatiquement après le redémarrage

Par défaut, MySQL démarrera automatiquement après un redémarrage. Il est utile d’examiner sa configuration pour pouvoir configurer vos propres services de cette façon.

Tout d’abord, vérifions si le processus du serveur MySQL est en cours d’exécution:

Vous devriez voir la sortie comme ceci:

Redémarrez le serveur:

Lorsque le serveur revient en ligne, utilisez SSH pour vous reconnecter.

Vérifiez le statut de MySQL:

La sortie montrera que MySQL a démarré automatiquement. Nous n’avons donc rien à faire ici pour activer le service.

Gardez à l'esprit que cela peut ne pas être le cas pour d'autres démons d'application où vous devez activer manuellement le service en créant votre propre fichier Upstart dans le répertoire/etc/init/.

En outre, comment Upstart sait-il que MySQL devrait démarrer automatiquement au redémarrage?

Jetons un coup d’œil au fichier d’initialisation Upstart de MySQL. Ouvrez le fichier/etc/init/mysql.conf dans un éditeur de texte:

Un fichier Upstart n'est pas un script shell comme nous l'avons vu sur notre machine Debian.

Le fichier de configuration init pour MySQL comportera des blocs de script pour les événements pré-démarrés et post-démarrés. Ces blocs de code indiquent au système Upstart ce qu’il faut exécuter lorsque le processus mysqld est en cours ou a déjà été lancé.

Examinons de plus près les dix premières lignes du fichier:

/etc/init/mysql.conf

Nous pouvons voir que MySQL est supposé démarrer aux niveaux de fonctionnement 2, 3, 4 et 5, et non aux niveaux de fonctionnement 0, 1 et 6.

C'est ici que nous définissons le comportement de démarrage du service pour un démon Upstart. Contrairement à System V où nous avons utilisé les commandesupdate-rc.d ouchkconfig, nous utilisons les fichiers de configuration de service dans Upstart. Tout ce que nous avons à faire est d'ajouter / modifier la strophestart. Dans la partie 2, nous allons jouer avec ce fichier et voir comment l'activation et la désactivation du service MySQL affectent ce fichier et inversement.

Les directivesrespawn redémarrent le service après un plantage, nous en parlerons donc à l'étape suivante.

[[step-4 -—- configuration-mysql-to-auto-start-after-crash]] == Étape 4 - Configuration de MySQL pour démarrer automatiquement après un crash

Vous devriez toujours avoir/etc/init/mysql.conf ouvert.

La directiverespawn est explicite: MySQL démarrera s'il plante. Ceci est déjà activé par défaut.

La directive qui suit est plus intéressante: la directiverespawn limit stipule combien de fois Linux tentera de redémarrer le service en panne dans un intervalle spécifié en secondes. Dans ce cas, le premier argument (2) est le nombre d'essais et le second (5) est l'intervalle. Si le service ne démarre pas (respawn) correctement dans les limites de ce seuil, il sera maintenu à l'état arrêté. Ce comportement sain par défaut, car si un service tombe en panne de manière continue, il est préférable de le désactiver que d’affecter la stabilité de l’ensemble du système.

Pour l'instant, quittez l'éditeur de texte sans apporter de modifications.

Comme nous venons de le voir, par défaut, MySQL est également configuré pour revenir automatiquement après un crash.

Pour tester cela, vérifions le PID du service:

Le nouveau PID (après le redémarrage) de notre système devrait ressembler à ceci:

Notez l'ID de processus pour votre scénario de test. Ensuite, émulez un crash en tuant le processus avec une commandekill -9, en utilisant votre propre numéro de processus:

Vérifiez l'état de MySQL maintenant. Il devrait fonctionner (immédiatement ou dans quelques secondes) avec un nouveau PID:

Dans notre cas, le nouveau PID est 1552:

Si vous le souhaitez, vous pouvez le tuer à nouveau. Il reviendra à chaque fois:

Cela se produit à cause de la directiverespawn dans le fichiermysql.conf.

/etc/init/mysql.conf

MySQL offre la possibilité de redémarrer après un blocage par défaut, mais pour d'autres services, vous devrez peut-être ajouter cette directive manuellement dans le fichier Upstart. Encore une fois, dans la deuxième partie, nous verrons comment modifier le comportement en cas d’incident à partir du fichier de configuration.

systemd est unsystem and service manager pour Linux qui est devenu le démon d'initialisation de facto pour la plupart des nouvelles distributions Linux.

D'abord implémenté dans Fedora, systemd est maintenant livré avec RHEL 7 et ses dérivés tels que CentOS 7. Ubuntu 15.04 est également livré avec systemd natif. D'autres distributions ont soit incorporé systemd, soit annoncé prochainement.

systemd est rétro-compatible avec les commandes et les scripts d'initialisation System V.

Cela signifie que tout service System V fonctionnera également sous systemd. La plupart des commandes administratives Upstart et System V ont été modifiées pour fonctionner sous systemd. C’est pourquoi on l’appelle souventdrop-in replacement pour l’initialisation de System V.

Avec systemd, la plupart des applications standard que vous pouvez installer, telles que Nginx ou MySQL, serontstart after reboot et aussistart after a crash par défaut, vous n'avez donc rien à faire pour que cela fonctionne. Ils viendront déjà avec leurs propres scripts d'initialisation dans/etc/systemd/system.

Pour les applications personnalisées, vous devrez créer vos propres scripts d’initialisation et permettre aux services de démarrer automatiquement par vous-même. Nous n'entrerons pas dans les détails de ce qui entre dans un script d'initialisation personnalisé en détail ici, mais vous pouvez en savoir plus sur systemd dans ceintroductory systemd article.

Cette section est une référence rapide pour vous assurer que votre service est configuré pour démarrer automatiquement.

Liste de contrôle de la configuration

Cela activera le démarrage automatique après un redémarrage.

Test

Pour tester leur fonctionnement, vous pouvez:

[[step-1 -—- connection-to-your-centos-7-droplet]] == Étape 1 - Connexion à votre Droplet CentOS 7

Nous utiliserons CentOS 7 et MySQL pour vous montrer comment configurer les services systemd.

Créez un droplet avec 1 Go de RAM et choisissezCentOS 7 x64 comme image de base.

Utilisez SSH pour vous connecter au serveur (les utilisateurs Windows peuvent se connecter en utilisant un outil tel que PuTTy).

Nous supposons que vous utilisez un compte avec les privilèges sudo.

[[step-2 -—- Installing-mysql]] == Étape 2 - Installation de MySQL

Exécutez les commandes suivantes pour télécharger et installer le référentiel du serveur MySQL Community:

Installez le serveur MySQL:

Une fois l'installation terminée, démarrez le service mysqld.

(Notez que ce n’est pas la même chose que lorsque nous avons installé MySQL sous Debian et Ubuntu. Dans les autres distributions, MySQL a démarré automatiquement.)

De plus, nous utilisons une nouvelle commande systemd appeléesystemctl pour contrôler le service:

Ensuite, exécutez la commandemysql_secure_installation.

Dans ce cas, le mot de passe root de MySQL sera vide. Vous devez donc choisir de créer un nouveau mot de passe. Répondez aux mêmes invites que lors de l’installation sous Debian ou Ubuntu (voir la section précédente de Debian pour plus de détails).

[[step-3 -—- configuration-mysql-to-auto-start-after-reboot]] == Étape 3 - Configuration de MySQL pour démarrer automatiquement après le redémarrage

Par défaut, MySQL est configuré pour démarrer automatiquement après un redémarrage. Voyons comment cela fonctionne.

Pour vérifier si le démonmysqld a été configuré pour démarrer automatiquement au démarrage, exécutez la commandesystemctl avec l'optionis-enabled:

Le résultat sera:

Réinitialisons la machine:

Lorsque le serveur est rétabli, connectez-vous avec SSH.

Exécutez la commande suivante pour vérifier l’état du service:

La sortie montrera que le service est en cours d'exécution:

Pour désactiver le service, exécutez la commande suivante:

Cela n'arrêtera pas le service, mais le désactivera. En fait, la sortie indique que les liens symboliques ont été supprimés:

Si vous le souhaitez, vous pouvez redémarrer le serveur et tester à nouveau pour voir si le serveur MySQL est en cours de fonctionnement (ce ne sera pas le cas).

Ou exécutez à nouveausystemctl is-enabled; nous devrions obtenir une réponse dedisabled:

Activez à nouveau le service:

La sortie montrera les liens symboliques recréés:

Votre service démarrera automatiquement après un redémarrage.

[[step-4 -—- configuration-mysql-to-auto-start-after-crash]] == Étape 4 - Configuration de MySQL pour démarrer automatiquement après un crash

Nous allons maintenant voir comment MySQL est configuré pour démarrer automatiquement après un crash.

Tout d'abord, ouvrez le fichier d'unité demysqld.service dans un éditeur (rappelez-vous que les services systemd utilisent des fichiers d'unité pour la configuration):

A la fin du fichier, il y a une directive pour redémarrer:

/etc/systemd/system/multi-user.target.wants/mysqld.service

La valeur du paramètreRestart est définie suralways. Cela signifie que le service MySQL va redémarrer pour des codes de sortie ou des délais d'attente propres ou impurs.

C’est là qu’un redémarrage automatique est défini dans systemd.

Tout comme la directiverespawn dans Upstart, le paramètreRestart dans systemd définit comment le service doit se comporter en cas de panne.

Tous les services systemd n'ont pas cette fonctionnalité activée par défaut; pour qu'un service apparaisse après un crash, il suffit d'ajouter cette directive supplémentaire dans la section[Service] du fichier d'unité de service. Si l'en-tête de section n'existe pas, nous devons également ajouter l'en-tête[Service].

Pour émuler un plantage, quittez d'abord l'éditeur, puis vérifiez l'ID de processus MySQL:

Tuez ce processus avec un signalkill -9. Dans notre cas, le PID principal est 661; remplacez le PID par le vôtre:

Vérifiez le statut:

La sortie montrera que MySQL a redémarré avec un nouveau PID (dans notre cas, le nouveau Process ID est 11217):

Vous voyez donc que le service est activé même après un crash.

Dans cette première partie du didacticiel, nous avons vu comment les services System V, Upstart et systemd peuvent être configurés pour un démarrage automatique après un redémarrage ou un blocage.

Nous avons également vu les fichiers, les paramètres de configuration et les commandes qui contrôlent ce comportement.

C'était plus une introduction pratique. Nous aborderons les concepts et les bases plus en détail dans la prochaine tranche de la série.

Ne supprimez pas encore les Droplets - laissez-les fonctionner, car nous y reviendrons dansthe next part.