delonix stack

Aplica um manifesto inteiro (delonix-manifest.yaml) — todos os Kinds, por ordem.

Applies a whole manifest (delonix-manifest.yaml) — every Kind, in dependency order.

O equivalente declarativo do compose, ao estilo Kubernetes: um YAML multi-documento (apiVersion: delonix.io/v1) com 5 Kinds — Network, Volume, Image, Vm, Container — aplicados por essa ordem de dependência. Semântica garante-presente (idempotente por nome), não um reconciliador: sem diffing, rollout nem rollback — fail-fast, o que já foi aplicado fica.

The declarative, Kubernetes-style counterpart to compose: a multi-document YAML (apiVersion: delonix.io/v1) with 5 Kinds — Network, Volume, Image, Vm, Container — applied in that dependency order. Ensure-present semantics (idempotent by name), not a reconciler: no diffing, rollout or rollback — fail-fast, whatever was already applied stays applied.

📄 Implementação real em Rust: cmd/stack.rs

Usage: dlx stack [OPTIONS] <COMMAND>

Commands:
  init      Initializes a COMPLETE project: Delonixfile + manifest + cluster + README — files ALREADY FILLED IN (images included), ready to use without editing anything
  apply     Applies all the manifest Kinds (Network → Volume → Image → Vm → Container)
  ls        Stack detail in `kubectl describe` style: each resource DECLARED in the manifest and whether or not it is present on the machine
  describe  
  validate  Validates the manifest WITHOUT touching anything (dry-run): resolves the cross-references (`Container.network`/`.volumes`, `Vm.network`, `Ingress/Egress. target`) against what the manifest declares PLUS what already exists in the stores. Exits with an error if any reference is left unresolved — it is the safety net against an `apply` that would only fail halfway through (fail-fast, no rollback)
  help      Print this message or the help of the given subcommand(s)

Options:
      --l18n <en|pt>  Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand
  -h, --help          Print help

Exemplo de manifesto

apiVersion: delonix.io/v1
kind: Network
metadata: { name: backend }
---
apiVersion: delonix.io/v1
kind: Volume
metadata: { name: dados }
---
apiVersion: delonix.io/v1
kind: Container
metadata: { name: db }
spec:
  image: postgres:16-alpine
  network: backend
  volumes: [ "dados:/var/lib/postgresql/data" ]
  ports: [ "5432:5432" ]
  env: [ "POSTGRES_PASSWORD=segredo" ]

`stack validate`

Validates the manifest WITHOUT touching anything (dry-run): resolves the cross-references (Container.network/.volumes, Vm.network, Ingress/Egress. target) against what the manifest declares PLUS what already exists in the stores. Exits with an error if any reference is left unresolved — it is the safety net against an apply that would only fail halfway through (fail-fast, no rollback)

Usage: dlx stack validate [OPTIONS]

Options:
  -f, --file <FILE>   
      --l18n <en|pt>  Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand
  -h, --help          Print help

Exemplos

Validar o manifesto SEM aplicar nada

delonix stack validate -f delonix-manifest.yaml

`stack describe`

Usage: dlx stack describe [OPTIONS]

Options:
  -f, --file <FILE>   
      --l18n <en|pt>  Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand
  -h, --help          Print help

Exemplos

Estado recurso a recurso, confrontado com o manifesto

delonix stack describe

`stack ls`

Stack detail in kubectl describe style: each resource DECLARED in the manifest and whether or not it is present on the machine.

The stack has no state of its own — there is no registry of "stacks", only a manifest and the resources it creates. That is why this describe always starts from the file and goes to confirm each resource against the respective store, instead of inventing a new registry that would drift out of sync (the same reason cluster ls derives its state from the container labels).

The column that matters is PRESENCE: an apply is fail-fast and without rollback, so a half-applied stack is a normal state and this is exactly what it shows. List the structure the manifest composes (containers, volumes, networks, ...) and whether each resource exists — the tabular summary of describe.

Usage: dlx stack ls [OPTIONS]

Options:
  -f, --file <FILE>
          

      --l18n <en|pt>
          Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand

  -h, --help
          Print help (see a summary with '-h')

Exemplos

Que recursos do manifesto existem de facto neste host

delonix stack ls

`stack init`

Initializes a COMPLETE project: Delonixfile + manifest + cluster + README — files ALREADY FILLED IN (images included), ready to use without editing anything

Usage: dlx stack init [OPTIONS] [DIR]

Arguments:
  [DIR]  Project directory (default: the current one) [default: .]

Options:
      --l18n <en|pt>         Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand
      --name <NAME>          Project name (default: the directory name)
      --image <IMAGE>        Image to use. Omit = fills in with the default image
      --force                Overwrites already existing files
  -t, --template <TEMPLATE>  Generates a complete PROJECT for a stack (e.g. `python`) with best practices, instead of the generic scaffold. `--template list` shows the available ones
      --up                   After generating, builds the image, starts it and waits for it to become healthy
  -h, --help                 Print help

--template <nome> gera um projecto real e funcional de uma linguagem/framework, com boas práticas (multi-stage não-root, healthcheck, testes, dotfiles) e já delonix-native (Delonixfile + manifesto). Sem --template, o init gera o scaffold genérico. Os tokens __NAME__/__MODULE__ são substituídos pelo nome do projecto.

Exemplos

Projecto COMPLETO de uma stack (FastAPI): código + Delonixfile + manifesto + testes

delonix stack init myapi --template python

Ver os templates disponíveis

delonix stack init --template list

`stack apply`

Applies all the manifest Kinds (Network → Volume → Image → Vm → Container)

Usage: dlx stack apply [OPTIONS]

Options:
  -f, --file <FILE>   
      --l18n <en|pt>  Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand
      --dry-run       Don't apply anything — print the full manifest with every default filled in (like `kubectl apply --dry-run=client -o yaml`). Stacks are expanded and Kinds canonicalized, so you see exactly what WOULD run
  -h, --help          Print help

Exemplos

Aplicar o manifesto por omissão (./delonix-manifest.yaml)

delonix stack apply

Manifesto explícito

delonix stack apply -f infra/stack.yaml

LaboratórioLab

Gera um projecto COMPLETO já pronto (código + Delonixfile + manifesto) a partir de um template, e aplica-o.

delonix stack init minha-api --template python
cd minha-api
delonix stack apply

Generate a COMPLETE, ready-to-run project (code + Delonixfile + manifest) from a template, and apply it.

delonix stack init my-api --template python
cd my-api
delonix stack apply

DesafioChallenge

Corre stack apply --dry-run e compara o YAML impresso (com todos os defaults preenchidos) com o teu delonix-manifest.yaml original — que campos é que o motor preencheu por ti?

Run stack apply --dry-run and compare the printed YAML (every default filled in) against your original delonix-manifest.yaml — which fields did the engine fill in for you?