Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Montaggio automatico di volumi NFS su un'istanza Linux

By Sayle MatthewsJul 20, 20208 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

Qualche settimana fa mi sono imbattuto in quello che, sul momento, mi era sembrato un caso d'uso piuttosto particolare durante la migrazione di numerose VM del mio home lab verso Kubernetes: il montaggio automatico di un volume NFS su una macchina Linux o un container Docker.

L'obiettivo era spostare lo storage di backing di InfluxDB, MySQL e Grafana sul mio NAS, anziché tenerlo sul filesystem locale del dispositivo su cui giravano. Uso NFS molto spesso nella mia rete per condividere file tra più dispositivi, grazie alla sua semplicità e all'ampio supporto.

Una volta completata la configurazione nel mio home lab, mi sono reso conto che, in realtà, non era affatto un caso d'uso così raro, vista la diffusione di NFS nel mondo. Lo si può sfruttare in un ambiente cloud per montare una share NFS on-premise da cui estrarre dati, per consentire ai processi di leggere o scrivere su una share NFS, per montare le home directory degli utenti da NFS e in molti altri scenari.

Il problema e la chiave per far funzionare il montaggio automatico

All'inizio ho seguito la strada che conoscevo meglio, ovvero fstab, che ho usato a fasi alterne negli ultimi decenni, ma ho subito scoperto che non montava la share NFS abbastanza in fretta perché i daemon dei database la rilevassero, generando problemi non da poco.

È a quel punto che mi sono imbattuto in un pacchetto Linux chiamato autofs. Farlo funzionare ha richiesto parecchia sperimentazione, perché molte guide online erano obsolete o tralasciavano dettagli fondamentali. Questa guida le spiegherà direttamente come procedere, così non dovrà passare mezza giornata a capirlo: il tempo è una risorsa di cui chi lavora nel settore non ha mai abbastanza.

In sostanza, autofs è semplicemente un daemon che monta e smonta automaticamente le share in background quando servono. A differenza di fstab, lo fa su richiesta: può quindi agire durante il boot senza preoccuparsi dell'ordine di avvio dei daemon.

Prerequisiti

Per semplicità, in questo esercizio darò per scontato che lei disponga già di un server NFS configurato sul proprio NAS o su una macchina Linux, oppure che stia utilizzando un servizio come Filestore di Google Cloud nel ruolo di NAS.

Si assicuri di avere a portata di mano i percorsi completi di ciascuna share NFS che desidera aggiungere. A volte non sono quelli che ci si aspetta, quindi conviene verificarli con attenzione: ad esempio, sui NAS Synology viene anteposto il volume, come in /volume1/share_path.

I comandi che riporto sono specifici per le distribuzioni derivate da Debian, quindi dovrebbero funzionare con Debian, Ubuntu, Kali e simili; in ogni sezione aggiungerò anche i comandi corrispondenti per le distribuzioni derivate da Red Hat, così chi utilizza RHEL o CentOS non dovrà tradurli da sé.

Tenga presente che in questa guida non tratterò le pratiche di sicurezza NFS, perché si tratta di un argomento molto vasto. Aggiungerebbe un livello di complessità tale da raddoppiare facilmente la lunghezza della guida, quindi lo ometto. È un aspetto tutt'altro che secondario, sia chiaro, ma non lo affronterò in questo articolo: le consiglio di approfondirlo per integrarlo in questa configurazione nel modo più adatto alla sua organizzazione, una volta completato il setup. Se desidera saperne di più, può partire da questo ottimo articolo di Red Hat che ne illustra le basi qui.

