Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Intro: Brigade - Radu Matei & Kent Rancourt, Microsoft

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Intro: Brigade - Radu Matei & Kent Rancourt, Microsoft

Brigade is a lightweight, Kubernetes-native framework which allows the creation of event-driven workflows. Using JavaScript, Brigade chains together containers and controls their execution in an in-cluster scripting environment that enables easy error handling and data sharing. In this session, you will learn how to get started with Brigade, how to use the existing GitHub, CloudEvents and generic event support and integrate them in your workflow, and how different companies are using Brigade to automate their internal workflows (from code quality assessment and security scanning, to automatically generating preview environments for each pull request), and ultimately allow teams to build massively distributed workflows using a few lines of JavaScript. Finally, we will explore future plans and share the progress for the next major version of Brigade, 2.0.

https://sched.co/Zeuq

A

Everybody uh we want to thank you in advance for coming to our session today. um Rodney and I are going to be talking about brigade.

A

So brigade is event driven scripting for kubernetes and who are we we're both software engineers at microsoft, in a group that identifies uh outwardly as deus labs, we're both open source maintainers for brigade and a few other projects.

A

um As for myself, my info is down at the bottom there you can find me on twitter at crankcore um and I'm a dad, a martial arts instructor and a comic book nerd and I'll. Let radu introduce himself.

B

Hello: everyone, I'm radho, you can find me on the internet. If you, uh if you need to contact me, I blog quite a bit about open source and distributed systems and webassembly, and things like that. I'm trying to learn to play the piano, I'm a cyclist and aspiring trail runner and a webassembly tinker back to kent.

A

All right, thanks ronnie, um so to talk about brigade, we're going to give a little bit of historical background about where the project comes from, because it's it's kind of interesting. um So in fall of 2016 um davis and this is before deus- was uh later acquired by microsoft. We were doing something that we called the shark tank exercise, which was kind of modeled after the television program, shark tank and so engineers broke into groups and pitched new ideas to management, and the idea was that the winning pitch.

A

Spoiler alert brigade won that year um and helm won the the previous year and the pitch began with the comparison of kubernetes to an operating system, um and- and this is kind of also how the pitch for helm uh began also, um both years, the the winning teams who came up with with these ideas, ask the question: if you, if you think of kubernetes, like uh an operating system of sorts, what um pieces of functionality that were accustomed to in a real operating system are missing from kubernetes.

A

So um just to you know dive into this analogy a little bit. What is an operating system, and this is kind of like the you know, the the wikipedia level um definition here, but it's it's a program that, after being initially loaded into the computer, manages all the other programs, so kubernetes um can be thought of. As your cluster operating system, the os manages processes on a machine and kubernetes manages containers in a cluster. Kubernetes is an operating system of sorts.

A

um So you know when help was conceived. The thing that was obviously missing from kubernetes at the time was a package manager and when brigade was conceived, the thing that was conspicuously missing was some kind of shell scripting.

A

So in traditional shell scripting in on your desktop operating system, um it's flow control that wraps the execution processes, but it's not opinionated about what those processes do or how they run. So what would shell scripting in a cluster look like? Well, it would be flow control that wraps the execution of containers, but isn't particularly opinionated about what the containers do.

A

So that's what led pretty directly to to brigade um fast forward to the current day uh and we're a cloud native sandbox.

A

Project we are event driven scripting for kubernetes, we're extremely lightweight and kubernetes native and brigade chains together. Containers to create workflows and radio will show us more about that as we get going um some key design decisions that went into creating brigade what programming language to use. If you're going to create some kind of scripting engine, um you know what language do you write those scripts in?

A

um How can data be shared between containers?

A

If you, if you think about writing a traditional shell scripts like in your desktop um operating system, um you know you have several ways that data can can go into a process or come out of the process, so you can pass uh commands on the command line or you can use a file as inputs or you can pipe some input in from standard in um same thing, on the on the tail and getting output out of a process, you could be writing to a file or you could be writing something to standard out and you could pipe that into another process.

A

um When should scripts be executed? um It's it's pretty simple. In the desktop operating system, uh a script is executed when, when you type its name and hit enter, um but what are the the triggers for executing the script um in a cloud environment? So that's another thing that that had to be considered so on the subject of of what language to use um these uh stats that you're looking at here are a little bit out of date, but I think that's, okay.

