Il modello dei servizi Cloud Noce

Cloud Noce è organizzato in account, progetti, ambienti e servizi. Comprendere questi quattro livelli chiarisce gran parte del funzionamento del pannello e della CLI.

Account, progetto e ambiente

L’account è la tua identità di accesso. Il progetto è il perimetro operativo di un prodotto: contiene membri, ambienti, servizi, Add-on, domini e Audit. Ogni progetto ha un ambiente di produzione e può avere anche staging e preview. Variabili e release dipendono dall’ambiente, quindi una modifica allo staging non deve modificare involontariamente la produzione.

Un unico modello di servizio

Nella versione attuale, «applicazione» e «container» non sono due prodotti separati. Tutti i carichi di lavoro sono servizi e condividono gli stessi strumenti per gestire stato, log, variabili, domini, build e release. Un servizio può avere come sorgente GitHub/GitLab, una cartella locale, un’immagine Docker o un template del Marketplace.

Il tipo di accesso è indipendente dal sorgente:

HTTP: sito web o API con URL e HTTPS;
TCP: protocollo non HTTP, come un database o un broker, con endpoint e porta;
Private: solo comunicazione interna tra servizi;
Cron: esecuzione pianificata e di breve durata, senza endpoint pubblico.

I servizi ordinari restano sempre attivi. Stop è un’azione esplicita e Start li riavvia; una richiesta in ingresso non avvia automaticamente un servizio arrestato.

Build e release

Una build è l’output immutabile di una versione del sorgente. Una release attiva quella build in un ambiente insieme a un’istantanea della configurazione. Rollback pubblica nuovamente una build precedente già pronta senza ricostruirla. Promote trasferisce la build corrente in un altro ambiente.

Precedenza delle variabili

Quando più livelli definiscono la stessa chiave, prevale il valore più vicino al servizio. L’ordine dalla priorità più bassa alla più alta è:

Segreto condiviso del progetto;
Variabile dell’ambiente;
Variabile di connessione dell’Add-on;
Variabile o env del servizio.

Le variabili build-time sono disponibili durante la creazione dell’immagine; quelle runtime vengono inserite solo durante l’esecuzione del container. I valori segreti vengono mascherati dopo il salvataggio.

Dati persistenti

Non considerare persistenti i file nel filesystem temporaneo del container. I dati importanti devono essere salvati in un Volume o in un Add-on. Un Volume sopravvive ai riavvii, ma non è un backup: conserva i backup fuori dal servizio e prova il ripristino.