Cuber CLI

The Cuber CLI makes it easy to create and manage your apps on Kubernetes directly from the terminal.

Before using the CLI you need to install these command line tools: git, docker, pack, kubectl.

All the commands must be executed in a folder that contains a Cuberfile.

Some commands also write temporary files in a .cuber subfolder (this information can be useful for debugging). In any case you are free to delete all content at any time and remember to always exclude it from version control.

Cuber, by design, does not store important information locally: all the information is contained in the Cuberfile, which should be kept in version control (not required, but recommended).

Even the information in the Kubernetes cluster can be considered ephemeral, since you can delete it and then restore all the configuration with a simple cuber deploy.

cuber deploy

This command builds and deploys your app on Kubernetes, reading the configuration from the Cuberfile.

You can use this command to create or update the app on the Kubernetes cluster.

See the Cuberfile reference for more information.

This command performs the following steps:

Checkout your app from the Git repository
Build the Docker image (using a Dockerfile or Buildpacks) and publish it in a Docker registry
Generate the Kubernetes configuration and apply it to the cluster

Cuber always reads the latest version of the Cuberfile from the current folder, not from the Git repository, while it gets your app code from the Git repository.

Each deployment creates a new release of your app: the tag of the image has the format hash-timestamp, where hash is the commit hash and timestamp the current timestamp. This means that you can rollback to a previous version, or keep the currently deployed version, setting release in the Cuberfile.

Note that release only controls the version of the Docker image, and not other settings: for example the environment variables are not rolled back automatically if you choose a past release, but you can easily change them in the Cuberfile. That is not an issue, but the intended behavior, since you can easily restore a previous version of the Cuberfile from your Git repository (you can also compare changes in different versions of the Cuberfile using Git).

If you just want to update some settings (e.g. proc, env, etc.) in a faster way, while keeping the current release (current Docker image), then you can get the current release name using cuber info and then set release 'abcdefg-20211201170000' in the Cuberfile: this will skip the build phase and deploy only the new settings.

The entire app is deployed inside a dedicated Kubernetes namespace: this means that you can have multiple apps in the same cluster and they will not interfere with each other.

$ cuber deploy

cuber info

Display useful information and the status of the app currently running in Kubernetes.

In particular, this is displayed:

App and current release (version)
Public IP of your app
Environment variables (secrets are obfuscated)
Migration status (e.g. database migrations)
Proc and deployment status (the processes and how many of them are running properly)
Cron jobs and last time they run
Pods and their status

$ cuber info

cuber logs [POD]

Show the logs from your entire application or the logs for a specific pod.

You can see the list of all pods and their status using cuber info, then you can use cuber logs to get additional information.

$ cuber logs
$ cuber logs web-557b3d5b69-3ptlk

cuber run [CMD]

Run the given command in a new pod.

If the command is not specified, an interactive shell (sh) will be opened.

You can run any kind of commands, including interactive commands or a shell: both input and output are attached to your terminal.

A new pod is created for the command and then deleted when the command ends.

The pod includes the basic shell commands and also your app code and configuration, so you can run generic shell commands or any specific command defined by your app (including commands that need database access, etc.).

$ cuber run
$ cuber run bash
$ cuber run mycommand --arg1 --arg2
$ cuber run rake my:task
$ cuber run rails db:migrate
$ cuber run rails console

cuber restart

Restart your application.

Restarting all the application pods can be useful for example to reset any cached value inside the pods.

$ cuber restart

cuber ctl CMD

A proxy for the kubectl command that automatically sets the --kubeconfig and --namespace options based on your Cuberfile.

$ cuber ctl get pods
$ cuber ctl top pods

cuber version

The Cuber CLI version (the version of Cuber installed locally).

$ cuber version