Monter automatiquement des volumes NFS sur une instance Linux

J'ai d'abord opté pour la solution que je connaissais le mieux : fstab, que j'utilise occasionnellement depuis plusieurs décennies. Mais j'ai très vite constaté qu'il ne montait pas le volume NFS assez rapidement pour que les daemons de base de données puissent le détecter, ce qui causait de gros problèmes.

C'est alors que j'ai découvert un paquet Linux nommé autofs. Le faire fonctionner a demandé pas mal de tâtonnements, car de nombreux guides en ligne étaient obsolètes ou passaient à côté de détails essentiels. Ce guide va droit au but pour vous éviter d'y passer une demi-journée — car le temps est une denrée rare pour ceux d'entre nous qui travaillent dans ce secteur.

Au fond, autofs n'est qu'un daemon qui monte et démonte automatiquement les partages selon les besoins, en arrière-plan. Contrairement à fstab, il agit à la demande, ce qui lui permet d'intervenir au démarrage sans se soucier de l'ordre de lancement des daemons.

Pour simplifier, je pars du principe dans cet exercice que vous disposez déjà d'un serveur NFS configuré sur votre NAS ou votre machine Linux, ou que vous utilisez un service tel que Filestore de Google Cloud comme NAS.

Assurez-vous d'avoir les chemins complets de chaque partage NFS à ajouter. Ils ne sont pas toujours ceux auxquels on s'attend : vérifiez-les bien. Sur les NAS Synology, par exemple, ils sont préfixés par le numéro de volume, du type /volume1/share_path.

Côté commandes, je vais privilégier les distributions dérivées de Debian. Tout fonctionnera donc avec Debian, Ubuntu, Kali, etc. J'indiquerai dans chaque section la commande équivalente pour les distributions dérivées de Red Hat, afin que ceux qui utilisent RHEL ou CentOS n'aient pas à faire la traduction.

À noter : je n'aborderai pas dans ce guide les bonnes pratiques de sécurité NFS, qui constituent un sujet très vaste. Cela ajouterait un niveau de complexité susceptible de doubler la longueur du guide, je l'écarte donc volontairement. C'est pourtant TRÈS important, ne vous méprenez pas, mais ce n'est pas l'objet de cet article. Je vous recommande de vous documenter pour intégrer la sécurité dans cette configuration de la manière la mieux adaptée à votre organisation. Pour aller plus loin, je vous conseille de commencer par cet excellent article de Red Hat qui en présente les bases ici.

1. Installez le paquet autofs avec la commande adaptée à votre distribution :

   Ubuntu : sudo apt -y install nfs-common autofs Red Hat : sudo yum -y install nfs-common autofs

2. Ouvrez le fichier /etc/auto.master dans votre éditeur favori.

3. Rendez-vous à la fin du fichier et ajoutez une ligne comme celle-ci pour chaque montage à ajouter, en remplaçant le mot share dans auto.share par le nom de votre choix :

   /- /etc/auto.share -nosuid,noowners (Si vous le souhaitez, ajoutez davantage d'espaces pour faciliter la lecture. Medium n'autorise pas plus d'un espace dans un bloc de code au sein d'une liste numérotée.)

4. Vous devrez ensuite créer chacun des fichiers référencés à l'étape précédente. Ils se trouveront tous dans /etc et suivront le format auto.[share_name]. Pour chaque ligne auto.share ajoutée plus haut, ouvrez donc le fichier correspondant dans votre éditeur favori pour le créer. Une fois dedans, ajoutez la ligne suivante en remplaçant le nom du partage (personnellement, je préfère tout placer dans /mnt, mais à vous de l'ajuster), le nom du serveur et le chemin du partage :

   /mnt/[share_name] -fstype=nfs,user,nolock,nosuid,rw [server_name]:[share_path] (Là encore, ajoutez plus d'espaces si vous le souhaitez pour la lisibilité. Et si vous voulez un montage en lecture seule plutôt qu'en lecture-écriture, remplacez rw par ro.)

5. Une fois cette étape terminée, redémarrez le service autofs avec la commande suivante :

   Ubuntu : sudo service autofs restart

   Red Hat : sudo systemctl restart autofs

