Salta ai contenuti

Setup wizard

Il wizard di Citadel porta l’appliance da “nodo installato” a “piattaforma operativa”. Si esegue una sola volta, sul primo nodo, e va completato prima di aggiungerne altri.

Si apre da solo al primo accesso a https://<indirizzo-del-nodo>:8443.

Inserite la chiave ricevuta con la fornitura. La licenza non è solo un abilitatore commerciale: definisce due cose che la piattaforma userà per costruire tutto il resto.

  • Il customer slug — l’identificativo del cliente, che diventa parte dell’hostname del portale. Non è modificabile: il campo nei passi successivi lo mostra in sola lettura e il valore della licenza ha sempre la precedenza.
  • I componenti attivati — quali funzionalità e quali moduli licenziati (per esempio Lamp) verranno installati.

La validazione è locale: non serve connettività verso Internet. In caso di errore verificate di aver copiato la chiave per intero, senza spazi o interruzioni di riga.

Scegliete il dominio DNS sotto cui la piattaforma pubblicherà i propri hostname. Il valore predefinito è corellix.loc.

Potete usare:

  • un TLD privato — corellix.loc, corp.local, interno.azienda — che è la scelta più comune e non richiede nulla al DNS pubblico;
  • un sottodominio del vostro dominio reale — corellix.azienda.it — se preferite nomi coerenti con il resto della vostra infrastruttura.

Cambiare il base domain dopo il deploy significa rigenerare certificati e rifare i record DNS: sceglietelo con calma adesso.

Il wizard mostra l’elenco esatto dei record da creare sul vostro DNS interno. Sono tutti record A verso l’indirizzo dell’appliance (il VIP, una volta configurato al passo successivo).

RecordObbligatorioA che serve
<slug>.services.<dominio>Il portale Lumina. È l’indirizzo che useranno gli utenti.
api.<dominio>NoL’API Gateway, per agent e integrazioni esterne al cluster.
agents.<dominio>NoIl punto di raccolta degli agent. Necessario se installate User Agent o Infra Agent.
docs.<dominio>NoIl portale documentazione interno — questo che state leggendo.
beaconstudio.<dominio>NoBeacon Studio. È l’unico hostname da cui funziona il login Entra ID di Studio.
*.console.<dominio>NoLe console web incorporate: ognuna si apre su un proprio sottodominio.

“Non obbligatorio” significa che la piattaforma parte comunque; significa anche che la funzionalità corrispondente non sarà raggiungibile. Se avete già il controllo del DNS interno, createli tutti adesso: sono sei record verso lo stesso indirizzo, e vi risparmiano di tornare qui fra qualche settimana chiedendovi perché gli agent non riportano.

Indicate l’indirizzo IP che rappresenterà il cluster. Deve essere:

  • libero, cioè non assegnato ad alcun host e fuori dal pool DHCP;
  • nella stessa subnet dei nodi.

È l’indirizzo a cui puntano tutti i record DNS del passo precedente. Warden lo mantiene attivo su uno dei nodi e lo sposta automaticamente se quel nodo cade: per questo il DNS non va mai aggiornato quando cambia la topologia.

Il wizard verifica la connettività, poi avvia l’installazione dei servizi applicativi. Warden e CoreLCM eseguono, nell’ordine: storage, database, cache, segreti, ingress, osservabilità e infine i componenti Corellix.

L’operazione richiede tipicamente 10–20 minuti su un nodo, di più se le immagini vanno scaricate. La pagina mostra l’avanzamento per layer; il registro completo resta disponibile in Citadel a fine deploy.

Al termine il wizard mostra l’indirizzo del portale:

https://<slug>.services.<dominio>
  1. Verificate il deploy da Citadel (Dashboard → stato dei componenti) o da CoreCLI:

    Terminal window
    core service status --all
  2. Accedete al portale e create il primo amministratore. Vedi Primo accesso al portale.

  3. Sostituite il certificato, se avete una PKI aziendale. Vedi Certificati e TLS.

  4. Collegate la prima piattaforma sorgente. Vedi Connettori.

  5. Aggiungete gli altri nodi, se avete previsto una configurazione a tre. Vedi Installare CorellixOS.

Il wizard è ripartibile: riaprendo Citadel riprende dal passo in cui si era fermato, mantenendo quanto già salvato. Un deploy interrotto a metà viene riconciliato — CoreLCM confronta lo stato desiderato con quello reale e completa ciò che manca, senza rifare da capo quello che c’è già.

Se il deploy fallisce ripetutamente, le cause più frequenti sono tre: il VIP è già occupato da un altro host, i record DNS non risolvono, oppure in modalità Connected il nodo non raggiunge il registro delle immagini. La pagina di avanzamento indica il layer che si è fermato; da lì partite con Diagnostica.