A CLI tool used to deploy ephemeral environments for testing cloud.redhat.com applications
Project description
bonfire
A CLI tool used to deploy ephemeral environments for testing cloud.redhat.com applications
bonfire interacts with a running instance of qontract-server (the component that powers the AppSRE team's internal app-interface graphql API) or a local configuration file to obtain applications' OpenShift templates, process them, and deploy them.
It also interacts with OpenShift to manage the reservation of ephemeral namespaces for testing.
It is meant to be partnered with the Clowder and namespace reservation operator operators to spin up an ephemeral environment for testing on either a remote OpenShift cluster or a local k8s cluster.
Installation
We'd recommend setting up a virtual environment for bonfire:
VENV_DIR=~/bonfire_venv
mkdir -p $VENV_DIR
python3 -m venv $VENV_DIR
. $VENV_DIR/bin/activate
pip install crc-bonfire
bonfire --help
Overview
The bonfire process command can be used to print processed app configs to stdout.
The bonfire namespace reserve command can be used to acquire a namespace on a cluster
if that cluster has been set up with the namespace reservation operator.
The bonfire deploy command can be used as a helpful "1-liner" command to reserve a namespace,
process application configs, apply them into a desired namespace, and wait for them to come up successfully.
The bonfire process-env command can be used to print a processed ClowdEnvironment config to stdout.
The bonfire deploy-env command can be used as a helpful "1-liner" command to apply a ClowdEnvironment
configuration into a cluster and wait for environment resources to come up successfully.
Use bonfire --help to get a list of other commands you may find useful.
Loading an app's ephemeral config from app-interface (default behavior)
When running bonfire process/bonfire deploy, by default --source appsre will be selected. By default app-sre team's internal GraphQL API URL is used. bonfire will query the GraphQL API and read the desired application's deploy configuration.
NOTE: You need to be on the internal VPN in order to access the default GraphQL API URL.
You can edit the local configuration file (see 'App config overrides' below) if you wish to override any app configurations to allow for "local tinkering". If you define an app under the apps key of the config, it will take precedence over that app's configuration that was fetched from app-interface.
Using a local config
To get up and running without contacting app-interface's qontract-server at all, you can utilize
a local config file. bonfire ships with a default config that
should be enough to get started for most internal Red Hat employees. An internal repository holds
application configurations for the cloud.redhat.com platform that are valid for use in ephemeral environments.
By default, the configuration file will be stored in ~/.config/bonfire/config.yaml. You can reset the config to default at any time using bonfire config write-default.
App config overrides
You can edit your local config file to override any app configurations to allow for "local tinkering". If you define an app under the
apps key of the config, it will take precedence over any app's configuration that was fetched/downloaded.
Deploy app template using changes you've made locally
As an example, if you wanted to test out some changes you're making to an app but you have not yet pushed these changes to a git repo, the local config could look similar to:
apps:
- name: my_app
components:
- name: service
host: local
repo: ~/dev/projects/my-app
path: /clowdapp.yaml
- Where host set
localindicates to look for the repo in a local directory - Where repo indicates the path to your git repo folder
- Where path specifies the relative path to your ClowdApp template file in your git repo
- An
appis similar to an application folder in app-interface. Acomponentis similar to what app-interface would call aresourceTemplatewithin an app.
By default, bonfire will run git rev-parse to determine what IMAGE_TAG to set when the template is deployed. However, you can use --set-image-tag or --set-parameter to override this.
Deploy app template using changes you've made in a remote git branch
As an example, if you wanted to deploy changes to your app that you were working on which have been pushed to a PR/branch, the local config could look similar to:
apps:
- name: my_app
components:
- name: service
host: github
repo: MyOrg/MyRepo
path: /clowdapp.yaml
- Where host set to
githuborgitlabindicates where the repo is hosted - Where repo indicates the
OrganizationName/RepoName - Where path specifies the relative path to your ClowdApp template file in your git repo
- An
appis similar to an application folder in app-interface. Acomponentis similar to what app-interface would call aresourceTemplatewithin an app.
By default, bonfire will use the commit hash of master to determine what IMAGE_TAG to deploy.
NOTE: For this particular use case, if your changes are already present in a git repo, and your app already has appropriate ephemeral deployment configs set up, then using the --set-template-ref and --set-image-tag flags in bonfire may be simpler than editing your app config.
Loading application configs
bonfire process relies on a few key pieces of info to process app configs:
- The application name. This is typically the name of the listed in
app.yamlinapp-interface - (applies to
--source=appsreonly) a 'target env' -- the name of theapp-interfaceenvironment that you want to pull application configs for. An app's config will only be processed if it has a deploy target set up that points to a namespace mapped to this environment (default: "ephemeral") - (optional) a 'ref env' -- the name of the
app-interfaceenvironment that we want to use in order to set the applicationsIMAGE_TAGvalues and deploy template ref. This can be useful if you want to deploy applications using ephemeral template parameters, but you want to override theIMAGE_TAG/refdefined on all apps to use the values found inprodorstage. - Any template refs you wish to override -- in other words, if you want to download a different git hash of an application component's template.
- Any image tags you wish to override -- in other words, if you want to use a different image tag for just a specific docker image.
- Any parameters you wish to override -- if you want to set a different template parameter for a specific app.
By default, bonfire will dynamically load dependencies that all components of app relies on. This requires the app to be using the Clowder operator and to have the dependencies or optionalDependencies section of the ClowdApp set up.
Example usage in a smoke test
The goal of a smoke test running against an app is to:
- deploy the PR's code for
app - deploy the production versions of
app's dependencies alongside it
Below we'll show how bonfire deploy will enable this:
Let's say that we are running a PR check against the insights-puptoo service. This service:
- is a member of the
ingressapplication. - has a kubernetes deploy manifest that resides in the same repo as the code
- has its CI/CD
pr_check.shset up such that if a PR is opened, a docker image is built and pushed toquay.io/myorg/insights-puptoowith the tagpr-<git hash>. The PR opened against the app has commit hashabc1234
If we intend to reserve a namespace and deploy the ingress application group into it, using the new template/image of the insights-puptoo PR, but using the production template/image for all other components, we could run:
APP_NAME=ingress
COMPONENT_NAME=insights-puptoo
GIT_COMMIT=pr-abc1234
IMAGE=quay.io/myorg/insights-puptoo
IMAGE_TAG=abc1234
NAMESPACE=$(bonfire deploy $APP_NAME \
--ref-env insights-prod \
--set-template-ref $COMPONENT_NAME=$GIT_COMMIT \
--set-image-tag $IMAGE=$IMAGE_TAG)
echo "My environment is deployed into $NAMESPACE"
This is functionally equivalent to:
NAMESPACE=$(bonfire namespace reserve)
bonfire process $APP_NAME
--ref-env insights-prod
--set-template-ref $COMPONENT_NAME=$GIT_COMMIT
--set-image-tag $IMAGE=$IMAGE_TAG
--clowd-env env-$NAMESPACE
bonfire namespace wait-on-resources $NAMESPACE
echo "My environment is deployed into $NAMESPACE"
Namespace management
bonfire is also used to reserve, release, and reconcile ephemeral namespaces running on our test OpenShift clusters. It interacts with the
namespace reservation operator to reserve/release namespaces in a cluster
that has the operator installed.
When a tester is logged in using the proper account, namespace commands can be used such as:
bonfire namespace reserve -- find an available namespace and reserve it. By default the TTL is 1 hr.
bonfire namespace release <namespace> -- release a namespace reservation
Use bonfire namespace -h to see a list of all available namespace commands.
Interactions with Clowder
-
bonfireexpects a ClowderClowdEnvironmentresource similar to this template to be created for a namespace before it can deploy into it. ThisClowdEnvironmentmay have been created by the ephemeral namespace operator, or by a user manually runningbonfire deploy-env -
When
bonfire deployis executed for a namespace, it will attempt to find the ClowdEnvironment associated with that namespace and set theENV_NAMEparameter accordingly for all templates it processes. All templates that define aClowdAppresource should set theenvironmentmapping in their spec using an${ENV_NAME}parameter. -
When
bonfire namespace wait-on-resourcesis executed, it follows this logic:
- Wait for all resources owned by a 'ClowdEnvironment' to appear in the namespace
- Wait for all the deployments in the namespace to reach 'active' state.
- Wait for resources owned by a 'ClowdApp' to appear in the namespace
- Wait for all the deployments in the namespace to reach 'active' state (deployments we already waited on in step 2 are not waited on again)
- Wait for other resources such as ClowdJobInvocations, CyndiPipelines, XJoinPipelines, etc. to reach a 'ready' state.
Miscellaneous
Running a local qontract-server
bonfire is configured to point to the app-sre team's internal GraphQL API by default, but by using env variables you can point to your your own instance of qontract-server:
export QONTRACT_BASE_URL="https://localhost:4000/graphql"
export QONTRACT_USERNAME=myUsername
export QONTRACT_PASSWORD=myPassword
For testing/debug purposes, instead of committing changes directly to app-interface, you can run your own local copy of the app-interface API server.
- Clone https://github.com/app-sre/qontract-server
- Clone the internal
app-interfacerepo
In qontract-server, run:
npm install yarn
yarn install
yarn build
make bundle APP_INTERFACE_PATH=/path/to/app-interface
LOAD_METHOD=fs DATAFILES_FILE=bundle/bundle.json yarn run server
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file crc-bonfire-4.2.0.tar.gz.
File metadata
- Download URL: crc-bonfire-4.2.0.tar.gz
- Upload date:
- Size: 67.6 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.0 CPython/3.9.13
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | 86dbf13b5f27fedec792c4682d15adb904c54eb641d77e64f3eeccfeed4f1c1b |
|
| MD5 | 83ce137cd766ed20ec89fab09772b2b3 |
|
| BLAKE2b-256 | 5e670ef81467d33a6931b4c50558421ac92e1455e370e0f048f90286e058a671 |
Provenance
File details
Details for the file crc_bonfire-4.2.0-py3-none-any.whl.
File metadata
- Download URL: crc_bonfire-4.2.0-py3-none-any.whl
- Upload date:
- Size: 52.8 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/4.0.0 CPython/3.9.13
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | afd2200c5911e8cc65f00844930bff496e2b6552a3122d345a14538989f93332 |
|
| MD5 | 763910aad7cf224dc12a9809e3cedf60 |
|
| BLAKE2b-256 | be7e3241d251717a08278a0d04b0782189bc2ae5534abb25dfec8b0615af7fc5 |