La procedura

  1. Installi il pacchetto autofs eseguendo i comandi corrispondenti alla sua distribuzione:

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

  2. Apra il file /etc/auto.master nel suo editor preferito.

  3. Scorra fino in fondo al file e aggiunga una riga come la seguente per ogni mount che desidera inserire, sostituendo la parola share in auto.share con il nome che preferisce per la share:

    /- /etc/auto.share -nosuid,noowners (Se preferisce, aggiunga pure più spazi tra i campi per una lettura più agevole; Medium non consente più di un singolo spazio in un blocco di codice all'interno di un elenco numerato.)

  4. A questo punto dovrà creare ognuno dei file a cui ha fatto riferimento nel passaggio precedente. Si troveranno tutti in /etc e avranno il formato auto.[share_name]. Quindi, per ogni riga auto.share aggiunta sopra, dovrà aprire quel file nel suo editor di testo preferito per crearlo. Una volta dentro, inserisca questa riga sostituendo il nome della share (la mia preferenza personale è di tenere tutto in /mnt, ma può modificarla a piacere), il nome del server e il percorso della share:

    /mnt/[share_name] -fstyle=nfs,user,nolock,nosuid,rw [server_name]:[share_path] (Anche qui, se preferisce, aggiunga più spazi per migliorare la leggibilità. Inoltre, se desidera che il mount sia in sola lettura anziché in lettura/scrittura, sostituisca rw con ro.)

  5. Una volta completata questa parte, è il momento di riavviare il servizio autofs con il seguente comando:

    Ubuntu: sudo service autofs restart

    Red Hat: sudo systemctl restart autofs

  6. Successivamente è opportuno verificare che il servizio si sia avviato correttamente e che non vi siano errori di sintassi, di rete o di altro tipo. Esegua il seguente comando per controllarne lo stato:

    Ubuntu: sudo service autofs status

    Red Hat: sudo systemctl status autofs

  7. Nell'output del passaggio precedente dovrebbe essere indicato che il servizio è in esecuzione e che tutto funziona correttamente. In caso contrario, l'output mostrerà le ultime righe dei log per aiutarla nel debug. Ho aggiunto anche una sezione finale con alcuni passaggi base di debug.

  8. A questo punto può eseguire un comando cd per raggiungere le directory indicate nei file sopra e accedere alle share. Non dovrà creare quelle directory: il daemon autofs le crea automaticamente.

  9. Un'ultima verifica consiste nell'eseguire il comando mount, che elencherà tutti i mount presenti sull'istanza. Un modo semplice per individuare quelli creati da autofs è eseguire mount | grep autofs.

  10. Da qui in poi i mount verranno caricati automaticamente sul sistema e ricollegati all'occorrenza.

  11. A questo punto le consiglio vivamente di approfondire la sicurezza NFS, mettere in sicurezza i suoi mount e adottare il metodo più adatto al suo caso d'uso.

Debug dei problemi più comuni

Durante questo percorso ho incontrato alcuni intoppi che voglio elencare, spiegando come li ho risolti.

Il primo è stato il daemon che restituiva ogni sorta di errore di mancata connessione a NFS. Il motivo era che Synology antepone il numero del volume al nome della share, cosa che all'epoca ignoravo. L'ho diagnosticato provando a montare manualmente la share NFS in una cartella della mia home directory con il comando mkdir tmp_mnt && sudo mount -v -r -o user,nolock,nosuid [server_name]:[share_path] tmp_mnt, che monta la share in una directory locale. In questo modo si ottiene un esito positivo oppure un errore che spiega cosa sta accadendo. Per smontarla, esegua il comando sudo umount tmp_mnt.

Un altro errore che ho riscontrato riguardava il server non raggiungibile tramite hostname. Si è rivelato un problema di DNS interno: l'hostname non veniva risolto. L'ho diagnosticato verificando di poter raggiungere la share tramite indirizzo IP e poi eseguendo nslookup hostname per appurare che non riusciva a tradurre l'indirizzo IP in hostname. Per questa verifica potrebbe essere necessario installare i pacchetti bind-utils (per Red Hat sudo yum -y install bind-utils) o dnsutils (per Debian sudo apt install -y dnsutils).

L'ultimo problema è specifico di Kubernetes. Da nessun pod del cluster riuscivo ad accedere ad alcun servizio esterno, comprese le share NFS, che si trovasse al di fuori del cluster. La causa era che il cluster non riusciva a risolvere l'hostname tramite DNS, perché non era a conoscenza del mio server DNS interno, collocato fuori dal cluster. La teoria alla base esula ampiamente dagli scopi di questa guida, quindi mi limiterò a fornire una soluzione e un link per approfondire.

  1. Modifichi la configmap di CoreDNS con il seguente comando: kubectl edit configmap coredns -n kube-system.
  2. Si aprirà un editor di testo con il file yaml di CoreDNS; al suo interno c'è una sezione chiamata Corefile con un blocco yaml che inizia con .:53.
  3. Determini il suo dominio interno. Sarà definito dalla configurazione del suo server DNS interno; se non ne ha uno, usi semplicemente local.
  4. Determini l'indirizzo IP del suo server DNS. Se non ne ha uno, con ogni probabilità sarà l'indirizzo IP del suo router.
  5. Aggiunga il seguente blocco di codice, inserendo i suoi dati, su una nuova riga al di sotto (si assicuri di usare spazi e non tab!), salvi ed esca dall'editor:
[domain_name]:53 {
                errors
                cache 30
                forward . [dns_server]
}

Per maggiori informazioni sul perché funzioni, può consultare questa pagina.