Comment on page
CLI usage example
We can use the Release CLI to create, manage, and interact with ephemeral environments. The example voting application is a Dockerized application that contains three services: Vote, Result, and Worker, along with a Postgres database and Redis. We can use it to illustrate how to work with the Release CLI.
By using the
release environments createcommand, we can spin up an environment from the Release CLI. This is often used in automation tasks in CI to create ephemeral environments programmatically.
If we have configured our application correctly in the above step, we should be able to list all our applications using
release apps list:
% release apps list
NAMEof an application can be used interchangeably in commands that require the
As arguments to the
createcommand, we pass in the app we want to deploy, the branch we want to track related to that application, and optionally any image overrides that are present.
We can also provide the
--waitflag, which specifies that the command should wait for the deployment of the environment to complete before exiting. Additionally, the
--verboseflag can be used to give us more detailed log output.
Before creating an environment for an application, we need to ensure that we have configured it to be able to be built automatically, or we need to have manually created a build for the branch we want to specify, through the UI.
% release environments create --app example-voting-app-1 --branch main --wait --verbose
2022/05/20 00:01:20 Task  started as part of Task Chain !
2022/05/20 00:01:21 Task  started as part of Task Chain !
2022/05/20 00:01:22 Applying: registry-secrets
2022/05/20 00:01:22 Applying: example-voting-app-1-ingress
2022/05/20 00:01:22 Creating example-voting-app-1-ingress.
2022/05/20 00:03:06 Task Chain  done as part of Pipeline Stage ! End State is [done]!
2022/05/20 00:03:06 SpaceStage  finished successfully as part of Space Pipeline !
2022/05/20 00:03:06 Space Pipeline  finished successfully!
Created Environment: 36470
Created Deploy: 153125
Once we’ve run the command, it will create the environment and wait for the deployment. We should see output from the build and deploy logs in our terminal. This output replicates what we might see in the Release UI under the environment deploys page.
Release UI Deployment
We can also optionally provide the
-o jsonflag to the above command, so that the command output is JSON formatted. This is useful in CI and automation tasks.
We can now list the environments for our app with the
% release environments list --app example-voting-app-1
ID HANDLE NAME STATE BRANCH TYPE VERSION LAST DEPLOYED EXPIRES
36470 tede739 awesome-release-main deployed main ephemeral v2.1 2022-05-19T22:02:48Z 2022-05-26T22:02:48Z
Additionally, we can view the
deploysfor our environment using the
release deploys listcommand. This command gives us the details of the deploy that was initiated when our environment was created, including how long it took, and the name of the environment it was against.
% release deploys list --app 1921
ID NAME ENV NAME STATE STARTED AT TOTAL DURATION
154371 Deploy awesome-release-main done 2022-05-23 17:54:25.366 +0000 UTC 1m55s
In a similar vein to the capabilities provided by the UI, the Release CLI lets us interact with the instances in an environment.
- Stream logs from an instance deployed in an environment.
execinto a terminal in an instance to run commands in the container.
Using the environment we created in the above section, we can
execinto a terminal in the pod our application is running in.
execinto a terminal from the CLI, we can run the
instances terminalcommand. This command automatically downloads the Kubernetes configuration for the environment to our development machine and sets us up with a terminal running whatever shell is installed on the pod.
release instances terminal --app backend
If we don’t specify an environment name, the Release CLI will provide a fuzzy search interactive prompt to allow us to select the environment we want.
CLI environment search
Additionally, we will be prompted to choose the instance we want to create a terminal for.
CLI instance search
After running the command, we should be able to interact with a shell running in the pod:
Similarly, we can stream logs from a pod by running the
release instances logs --app example-voting-app-1
This command will connect to the pod in a specific environment that corresponds to the app, and stream the logs to the terminal.
% release instances logs --app example-voting-app-1
vote-7d65b9959f-b255h/vote: * Serving Flask app "app" (lazy loading)
vote-7d65b9959f-b255h/vote: * Environment: production
vote-7d65b9959f-b255h/vote: WARNING: This is a development server. Do not use it in a production deployment.
vote-7d65b9959f-b255h/vote: Use a production WSGI server instead.
vote-7d65b9959f-b255h/vote: * Debug mode: on
vote-7d65b9959f-b255h/vote: * Running on http://0.0.0.0:80/ (Press CTRL+C to quit)
vote-7d65b9959f-b255h/vote: * Restarting with stat
vote-7d65b9959f-b255h/vote: * Debugger is active!
vote-7d65b9959f-b255h/vote: * Debugger PIN: 152-459-136
vote-7d65b9959f-b255h/vote: 10.8.108.167 - - [19/May/2022 22:02:58] "HEAD / HTTP/1.1" 200 -
clusterscommands, make sure you have configured a cluster in the Account Settings page of the Release UI.
Should we need to interact with the cluster, we can do this through the
clusters execcommand. The
clusters execcommand will run the provided Kubernetes client command with the following environment variables set:
KUBECONFIG, set to a temporary file containing the cluster's Kubernetes config.
AWS_SECRET_KEY, set to the credentials with access to the AWS account.
The command will download the configuration for the cluster and inject it locally through the above environment variables.
We can use
clusters execto run any Kubernetes client command that respects the above variables, such as
aws, and many others.
The temporary environment variables are cleaned up as soon as the command completes.
There are a few ways to specify the cluster you want to
- We can specify the cluster context directly via the
- We can specify the
--environmentflags. This will point to the cluster to the environment containing the app and set the Kubernetes namespace to the namespace containing the app, for example,
release clusters exec --app backend --environment training -- kubectl get pods. This command tells the CLI to access the cluster the backend app is using in the training environment and run
kubectl get pods.
A related command is
clusters shell. Instead of running a provided command, this command will give us a new shell with the Kubernetes configuration set (the namespace and cluster for the environment). This allows us to run multiple commands against that cluster.
Exiting the created shell will clear the configuration in a similar way to the
clusters execcommand and return to the regular terminal.
This is still a relatively new feature. Should you wish to use
gitops, please contact the Release team to have it enabled on your account. You can still commit and download the configuration, but the integration needs to be turned on.
We can use the
release gitopscommands to ease the process of migrating an application that was configured via the Release UI, but isn’t currently using GitOps.
By running the
release gitops initcommand in an application's repo, we can automatically download the required configuration for the app. The following configuration files will be downloaded:
.release.yamlfile, containing the default configuration for the application.
- A directory called
.release/, containing the application template and environment variable configuration for the app.
% release gitops init --app example-voting-app-1
⣾ Downloading existing configs...
Copying existing application template to .release/application_template.yaml
⣽ Downloading existing configs...
Copying existing environment variables config to .release/environment_variables.yaml
When we update any of our configuration, we can ensure that it is sane and valid by running
release gitops validate. The output of this command will inform us of any errors in the configuration, and make suggestions for how it can be fixed. This is especially useful if the Release CLI is being used as part of CI/CD, and we need to validate any configuration errors before running other commands. It's useful to set this up as a Git pre-commit hook to catch any errors up front.
% release gitops validate
⣟ Validating GitOps config...
✅ GitOps config is valid
Although ephemeral environments will automatically be deleted after a specific amount of time, we might want to delete an environment before then. To do this, we can use the
Run the following command, specifying the app (by ID or by name) and the environment you want to delete (by ID or by name).
% release environments delete --app example-voting-app-1 36470
⣾ Deleting environment...
In the above command,
example-voting-app-1is the name of the application, and
36470is the ID of the environment we want to delete.