Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

cargoship inventory from-ansible

Translates an Ansible inventory into a cluster inventory

Synopsis

Translates an inventory Ansible has already resolved into a ZarfCluster document, deriving each host’s role from the Ansible groups it belongs to.

This does not read an Ansible inventory file. Ansible resolves the inventory – group membership, group_vars, host_vars, dynamic inventory plugins, and the precedence rules over all of them – and this reads the resolved result: a JSON document holding ‘groups’, ‘hostvars’, an optional ‘roleGroups’ mapping, and the cluster-wide settings an Ansible inventory has no way to carry. The cargoship Ansible collection produces that document; write it by hand to reproduce a translation outside a playbook run.

By default the Ansible group named ‘controller’ supplies the control-plane nodes and the group named ‘worker’ supplies the rest. Set ‘roleGroups’ to map cargoship’s roles onto the group names the inventory actually uses. A host in none of the mapped groups is left out, so a play’s inventory may carry hosts that are not part of the cluster; a host in groups mapped to two different roles is an error.

Host order is not cosmetic. Controllers are written first, and the first controller in the document becomes the cluster leader.

Each host’s connection details come from its Ansible variables – ansible_host, ansible_user, ansible_port, ansible_ssh_private_key_file – and everything cargoship needs beyond those comes from variables under a ‘cargoship_’ prefix. A ‘cargoship_’ variable cargoship does not read is an error rather than a value ignored, because a misspelled variable and an unset one are indistinguishable at install time.

The generated document is checked against the inventory schema before it is written. The output goes to stdout, or to –output. Ansible does not connect to the fleet: cargoship opens every SSH connection itself, from the node it runs on.

cargoship inventory from-ansible [FILE] [flags]

Examples

# Translate a resolved Ansible inventory, and check the result against the schema
$ cargoship inventory from-ansible ./resolved.json -o ./inventory.yaml
$ cargoship validate ./inventory.yaml

# Read from stdin and write to stdout, so it composes with whatever produced the projection
$ cargoship inventory from-ansible < ./resolved.json | tee ./inventory.yaml

# Translate one projection of a fleet for a second cluster without rewriting it
$ cargoship inventory from-ansible ./resolved.json --name staging --loadbalancer staging-kc.test.com

Options

  -h, --help                  help for from-ansible
      --loadbalancer string   Control-plane address, overriding the one in the input. Cargoship adds it to the API server's TLS subject alternative names.
      --name string           Cluster name, overriding the one in the input. It becomes metadata.name, and the context name in the kubeconfig.
  -o, --output string         Path to write the generated inventory to. Omit it to write to stdout.

Options inherited from parent commands

      --log-file                     Always write a full-verbosity debug log to a file, regardless of --log-level.
  -L, --log-format string            Select a logging format. Defaults to 'console'. Valid options are: 'console', 'json', 'dev'. (default "console")
  -l, --log-level string             Log level when running cargoship. Valid options are: warn, info, debug, trace (default "info")
      --no-color                     Disable terminal color codes in logging and stdout prints.
      --vault-password-file string   Path to a file containing the Ansible Vault password. Falls back to the CARGOSHIP_VAULT_PASSWORD, then ANSIBLE_VAULT_PASSWORD, environment variable.

SEE ALSO