A

I think it's it's relevant to show um you know kind of point in time, statistics um here, so it was, it was 2016 when this decision was being made and javascript was then, as is now overwhelmingly um one of the most popular programming languages, the the most popular programming language and uh why javascript? So yes, popular we've established that rich ecosystem of tools and extremely flexible um just to back up that uh second bullet point about the rich ecosystem of tools.

A

um Again, this is a couple years ago, um npm, which is the one of the package managers for for uh javascript. They surpassed one billion weekly package pulse. So if, if that doesn't speak to uh how vibrant um the ecosystem is and how many tools are available and how popular they are, I I don't know what does so javascript, um basically slam dunk here so sharing data between containers. We talked about that. We know what we know. What sharing data between processes looks like on your desktop operating system.

A

What does it look like um in the cloud so passing information to a container? Well, it's not that different than passing information to a process on your desktop. You can pass things in through the commands, so command line, flags.

B

A

Command arguments right, you do specify a command or arguments when you create a container, so that's one way of getting information into the container. You have environment variables, of course, and you can pass information um to a process in a container using a file.

A

How do you get information out of containers? While you have standard out? You have exit codes. What was the exit code of the containerized process and, of course you have files.

A

So in the end everything is just javascript, so I will quickly go through um this one little snippet I'll. Let raju go into much more detail when he does his demos, um but what we have here is we're basically importing the brigadier library. Brigadier is just a library for javascript that exposes the primitives that you need, for um you know creating these pipelines, so they have primitives like um like jobs, for instance, and and we see that in use here- so you say, bar program equals new job.

A

We give it a name, and we tell it um what uh what docker container to base this job on, and we give it some tasks to do echo hello, echo goodbye. These will be executed in order. We set an environment variable, we give the variable key, the the value value, and then we say program.run. So this is. This is a pretty simple script that just runs one container.

A

So there's still the question of when to execute. um As I said, if you were talking about a desktop operating system, things execute when you type the script's name and hit enter, but that's not really the way you're going to expect things to work with cloud right. um So, as I understand it, um some inspiration for this came actually from from applescript, um which is you know a little bit more event driven um in terms of you know, you do something on your mac desktop and that triggers subscript.

A

um So that's how brigade works. We are event driven and gateways um broker, events from upstream systems like github or docker, hub or slack, and there are others we have other integrations as well, and you can pretty easily build your own and event. Handlers therefore become the entry points into your brigade scripts, so we'll. uh So this is roughly what that looks like you have um over on the left. You have some kind of upstream event, so this could be like a web hook coming from um github or slack, or something like that.

A

It comes into a gateway which is a little program that that understands the events from the upstream system and uh turns them into events that it emits into brigade which, which triggers uh a build.

A

So this is the same script we looked at before, but adapted a little bit to look uh event driven, so you can see we're still importing some things from brigadier before we just imported jobs. This time we are importing events as well, and you can see on the next line, we're saying events.on some event.

A

Then we want this container to execute and these lines that you see here are the same lines that we looked at earlier.

A

So some popular use cases that we know brigade has been used to tackle um ci cd is probably the most popular. Although I really want to note that brigade is not a ciacd platform, it's just that it's one popular use for it. We know of teams that have done nightly security audits of their source code repositories.

A

um You can use it for things like aggregating and analyzing data to build reports. um You could create complex, sandbox environments on demand, so you know you could have some events that might trigger a kind cluster being deployed within your kubernetes cluster in order to facilitate uh end-to-end testing of some something.

A

um So at this point, I'm going to turn it over to uh raju um to do a little demo and uh then uh will come back to me at the end to get some updates about future projects.

B

Hello, everyone in this video we will get started with brigade. First of all, you will need a kubernetes cluster. You can use any cloud provided cluster or local one in this case, I'm using docker desktop and with a single node cluster.

B

Everything you're about to see can be found on the documentation website for brigade and to get started. We will deploy brigade in our cluster using helm, I'm using helm3 to deploy brigade to its own namespace, uh and at this point we can start using the brigade cli, which can be downloaded from the release pages from the release page on github and run brick check, which makes sure that all of brigade's component uh components are properly uh deployed in our cluster and are running.

B

