Command-Line Interface

The Signadot CLI provides a command-line interface to the Signadot API.

Installation

To install the CLI, download and extract the latest release archive for your platform, or use Homebrew (on either macOS or Linux):

brew tap signadot/tap
brew install signadot-cli

Configuration

In order to talk to the Signadot API, the CLI needs your Signadot org name as well as a Signadot API key, which you can generate in the dashboard.

These values can be provided in a file stored at $HOME/.signadot/config.yaml:

org: ...
api_key: ...

Or you can provide them as environment variables:

export SIGNADOT_ORG=...
export SIGNADOT_API_KEY=...

Usage

Use the help command to see a list of all available "root" commands and global flags:

signadot help

Each command may have command-specific flags and nested sub-commands, which you can see by running:

signadot help <command>

Examples

Clusters

You can use the cluster connect command to begin the process of connecting a Kubernetes cluster to Signadot:

signadot cluster connect --name my-cluster

The --name that you specify is only used within Signadot. It's the value you'll pass back in other commands to tell Signadot which Kubernetes cluster you want to work with.

The cluster connect command will generate the first auth token for that cluster and provide an example kubectl command to install the cluster token as a Secret.

You can use signadot cluster list to see the names of clusters already registered with Signadot.

You can also create a new auth token for an existing cluster with:

signadot cluster token create --cluster my-cluster

Sandboxes

To create a sandbox, first write the request as a YAML or JSON file, using the fields available in the body of a Create Sandbox API call.

For example:

name: my-sandbox
cluster: my-cluster
description: Testing sandboxes
forks:
- forkOf:
    kind: Deployment
    namespace: example
    name: my-app
  customizations:
    images:
    - image: example.com/my-app:dev-abcdef
    env:
    - name: EXTRA_ENV
      value: foo

Then submit this sandbox by passing the filename to the sandbox create command:

signadot sandbox create -f my-sandbox.yaml

You can use signadot sandbox list to see all existing sandboxes, signadot sandbox get to see details about a single sandbox, and signadot sandbox get-status to check in-cluster state:

# List all sandboxes
signadot sandbox list

# Get one sandbox by name
signadot sandbox get my-sandbox

# Check in-cluster state of a sandbox (e.g. workload readiness)
signadot sandbox get-status my-sandbox

Each of the above commands can also produce meachine-readable output (JSON or YAML). For example:

# List all sandboxes in machine-readable format
signadot sandbox list -o json

# Get one sandbox in machine-readable format
signadot sandbox get my-sandbox -o yaml

# Get in-cluster state of a sandbox in machine-readable format
signadot sandbox get-status my-sandbox -o json

You can delete a sandbox either by name, or by pointing at the same file that was used to create it:

# Delete sandbox by name
signadot sandbox delete my-sandbox

# Delete sandbox specified in a file
signadot sandbox delete -f my-sandbox.yaml