 So I guess we'll get started right now. Thanks everyone for closing out CF Summit with us. My name is Angela Chin. I'm a software engineer at Pivotal. And I'm Christian Ng, another software engineer at Pivotal. And today we'll be talking about deploying Cloud Boundary using the newest set of open source tools, Bosch Bootloader, or Bubble for short, Bosch 2.0, and CF deployment. So before we delve into the meat of the talk, we just want to take a quick temperature of the room to see where everybody was at. So who here has used Bosch Bootloader before? Hey, awesome. How many of you have used Bosch before? Cool. How about use the new set of features in Bosch 2.0? How about deploy CF using CF release? How about CF deployment? OK. So it seems like we have a good variety in this audience about all of these sets of tools. But we're really hoping by the end of the talk that everybody is sort of level set on how to use all of these tools and what the power of using all these tools is and is able to go out there and deploy open source Cloud Foundry on your own. Cool. So to kind of start us off, I want to describe what does it mean to deploy Cloud Foundry? What does it take? So as you can see, this is a very complex diagram, which you don't have to dig too deeply into it. But it kind of just shows all the VMs that you need to deploy Cloud Foundry, along with all the software and all the configuration, like what needs to talk to what, to deploy a Cloud Foundry. And if you were to do this manually, it'd be super complex. Luckily, we have a tool called Bosch, which handles all of this for us. And for those of you who haven't used or heard of Bosch, essentially, you could take like this deployment manifest, which is this huge YAML document. Give that to Bosch, and then it will create all the VMs, upload all the software, and configure it all for you. So to dive a little deeper, this is basically the description on Bosch.io for Bosch. So it's an open source tool for release engineering, deployment, lifecycle management, and monitoring of distributed systems. So to kind of unpack that, since that's a lot of information, basically, Bosch will handle deploying your VMs. So this kind of means creating all the VMs, uploading all the software, which is in the form of Bosch releases, which is just kind of a special format that Bosch understands how to start and stop your software. So it'll take those Bosch releases and start all the software on those VMs and get it configured for you. Second is Bosch will handle the lifecycle of all the software. So Bosch will handle starting all the software and also upgrading and doing rolling upgrades. And Bosch will also watch all your VMs. So if you lose a VM, Bosch will create a new VM for you, put all the software back on, get it up and running. And if a piece of software crashes on a VM, then Bosch will also try to restart that software. So Bosch is cool in that it makes deploying Cloud Foundry pretty easy. You just take that manifest and Bosch will play it. But before you even get to that stage, you have to try to figure out, how are you going to deploy a Bosch director? So usually what that requires is a network, usually like a public subnet and a private subnet. And then you'll throw your jump box into your public subnet and your Bosch and your private. And also some firewall rules to take care of all the configuration. So second, you'll also need some load balancers to kind of expose your apps that are running in Cloud Foundry to the internet. And then finally, you'll Bosch deploy your Cloud Foundry. And so if you even make it that far, you figured out how to deploy your Bosch director. This is great. You now want to deploy Cloud Foundry. You run into a second major hiccup. We said, you know, Bosch is great. You can just give a deployment manifest and you get CF up and running. But how exactly are you configuring that deployment manifest? The deployment manifest is a lot of YAML. It's often thousands of lines long. And you have to specify all the configurations for your VMs. You need to say what software you want to run on all of your VMs. You need to tell it the network. You need to get the properties. You need to get the secrets. And there's a lot of places that you could make a mistake. And so this is the second major hiccup that a lot of users previously faced. So even though Bosch is giving you a lot of power in that you have releases that pre-package the software and take away that operational complexity of deploying it, you have this new complexity of making sure that you have all this information correctly formatted. And so we realize this pain. And that's really the motivation for our talk is we want to simplify how you deploy Cloud Foundry. So for the past, I'd say, year and a half, core CF teams have been working on simplifying a setup for Cloud Foundry by creating a set of new tools that allow an easy experience for operators to get from nothing to Cloud Foundry in a matter of a couple of hours. Most of it wait time for VMs and software to be up and running. And so these tools are as followed. First is Bosch bootloader, or bubble for short, which takes you from nothing to having a Bosch director plus the underlying infrastructure you need to deploy your Cloud Foundry. And so bubble is pretty opinionated. It takes a lot of the complexity away from the user. And so you can just run two commands and you get your Bosch director and your load balancers that you can then use to deploy CF. Under the hood, bubble is using a lot of the new features that are present in Bosch 2.0. And Bosch 2.0 is also heavily used in CF deployment, which is the repository that now houses the main manifests for deploying the Cloud Foundry. And really the power in all of these tools isn't that they each are solving an individual use case in the workflow of deploying Cloud Foundry, but it's how they're integrated and coupled with one another. So for example, you could be thinking about bubble as a tool that gives you a Bosch director. But we prefer for you to think about it as a tool that gives you a Bosch director for the purpose of deploying CF. And we see this through integrations in our pipelines. We'll have pipelines where we deploy a Bosch director using bubble and then deploy CF using that Bosch director. And so we have teams constantly running these pipelines. So we will catch if a change in bubble breaks its compatibility with CF deployment. So it should never hit you as an end user of these tools. These tools should always be compatible with one another for you. And this way, you can then deploy Cloud Foundry in a way that's automatable, repeatable, and reproducible. So with that, we'll dive a little bit into what each of these tools does and what it gets you. Cool. And just to give you a little visual as to what we're kind of describing today, this is a concourse pipeline. And if you haven't used concourse, it's a CI CD tool that we use for the core CF teams to help automate a lot of these tasks. So the first box is bubble up. It's kind of hard to read. But this will create your Bosch director and then deploy CF in the second box to deploy your Cloud Foundry on top of that infrastructure. And then finally, deploying it out. So we're going to dive into that first box, bubble up. So to reiterate, bubble will stand up all the underlying infrastructure that CF needs and Bosch needs for you. And it does that using Terraform. And if you haven't heard of Terraform, it's basically a declarative way to create all the IaaS like networks, firewall rules, subnets, IPs, whatever. And the nice thing about Terraform is that it's also idempotent so that we could run it over and over and we end up with the same state. After bubble creates the infrastructure for you, it'll then create the Bosch director. And this Bosch director is created with Bosch deployment, which also has credub and will also create a jump box for you. So at the end, if you refer back to that first diagram, you'll end up with this state where you have basically everything you need to Bosch deploy a CF. And again, bubble is also idempotent, which is useful for automating this so you could run it over and over again. And you'll always end up with the same state. And it's also helpful for upgrading your Bosch director or whatever infrastructure. If bubble were to release a new patch to fix like a security hole or update your Bosch director, you could just run bubble up again with the new version and it'll update your old Bosch director for you. And it currently supports AWS and GCP, and it currently has partial Azure support. Cool. So once you've bubbled up and you have this Bosch director, bubble also gives you a few helper functions to target this Bosch director, one of which is Bubble Prince Ev, which basically will print out all the environment variables, along with a way to create a SOX5 proxy to your jump box so that the Bosch CLI knows how to talk to the Bosch director through the jump box. The second thing bubble will give you, which is probably one of the more important things, is it'll give you a Cloud Config. So in the Bosch 1.0 world, the manifest had a lot of IA specific information that you had to configure to make sure that Bosch could deploy VMs into whatever network and attach the correct firewall rules for you. But all of that is abstracted out in Bosch 2.0 into this thing called the Cloud Config. And this is attached to your Bosch director so that your deployment manifest no longer has to deal with it. So what this kind of looks like is basically a whole bunch of AZs, disk types, networks, VM types, and VM extensions. And the convenient thing about this is that bubble will, it has a specific naming convention across IAZs to keep whatever deployments against bubble IAZ agnostic, like CF deployment, which gives it an easy way to basically interface with CF deployment. And if you're kind of wondering what this looks like under the hood of that box, it's very simple. It's basically a bubble up and then a bubble create LBs type CF, and that's it. Great. So now that we've run the first box here, we're now ready with a Bosch director and the underlying infrastructure to deploy CF using CF deployment. So what exactly is CF deployment? CF deployment, as I mentioned previously, is the repository that houses the main manifest for deploying Cloud Foundry. And CF deployment really optimizes for several things. First, it really places human reliability at the forefront of the user experience. We really want to make it easy for operators to understand and deploy Cloud Foundry and know what they're deploying when they deploy their CF installation. CF deployment is also on the bleeding edge. So if other teams are releasing new experimental features, there's usually a configuration in CF deployment in order to turn it on and try it out. And with us moving more towards CF deployment, you might not find an ability to turn on that experimental feature as easily using CF release. Also, CF deployment is TLS for all components that can be TLS by default, which is just best security practices. So we're making sure that you, as an operator, don't shoot yourself in the foot. And CF deployment is also geared towards production. So any components that should be highly available are, by default, turned on to be HA and are also streaked across multiple availability sounds. So this all sounds great, right? But you might be wondering, how exactly am I getting all of these features? And so CF deployment really gets a lot of this from things that are in Bosch 2.0. So for example, human readability. How do we really enhance the operator's experience? Well, one way we do this is by having a static main manifest. And the way CF deployment has a static main manifest is due to Bosch 2.0 features, such as a Cloud config, an ops file, and bar store. As Christian's already talked about the Cloud config and how it allows for us to have a static main manifest because of it being i as agnostic, let's dive into the other two. Ops files and bar stores. So an ops file can be thought of as a configuration that can be applied on top of your main static manifest. And so it's usually a short YAML file. We can see an example right here where you say a type. So maybe you want to replace a value in the main manifest and you give a path. So in this case, let's say I want to bump the number of cell instances to a value of five. You then take this file and you apply it to the main manifest, which might say have a default value of two. And in your resulting Cloud boundary that's deployed, you'll have the five instances that you desire. And the really great thing about this is by applying ops files, each ops file can be its own modular configuration. So you could have an ops file that's looking specifically at enabling TCP routing, for example, or an ops file that's looking at disabling the Cloud controller bridge. And so this way, you as an operator, you have the static main manifest. And you know exactly what type of Cloud boundary you're deploying because you can see each of the specific ops files you're applying on top of it. And so this is also great because you can write your own ops files too. So one common thing that I do a lot is I'll have an instance count overrides. So I can put all the instance counts that I want for a particular CF deployment in one ops file. And I know when I'm applying it that I get a different set of instances. And so this really does enhance the user experience. The other thing I mentioned that CF deployment uses is var stores. So before we had, watch 2.0, we had this idea of a var store. If you had something like, say, a database, you had to set all the values in it. And one of the things for your database that you'd have to set would be your password. So if you are extremely awful, maybe you inlined your password. I really hope you never did that. More likely, you probably put the password in some other file and use some third-party tooling, such as Spiff, to merge that secret into your manifest. But third-party tooling isn't necessarily made for our use case and could sometimes be difficult to operate. So with a var store, so with the idea of a var store, we now have this main file that will house all of your secrets. And so you can denote when you want to use a value from your var store by giving a special syntax of double parentheses. And that way, Bosch knows to look at your var store to get the secret and place it in when deploying Cloud Foundry. Another really cool thing is if I didn't have, in this case, my DiegoDB password set up before I tried to deploy Cloud Foundry, Bosch would actually generate this secret for me. And this is really powerful, especially in the case of turning on all components that can use TLS to use TLS by default. Because one of the major things that turned people away from using TLS is often making sure that they set up everything correctly, that their CAs, inserts, and keys, all the values are correctly configured. But by having this var store, where Bosch is generating you your CAs, inserts, and keys, you don't have to worry about making that human mistake. And so that's another added benefit. So you might be wondering, OK, I now understand how you get some of these cool features that CIF deployment is giving. How do I actually use it? Well, all you have to do is run Bosch deploy, give a path to the main manifest, plus any additional ops files. And because Bubble now has cred hub support for your Bosch director, it will pull your var store from cred hub. So you don't even have to worry about storing that file in a secure place. And then you have your Cloud Foundry up and running, and you can deploy your apps to it. Cool. And another thing we want to mention is that Bubble also supports concourse. So you'll be able to do a bubble up, bubble create LBs type concourse, and then do a Bosch deploy with a concourse manifest to create a concourse that you can then use to automate your CIF deployment. Release integration, the team that maintains CIF deployment has also published a concourse task that could be used to do basically everything that we've shown in this previous slide deck. And that's what that looks like. So you might be wondering, how are people currently using these tools? Well, the majority of core Cloud Foundry development teams are using these tools right now in their pipelines. So this is one example of a real world use case, which is from the networking team, where we have an environment called Pickle Helm, which is the name of a hat. And we have a Pickle Helm bubble up. So you create your Bosch director for your Pickle Helm environment. You have a Pickle Helm deploy, which will deploy your Cloud Foundry. And then we have a box called Pickle Helm test, which will run the networking acceptance tests against that deployment. We also have a delete Pickle Helm deployment and a Pickle Helm bubble destroy, which will allow us to tear down our Cloud Foundry and also tear down the Bosch director and any underlying infrastructure. Because if you're not going to use this environment for a prolonged period of time, why keep it up and spend money on resources you're not using? Cool. So to end this, we want to talk about some of the future plans that we have for some of these. So first is bubble terraform customization. As we mentioned before, bubble currently is highly opinionated, which doesn't give you a lot of room for customization. So we're kind of exposing some of the templates that we use. The first of which is going to be terraform. Second would be the deployment manifest that we use to deploy jump boxes and the Bosch director. So you can make whatever customizations you want to those. Third is Azure support for bubble. Currently, you could do a bubble up, but bubble create LBs is unsupported. But we also have a team from Microsoft working on getting that into bubble. Lastly is a migration path from CF release to CF deployment. The release integration team is currently working on a way for anybody who's using CF release to migrate to CF deployment. So if you're interested in diving deeper into anything that we talked about today, here are some resources that might be of interest to you. We have the GitHub repositories for all of the tools that we talked about here today, as well as a repository for the CF deployment concourse tasks. So if you want to run any of the boxes you saw in our concourse pipelines today. We also have the Slack channels for each of the teams responsible for each of these tools. And we're really responsive. So if you have any feedback or any questions, feel free to hit us on Slack. It's probably the fastest way to get a response. And with that, we're open to any questions. Thanks again. Thanks very, very nice speech. What about support for OpenStack and VMware? Yeah, we get that question a lot. It's somewhat in the works, well, not in the works. It's an idea. It's on our radar. I think one of the things that suggests, for a long time we supported just AWS and GCP. And one of the things that really helped us start working on Azure support was getting help from Microsoft and getting support from other community members. I know it's on our radar for OpenStack. Visa is also on our radar. But the prioritization, I think, is a little bit up in the air. If you want to push for it, I would suggest going into the bubble user Slack channel. Yeah, so PRs are accepted. Yeah. Of course, I would like to help. But what it means, implementing something in Go or Terraform, or what's the? Yeah, so bubble itself is written in Go. I think, I don't know if there's Terraform. Is there Terraform support for OpenStack? Yeah, so. Yeah, you could submit PRs to add Terraform templates and basically the way to deploy Bosch on OpenStack. And we could pull those in. It'll be a little harder for vSphere since that doesn't have Terraform support. And right now, bubble is pretty Terraform-specific, so. Yeah. Thanks. All right, it doesn't look like there's any other questions. Thank you. Thanks again. Thank you.