So we can see an api server, a controller which is listening for events and an optional web dashboard, and now we are ready to start writing brigade scripts. What I did previously, I created a brigade project which is just a logical grouping for data secrets, and things like that, so I didn't have to create it right now. It's called hello kubecon and we will reference it when uh generating events through the break cli.

B

So the simplest brigade script requires us to import brigadier, which is the javascript api for brigade, specifically we're using the events and job objects which we will see throughout. The examples in this video brigade is a an event-driven scripting engine on top of kubernetes. So every every entry point in a brigade script is an event handler, in this case we're reacting to an event called exec and we're reacting by executing this particular function.

B

So what this function does is every time there's an exec event. We create a new job called, do nothing based on an alpine container and we execute the following: two jobs, echo, hello and echo world, and then we run it and we can use break to generate an exact event which the script and the controller are listening for.

B

And we're passing the name of the project that we saw earlier and the name of the script file that we want to execute.

B

If this was a real world scenario, the brigade.js file will be somewhere in a github repo and the event itself would be generated by an external system and right now uh the brigade worker executed our script and we can start inspecting what happened in our cluster uh brigade offers multiple ways of seeing what's happening in the cluster. First of all, we have a web dashboard that I mentioned earlier uh and brick.

B

Dashboard is a cli command that tunnels traffic from your machine to inside a cluster using port forwarding, and you can see the name of the project. There was uh an event from the brigade. Cli called exec that ran a few seconds ago and there's a job called do nothing, and if we click on it, we see the logs for for our jobs if you're not familiar with or don't have access to a web dashboard or browser in your environment. You can also use a cli dashboard built by the community, there's a brig term command.

B

That starts this dashboard and you can see the same sort of information, but in a terminal dashboard as well. You can see the logs type of job source and everything else.

B

Of course, you can run multiple, create multiple jobs, job objects and run them the same way. But brigade also offers you a way of grouping multiple jobs. Imagine you have lots and lots of jobs, and you want to schedule and orchestrate their execution brigade offers an api called groups, and one of the methods on the group object is run each which makes sure that your jobs are run sequentially, so hello started, its execution is finished and then goodbye started.

B

So if we executed this um this brigade script, we would expect that hello to start and finish and then goodbye to be executed and break term also offers a very nice visual representation of the pipeline invocation and execution.

B

And here you can see brigade started and then, after it finished, the goodbye job was started so and and the logs as well, because this is playing javascript. You also have multiple ways of making sure you can await certain operations.

B

The run function returns a javascript native promise, so, if you're familiar with the async await functionality in javascript, you can also use that as well. If you're, not if you're more familiar with grouping api, you can just use that.

B

Brigade also offers a on sim a very simple way of dealing with storage in kubernetes.

B

There's an object, called storage that you can enable or disable per job, and if you enable storage for for jobs in your event, execution, the brigade worker will create a persistent volume and attach it to each of these jobs that require it. So if we run this, what we expect to happen is the persistent volume will be mounted on mount brigade share by default. You can change that. Of course, uh the first job will write.

B

The first two jobs will write in the file and the third file, and the third job will uh will print the content of the file. So if we go to brigade term and the first one wrote into the file, the second one wrote as well and the third job printed the contents of the particular file again. What this does is. It creates persistent volume storages it attaches them to each of the jobs sequentially and then deletes them at the end of the execution.

B

Keep in mind that the the storage is volatile, so it's deleted at the end of the execution, but it's a very simple way of attaching storage to event. Executions, there's also another type of storage that brigade surfaces in its api called the cache.

B

The build storage is storage per event, so, on every exact on every new exact event, brigade will create a new persistent volume and it will attach it to each of these jobs. In the case of a cache, it's uh the persistent volume survives multiple invocations of the same events type so every time there's a new exact event, and then you cache your job. It's by the name of the job and container uh the same. Persistent volume will be attached and you can use that to, uh for example, build caches, compiler caches and things like that.

B

So if we execute uh this particular script multiple times, we expect um the same persistent volume to be attached to this job and us to be able to write across multiple event, executions. So we can see if we run it again, it will append to that particular file and the same storage will be attached again.

B

So so you can see it was, it was attached again. Another type of interesting thing we can do with uh with brigade is get results out of job executions.

B

