Saltar al contenido principal

Primeros pasos

Horizon recién instalado no sabe nada de la red. Esta es la secuencia esperada para ponerlo en marcha, alternando entre lo que hace el administrador (servidores, credenciales y listas de referencia) y lo que hace el operador (estructura de la red y stacks).

En rojo los pasos del administrador, en azul los del operador.

consejo

Conductor ya deja registrados el Pi-hole, el NTP y el Nagios del propio orquestador, así que esos servidores no hay que crearlos, solo revisarlos.

1. Administrador: la base​

Iniciar sesión con el administrador por defecto ([email protected] / changeme) y cambiar la contraseña de inmediato desde el perfil. Después, en Admin:

  1. Users: invitar al resto de usuarios con su rol (viewer, operator o admin).
  2. Organization: definir los Environments (testing, producción, ...) y su orden, los Tags, las Device categories, las Attachment sources y, si hacen falta, más Folder types.
  3. Monitoring › Nagios: revisar el servidor que registró Conductor, sus host groups y pulsar Resync para leer sus comandos y plantillas.
  4. Infrastructure:
    • Proxmox: cada servidor con su token, usuario SSH, datastores, resource pools y, si forman un clúster, el mismo nombre de cluster. Pulsar Verify.
    • SSH keys: las llaves que se instalarán en las VMs, con su usuario SSH si se quiere fijar.
    • NTP: añadir los servidores extra (Conductor ya registra el orquestador) y asignar el primario y el secundario.
  5. Network:
    • Networks: los rangos de la red con su gateway y pool DHCP.
    • Domains: los dominios DNS, ligados a su red y al Pi-hole del orquestador (Conductor ya lo registra como Pi-hole).
    • IP types: revisar los tipos y crear los que bloquean la asignación para lo que ningún stack debe usar.

Detalle de cada sección en Configuración.

2. Operador: la estructura​

Con la base definida, el operador prepara lo que necesitarán los stacks:

  1. Plantillas: importar desde Git las Application Templates y las ISO Templates. Las de Sora están en sora-project-infrastructure. Ver Plantillas.
  2. ISO de Ubuntu: desplegar la imagen principal desde ISOs, ya que todas las VMs arrancan de ella.
  3. Network: marcar en el mapa lo que ya existe o está reservado (hosts de Proxmox, NAS, routers, rangos de MetalLB, ...) con su nombre y su tipo, de forma que ningún stack lo use.
  4. Shared folders: registrar las carpetas compartidas que ya existen, con sus permisos de acceso. Horizon no las crea: deben existir en el NAS o el servidor que se ocupa de ellas. Como mínimo, la carpeta NFS de copias de seguridad.
  5. Inventory: si es posible, registrar los dispositivos de la red y reservar sus direcciones.

Detalle en Red e inventario.

3. Operador: los stacks básicos​

Con la estructura lista, se despliegan los primeros stacks:

  1. PostgreSQL como base de datos de toda la red.
  2. Monitoring: Prometheus, Loki, Tempo y Grafana.
  3. GitLab Runner, si se usa GitLab.

4. Administrador: la monitorización​

Con la máquina de monitorización desplegada, el administrador la registra en Admin › Monitoring, partiendo del propio stack para que se rellene sola:

  1. Prometheus, y comprobar con Verify que su configuración lee la carpeta de Horizon.
  2. Grafana, junto a sus configuraciones específicas: contraseña de administrador, notificaciones y puntos de contacto. Aplicarlas con Apply configuration.

A partir de aquí, el operador puede usar ambos sistemas tanto en los stacks propios (sus targets y checks se publican solos) como para elementos de la red que no son de ningún stack, desde la sección Monitorización.

5. Operador: Kubernetes​

El operador despliega el stack de Kubernetes y usa su kubeconfig para instalar FluxCD, fuera de Horizon, que despliega todas las piezas del clúster: red, ingress, observabilidad, Keycloak y aplicaciones.

6. Administrador: Keycloak​

Con Keycloak arrancado en el clúster, el administrador configura la conexión en Admin › Infrastructure › Keycloak con el administrador inicial que crea FluxCD. Ver Keycloak.

7. Operador: realms y aplicaciones​

El operador crea los realms e importa la configuración de Keycloak de cada aplicación (sus manifiestos KeycloakApplication), y las aplicaciones de FluxCD ya pueden iniciar sesión. Grafana también puede pasar a usar Keycloak desde su ficha de Admin.

Y con esto, toda la red está totalmente funcional con la arquitectura básica. Lo suficientemente básica como para ser el sueño húmedo de muchas empresas o, peor, el que ni siquiera saben que existe.