Montaje automático de volúmenes NFS en una instancia Linux

Primero fui por el camino que mejor conocía: usar fstab, que vengo usando de forma intermitente desde hace décadas. Pero descubrí muy rápido que no montaba el recurso NFS con la velocidad suficiente para que los daemons de las bases de datos lo detectaran, y eso me estaba causando problemas serios.

Fue ahí cuando me crucé con un paquete de Linux llamado autofs. Ponerlo en marcha me costó bastante experimentación, porque muchas guías en línea estaban desactualizadas o les faltaban detalles clave. Esta guía te muestra directo cómo hacerlo para que no pierdas medio día averiguándolo, porque el tiempo es algo que a quienes trabajamos en esta industria siempre nos hace falta.

En esencia, autofs es un daemon que monta y desmonta recursos de forma automática, según se necesiten, en segundo plano. A diferencia de fstab, lo hace bajo demanda, así que puede hacerlo durante el arranque sin tener que preocuparse por el orden en que inician los daemons.

Para que sea sencillo, en este ejercicio voy a asumir que ya tienes un servidor NFS configurado en tu NAS o en una máquina Linux, o que estás usando algo como Filestore de Google Cloud para que haga las veces de NAS.

Asegúrate de tener las rutas completas de cada recurso NFS que quieras agregar. A veces no son las que esperas, así que verifícalas dos veces. Por ejemplo, en los NAS de Synology llevan el volumen como prefijo, algo así como /volume1/share_path.

También voy a usar comandos específicos para distribuciones derivadas de Debian, así que esto debería funcionar con Debian, Ubuntu, Kali, etc. Y en cada sección voy a agregar el comando equivalente para distribuciones derivadas de Red Hat, para que quienes corran RHEL o CentOS no tengan que andar traduciendo.

Ten en cuenta que en esta guía no voy a cubrir prácticas de seguridad de NFS, ya que es un tema muy amplio. Sumaría un nivel de complejidad que perfectamente podría duplicar la extensión de la guía, así que lo dejo fuera. SÍ es muy importante, no me malinterpretes, pero no lo cubro en este artículo y te recomiendo que lo investigues para integrarlo a esta configuración una vez que la tengas armada de la manera que mejor le sirva a tu organización. Si quieres saber más, te recomiendo empezar por este excelente artículo de Red Hat que cubre lo básico aquí.

1. Instala el paquete autofs ejecutando los siguientes comandos según tu distribución:

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

2. Abre el archivo /etc/auto.master en tu editor favorito.

3. Desplázate hasta el final del archivo y agrega una línea como esta por cada montaje que quieras añadir, cambiando la palabra share en auto.share por el nombre que prefieras para el recurso:

   /- /etc/auto.share -nosuid,noowners (Si lo prefieres, agrega más espacios entre los elementos para que se lea mejor; Medium no permite poner más de un espacio dentro de un bloque de código en una lista numerada.)

4. Después tendrás que crear cada archivo que mencionaste en el paso anterior. Todos van a estar ubicados en /etc y tendrán el formato auto.[share_name]. Así que por cada línea auto.share que agregaste arriba, tendrás que abrir ese archivo en tu editor de texto favorito para crearlo. Una vez dentro, coloca esta línea sustituyendo el nombre del recurso (mi preferencia personal es mantener todo en /mnt, pero puedes modificarlo a tu gusto), el nombre del servidor y la ruta del recurso:

   /mnt/[share_name] -fstyle=nfs,user,nolock,nosuid,rw [server_name]:[share_path] (De nuevo, si lo prefieres, agrega más espacios para mejorar la legibilidad. Además, si quieres que sea de solo lectura en lugar de lectura-escritura, cambia el rw de arriba por ro.)

5. Una vez completado esto, llega el momento de reiniciar el servicio autofs ejecutando el siguiente comando:

   Ubuntu: sudo service autofs restart

   Red Hat: sudo systemctl restart autofs

6. A continuación, hay que verificar que el servicio inició correctamente y que no hubo errores de sintaxis, de red ni de otro tipo durante el arranque. Ejecuta el siguiente comando para ver el estado:

   Ubuntu: sudo service autofs status

   Red Hat: sudo systemctl status autofs

7. En la salida del paso anterior, debería indicarte que el estado es running y que todo está en orden. Si no es así, la salida mostrará las últimas líneas de los logs para ayudarte a depurar el problema. También agregué una sección al final con algunos pasos básicos de debugging.

8. Llegado este punto, puedes ejecutar un comando cd para llegar a los directorios que pusiste en los archivos anteriores y acceder a los recursos. Ten en cuenta que no necesitas crear esos directorios: el daemon de autofs los crea automáticamente.

9. Una última verificación que puedes hacer es ejecutar el comando mount, que listará todos los montajes de la instancia. Una manera fácil de encontrar todos los creados por autofs es ejecutar el siguiente comando: mount | grep autofs.

10. De aquí en adelante, los montajes se cargarán solos en el sistema y se volverán a conectar cuando haga falta.

11. Llegado este punto, te recomendaría revisar a fondo la seguridad de NFS, asegurar tus montajes e implementar el mejor método de seguridad para el uso que les vas a dar.

A lo largo de este aprendizaje me crucé con algunos tropiezos que quiero listar, junto con la forma en que los depuré.

El primero fue que el daemon arrojaba todo tipo de errores por no poder conectarse a NFS. Resultó ser que Synology agrega el número de volumen delante del nombre del recurso, algo que yo no sabía en ese momento. Lo diagnostiqué intentando montar manualmente el recurso NFS en una carpeta de mi directorio home con el siguiente comando: mkdir tmp_mnt && sudo mount -v -r -o user,nolock,nosuid [server_name]:[share_path] tmp_mnt, que monta el recurso en un directorio local. Esto debería darte un éxito o un error que indique qué está pasando. Para desmontarlo, ejecuta el siguiente comando: sudo umount tmp_mnt.

Otro error que tuve fue que el servidor no era accesible por su hostname. Resultó ser un problema de DNS interno: no estaba resolviendo el hostname. Lo diagnostiqué porque podía llegar al recurso por su dirección IP, y luego ejecuté nslookup hostname para confirmar que no podía traducir la IP al hostname. Ten en cuenta que para esto quizás tengas que instalar los paquetes bind-utils (para Red Hat sudo yum -y install bind-utils) o dnsutils (para Debian sudo apt install -y dnsutils).

El último problema que tuve es específico de Kubernetes. No podía acceder a ningún servicio externo, incluidos los recursos NFS, que estuviera fuera del cluster desde ningún pod del cluster. Resultó que no podía resolver el hostname desde DNS porque el cluster no conocía mi servidor DNS interno, que estaba fuera del cluster. La teoría detrás de todo esto excede ampliamente el alcance de esta guía, así que te dejo una solución y un enlace para que puedas leer más al respecto.

1. Edita el configmap de CoreDNS con el siguiente comando: kubectl edit configmap coredns -n kube-system.
2. Esto abrirá un editor de texto con el archivo yaml de CoreDNS. Adentro hay una sección llamada Corefile con un bloque de yaml que comienza con .:53.
3. Determina tu dominio interno. Esto va a depender de cómo esté configurado tu servidor DNS interno; si no tienes uno, simplemente usa local.
4. Determina la dirección IP de tu servidor DNS. Si no tienes uno, lo más probable es que sea la dirección IP de tu router.
5. Agrega el siguiente bloque de código, sustituyendo tu información, debajo de eso en una línea nueva (¡asegúrate de usar espacios y no tabulaciones!), guarda y sal del editor:

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

Puedes encontrar más información sobre por qué esto funciona aquí.