Architettura

Corellix è organizzato a layer. Ogni layer dipende solo da quelli sotto di sé, ha un proprio ciclo di vita e viene aggiornato indipendentemente. Questa pagina descrive lo stack di CorellixOS, che è la forma completa; Corellix Cloud usa gli stessi servizi applicativi (Layer 9) su servizi gestiti Azure al posto dei layer infrastrutturali.

Lo stack

Layer 10   CoreLCM              Lifecycle: upgrade, rollback, compatibilità
Layer  9   Corellix Services    Nucleus · Meridian · Lumina · Beacon · Corell!A · Vanguard · Docs
Layer  8   Logging              Loki
Layer  7   Monitoring           Prometheus · OpenTelemetry
Layer  6   Ingress              Traefik
Layer  5   Cache                Redis
Layer 4.5  Segreti e KMS        OpenBao (Arcanum)
Layer  4   Database             CloudNativePG (PostgreSQL)
Layer 3.5  Object storage       MinIO
Layer  3   Block storage        Longhorn
Layer  2   Kubernetes           RKE2
Layer  1   Warden               Bootstrap, nodi, certificati, recovery
Layer  0   Sistema operativo    Rocky Linux, immagine immutabile

I layer da 0 a 2 e Warden sono nativi: girano come servizi systemd sul nodo, non dentro Kubernetes, perché sono ciò che rende Kubernetes possibile. Dal Layer 3 in su tutto è un workload del cluster.

Il percorso di una richiesta

        Browser / CoreCLI / agent
                    │
                    ▼
              Traefik (443)
                    │
        ┌───────────┼───────────────┬──────────────┐
        ▼           ▼               ▼              ▼
     Lumina     Meridian         Beacon          Docs
    (portale)  (API Gateway)  (ingest agent)  (documentazione)
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     Nucleus     Corell!A    Vanguard
        │
        ▼
   PostgreSQL · Redis · OpenBao

Tutto il traffico applicativo entra da Traefik sulla porta 443 e viene smistato per hostname, non per percorso. Ogni servizio pubblico ha il proprio nome DNS: questo evita che le rotte di servizi diversi collidano e permette di dare a ciascuno il proprio certificato e la propria policy. L’elenco completo è in Hostname e porte.

I due Meridian

Il nome “Meridian” indica due artefatti distinti, entrambi API gateway ma a due livelli diversi. È una distinzione che conta quando si legge l’inventario dei componenti o si pianifica un aggiornamento:

• Meridian-South — binario nativo sul nodo (corellix-meridian.service). Espone le API di piattaforma verso Citadel, CoreCLI e Warden: bootstrap, stato del cluster, lifecycle. Vive sotto Kubernetes, non dentro.
• Meridian-North — deployment nel cluster, l’API Gateway di prodotto. È il punto d’ingresso di tutte le API applicative, quelle che usano il portale, gli agent e le integrazioni dei clienti.

I due si aggiornano separatamente e riportano versioni diverse. Vedi Meridian.

Dove stanno i dati

Tipo di dato	Dove	Note
Configurazione, inventario, storico	PostgreSQL (CloudNativePG)	Un database globale più uno per tenant
Cache, sessioni, code di eventi	Redis	Anche coordinamento fra repliche
Segreti, chiavi, credenziali PAM	OpenBao (Arcanum)	Cifratura transit per le credenziali privilegiate
Volumi persistenti	Longhorn	Replica configurata in base al numero di nodi
Oggetti (export, backup, allegati)	MinIO
Metriche e log della piattaforma	Prometheus, Loki	Ritenzione configurabile

Alta disponibilità

L’appliance si installa da un nodo singolo e si espande. Il cluster è raggiunto tramite un VIP flottante indipendente dal nodo che ospita in quel momento ingress e API server: il DNS del cliente punta al VIP e non cambia mai, anche quando un nodo cade o viene sostituito.

Con tre nodi o più: etcd in quorum, Longhorn con repliche multiple, PostgreSQL in replica streaming, servizi applicativi con più repliche e autoscaling.

Come sono impacchettati i servizi applicativi

Il Layer 9 è un unico chart Helm (corellix-services) che contiene tutti i componenti applicativi. Quali di essi vengono effettivamente installati dipende da due cose:

• il profilo dell’appliance — onprem installa la piattaforma completa, beacon solo i componenti di raccolta e accesso remoto;
• la licenza — alcuni componenti, come Lamp, sono attivati da un flag di licenza.

CoreLCM applica il chart passando a ciascun componente il tag dell’immagine da usare, e sa aggiornare un singolo componente senza toccare gli altri. Vedi Aggiornamenti.

Principi

• Cloud native e Kubernetes native. Nessun componente applicativo presuppone un host specifico.
• API first. Il portale non ha scorciatoie: usa le stesse API pubbliche documentate.
• Sicurezza per costruzione. TLS ovunque, minimo privilegio, segreti mai su disco in chiaro, audit delle operazioni.
• Agnostica rispetto all’infrastruttura. L’aggiunta di una piattaforma sorgente è un connettore, non una modifica al nucleo.
• Estensibile. Nuove integrazioni si aggiungono senza rilasciare l’intera piattaforma.