Particularly standard output is one of the things we can get out of event executions, and here you can see another way of waiting for uh jobs. You can use the venable uh syntax in javascript is the same sort of result as you would get with a waiting uh job runs, but specifically we start a new job called one. We wait for it to finish. We grab its result, which is the standard output and use it as input for job number two and use it to uh echo whatever the input was.

B

So if we execute this, what we would expect to happen is job1 to start and finish its standard output captured by brigade and used as input for uh job number. Two, and if we look at this, we can see job1 started it finished and then job 2 exited, and we can see the output for the first one used as input for the second one, which is rather difficult to do.

B

If you don't have a way of capturing output with a real programming language, uh the final thing I want to show you with a real programming language is uh handling errors and ways to handle cleanup. For example, if something goes wrong, we have a first job that will exit this text successfully and the second one which exits with an error code every time. What we want to do is make sure that we catch any sort of exceptions in in the execution and make sure to clean up.

B

Do some some other operations, if, if it fails, so, if we execute this, we expect the second job to fail, but only the job, the the execution of the script itself will continue and we can continue to to execute code. That does, for example, cleanup and, as expected, it failed to run to completion, but.

B

The second job failed, but if we have a look at the uh the logs for um for the worker itself, we can see that the execution continued and we could have done other things as well. This is just uh of these are a few things that you can do with brigade for a for a complete uh guide.

B

I recommend you check out the brigade documentation. Everything you've seen here is detailed uh and described here together with many more examples. Thanks enjoy your conference.

A

A

Okay, so just to uh recap a few quick things from uh rahu's demo. This slide is for your reference. If you want to get started quickly, just add an accounting repository for the page here on this slide create a name space for it and install. It then wrong check to make sure that everything is up and running.

A

Okay, so we'll talk quickly about community and integrations. We have built-in support for uh cloud events uh integrations for uh is that first bullet point shouldn't be there cloud events, as I've mentioned already: uh github checks, api um inspirations for prometheus virtual public others and also arbitrary event, data that can be adjusted via generic.

A

um We have a growing ecosystem, so we have uh costly. You saw that in robbie's. Demo is a web-based dashboard for looking at your brigade, pipelines, uh brigade term, which robbie also showed uh started as a community project and then actually got folded into great cli itself, um and there are uh several gateways listed here. um We have gateways for uh bitbucket uh a lot of things um and, uh of course we love developers. Brigade is for developers, this isn't for end users.

A

So we want you to get involved so ways of doing that. There's thoughts.sh, which.

A

uh And some other ways to get involved. You can find us on github or on the kubernetes. We have our own channel there and we also have a bi-weekly community meeting that we haven't been doing for a while we're going to be getting.

A

It started again very shortly, so stay tuned for that um now, it's time to talk about brigade 2.0 in the the future of the project, um so brigade 2.0 is going to usher in sort of a nuanced shift from brigade as an event-driven scripting for kubernetes platform to one that is event driven scripting for kubernetes, so so notes the the parentheses there. So kubernetes fades into the background and becomes a little bit more of an implementation of detail.

A

um Although you know we're not planning on supporting anything other than kubernetes, but we want kubernetes to be a little bit less um in your face as it were, because we want to make brigade useful to developers who don't necessarily have kubernetes expertise. If you were paying close attention to raju's demos, none of the scripts that he showed really had anything that was especially kubernetes specific um within them.

A

So we think there's a lot of potential here for uh the power of brigade to be leveraged by people who aren't necessarily um we're going to be building for the enterprise.

A

We're going to be doing some things that we haven't done previously up until this point we've been super lightweight up until this point um we're going to be getting, I don't want to say heavier, but we're going to be getting a little bit more robust, so we're going to be persisting project and event, data outside of kubernetes in a document store and we're going to be for sustaining log data outside computer meetings, the laws from your job studies and utilizing a message bus to do things like limit concurrent work, both globally and on a per project basis, and to do some fair scheduling and things like that, and we hope that this paves the way for uh an expanded ecosystem.

A

um So we'll be introducing a new api um bindings to that api for go and uh improved support for alternative worker images.

A

So everything that you've seen demo here today uses javascript to define pipelines, but lots of people have asked about using yaml or typescript or something else to um to find their pipelines and and actually the previous kubecon. We showed a demo of that being done so once we have better support for these alternative workers into brigade 2.0, you can probably look for official support for declarative pipelines to follow up with.

A

A

