Brigade Brigade in 5 Minutes, 12 Jan 2022

Previous Meeting

⏯

youtube image

►

From YouTube: Brigade in 5 Minutes -- Episode 1 -- Video QuickStart

Description

The inaugural episode of our "Brigade in 5 Minutes" series is a video adaptation of the Brigade QuickStart (https://quickstart.brigade.sh).

We're still learning the "5 minute" formula, so please excuse and enjoy the two bonus minutes! 😂

A

Hello brigadiers and welcome to the inaugural episode of brigade in five minutes. I'm kent rancourt one of the project, maintainers and I'll, be your host for this series of short video tutorials.

A

Today's tutorial is a video adaptation of our quick start documentation.

A

So we'll start here at docs.brigade.sh and from the left navigation menu. We can select quick start before we really get started. We've got a few prerequisites, the first being a local development grade kubernetes cluster. Let me take a moment to address what we mean when we say local development grade cluster.

A

The steps we're following in this tutorial deploy brigade using some insecure default configuration. It is in no way a production grade deployment we'll cover that in another episode. With this being the case, we recommend completing this tutorial in a small cluster that you can throw away when you're done here. In the interest of time, I've created such a cluster in advance, using kind which stands for kubernetes and docker. If you're not familiar with it, the quick start does contain instructions for getting started.

A

We also need helm version 370 or later last. We need cube ctl. I can verify that both of these are pre-installed on the system that I'm recording on next. We need to install the brigade cli once again in the interest of time. I've pre-installed this, but the quick start does contain installation instructions for linux, macos and windows.

A

Now we'll install the server side components because we are using experimental features of helm, 370 and greater, we need to set the helm, experimental, oci environment variable to a value of one.

A

Now we can use the following command to install brigade onto our cluster with default configuration.

A

This will take between two and five minutes, so we'll pause the recording here and resume when it completes welcome back when installation completes you'll, see a variety of notes. Instructing you on your next steps. One of these notes tells us how to retrieve the root user's password, we'll copy that command and execute it.

A

This password was automatically generated during the installation process for convenience, we'll assign this password to an environment variable.

A

Next, we'll do some port forwarding to create a tunnel from port 8443 on localhost through to the api server running inside our cluster. Now we can use the brigade cli to log in to the api server.

A

Now that we're logged in we'll list all the available projects.

A

And there are none, so, let's create one first, we'll make a new directory.

A

And change into that directory here, we'll type breg.init and give the project an id first project.

A

This generated a number of files for us, the most interesting one being this one. This is our project definition file. Let's have a look at that.

A

Here's our project definition note that, although it looks an awful lot like a kubernetes manifest, it is not a brigade project fundamentally pairs event subscriptions with configuration for a so-called worker container that will execute a script that handles events.

A

We can see this project is subscribed to exec events that originate from the brigade cli.

A

This is good for demo purposes, but in reality, most events originate from things called gateways which are components that receive web hooks or other sorts of events from external systems and convert them to brigade events to keep things simple, we're just dealing with events that we can generate quickly and easily using the cli.

A

In the worker template section, we can see some configuration for the container that will execute our script and in this case the script is actually embedded in the project. Definition that works for this quick example, but obviously isn't ideal for all scenarios, because we're missing things like syntax, highlighting, for instance, in most cases, this configuration will instead point to a git repository where your script can be found and downloaded.

A

The script itself is pretty simple: it uses a library called brigadier to describe how to handle each of the various events. Your project might be subscribed to here. We're handling the event by creating a job called hello based on the debian latest docker image.

A

You might infer from the configuration that this job merely prints the string hello world to standard out.

A

Although our project definition is not a kubernetes manifest, you can think of it in similar terms, you can define a pod or service and manifest, but it doesn't really exist in your kubernetes cluster until you upload that manifest using cube, ctl create or apply. Similarly with brigade, we need to upload our project definition using brig project create.

A

Now we can list our projects again.

A

And now we see first projects listed next, we'll create an event for this project.

A

And we'll use the follow flag to ensure that logs from the worker are forwarded to our terminal.

A

Now that our event has been handled, let's list all events.

A

We can see the event we just created with its id and we can see that it has a phase of succeeded.

A

If we retrieve this event by id.

A

We can see more details such as the jobs that ran and their own individual statuses,.

A

We can also get logs for an event.

A

These are the same logs. We saw streamed from the worker earlier. We can also ask for the logs from a specific job.

A

That concludes this video adaptation of our quick start document. We'll see you next time on brigade in five minutes.