Día 0 — Fundaciones del servidor

Debian, particiones, Docker, Nginx y base reproducible: el día dedicado a que el stack KM0 sea auditable y operable.

Introducción

El día 0 está dedicado a fundaciones: sin una base reproducible del sistema operativo y del entorno de trabajo, cualquier stack posterior sería frágil y difícil de auditar.

El objetivo es salir del día con Debian estable, disco ordenado, herramientas mínimas pero suficientes y una consola que invite a documentar cada cambio.

Infraestructura

Plan técnico del arranque

KM0 persigue una infraestructura operable por el equipo, sin paneles propietarios opacos. La visión completa del arranque incluye:

  • Sistema: VPS con Debian actualizado y particiones que separan sistema de datos cuando el proyecto lo requiere (snapshots y backups más claros).
  • Colaboración: OpenCloud como microservicios en imagen oficial de OpenCloud.eu, con volúmenes estables (COMPOSE_PROJECT_NAME) independientes del directorio de ejecución de Compose.
  • Perímetro: Nginx como único frontal HTTPS; Docker publicando HTTP solo en 127.0.0.1.
  • Comunicación: Astro dockerizado en otro puerto loopback; vhosts separados para km0digital.com y cloud.km0digital.com.
  • Observabilidad: logs rotados (json-file), runbooks con docker compose ps, logs, pull, y backups de volúmenes comprimidos.
  • Evolución: TLS interno en producción, copias automatizadas y Fail2ban por jails concretos.

Disco y sistema

Provisionamiento del VPS y particiones

Se eligió Debian por predictibilidad de paquetes y documentación para administración manual, sin paneles obligatorios. El primer paso fue revisar el layout del disco:

  • Separar datos del proyecto del sistema de ficheros raíz cuando haga falta respaldar por volumen.
  • Definir montajes con criterio: /var/lib/docker puede concentrar el I/O de OpenCloud según el tamaño del VPS.
  • Documentar convenciones para distinguir montajes persistentes frente al sistema operativo.
El mapa exacto de particiones depende del proveedor y del tamaño contratado. Debe quedar en la wiki o runbook del proyecto, no solo en este blog, para recuperación ante fallos.

Paquetes base

Software base

Se instaló el mínimo razonable para administración remota segura y Docker, sin peso muerto:

  • Utilidades habituales: curl, editores, red y diagnóstico.
  • Docker Engine con logs rotativos en /etc/docker/daemon.json.
  • Nginx desde paquetes del sistema como frontal estable.
  • Certbot y TLS según fase (HTTP-01 o certificado autofirmado en laboratorio).

Cada pieza tiene un rol observable: systemctl status, nginx -t, docker compose ps.

Consola

Ergonómica del shell

Para sesiones SSH consistentes se aplicó la guía initialConfiguration del wiki:

  • Prompt de Bash legible (ruta, estado del comando, pistas visuales).
  • Historial y opciones seguras que reducen errores repetidos.
  • Aliases y PATH orientados a Compose y Git bajo /opt/....

Esta base, documentada fuera del servidor, permite repetir el mismo molde en otros VPS sin improvisar.

Herramientas

cursor-agent

Asistencia en la línea de comandos

Se instaló cursor-agent para acercar el trabajo diario al flujo de desarrollo asistido: revisiones, scripts auxiliares y documentación incremental desde la consola.

No sustituye la revisión humana ni los controles del equipo, pero reduce fricción en tareas repetibles (overlays de Compose, validar Nginx antes de recargar, etc.).

Cierre del día

Estado al terminar el día 0

Al cerrar el día, el servidor cumple tres propiedades:

  1. Es auditable: layout de disco y paquetes conocidos.
  2. Es repetible: pasos principales enlazados con wiki y runbooks.
  3. Está listo para Docker sin exponer servicios al público antes de tiempo.

Siguiente paso

Día 1

El día 1 materializa OpenCloud, el virtual host del proxy y la web KM0 con TLS. Mientras tanto, explora los servicios o escríbenos si quieres colaborar.