CLI#
manent ha due binari:
| Binario | Per chi | Cosa fa |
|---|---|---|
manent |
Sviluppatori, release manager, pipeline CI | Client: legge descrittori YAML e parla solo con l'API del server. Non contiene il motore, i plugin né i driver di database. |
manent-server |
Piattaforma | API, worker e operazioni sul database. Vedi manent-server. |
Questa pagina descrive il client.
manent [-c <client.yml>] [--server <url>] [--token-file <file>] [--ca-file <pem>] <comando> [opzioni]
Output#
Sul terminale il client stampa per le persone: deploy, promote e rollback mostrano ogni step appena concluso, una riga per ondata con il suo health gate e un riepilogo; list, inventory e status stampano tabelle; logs mostra l'ora, i livelli colorati e solo gli attributi che dicono qualcosa sulla riga. Quando l'output va in una pipe o in un file (script, CI) o con --json, stampano il JSON dell'API, come prima. NO_COLOR disattiva i colori.
$ manent deploy -f shop.yml
deploy enqueued: 8c1f…
✓ deploy@canary#0 1.1s
◷ wave canary 1 host released, health gate running
✗ wave canary health gate red
✓ rollback:deploy@canary#0 0.1s
↺ wave canary rolled back
✗ shop 1.4.0 → prod deploy failed after 2.9s
automatic rollback: completed
Configurazione del client#
Ogni comando passa dall'API: valgono sempre l'autenticazione, i permessi e l'audit del server.
server: https://manent.example.com
token_file: ~/.config/manent/token # token OIDC o statico
ca_file: /etc/ssl/certs/ca-aziendale.pem # solo se la CA del server non è tra quelle di sistema
timeout: 60s # di ogni richiesta
| Impostazione | Opzione | Variabile | File | Default |
|---|---|---|---|---|
| File di configurazione | -c, --config |
MANENT_CLIENT_CONFIG |
$XDG_CONFIG_HOME/manent/client.yml o ~/.config/manent/client.yml, se esiste |
|
| Server | --server |
MANENT_SERVER |
server |
http://127.0.0.1:8080 (manent-server serve in locale) |
| Token | MANENT_TOKEN |
|||
| File del token | --token-file |
MANENT_TOKEN_FILE |
token_file |
|
| CA del server | --ca-file |
MANENT_CA_FILE |
ca_file |
CA di sistema |
L'opzione prevale sulla variabile, che prevale sul file. Per il token: --token-file (o MANENT_TOKEN_FILE), poi MANENT_TOKEN, poi token_file del file. Il token non si passa mai come opzione, perché resterebbe nella cronologia della shell.
In una pipeline di CI si può usare l'immagine ghcr.io/manent-deployer/manent, che contiene solo il client.
Deploy#
deploy#
Accoda un deploy da descrittore YAML e, di default, ne attende la conclusione.
| Opzione | Descrizione |
|---|---|
-f, --file |
Descrittore YAML (obbligatorio). |
--no-wait |
Stampa l'ID e termina subito, senza attendere. |
--timeout |
Tempo massimo di attesa (es. 30m). Scaduto il tempo il comando termina, ma il deploy prosegue. |
--dry-run |
Esegue il deploy in simulazione. |
--after <id> |
Avvia il deploy solo dopo il successo del deploy <id> (ripetibile): vedi Catene di deploy. |
--import <nome>=<id> |
Legge gli export del deploy <id> come import <nome> del descrittore e aggiunge <id> ad after (ripetibile): vedi Export e import. |
--id, --version, --source, --sha256 |
Sostituiscono ID e campi dell'artefatto del descrittore (la pipeline dà la versione). |
--tenant <tenant> (-t) |
Imposta tenant: sceglie tra i tenant che elencano l'applicazione. Anche su rollback, promote, env validate e policy access. |
--config-ref <ref> |
Imposta config.ref: la revisione della configurazione di ambiente (provider git), entro descriptor_policy.config_ref. |
--outputs <file>, --summary <file>, --ci |
Esiti chiave=valore e riepilogo Markdown per la CI: vedi CI e infrastruttura come codice. |
I deploy pianificati (schedule nel descrittore) e quelli in attesa di approvazione non vengono attesi: il comando stampa lo stato e termina.
validate#
Verifica il descrittore sul server con gli stessi controlli dell'accodamento (policy sui descrittori, configurazione di ambiente, callback, sorgente dell'artefatto, rollback) e mostra il piano e il deploy effettivo, cioè il descrittore fuso con la configurazione di ambiente. Non accoda nulla e non contatta segreti o target, né la sorgente dell'artefatto se non con --check-artifact. Richiede il permesso deployment.read.
manent validate -f examples/descriptor.yml
manent validate -f examples/descriptor.yml --check-artifact
L'output riporta anche i nomi dei segreti dichiarati, la regola di governance che si applica e l'eventuale freeze attivo. Se la configurazione di ambiente non è raggiungibile, il server lo segnala in warnings e la verifica resta al worker. Per verificare una configurazione di manent prima di installarla c'è manent-server validate.
Con --check-artifact il server API cerca anche l'artefatto nella sua sorgente, con le credenziali di artifacts.sources e senza scaricarlo: HEAD per un URL http(s), il manifest per un'immagine oci://, il file per un percorso locale. Un artefatto mancante, un accesso negato o una sorgente irraggiungibile fanno fallire la validazione; l'esito è nel campo artifact. Per un'immagine il digest del manifest viene confrontato con artifact.sha256 (sha256_verified); per file e URL servirebbe il download, che resta allo step artifacts (o a deploy --dry-run). La richiesta parte dal server API, non da un worker: dove solo i worker raggiungono il repository, usa il dry-run. Richiede anche il permesso deployment.dry-run.
env validate#
Verifica una configurazione di ambiente candidata prima che arrivi nel sistema di configurazione, fondendola con un descrittore di esempio (default: la richiesta del deploy in esercizio). Vedi CI e infrastruttura come codice.
status#
Stampa stato, date e, per i deploy conclusi, il risultato di ogni step o l'errore.
list#
Elenca i deploy dal più recente, compresi quelli in attesa di approvazione o respinti. Con --schedule mostra solo le esecuzioni di una schedule ricorrente. I filtri (e i permessi) non riducono il numero di risultati: l'elenco prosegue sui deploy più vecchi fino a -n.
cancel#
Un deploy in coda, pianificato o in attesa di approvazione viene rimosso. Un deploy in esecuzione si ferma all'inizio dello step successivo: lo step in corso termina comunque.
Governance#
Vedi Governance dei rilasci.
manent inventory [-a <applicazione>] [-e <ambiente>] [--out-of-sync]
manent promote -a <applicazione> --from <ambiente> --to <ambiente> [--version <v>] [--deploy-file <yaml>] [--config-ref <ref>]
manent rollback -a <applicazione> -e <ambiente> [--to <versione>]
manent approve <id> [-m <commento>]
manent reject <id> -m <motivo>
manent freezes [-a <applicazione>] [-e <ambiente>]
manent approvals # deploy in attesa di una decisione che puoi prendere
manent whoami # la tua identità sul server e i tuoi ruoli
promote e rollback accettano anche --id, --dry-run, --freeze-override <motivo>, --no-wait e --timeout, con lo stesso significato di deploy.
Artefatti#
Vedi Applicazioni con più artefatti.
manent list|inventory|dora -A <artefatto>
manent promote -a <applicazione> --from <amb> --to <amb> -A <artefatto>
manent rollback -a <applicazione> -e <amb> -A <artefatto> # obbligatorio con più artefatti nell'ambiente
manent env validate -a <applicazione> -e <amb> -A <artefatto> -f <yaml>
manent freeze add --name <nome> -e <amb> -A <pattern dell'artefatto> --for 4h
manent-server -c manent.yml admin rename-artifact -a <applicazione> --from <nome> --to <nome> [--dry-run]
Tenant#
Vedi Tenant.
manent tenants list [-a <applicazione>] [--selector <selettore sui tenant>]
manent tenants show <tenant> # applicazioni con i loro tag, coda
manent list|inventory|activity|dora -t <tenant> # dora --by-tenant: metriche per tenant
manent list|inventory --selector <selettore sulle applicazioni> # es. criticality=high, tenant=payments
manent freeze add ... --selector <selettore sulle applicazioni>
Freeze e policy#
Vedi Policy in Rego.
manent freeze add --name <nome> -e <ambiente> [-a <applicazione>] [--region <r>] (--for <durata> | --until <RFC 3339>) [--from <RFC 3339>] [--reason <testo>] [--hard]
manent freeze delete <nome>
manent freeze list
manent policy list
manent policy show <revisione|current>
manent policy pull <revisione|current> -d <dir>
manent policy push -d <dir> [-m <commento>]
manent policy diff <revisione> <revisione>
manent policy eval <revisione|current> -f <yaml> [--phase submit|validate|start|stage|tick] [--kind deploy|promotion|rollback]
manent policy impact <revisione> [--since 7d]
manent policy access <revisione|current> --subject <metodo:nome> [--group <g>]... [--claim k=v]... [--compare]
[--action <azione> -a <app> -e <env> [-A <artefatto>] [-f <yaml>]] [--json] # rbac.engine: opa
manent policy approve <revisione> # attiva una bozza
manent policy activate <revisione> # torna a una revisione già attiva in passato
Log, timeline e metriche#
manent logs [-f] [--json] [--level warn] <id> # log del deploy; -f lo segue fino alla conclusione, --level nasconde i livelli inferiori
manent steps <id> # step registrati con orari, durata, output ed errori
manent dora [--since 30d] [-a <applicazione>] [-e <ambiente>]
Vedi Osservabilità.
Release composte#
manent release submit -f release.yml [--no-wait] [--timeout 2h] # invia e segue la release
manent release status <id>
manent release list [-n 20]
manent release cancel <id>
submit stampa una riga a ogni cambio di stato di un deploy (e del suo rollback) e termina con errore se la release non riesce. Vedi Catene di deploy.
Attività e worker#
manent activity [-a <applicazione>] [-e <ambiente>] [-w 5s] [--json] # deploy attivi
manent queues [-w 5s] [--json] # code, limiti e worker in ascolto
manent workers [-w 5s] [--json] # worker e lavoro in corso
activity mostra i deploy non ancora conclusi, raggruppati in in esecuzione (con il worker che li esegue, l'ultimo step registrato e l'avanzamento delle ondate), in attesa di approvazione, in attesa delle dipendenze (con i deploy ancora attesi), in coda (in attesa di uno slot libero dell'ambiente) e pianificati (schedule.at). Sono elencati solo i deploy che puoi leggere.
workers elenca i worker registrati con stato (alive, stale se manca l'heartbeat, stopped, unregistered per un executor con workflow in sospeso ma assente dal registro), region, versione dei workflow e del binario, ultimo heartbeat e i workflow in esecuzione su ciascuno: deploy, passi di un'ondata in una region, health gate, approvazioni in attesa di una decisione. Richiede il permesso platform.read; i workflow delle applicazioni che non puoi leggere sono solo contati. Una seconda tabella mostra le risorse che ogni worker comunica a ogni heartbeat (CPU usata rispetto alle CPU utilizzabili, memoria del processo rispetto al limite del container o alla memoria dell'host, carico dell'host, spazio libero della workdir, deploy eseguiti insieme) e le code che ascolta.
queues elenca le code: quella dei deploy, partizionata per applicazione e ambiente, quella delle approvazioni e delle attese, che non occupa slot di deploy, e una coda per region con il routing per region. Per ciascuna: workflow in attesa di uno slot, in esecuzione e pianificati, l'attesa più lunga, i limiti di concorrenza e i worker attivi in ascolto. Una coda con lavoro e nessun worker in ascolto (per esempio una region con tutti i worker fermi) è la prima cosa da controllare quando i deploy non partono. Richiede platform.read.
Tutti e tre stampano una tabella; --json stampa la risposta dell'API, -w ripete l'elenco all'intervallo indicato fino a Ctrl-C.
Schedule#
manent schedule list
manent schedule show <nome>
manent schedule pause <nome>
manent schedule resume <nome>
manent schedule delete <nome>
Le schedule si creano con un descrittore che contiene schedule.cron. Vedi Deploy pianificati.
Versione#
Codici di uscita#
Il comando termina con codice 0 se l'operazione riesce e con un codice diverso da 0 in caso di errore, incluso un deploy concluso con errore quando deploy ne attende l'esito.