Introducción
sora-project-infrastructure contiene las plantillas que Sora Horizon importa y todo lo que necesitan: los proyectos de Terraform, los scripts de cada fase, las acciones, la configuración de los servicios y los checks de Nagios.
Cada aplicación es un stack de Horizon desplegado por fases: la máquina primero (siempre el mismo servidor Ubuntu base) y después los scripts que instalan lo que esa máquina debe ser. Cambiar un ajuste es editar el stack, lo que vuelve a ejecutar únicamente el trabajo afectado.
Plantillas
| Plantilla | Despliega | Acciones | Documentación |
|---|---|---|---|
| Linux Cloud Image Downloader (ISO) | La cloud image de Ubuntu en un datastore de Proxmox | - | Linux |
| Ubuntu Base Server | Una VM Ubuntu sin servicios | - | Linux |
| PostgreSQL Server | PostgreSQL con PgBouncer, exporter y copias de seguridad | Create User | PostgreSQL |
| Monitoring | Prometheus, Loki, Tempo, Grafana y cAdvisor tras Traefik | - | Monitorización |
| Kubernetes Cluster | Un clúster kubeadm, un control plane y N workers | Upgrade control plane, Renew certificates | Kubernetes |
| GitLab Runner | Un GitLab Runner en Docker | - | GitLab Runner |
Los descriptores están en la carpeta horizon/. Para usarlos, basta con importar el repositorio en Application Templates e ISO Templates de Horizon.
Orden de despliegue
- La imagen Linux es la base de todas las VMs.
- PostgreSQL va antes que cualquier cosa que guarde datos (Keycloak y las aplicaciones de Kubernetes).
- La monitorización va antes que Kubernetes, que le envía su telemetría.
- El GitLab Runner solo necesita la imagen.
Estructura del repositorio
| Ruta | Contenido |
|---|---|
<aplicación>/ | Una aplicación desplegable con todo lo que necesita: los scripts de sus fases (jobs/), sus acciones, su configuración, sus checks de Nagios y su documentación (docs/) |
linux-image/ | La cloud image de Linux que usan todas las VMs |
linux/ | El servidor Ubuntu base, primera fase de todas las aplicaciones |
modules/ | Módulos de Terraform reutilizables, publicados en el registro de módulos de GitLab |
horizon/ | Los descriptores de las plantillas de Horizon |
nagios_config/ | Las convenciones de Nagios: los checks base, las plantillas de servicio y los comandos NRPE |
Nagios
Todas las VMs se monitorizan con NRPE y el Node Exporter de Prometheus. Ningún proyecto se conecta a Nagios: cada plantilla lista los checks de sus máquinas en su bloque nagios:, y Horizon los publica al desplegar y los quita al destruir. El Terraform y los scripts únicamente preparan el agente NRPE y sus comandos.
Todas las VMs empiezan con los mismos checks base, y cada aplicación añade los suyos:
| Servicio | Check | Plantilla |
|---|---|---|
| Hard disk - Root | check_nrpe_disk_root | sora-hdd |
| Hard disk - Data | check_nrpe_disk_data (solo si hay disco de datos) | sora-hdd |
| Current Users | check_nrpe_users | sora-service |
| Total Processes | check_nrpe_total_procs | sora-service |
| Zombie Processes | check_nrpe_zombie_procs | sora-service |
| Current Load | check_nrpe_load | sora-service |
| PING | check_ping | sora-service |
| SSH | check_ssh | sora-service |
| Prometheus Node Exporter | HTTP a su URL de métricas (solo si está instalado) | sora-metrics |
Las plantillas sora-* y los comandos los publica el Nagios de Conductor, así que no hace falta añadir nada a Nagios para monitorizar una máquina nueva. El host group de cada VM lo elige el operador al desplegar, ya que indica el entorno.
Nagios y la monitorización con Grafana responden preguntas diferentes y se mantienen ambas: Nagios dice si un host y sus servicios están funcionando, Grafana dice qué cuentan los datos recogidos.
Módulos
Los módulos de modules/ se publican en el registro de módulos de Terraform de GitLab y se usan con versión:
module "iso" {
source = "gitlab.com/ReiIzumi/proxmox-iso/proxmox"
version = "1.0.0"
}
El proyecto es público, así que terraform init los descarga sin token. Para publicar una versión, basta con crear un tag <módulo>/v<semver>:
git tag proxmox-iso/v1.0.1
git push origin proxmox-iso/v1.0.1
Mantener las plantillas
Cambiar las variables de un proyecto o un script obliga a subir el version de todos los descriptores que lo usan: Horizon solo vuelve a leer el código al sincronizar cuando la versión remota es mayor. Un cambio sin subir la versión está en Git, pero es invisible para Horizon.