 Hello everyone, welcome to the talk, building your first Bosch release. So we're going to talk about what is Bosch, what are releases, and how to build them. So what is Bosch? Bosch is an open source cluster management tool developed and used by Pivotal and other companies to efficiently manage large scale systems like cloud funding. It can handle infrastructure provisioning, release engineering, configuration management, and deployment life cycle of a complex distributed system. Several people asked me during CF Summit if Bosch is something like Chef or Puppet. Well, some features of Bosch can be compared to configuration management systems, but it does much more than just configuration management. It can manage deployments that span hundreds of VMs, providing all required tooling for release engineering, rolling cluster updates, operating system updates, real time monitoring, and recovery. It can utilize your infrastructure efficiently by provisioning, allocating, and releasing resources for your deployment in a controlled manner. Rolling updates is a hard problem to solve. So many systems leave it up to operator to figure out the proper order of updates and minimize the number of disruptions to production systems. Bosch deployment manifest is completely declarative. The system itself takes care of understanding what is currently running in your cloud, what do you intend to run, and figures out the best way of running updates, minimizing the number of disruptions. If something did not change, it's not gonna get updated, only affected nodes will be touched. Release engineering is part of Bosch. It is opinionated about structure and lifecycle of the release. It provides required tooling for creating and updating your releases. It is easy to iterate on your releases while developing and create production releases. Everything is fingerprinted and incremental. If something did not change, it's not gonna get included in release, rebuilt, and deployed. Bosch can perform all kind of complex updates, including operating system updates. So operator can specify the OS image version he wants to deploy and Bosch will take care of recreating every node in a deployment with the base OS image, with the new version of base OS image. Bosch provides a built-in mechanism for detecting potential infrastructure problems. It provides recovery mechanisms for failing services and inconsistent infrastructure state. As you can see, Bosch takes a holistic approach to managing your deployments. It is a prescribed solution that will take care of your complex workloads every step of the way. Let's quickly take a look how Bosch works. So the main Bosch component is director. Director exposes a RESTful API that allows you to manage your deployments, manage your releases, get the current state of your deployment, and perform other administrative tasks. You configure director with the cloud config, which contains your cloud provider properties that define types of resources that your deployments can use, like networks, VM types, disks. Director interacts with cloud providers via something we call cloud provider interface, or CPI. CPI abstracts away infrastructure details to a well-defined interface. It has methods like create VM, create disk, attach disk. This way, if you have your Amazon or GCE or any other infrastructure, you can make it work with Bosch by just implementing the CPI. We officially support CPIs for AWS OpenStack, vSphere, and other infrastructures, but since it's all open source, you can add support for infrastructure by implementing the CPI. Bosch creates VMs from a set of predefined templates, which we call stem cells. You can think of a stem cell as AMI for AWS, for example. And at its core, stem cell is a base OS image with some hardening on top of it and Bosch agent. Bosch agent is a process that runs on every VM. We officially support stem cells for multiple infrastructures. You can download them at bosch.io website, and they're constantly released with new security updates to kernel and base OS packages. So once VM that was created from stem cell boots up, Bosch agent starts running on that VM. And agent bootstraps itself. It fetches information provided by CPI, and that information tells agent how to interact with the rest of the system. So once agent is ready, it starts reporting to director, and director starts issuing commands to the agent to configure VM in a certain way, like configure networks, setup disks, and install software. Agents are also responsible for supervising jobs that are running on that VM and also perform some housekeeping, like rolling over debug logs, reporting resource usages, and et cetera. In order for software to be runnable on Bosch, it needs to be packaged into release. Manifest is where it ties it all together. Manifest defines your deployment layout, what releases to deploy, and what stem cells to use. So let's quickly take a look at deployment manifest. So manifest consists of the following sections. It has some deployment information, list of stem cells to use to provision VMs, releases to deploy, update section defines how to perform a rolling update of your deployment, and instance groups define what software to install, what stem cells to use to provision VM, and what jobs from releases to install on that VM. So what is release? Let's say you have some source files, and in order to deploy those source files, you need to package them into release. This is how Bosch understands how to run your software, how to deploy it. Release contains all the bits that needed to be deployed, like your package contents, installation scripts, and configuration file templates. So every release consists of the following parts. It has your software source files, it has packages that define how to install your software, and it has jobs that specify how to run your software. So let's take a look at example release, simple release. Let's say you have some goal application, you will need to include its source files in a source directory. Then in order to install those files, you will need to provide a goaling binary. So usually releases live in Git repos, and large objects are not included in release itself. Instead they're referenced as some block store identifiers like S3 or Swift. And Bosch will take care of downloading those binaries and including them in your release once you're gonna create your release for the first time, and then it's gonna cache them for subsequent use. Also you need to provide a packaging script where you will specify how to install your software. And then you'll have to provide the startup script that will define how to run your software on Bosch. So let's take a look what Bosch will do, how it's gonna deploy your release. So it will start by compiling packages that were updated. It detects what source files were changed, it will create a predefined number of compilation VMs, and it will start compiling all your source packages that were changed. Packages might depend on other packages and Bosch will take care of resolving dependency graph and making sure to provide all the packages that your dependencies need on the node that runs them. So once the packages are compiled, Bosch will store them in its block store. One of the nice things about this approach is that Bosch only compiles packages once, and then it distributes them across all the nodes that need those packages. So this way, scaling up the number of instances is not slowed down by package compilation because Bosch already has all the packages pre-compiled in its block store. So release engineering is completely automated in the sense that if you change one file, then every package that is using that file and every job that is using that package is going to be rebuilt for that new version. If something did not change, it won't get rebuilt. And one of the design principles of Bosch is that it does a minimal amount of work to deploy the new version of your software. If something did not change, it's not gonna get updated, restarted, and deployed. Whether you're working on a new deployment or an existing deployment, the flow every time the same. You create a new version of your release. You upload that version of your release to director. Then you can make some changes to your manifest file, and then you would run Bosch Deploy. The deployment process will reach out to every node in the existing deployment and try to match its state and its actual state to your desired intent that is declared in your deployment manifest and by your release. Release and deployment manifest are completely declarative. Bosch makes sure that record of intent matches the actual state of the system. So let's take a look how you can configure release. You can specify a list of properties in your job manifest file and then you can reference those properties in your release configuration template. Also, you will provide values for those properties in your manifest. These properties will be filled out by Bosch when it's gonna process those configuration file templates. So this is how you configure your releases. In case if you wanna connect two services together, you can use links feature. So let's say you have a web server release and your web application needs a database access. So it can define that it needs these database properties. Then your MySQL release on the other hand can say that it provides these database properties. So what that means is that if these two jobs are deployed together, Bosch will wire them up automatically and it will make database properties available to your web server job. So now your web server job can reference those properties in its configuration templates. Let's do demo. Okay, so I have a concourse release deployed and let's take a look at it. So this is a concourse release. Concourse is a CI system that we use in Cloud Fundry and you can deploy it with Bosch. So it provides source files. As you can see it contains a bunch of goal link packages so they need to be provided in the source directory. Then it includes packages that specify how to install them. So let's take a look at this ATC package. Every package contains a manifest file which specifies what files to include from your source files and also what dependencies need to be provided when this package is gonna be compiled. As you can see this package depends on goal link package and that means that Bosch will first compile goal link package and then provide it to the compilation VM that will install your ATC package. So the important part of the package is the packaging script which defines how to install your software. So you can see here they run some Go build. So basically that tells Bosch how to transform your software into something that's runnable on Bosch. Then release contains jobs folder. These are different services that you can reference in your manifest and they specify how to run your software. So here every job has a manifest file which defines what packages are included in this job and what properties this job exposes. So what that means is that if you're going to deploy this job you can configure these properties in your deploy manifest. How these properties are being used? They're being used in the configuration file templates that also are included in the job. So here we have this template ATC CTL. So let's take a look at it and you can see how here these properties are being referenced. So Bosch will fill out the values for these properties that you specified in your manifest during deploy. Then also this package here is using links. So it depends on database and it specifies that it consumes database properties and if it's going to be deployed alongside with your database job or job that provides a database link Bosch will make your database job properties available to this package. So let's take a look at this Postgres SQL manifest file so you can see here it provides link database with these properties. So now your ATC configuration file templates can use these properties directly in a template. Depending on which platform your release is going to be running release offers must provide job supervisor configuration file. So for Linux platform, Bosch is using a monit to supervise running jobs and release offers might must include the monit file. So every monit file specifies what processes are going to be running as part of this job, how to start and how to stop these processes. So these are how the jobs look like and here we have also some blobs included in this release just to show you that these are some S-free references. So some binaries or tar balls, they will be downloaded when you for the first time gonna create this release. All right, so maybe let's change our release somehow and redeploy it. So I'm gonna show you my running concourse here. So this is a concourse that was deployed before and let's just add some color to it. So I'm gonna add some nice background image. So we are updating a source file which is somewhere here in the source directory. Then I'm going to my concourse release directory. And before I start anything, I need to regenerate JavaScript files. Then I'm gonna build new version of my release. So let's take a look. I'm gonna run Bosch create release. Then I'm gonna upload this release to director and then I'm gonna run deploy. So as you can see, Bosch figures out that ATC package was changed and it generates a new version of the release. So here that's a new version of release and then it's uploading this release to director and then it's running deploy. So it notices that the only thing that was changed is the release version. And both of these packages depend on the source file that I just changed. So it's gonna recompile both of these packages and then it's gonna update the job with the new compiled bits. So while it's doing that, let's take a look how Bosch versions releases. Usually developers iterate quite a lot on their releases until they happy with their feature until it's stable enough or it passed CI pipeline. Once they happy with their dev releases, they can mark it as final. And doing so basically applies a different versioning schema to your release and make it available to other people. So if you wanna share your release with others, you will share your final release. Others don't see your dev release history and you can internally iterate on it as much as you want. It is guaranteed that the final release will have exactly the same package contents as the dev release it was generated from on every machine every time. So let's take a look how our deploy is going. So it's still going. So maybe. You just couldn't leave it alone, could you? If you work on a bump Bosch, it's a two point error. Yeah, you're not allowed, you can tell people. I do have a question though. Yeah. When you have the different shots and stuff showing the different blocks and all that, do you say they were on S3? How does it know they're on S3 as opposed to... So there is a configuration also included in your release that specifies the Blob Store information. Okay, thank you. So here I have this. Final YAML, which contains your Blob Store. And also this is where your final releases will be stored. So if you're gonna upload them, you would put them in a separate configuration file which is usually git ignored so that you don't accidentally push it. And whenever you're gonna update your packages, you will have this file in your release directory. Exactly. All right, so we got our new version of Concord's deployed. So let's take a look at it. So it's hard to beat that, but... I also wanted to show that we can change some properties in our manifest that our release exposes. So here we have our job that defines properties that you can configure in your deploying manifest. So like this IP port, and also like this username and password. So let's maybe add some authentication to our Concord's deployment. So I'm gonna modify manifest file. And I'm gonna specify properties for ATC drop here because it exposes those properties. So we're gonna provide username, password, very secure, and I'm gonna run for deploy. And it notices that those properties were changed and let's deploy it. As you can see, it's not recompiling any packages. There were no source file changes. The only thing that was changed is your deployment and what it's gonna do is gonna process your configuration templates and provide them to your job and restart the job of the new configuration. So here we go. That was fast. Now let's take a look. Now our pipeline is gone and it requires us to log in with some basic authentication. Yep, that's one. So you can learn more about Bosch at these resources. We just looked at release engineering process, structure of deployment manifest, but there's much more to Bosch. So go to Bosch.io website. You can, it's a great source of Bosch documentation. Check out this Bosch tutorial. Also good introduction to Bosch. And if you're interested in contributing to Bosch, it's all open source. Go to our GitHub repo and start contributing. Do we have any other questions? We have a mic here. Stand up and ask a question. Any more questions? Okay, great. Thank you very much.