Saltar al contenido principal

Guía de despliegue

Esta es la ruta completa para levantar una red Sora desde cero. Cada paso enlaza a la sección donde se explica en detalle.

Spoiler

¡Fallar es el estado natural de todo esto! Empieza siempre por el entorno de testing: si fallas en muchos lados, siempre puedes tirarlo a la basura y volver a empezar.

Requisitos previos​

  • Proxmox VE operativo, en standalone o en clúster, con un token de API y acceso SSH. La documentación de Proxmox es la base.
  • Un servidor físico Ubuntu x64 para el orquestador, donde se instalará Horizon, con un usuario con sudo sin contraseña o root. Debe ser físico porque gestiona los servicios básicos de la red (DNS, DHCP, NTP, Horizon, ...): no puede depender de Proxmox, ya que todo lo demás depende de él.
  • Un NAS o servidor NFS para las copias de seguridad.
  • Un dominio en Cloudflare con un token de API que permita editar la zona DNS. Se usa para los certificados de Let's Encrypt por DNS-01, incluso para nombres que solo existen dentro de la red.
  • Una cuenta SMTP para las notificaciones por correo.
  • Opcionalmente, un workspace de Slack donde FluxCD envía sus avisos de actualizaciones y errores.

1. El servidor orquestador​

Ejecutar Sora Conductor en el servidor orquestador:

sudo bash -c "$(curl -fsSL https://gitlab.com/api/v4/projects/ReiIzumi%2Fsora-conductor/repository/files/init-sora-conductor.sh/raw?ref=main)"

El asistente deja instalado y configurado Pi-hole, el relay SMTP, NTP, lighttpd con certificado, PostgreSQL, Nagios y, finalmente, Sora Horizon, accesible en https://<dominio>:444/horizon.

2. Configurar Horizon​

Horizon se configura alternando entre el administrador y el operador. La secuencia detallada está en Primeros pasos; en resumen:

  1. Administrador: usuarios, organización (entornos, tags, ...), Nagios, Proxmox, llaves SSH, NTP y la red (redes, dominios y tipos de IP).
  2. Operador: importar las plantillas de sora-project-infrastructure, desplegar la ISO de Ubuntu y registrar lo que ya existe en la red: direcciones reservadas, carpetas compartidas y dispositivos.

3. Stacks básicos​

Cada pieza es un stack en Horizon. El orden importa, porque cada una usa la anterior:

  1. PostgreSQL: el servidor de base de datos, y una ejecución de la acción Create User por aplicación (por ejemplo keycloak).
  2. Monitorización: Prometheus, Loki, Tempo y Grafana.
  3. GitLab Runner, si se usa GitLab.

Con la monitorización desplegada, el administrador registra Prometheus y Grafana en Horizon a partir del propio stack y configura Grafana.

4. Kubernetes y FluxCD​

El operador despliega el stack de Kubernetes: un control plane y al menos tres workers. Con su salida kubeconfig, instalar el Flux Operator y aplicar el FluxInstance del entorno. A partir de ahí FluxCD despliega por niveles la red, el ingress, la observabilidad, Keycloak y las aplicaciones.

5. Keycloak y aplicaciones​

Con Keycloak arrancado, el administrador lo conecta en Admin › Keycloak de Horizon, y el operador crea los realms e importa la configuración de cada aplicación desde la sección Keycloak. Las aplicaciones de FluxCD ya pueden iniciar sesión, y Grafana puede pasar a usar Keycloak.

consejo

A partir de este punto, el día a día se reduce a: editar un stack en Horizon para cambiar una máquina, y hacer un commit en el repositorio de FluxCD para cambiar lo que corre en Kubernetes. Las actualizaciones menores llegan solas y Slack avisa de ellas.