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.
release apps list:
NAMEof an application can be used interchangeably in commands that require 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.
--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.
-o jsonflag to the above command, so that the command output is JSON formatted. This is useful in CI and automation tasks.
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.
execinto a terminal in an instance to run commands in the container.
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.
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.
clusters execto run any Kubernetes client command that respects the above variables, such as
aws, and many others.
--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.
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.
clusters execcommand and return to the regular terminal.
release gitopscommands to ease the process of migrating an application that was configured via the Release UI, but isn’t currently using GitOps.
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.
.release/, containing the application template and environment variable configuration for the app.
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.
example-voting-app-1is the name of the application, and
36470is the ID of the environment we want to delete.