Brigade 2 is currently in a beta state and remains under heavy development, but that development is primarily oriented around improving the platform's stability. Breaking changes to APIs are not anticipated.

Brigade 2 has been lovingly re-engineered from the ground up. We believe we've remained faithful to the original vision of Brigade 1.x, and as such, much general knowledge of Brigade 1.x can be carried over.

But we've also learned a lot from Brigade 1.x. Brigade 2 has been designed, explicitly to reduce the degree of Kubernetes knowledge required for success. While Brigade 1.x was hailed as "event driven scripting for Kubernetes," Brigade 2 is "event driven scripting (for Kubernetes)." Moreover, great care has been taken to improve security and scalability, and with our all new API and complementary SDKs, we're also lowering barriers to integration.

We hope you'll enjoy this product refresh as much as we are.

Comprehensive documentation will become available in conjunction with a beta release. In the meantime, here is a little to get you started.

Note: Brigade 2 is compatible with Kubernetes versions 1.16.0+

For now, we're using the GitHub Container Registry (which is an OCI registry) to host our Helm chart. Helm 3 has experimental support for OCI registries. In the event that the Helm 3 dependency proves troublesome for Brigade users, or in the event that this experimental feature goes away, or isn't working like we'd hope, we will revisit this choice before going GA.

To install Brigade 2 with default configuration:

$ export HELM_EXPERIMENTAL_OCI=1
$ helm chart pull ghcr.io/brigadecore/brigade:v2.0.0-beta.1
$ helm chart export ghcr.io/brigadecore/brigade:v2.0.0-beta.1 -d ~/charts
$ kubectl create namespace brigade2
$ helm install brigade2 ~/charts/brigade --namespace brigade2

Please take note that the default configuration is not secure and is not appropriate for any shared cluster. This is on account of hardcoded passwords, auto-generated, self-signed certificates, and the enablement of Brigade's "root" user. This configuration is appropriate for evaluating Brigade 2 in a private cluster only (for instance, a local minikube or kind cluster, or any cluster used exclusively by oneself).

To view configuration options:

$ helm inspect values ~/charts/brigade > ~/brigade2-values.yaml

To apply alternative configuration, edit ~/brigade2-values.yaml as you see fit, then:

$ helm install brigade2 ~/charts/brigade --namespace brigade2

Because you are presumably following these steps in a local cluster, the best method of exposing Brigade 2's API server is to do something like this after installation:

$ kubectl --namespace brigade2 port-forward service/brigade2-apiserver 8443:443 &>/dev/null &

Next, download the appropriate, pre-built brig CLI (command line interface) from our releases page and move it to any location on your path, such as /usr/local/bin, for instance.

Log in as the "root" user, using the default root password F00Bar!!!. Be sure to use the -k option to disregard issues with the self-signed certificate.

$ brig login -k --server https://localhost:8443 --root

For security reasons, root user sessions are invalidated one hour after they are created. If you play with Brigade 2 for more than an hour, or you walk away and come back, you will have to log in again.

For drastically improved security, Brigade supports authentication via GitHub OAuth and Open ID Connect. For the latter, some third-party identity providers include Azure Active Directory or Google Cloud Identity Platform. However, configuring these is a bit more involved and doesn't work well if you're taking Brigade 2 for a test drive in a local environment like minikube or kind.

Your next step is to create a Brigade project. Unlike Brigade 1.x, this is not accomplished by means of an onerous, interactive process. Rather, it is accomplished using a file that looks suspiciously like a Kubernetes manifest (but isn't).

You can download an example from here:

With this file stored locally, at a location such as ~/simple-pipeline.yaml, for instance, you can direct Brigade to create a new project from this file:

$ brig project create --file ~/simple-pipeline.yaml

If you want to alter the example, note that with an appropriate editor or IDE (we use VS Code) and appropriate plugins (we use this one), you can receive context help while editing the example!

With your first project set up, it's time to create your first event. You can use the --follow flag to wait for event handling to begin and have the logs streamed straight to the CLI:

$ brig event create --project simple-pipeline --follow

Be patient with your first event. Events are handled asynchronously, and after a new install, additional time is required for the images required to handle your event to be pulled. There's also up to a thirty second delay between the creation of a new project (previous section) and the Brigade scheduler beginning to schedule workers to handle that project's events.

On success, you'll see the logs produced by the worker that handled your event. The client will disconnect at the end of the stream.

Congratulations! You're using Brigade 2!

Brigade 2's all new API lowers the bar to creating all manner of peripherals-- tooling, event gateways, and more. To facilitate this, we have three complementary SDKs in varying states of development and maturity that should make it a snap to create interesting things that interact with Brigade 2.

Be sure to check out:

• Brigade SDK for Go (used by Brigade itself)
• Brigade SDK for JavaScript (and TypeScript)]
• Brigade SDK for Rust (still a work-in-progress)

Stay tuned for complete and comprehensive developer and operator documentation in a future release.

The Brigade project accepts contributions via GitHub pull requests. The Contributing document outlines the process to help get your contribution accepted.

We have a slack channel! Kubernetes/#brigade Feel free to join for any support questions or feedback, we are happy to help. To report an issue or to request a feature open an issue here