 Hi, we're gonna get started now. Welcome to the talk. We're going to go through creating a first boss release today But first we'll introduce ourselves. I'm Rebecca on the left there I've been on the boss team for just over a year and I'm a core contributor and I work out of the Toronto office with Pivotal Hi, I'm Peter. I also work in the Toronto office at Pivotal I work on Gemfire, which is also known as Apache Geode and I've been using Bosch for up to three years So a quick overview our session today. We're gonna do start off with a short review of what Bosch is and what a Bosch deployment is We're gonna mostly be talking about the building blocks of a Bosch release and at the very end We're gonna end it off with a Bosch deployment and a couple other Interesting Bosch features that you can take advantage of So can I get a show of hands who here has an a Bosch deployment before? Okay, almost half the room almost the whole room. Okay, cool for those of you who haven't We're gonna go over what a Bosch deployment is. But first, what is Bosch? Bosch is a project that unifies release engineering deployment lifecycle management of small and large scale cloud software So let's unpack this a little bit The first part is release engineering Which is the practice of gathering the software that you want to make available for people people to consume Second part of it is deployment. So now that you've gathered your software How do you put it somewhere so people can start using it and lastly life cycle management? How do you once you have your software in a place where people can access it? How do you start it? How do you stop it? How do you upgrade it and Throughout this presentation. We're gonna go through each one of these components So a Bosch deployment starts off with the Bosch director which is just a VM running Bosch software and It has a special ability to create VMs. It's connected to a CPI a cloud provider interface like Google or Amazon or Open stack and it creates VMs and when it does that we call those Bosch deployments So one or a set of VMs is a Bosch deployment You need to tell Bosch what you'll be running on these VMs and There's two parts of that the first part is your code It's what you want to make available on your deployment and we like to call that the Bosch release Which is what today's whole talk will be focused on second part of this is the OS and we call that the Bosch stem cell and To create a deployment you need these pieces you take your Bosch release Bosch stem cell you upload it to your Bosch director And it takes that and creates a Bosch deployment in that you have your code running on the OS running on one or a set of VMs To do to help with all of this we have the Bosch CLI it will manage the movement of Software and as you see today it also does scaffolding so throw the presentation We'll use the Bosch CLI to help us scaffold out all the pieces we need for Bosch So a quick overview of the building blocks of Bosch release We have blobs like binary large objects. You have your source code You have packages and lastly you have jobs and with all of these four pieces you have a complete Bosch release that is Possible to deploy Hey, thanks Peter for bringing us through how Basis of Bosch works. So of course with any kind of 101 talk where we make a thing for the first time We'll go with hello world. So what we'll do is we'll make a a new Bosch release called hello world So create a directory for the contents and get into it and then we'll initialize the release So this is what Peter mentioned where the CLI is used for scaffolding as well So you can say Bosch and knit release and this will create a bit of structure to this directory with some files So blobs packages and source those things Peter just mentioned How do those come into play? So blobs Is what is in a release and they're usually the binary large objects that are used for runtime or compilation Dependencies these are things that are referenced to they're not necessarily checked in to your release They're not really part of your source source code Source code though is your code So this is the code that you're interested in getting into a deployment making available to your users and And packages wrap around source code and blobs to instruct Bosch is how to Install or compile or just manage those pieces of code and this is the interface that you use to Make your make your release deployable So first let's add some source code. This will go in the source directory For us. We're just going to make a tiny Server in Golang which responds with the word yo every time you send any request to it That's what kind of wanted to move away from hello. So I'm going to use yo instead So now we're building up our release on the left here will show the file structure You'll be building and on the right is our kind of visual representation. So so far. We have this hello go Which is our tiny little Golang server? Okay, so we mentioned blobs before these are referenced things that you would include in a release But they're not necessarily part of your source code These are used to compile your source code or maybe it's a program like my sequel you're putting in a release So for us, we're going to configure a small blob store What we would call Something that stores these blobs on disk for temporary purposes for release development We're going to configure one on disk today, but you can also use s3 for when you want to publish these releases So why are we doing this at all? And it's because we want to add a compilation dependency if you've written any code in Golang before you know You need to compile this. How are we going to do that? So we'll add a package which will be Dependency for source compilation. So add Golang as a dependency and our release This package will reference a blob So that looks like this we're going to clone a Predefined package that the Bosch team has put together for you already. So we'll clone the Bosch packages Golang release We'll get into our own release. We're building and we'll say Bosch vendor package This will add that Golang package as a dependency for us to use later So now in addition to our Our source file, we also have this package we've added So this is still within our release and it's just a component of our release and that package references this blob That we're going to use later So now that we've got a dependency here that will eventually use we need another package for our source code And this is so we can tell Bosch how to actually compile and build this source code so we can run it later Again, we'll use the CLI to scaffold this package out. We can say Bosch generate package and we'll call this hello server Okay, so now we have two packages that we're dealing with we have the hello server package I just made and we have that other Golang one the one below it still Part of packaging with Bosch is to specify and define how to actually work with your source code So part of this specification will call We'll give our package a name which is hello server, which we already scaffolded and We'll say that this package depends on another so our package depends on the Golang package We already added so now we'll be able to use this package while building our source code and For our package, we're interested in the files in the source directory that end in go So you can use this glob pattern in many different ways for your source code, too So now we've built up a little bit more of our package We defined the dependency between the Golang package in our source package and we've added this spec file, which is the purple Okay, so I've talked about building source code. So let's finally get to that It's how do we do that we we're not going to fill out this file called packaging which is to actually Build our source first. We'll reference that Golang package I keep talking about so this we can just reference the package and That Golang package has a few special tools that the Bosch team has put together Which gives a nice compilation environment which allows us to simply say go build so now we have our our binary and That ends up just being in the same directory So now we're going to copy this to a well-defined location that Bosch gives us for later reference. So we'll be able to Touch our binary here and tell it to run So as part of our source package now or our package that we're building to actually compile our source code We have the spec and packaging file now. So we're almost done Well, great. That's really nice and stuff. But now with these this package. How do we actually run it? We're actually we've got it compiled. It's there, but how do we run it? So this is where our jobs come in so the packages were responsible for making our source code and our blobs available to the release and It's the jobs responsibility to control how to run them So jobs interact with packages and they're responsible for handling requests like start and stop and If you've ever run a go app or node app you run node app.js or go run Whatever and this is where that's specified. It's the how of how to run the code that's sitting in your Bosch release It also relax reacts to other lifecycle events. I've only mentioned start for now There's stop and there's a whole list of other ones that will go over in the end before hello world will keep with start So to create our job we can use the Bosch see a lie as well run Bosch generate job. Yo so our job is called yo and It creates a set of familiar Files Under the jobs directory under the yo directory Let's take a look at spec for now spec is similar to patching packaging spec. It's short for specification It has a name. We'll call it yo it has templates Which is our scripts that handle the start and stop that I mentioned It has the list of packages that this job needs and is going to use and lastly it has a set of properties We're gonna leave that empty for now because we don't need anything but again, Rebecca will go over What kind of fun things you can put in there at the end? So now that we have our spec file, there's two other files that we need before this job is complete Okay, so we've defined our job But we need a little bit more in order to run our package still so we'll get into job process control So what I mean by that is on the VM when you're running your Bosch release We'll need a way to start it stop it and monitor it in case it starts failing So Bosch uses Monit to accomplish this on the VM for local processes And then our scripts that we've defined earlier in our templates are used as a start and stop program for Monit Later on when we deploy this release What actually happens is the director issues a start command to Monit and then Monit will actually start your job Through the control script we already defined So we've got the spec file now and this Monit file we have filled out Continuing a job process control. What does that script look like to actually control our package? So this is where we connect the job to running our package So for my control script here, I have start and I have stop for start We just kind of echo the PID or the process identifier of this Shell script and then we're actually going to now run our hello binary So the var beacon packages. Hello server. Hello here the exec will actually start running our binary that we compiled earlier For stop. We'll just simply kill it off and remove that PID file Now we have these three files that are defining our job and this is how you now will run the package This control script is the one that controls our package running Okay, that's actually all it is to build this first release seemed kind of like a lot But it's not too bad if you go through with us. So now our release is ready How do we actually deploy it? so Again, we're going to use the Bosch CLI to help us but instead of scaffolding We're going to use it to move files around So we can start with the Bosch create release and it takes a snapshot of what you have so far You run Bosch upload release and it moves that onto the Bosch director So going back to our Bosch deployment Diagram we have the what that you put on to the Bosch director and it takes it and creates a deployment out of it One thing that I left out of this diagram is the how and we call that the Bosch manifest In the Bosch manifest is where you specify things like VM size the number of VMs You want to use some networking information and that's the how and usually written or it has to be written in YAML So for our hello world We'll have this simply YAML file has a name Specifies what releases you'll be using what we'll be using hello world And it specifies the jobs you'll be running The last line here specifies instances So this is one of the cool features of Bosch You can configure things really easily to scale us up to like 10 servers if you wanted to So now that we have The what and the how we're able to create our Bosch deployment by earning Bosch deploy So what's happening when you deploy Bosch so since we define our packages through or we have our blobs and source code defined through packages Bosch puts that on your VM and because we define our jobs Bosch will start a job and When the start command it issued which is happens by default when you do Bosch deploy Is actually able to start running your process and that is a Bosch deployment with all the pieces in there Did you guys get that photo? Okay Okay, so now we have our very first release deployed and if you were to actually Send a request so that VM it would reply back with yo it does work. I did try it really works There's a lot more that you can do with Bosch releases in the scope of a deployment So go through some of that now First of all you can actually deploy this release on any supported cloud now This release as you may have noticed in the what of that diagram Peter was showing It's a very portable piece of software now. You can deploy this on any supported cloud You can also share information between jobs of separate releases with something called Bosch links So you can share things like maybe credentials between a database server and a web server Without actually entering any credentials in your manifest at all One thing that can speed up deployments if you know you'll be deploying over the same Operating system as you can pre-compile your release for that operating system. So deployments become faster Another thing you can do is using the Bosch process manager or BPM you can Containerize your jobs and add some isolation In addition to that you can react to more lifecycle events during the deployment process with more templates We went over a start today and stop but you can do more So during the deployment process The Bosch director issues a few more lifecycle events to the job and you can optionally fill out templates for these If you so desire so one such as lifecycle event is pre-start So you might want to use this to create some directories or maybe gem install or something like that to prepare your software for running even more and Then in your template side on the left here, you can Define a pre-start script these have to be well named well defined So on the left side here pre-start dot it dot s8 you can name that anything you want But on the right side that has to be well defined and that's in our documentation pages There's a few more lifecycle events as well. You can react to Post start post deploy drain and post stop. There's a new one coming as well called pre-stop And this gives you better control over your software when you run it That's the end of our session. So thank you very much for coming out If you have any questions at all join us on Slack at any time if you have any questions right now about the session We'd be happy to help on the side. We find that's a little better for those kinds of questions And the documentation pages on the right here are a great resource for building your release even further. Thank you