CLI usage example
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
To get started using Release CLI, make sure you have a and have worked through the .
Get , and follow the .
By using the release environments create command, 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:
Note: The ID and NAME of an application can be used interchangeably in commands that require the --app flag.
As arguments to the create command, 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 --wait flag, which specifies that the command should wait for the deployment of the environment to complete before exiting. Additionally, the --verbose flag 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.
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.
We can also optionally provide the -o json flag 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 environments list command:
Additionally, we can view the deploys for our environment using the release deploys list command. 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.
In a similar vein to the capabilities provided by the UI, the Release CLI lets us interact with the instances in an environment.
We can:
Stream logs from an instance deployed in an environment.
exec into a terminal in an instance to run commands in the container.
Using the environment we created in the above section, we can exec into a terminal in the pod our application is running in.
To exec into a terminal from the CLI, we can run the instances terminal command. 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.
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.
Additionally, we will be prompted to choose the instance we want to create a terminal for.
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 instances logs command:
This command will connect to the pod in a specific environment that corresponds to the app, and stream the logs to the terminal.
Should we need to interact with the cluster, we can do this through the clusters exec command. The clusters exec command 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_ACCESS_KEY and 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 exec to run any Kubernetes client command that respects the above variables, such as kubectl, k9s, 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 exec against:
We can specify the cluster context directly via the --cluster flag.
We can specify the --app and --environment flags. 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 exec command and return to the regular terminal.
We can use the release gitops commands 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 init command in an application's repo, we can automatically download the required configuration for the app. The following configuration files will be downloaded:
A .release.yaml file, containing the default configuration for the application.
A directory called .release/, containing the application template and environment variable configuration for the app.
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.
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 environments delete command.
Run the following command, specifying the app (by ID or by name) and the environment you want to delete (by ID or by name).
In the above command, example-voting-app-1 is the name of the application, and 36470 is the ID of the environment we want to delete.
