Alojar un sitio o una app en un VPS: el método DevOps

Lo que aporta un VPS y lo que pide

Un VPS es un servidor virtual alquilado por meses. En él se instala lo que se quiera: un sitio, una API, una base de datos, tareas programadas. El precio no se mueve con el tráfico.

A cambio, nadie se ocupa de él por ti. Las actualizaciones, la seguridad y las copias son cosa tuya.

Votons funciona así: un sitio, una API y tareas de ingesta automáticas en un VPS de OVH.

Proteger antes de instalar nada

Un servidor nuevo es escaneado por robots en la hora siguiente a su puesta en línea. Los primeros gestos:

1. Conexión SSH solo con clave. Contraseña desactivada, acceso directo como root desactivado.
2. Un cortafuegos que solo abre los puertos útiles: SSH, 80 y 443.
3. Las actualizaciones de seguridad automáticas del sistema.
4. Un usuario por servicio, sin permisos de administración.
5. La base de datos cerrada al exterior. Solo escucha en la propia máquina.

El servidor web: Caddy

Caddy sirve los archivos, reenvía las peticiones a las aplicaciones y gestiona HTTPS por sí solo. Obtiene y renueva los certificados sin intervención. Su configuración cabe en unas pocas líneas por sitio.

Dos usos:

• Sitio estático. Caddy sirve una carpeta de archivos. Es el caso más simple, más rápido y más seguro.
• Aplicación. Caddy recibe las peticiones y las pasa a la aplicación que escucha en un puerto local.

Se le añaden la compresión, cabeceras de caché largas para los archivos cuyo nombre cambia en cada versión y las cabeceras de seguridad.

Desplegar sin pensar en ello

Un despliegue manual siempre acaba con un olvido. Se escribe un script, una vez.

Para un sitio estático:

1. 1ConstruirSe construye el sitio.
2. 2CopiarLos archivos van a una carpeta nueva en el servidor.
3. 3CambiarEl sitio apunta a esa carpeta.
4. 4Conservar la anteriorPara volver atrás con un solo comando.

< 1 minVolver atrás debe llevar menos de un minuto, y haberse probado ya.

Para una aplicación, el principio es el mismo con imágenes de Docker: se construye, se sube, se arranca la versión nueva, se comprueba que responde y después se detiene la anterior.

La regla: volver atrás debe llevar menos de un minuto, y haberse probado ya.

Hacer copias y probar la restauración

Una copia de seguridad que nunca se ha restaurado es una esperanza. Lo mínimo:

• una copia diaria de la base de datos, cifrada, enviada fuera del servidor;
• varios días y varias semanas de historial;
• los archivos subidos por los usuarios, también copiados;
• una restauración completa hecha en otra máquina, cada cierto tiempo.

Vigilar

Queremos enterarnos de una caída antes que los usuarios.

• Una sonda externa que llama al sitio cada minuto y avisa si falla.
• Alertas de disco, de memoria y de la fecha de caducidad de los certificados.
• Los registros de las aplicaciones guardados y consultables.
• El seguimiento de los errores de la aplicación, con su contexto.

Cambiar de servidor sin cortes

Un dominio pasa de un servidor a otro a través de su DNS. Para que el cambio no se note:

1. 1Día −1Bajar el TTLEl tiempo de vida de los registros DNS.
2. 2AntesProbarlo todoEl sitio completo, en el servidor nuevo, con una dirección provisional.
3. 3Día DCambiar el DNSEl registro apunta al servidor nuevo.
4. 4Unos díasConservar el antiguoEncendido, mientras todos los visitantes hacen el cambio.
5. 5DespuésSubir el TTLEl tiempo de vida vuelve a la normalidad.

Cuando el VPS ya no basta

Un solo VPS aguanta mucho tiempo. Se pasa a otra cosa cuando hace falta disponibilidad garantizada ante averías de hardware, o cuando la carga varía mucho de una hora a otra. Antes de eso se puede ampliar la máquina, sacar la base de datos a un servicio gestionado o poner un CDN delante del sitio.