Okay and the uh proposal for brigade 2.0 was uh as we're reporting this either um recently ratified or about to be ratified, in which case development will be starting. So probably by the time you see this video, it's underway.

A

um We are targeting an alpha release by the end of the year and hoping to be ga in the middle of 2021, and with that we'll open it up to questions and.

A

C

Okay, good morning.

B

C

I'm not centered in my all right uh any questions from.

C

C

Okay, um we have a a question from bridget um and let me see if uh here I'm publishing the question. um I believe everybody can see it now, but uh I'll I'll answer it here. um She asks on the 2.0 proposal. Do we see this as being brigade's final form, or will it change further?

C

um You know I I I see. I see it as uh well. It's it's hard to answer um because I can't tell the future, but I see it as being much closer to where we want to be long term. um The the the main thing about brigade 2.0 is that it makes kubernetes more of an implementation detail um than it is today.

C

So I I believe that you know in the unlikely event- and I mean really unlikely event that you know kubernetes like becomes obsolete or fades into obscurity, or something like that that you know you, you might see uh someday uh a brigade 3.0 that that you know introduces support for um you know some kind of uh alternative orchestrator or something like that.

C

um But you know at the at the moment I I see um 2.0 is as getting us as close to where we know we want to be, as as as we are aware, if that answers the.

C

C

Okay and jonathan asks how does brigade scale in terms of the amount of data possible to pass between jobs um and workers? um You know I uh I'll I'll, let radu jump in here if he thinks that that I misspeak at all.

C

um But you know some of the different ways that are available to you, of sharing jobs between uh sorry sharing data between jobs would uh include using uh the file system, so you can have a you, can have a read, write many volume, such as an nfs volume, or something like that attached to all of your jobs, and so they can actually share a file system. So I guess the the the question in terms of limits. Is you know how big of a file can you write um and I'll I'll?

C

Let radu correct me if he thinks that's wrong.

B

Yeah, I think you're right in both cases. Essentially, you can pass data either as standard input or arguments for the job you're about to start or uh write. The data in a volume that you can share between jobs, either way, there's no technical limit that either brigade or linux imposes on the file size.

B

That being said, we've usually guided people towards uh using standard input if they have very quick output from one container to the other, and they can use standard input for that and use actual kubernetes volumes for something more robust where you want to pass multiple files or larger amounts of data. That being said, both of them should work as well.

B

There's another question: does running the script: have the possibility of accessing the shared storage? um So this whenever running the script, the script will actually orchestrate starting the jobs and attaching the volumes. uh So technically I technically you do have access to it, but it's not exposed in in the api that you're using. So if you, if you need to access shared storage, the recommended way of doing that is by starting a job and accessing the storage there. I would be curious to understand the the use case for accessing the shared storage from brigadejs itself.

C

Yeah can I comment on this as as well radu, um so so yeah the as things stand. Currently, um the shared storage um is created by the worker, um so the worker is the thing that's executing your brigade.js. So during the execution of the script um the shared storage gets created and and then control gets passed to your script, um because the shared storage is created by the worker, um it's too late to mount that volume into the worker.

C

So your your script does not currently have direct access to that volume, um but this isn't the first time we've heard this question um people have asked about this before um and while I might not be entirely clear about the use case, it's it's been.

C

It's been requested, often enough that I I foresee this changing in brigade 2.0, especially because, as we're trying to add better support for alternative workers, we want to um lower the bar um for what it takes to um you know, implement um you know a custom worker which means offloading as as much responsibility to kind of the brigade core as possible.

C

So so definitely I foresee this changing in brigade 2.0, where, by the time a worker launches, the shared volume um has already been created and can be mounted into the worker itself if, if it needs to be accessed, so um I do foresee that changing and I hope that answers your question.

B

And backing up on my question a little bit uh while we well uh the workflow can describe, is accurate for default. Shared storage in brigade uh there's nothing stopping you from importing via kubernetes, javascript library, client library in brigadejs and creating a volume there and then manually mounting it. So you have that option and I think the document on docs.brigade.sage we have a few examples of actually importing the kubernetes, javascript, client and starting creating namespaces, and things like that. So you definitely have that option there, although it's not necessarily.

B

Straightforward.

C

Okay- and I think that's it uh for questions, I guess so we're going to uh wrap up and thank you all for um coming to our talk.

B

Thank you enjoy the rest of your conference.