Deploy from the terminal

The commands on this page act on the deployment linked to the current directory, on the one you name as an argument, or on the one --deployment names. Each is a shortcut for the edka deployments command of the same name, such as edka deployments logs.

Prerequisites

• The Edka CLI, signed in with edka login.
• A deployment. Create one in the console, as Deployments describes, or with edka deployments create.
• Optionally, a project directory linked with edka link. Without a link, name the deployment in each command, and its cluster with --cluster when two clusters have a deployment of that name.

Deploy a change

1. Change the image tag of a deployment and wait for the rollout:

   edka up api --field config.image_tag=v3 --wait

   --field sets one field of the deployment’s settings. --data @file.json sends several from a file. Without either, up redeploys the latest successful build of a Git deployment, and restarts an image deployment.

2. While it waits, the command prints how many pods are updated and ready, and each pod that fails with its reason:

   Deployment submitted. Waiting for generation 3…
   Applying generation 3…
   Rolling out: 1/2 updated, 2/2 ready
   Rolling out: 2/2 updated, 2/2 ready
   ✓ api is running generation 3

The command exits with an error when the change fails, when a later change such as an automatic rollback replaces it, or after --wait-timeout, 5 minutes by default. The error names the reason and the edka diagnose command to run.

See what a change would do

--diff compares the settings a change would send with the deployment, and sends nothing:

$ edka up api --data @settings.json --diff
api at generation 5: 3 changes. Nothing was sent.

  config.env_variables   + LOG_LEVEL=debug
                         ~ PORT: 8080 → 9090
                         - OLD_FLAG
  config.image_tag       v2 → v3
  secret_values          ~ API_KEY (values not shown)

Unchanged: config.port
Ignored: image_tag: the settings route does not read it; send config.image_tag

A change replaces each list it sends, so for config.env_variables, config.secrets, config.volumes and the hostnames, the diff lists every entry the change adds, changes or removes. Secrets show by name, never by value. Ignored lists fields that have no effect, and Refused lists what Edka would refuse the change for, such as an exposed deployment left with no hostname.

To apply exactly the change you compared, send it with the generation the diff printed:

edka up api --data @settings.json --expected-generation 5 --wait

Edka refuses it when the deployment has moved to another generation in the meantime.

Build a Git deployment

edka build api --wait

build starts a build of the deployment’s branch. With --wait, it streams the build log and each build step to stderr. With auto-deploy on, the default, it then follows the rollout of the new image, so the command ends when the new build runs. With auto-deploy off, deploy the build with edka up api --wait.

--ref and --commit build another branch, tag or commit.

Read logs

edka logs --follow --tail 200
edka logs --since 15m --timestamps

Without --pod, logs reads the failing pod with the most restarts, or else the newest pod. --container picks a container, and --previous reads the container from before its last restart, which holds the output of a crash.

--since reads the lines of the last minutes or hours, such as 15m or 2h, up to 2000 lines unless --tail sets fewer. --timestamps starts each line with its time.

--follow reads the last --tail lines again every 2 seconds and prints the new ones, until Ctrl+C. --interval changes the pause. Without --pod, it moves to the new pod after a rollout, and names the pod it follows on stderr. When more lines arrive between two reads than --tail holds, it prints the latest ones and warns on stderr that lines may be missing, so it isn’t a complete log stream. It keeps going through a failed read, and through a rollout that stops the old pod before the new one starts.

A message from Edka in place of a log, such as a container that is still starting, goes to stderr, so stdout holds only the log.

Variables and secrets

edka env                                  # Variables, and secrets by name
edka env set PORT=8080 LOG_LEVEL=debug --wait
edka env unset LOG_LEVEL
edka env set PORT=9090 --diff             # What the change would alter

set and unset change the keys they name and keep the others. Each change starts a rollout, and --wait follows it the way up --wait does. When every value is already set, set sends nothing.

To set a secret, name it with --secret. The CLI asks for each value at a hidden prompt, or reads one value from stdin:

edka env set --secret DATABASE_URL SESSION_KEY
printf %s "$API_TOKEN" | edka env set --secret API_TOKEN

The CLI refuses a value on the command line, since shell history keeps it. Setting a secret with the name of a variable moves the variable into secrets. edka env never prints a secret’s value.

Names use letters, digits and underscores, and start with a letter or an underscore.

Restart, scale and roll back

edka restart api
edka scale api --replicas 3
edka deployments revisions api            # Revisions to roll back to
edka rollback api --generation 4

scale takes 0 to 100 replicas. rollback, and scale to zero replicas, ask for confirmation, or take --yes.

Create a deployment

edka deployments create creates a deployment from a JSON body, in the linked cluster or the one --cluster names. The body names a container image, or with --git a GitHub repository that Edka builds.

1. Write a body to start from, and edit it:

   edka deployments create --example > deployment.json

   edka deployments create --git --example prints the body of a Git deployment, and --schema lists every field as JSON Schema. Neither sends a request.

2. Create the deployment, link this directory to it, and wait for the first rollout:

   edka deployments create --data @deployment.json --link --wait

   With --git, --wait follows the first build before the rollout. --dry-run prints the request and sends nothing.

Pull request previews

A Git deployment with previews on gets a preview for each open pull request. The previews commands name a preview by its pull request number, written 12 or #12:

edka previews list                       # Status, branch, author, URL and expiry
edka previews status 12                  # The preview, its replicas and pods
edka previews logs 12 --follow
edka previews open 12                    # Open its URL in the browser
edka previews delete 12

previews list --deleted includes deleted previews. A preview that is still building, or whose build failed, runs nothing yet, so status shows its record and error only.