Troubleshooting VS Code Remote SSH reconnecting loop en un VPS de 512MB

¡Hola mundo! Empiezo documentando mi primer articulo del blog técnico mostrando como quise montar un entorno web en un servidor dedicado.

Empieza la semana, un lunes cualquiera decidiendome adquirir un servidor por menos de lo que cuesta una entrada de cine en estos tiempos y con mucha carga en el trabajo solucionando problemas de sistemas, como no, metiendome en mas problemas de sistemas 😂

La idea es seguir aprendiendo en mi oficio y aprovechar la ola de motivación que me ha dado la primavera para poder crear de una pu** vez mi propia web. Decidi adquirir un servidor minimalista, liviano, que no me cueste mucho dinero (pero si dolor de cabeza, que me gusta complicarme)

Asi que en este articulo veremos como pretendo montar la infraestructura en Linux, probar ciertas herramientas, verme envuelto en problemas técnicos y como solucioné finalmente la incidencia (spoiler: pagando) realizando asi este maravilloso articulo de troubleshooting de sistemas para sistemas. 🤜🤛

Objetivo

Construccion de una web técnica profesional, blog estático con contenido tecnico (y no tan técnico) sin CMS y que el flujo de trabajo esté desde un editor de codigo como VSCode con la extension de Remote-SSH. Editar directamente los archivos del servidor usando VSCode (Si, me gusta tocar directamente en produccion y es mi servidor 😈) Me salto toda la parte donde he ido documentandome en ciertos aspectos como conexiones remotas al servidor por ssh, hardening básico, el porqué elegi VSCode, prepara el entorno con la extension de ssh, etc etc... ¿Fácil, no? Lets do it!

Contexto

El entorno:

• Servidor de Digital Ocean mas barato, el de 512mb de RAM y 10GB de SSD con 1CPU
• Ubuntu server
• Servidor web Nginx
• VSCode + extension OpenSSH
Bueno, ya tengo mi acceso al servidor por ssh en VSCode

Troubleshooting

Incidencia: Desconexion continua al servidor por ssh desde VSCode. Inicialmente VS Code conseguía conectarse correctamente. Sin embargo, tras unos segundos aparecían comportamientos extraños...

Síntomas observados

• reconnecting to ssh
• cannot reconnect
• terminal local en vez de remota
• imposibilidad de guardar archivos
• caídas SSH

Además:

• VS Code quedaba congelado
• la terminal dejaba de ser remota
• los archivos abiertos seguían visibles pero la sesión estaba caída
• nginx ocasionalmente dejaba de responder

Y mas errores donde se cuelga VSCode con mensajes

Llegados a este punto, pense que el programa no estaba actualizado, que habia incompatibilidades de la extension con el VSCode, que mi internet estaba mal. Bueno, tampoco hace falta ir como pollo sin cabeza, pero es común que nos suceda como administradores de sistemas pensar que el fin del mundo está cerca y no responde por causas terrorificas. Volviendo a la realidad, vamos a ver si esta ONLINE el servidor, no?

Vemos las métricas de consumo de comportamiento, y es que no tengo en cuenta que me he querido ir a lo mas barato con una memoria RAM que es un peo y querer meterle mucha carga al servidor, iluso de mi...

Ahora tiene sentido, aqui hay microcortes. ¿No será que le estoy dando mucha caña?...

Empecemos a ver cositas... Una vez accedamos a la terminal vemos si hubo algun mensaje del sistema con el comando

dmesg -T | grep -i kill

Este comando muestra los mensajes del sistema y la ventaja es que los errores se imprimen en rojo, y veo la palabra kill, por lo que filtro con grep -i la palabra kill Además vamos a consutar si hubo falta de memoria (tiene toda la pinta, no?).

journalctl -k | grep -i oom

Confirmamos sospechas.

Añadimos SWAP obligatoriamente en Linux. En resumen SWAP es un espacio en el disco duro usado como memoria virtual para extender la RAM fisica. Aunque aqui con mi servidor jugamos justito de recursos, vamos a darle un 20% del total que tenemos de disco duro, es decir 2GB de SWAP.

fallocate -l 2G /swapfile

chmod 600 /swapfile

Con el comando anterior aseguramos el permiso solo a root.

mkswap /swapfile

Preparamos el comando para inicializar como memoria virtual

swapon /swapfile

Lo habilitamos

echo '/swapfile none swap sw 0 0' >> /etc/fstab

Añadimos al fstab la configuracion del swap para hacerlo persistente tras un reinicio del sistema. Al reiniciar, comprobamos todo lo anterior con

free -h

swapon --show

Con el tiempo lei que a los servidores VPS pequeños con un disco SSD es recomendable añadirle la siguiente configuracion con idea de reducir el uso de swapping y mejorar la respuesta al mantener las cachés del sistema de archivos en la memoria ram mas tiempo. Buenas practicas: haz un backup del ficherito por si acaso...

cp /etc/sysctl.conf /etc/sysctl.bak

Abajo del todo de lo que haya en el fichero añadimos

vm.swappiness=10
vm.vfs_cache_pressure=50

Aplicamos

sysctl -p

Decisión y conclusión final

Tras ver que ahora el sistema estaba estable, consideré aumentarle la memoria RAM al VPS ya que la idea principal es tener el servidor con una web estática que apenas consume recursos Aunque las herramientas modernas se "come" a la memoria, por lo que es mas inteligente pagar un poquito mas para aumentar el recurso ya que esto irá creciendo.

¿Que hemos aprendido?

El tooling moderno consume muchos recursos, especialmente:

• VS Code Remote SSH
• extensiones remotas
• VS Code Server

512MB es extremadamente bajo para:

• VS Code remoto
• Túneles ssh
• procesos node js en el servidor

SWAP ayuda enormemente, aunque debemos tener en cuenta que SWAP ≠ RAM real. Con esta práctica le damos un punto de seguridad al servidor para evitar Out Of Memory (OOM), caidas, protege servicios criticos...

Y como no, como buen sysadmin las métricas y la monitorizacion son CLAVES.

Si has llegado hasta aqui, te merece mis respetos por leerme. Un abrazo!