6. Vérifiez ensuite que le service a bien démarré et qu'aucune erreur de syntaxe, de réseau ou autre ne s'est produite au lancement. Exécutez la commande suivante pour consulter le statut :

   Ubuntu : sudo service autofs status

   Red Hat : sudo systemctl status autofs

7. Dans la sortie de l'étape précédente, le statut doit indiquer que le service est en cours d'exécution et que tout fonctionne. Sinon, la sortie affichera les dernières lignes des logs pour vous aider à diagnostiquer le problème. J'ai également ajouté une section à la fin avec quelques étapes de debug de base.

8. À ce stade, vous pouvez utiliser une commande cd pour atteindre les répertoires renseignés dans les fichiers ci-dessus et accéder aux partages. À noter : inutile de créer ces répertoires, le daemon autofs s'en charge automatiquement.

9. Une dernière vérification possible consiste à exécuter la commande mount, qui listera tous les montages présents sur l'instance. Pour repérer facilement ceux créés par autofs, lancez mount | grep autofs.

10. À partir de là, les montages se chargeront automatiquement sur le système et se rattacheront en cas de besoin.

11. À ce stade, je vous recommande vivement de vous pencher sur la sécurité NFS et de sécuriser vos montages, puis de mettre en place la méthode la mieux adaptée à votre usage.

Au cours de mon apprentissage, j'ai rencontré quelques difficultés que je souhaite lister, ainsi que la manière dont je les ai diagnostiquées.

La première : le daemon générait toutes sortes d'erreurs liées à la connexion NFS. Il s'est avéré que Synology préfixe le nom du partage par le numéro de volume, ce que j'ignorais à l'époque. Je l'ai diagnostiqué en essayant de monter manuellement le partage NFS dans un dossier de mon répertoire personnel, à l'aide de la commande suivante : mkdir tmp_mnt && sudo mount -v -r -o user,nolock,nosuid [server_name]:[share_path] tmp_mnt, qui monte le partage dans un répertoire local. Cette commande renvoie soit un succès, soit une erreur indiquant ce qui se passe. Pour démonter, exécutez la commande suivante : sudo umount tmp_mnt.

Une autre erreur rencontrée concernait l'inaccessibilité du serveur via son hostname. Le problème venait d'un souci de DNS interne qui ne résolvait pas le hostname. Je l'ai diagnostiqué en parvenant à atteindre le partage via son adresse IP, puis en exécutant nslookup hostname pour confirmer qu'il était impossible de traduire l'adresse IP en hostname. À noter : pour cela, vous aurez peut-être besoin d'installer les paquets bind-utils (pour Red Hat sudo yum -y install bind-utils) ou dnsutils (pour Debian sudo apt install -y dnsutils).

Le dernier problème rencontré est spécifique à Kubernetes. Depuis n'importe quel pod du cluster, je n'arrivais à accéder à aucun service externe situé hors du cluster, y compris aux partages NFS. La cause : le pod ne parvenait pas à résoudre le hostname via le DNS, car le cluster ne connaissait pas mon serveur DNS interne situé en dehors du cluster. La théorie derrière tout cela dépasse largement le cadre de ce guide ; je me contenterai donc de fournir une solution et un lien pour aller plus loin.

1. Éditez le configmap CoreDNS avec la commande suivante : kubectl edit configmap coredns -n kube-system.
2. Cela ouvre un éditeur de texte avec le fichier yaml de CoreDNS. À l'intérieur, vous trouverez une section appelée Corefile contenant un bloc yaml qui commence par .:53.
3. Identifiez votre domaine interne. Il dépend de la configuration de votre serveur DNS interne ; si vous n'en avez pas, utilisez simplement local.
4. Identifiez l'adresse IP de votre serveur DNS. Si vous n'en avez pas, il s'agira très probablement de l'adresse IP de votre routeur.
5. Ajoutez le bloc de code suivant, en remplaçant par vos informations, en dessous sur une nouvelle ligne (utilisez bien des espaces et non des tabulations !), enregistrez et quittez l'éditeur :

[domain_name]:53 {
                errors
                cache 30
                forward . [dns_server]
}

Pour en savoir plus sur le fonctionnement de cette solution, c'est ici.