 Hi everybody. We're going to get started now. Thanks for coming to our talk. My name is Angela. I'm a software engineer at Pivotal. And I'm Christian, another software engineer at Pivotal. I'm currently working on the infrastructure team that works on Bubble. And today we'll be talking to you about deploying Cloud Foundry using Bosch Bootloader, which we call Bubble for short, Bosch 2.0 and CF deployment. So a set of new tools and features that core Cloud Foundry teams have been working on in the past year. But before we get into what all these tools are, I just want to take a quick temperature of the room. So who here has used Bosch Bootloader before? Awesome. How many of you have used Bosch? Great. Used Bosch 2.0. Deployed CF. Probably pretty important. Using CF release. And how about using CF deployment? So it seems like most people have used one tool or another. There seems to be a pretty even distribution. Hopefully by the end of the talk, no matter where you started on having used these tools before or heard about them, you'll be equipped to go from nothing to deploying a fully working Cloud Foundry in a matter of a couple of hours. Great. So just to start, I'd like to know what does it mean to deploy Cloud Foundry? It essentially means deploying whatever is in this diagram, which you don't care about because you have Bosch, right? Cool. So Bosch handles all this for you, which look like most of you use Bosch. So you know that you give it a deployment manifest, which details all the VMs, the software, all the configuration, and then out comes the Cloud Foundry. But usually there's a couple of hiccups that people encounter to even get to this point where they could do a Bosch deploy and get a Cloud Foundry. The first of which is you have to put all this infrastructure somewhere, or VMs somewhere. So you need some underlying infrastructure, which this simplified diagram kind of shows what you kind of need. So you essentially need a network which has a couple subnets, one for your Bosch, which you usually put in a public one so you can talk to it from your computer, and then have an internal subnet, which you could use to deploy CF, and you let Bosch know that it could deploy VMs into it. And then you usually create some load balancers for your Cloud Foundry so that you could round traffic to your apps through the router, which goes into your apps that are in your cells. And if you can figure out how to do this, the second hiccup that people usually encounter is you have to tell Bosch about all this infrastructure that you've created, and you usually do that through YAML. So as most of you know, through like CF Release or Bosch 1.0, there's a lot of cloud properties that you have to fill in, which are like your networks, your subnets, security groups, sider ranges, any IPs. So that's a lot of work, which you usually don't want to deal with when you're... All you're trying to do is deploy Cloud Foundry. I think most of you know what this looks like, but this is a deployment manifest. As you know, there's jobs, which are your VMs, and they usually have some amount of software on it, which are your job templates, and then some amount of configuration. Yeah. So as Christian showed us, deploying Cloud Foundry can be a really arduous task. And so our motivation here is really to streamline the process and simplify how you deploy CF. So for the past year, core Cloud Foundry teams have been working on creating tools that simplify a setup for Cloud Foundry. And so just a brief overview of each of these tools. The first tool is Bosch Bootloader, which we call Bubble for short. And it will take you from essentially nothing to having not only a Bosch director, but the underlying infrastructure necessary to deploy your Cloud Foundry. So in the diagram that Christian showed, it will give you your network, it will give you your subnets, it will give you that underlying CF infrastructure that you need. Under the hood, Bubble is utilizing a lot of the new features from Bosch 2.0. So for example, in Bubble we're using Bosch deployment to stand up your Bosch director. And Bosch 2.0 is also incorporated with the third tool, CF deployment, which is the repository that houses the new base manifest for deploying a Cloud Foundry. And by using these tools, you're now able to deploy CF in a way that's automatable, repeatable, and reproducible. And the power of these tools isn't just that each of these solves a specific problem in the process of deploying Cloud Foundry. The real value is that they each are solving a specific problem in the process of deploying CF with the end goal of having a Cloud Foundry up and running. So for example, while Bubble does solve the media problem of giving you a Bosch director, it's giving you that Bosch director with the end goal of utilizing it to have a CF up and running. And so one way this really manifests is you can see that we make sure that these tools are highly compatible and integrated with one another. So we have pipelines running that will use Bubble to deploy a Bosch director, and then use CF deployment to deploy your Cloud Foundry. And so this way, if there's ever a change to Bubble that would break its compatibility to CF deployment or vice versa, we're able to catch those quickly and make sure that it never gets to the end user who might be wanting to use these tools in conjunction with one another. So by using these tools, you can go from nothing to a fully running Cloud Foundry in a matter of a couple of hours where most of that's just waiting for your Cloud Foundry to deploy. So that's a brief overview, but you might be curious about how you utilize each of these tools and the additional features that each provide. Great. So here we have a concourse pipeline which kind of walks you through our process for doing all this. So it's a little hard to read, but the first box says bubble up which will basically create that infrastructure and deploy your Bosch director. The second box is deploying CF, which can take that bubble environment and just deploy a CF in it using CF deployment and then deploying an app or running tests or whatever you need to do. So I'm going to dive a little deeper into Bubble, the first box. So again, it deploys all your CF infrastructure for you. So your network subnets, load balancers, anything you need for Cloud Foundry, Bubble will give you. And then it'll deploy your Bosch director using Bosch deployment. So in the end, you'll end up with something like this. And another nice feature of Bubble is that it's item point, which means if you run bubble up again and again, you'll end up with the same end result, which is great for CI. It's also great when you can download the latest bubble, do a bubble up and get any latest patches that we've created. And currently we just support AWS and GCP, but there are talks of supporting more IASs in the future. Cool. So now that you've, you know, bubbled up, you might want to actually target your Bosch director. Bubble actually gives you some helpful functions to help you do this. So the first of which is bubble prints M, which will essentially print out the environment variables you need for the new Bosch CLI. So you can eval or source this and you essentially have an environment ready to use the Bosch CLI. The second thing that Bubble gives you is a cloud config, which if you haven't heard of this before, it's essentially an IAS specific manifest that contains all the information about your IAS and also your network infrastructure. And we essentially abstracted all this out from the deployment manifest, so we could keep that fairly static, which looks something like this, although a little bit more filled out, which also makes it well integrated with CF deployment, as CF deployment assumes a lot of the things that Bubble gives you are in the cloud config. And if you're kind of wondering what these commands look like, it's essentially just bubble up and bubble create LBs type CF, and you'll essentially have a Bosch director ready for you to deploy CF. Awesome. So after you've run the first task in this pipeline of bubbling up, you now have a Bosch director and the underlying CF infrastructure necessary for you to now deploy CF using CF deployment. So as I mentioned previously, CF deployment is a repository that houses the new base manifest for deploying a cloud boundary. And CF deployment provides several benefits for you as a user. The first being that it really emphasizes human readability, so making sure that there's a good user experience. The second is that CF deployment is on the bleeding edge. So a lot of other teams across cloud foundry may be working on new features, new products, something that's experimental. And by using CF deployment, you're able to have early access to these features to try them out, test them out, see if it's something that you want to use in the future. Another major benefit is on security. So CF deployment turns on all system components that can utilize TLS to have TLS on by default. So the out of the box solution for a CF here is going to be a secure cloud foundry. And last but not least, while CF deployment isn't necessarily ready for production use, it is geared for production. And this you can see in two ways. First, that they make sure that all the components that should be HA are highly available. And secondly, that different components are streaked across multiple availability zones. So you might be wondering how exactly CF deployment is able to have all of these benefits for you as a user. And so under the hood, it's using a lot of Bosch 2.0 features in order to provide the human readability in other aspects. So for example, one of the ways that optimizes for human readability and the user experience is by having a static main manifest. And the reason it's able to have a static main manifest is due to the cloud config ops file and bar store. Christian has already talked about the cloud config, but we'll dive a little bit deeper into the other two and how they work with CF deployment. So first, in the case of ops files, ops files are YAML files that house some configuration that you as a user may want to apply to your cloud foundry. So for example, an ops file looks something like this with a type. So in this case, we want to replace the value at this path. So we want to bump up the number of ourselves to a value of five. And so you can take this ops file and you can apply it to the base manifest, which presumably has some other value. Maybe it has an instance count of two. And by applying this ops file to it, you'll end up with a cloud foundry that has five instances. And so the value here is ops files allow you to compartmentalize configurations into different ops files, which makes it easier for a user to understand what exactly they're applying to their CF and what exactly they're modifying. So for example, you could have an ops file called instance count overrides that will just change the values for different instances in your deployment. You could also have an ops file for switching out a database usage. Or you could have an ops file to enable TCP routing. So there are multiple different ops files that you can use. And as an operator, I know exactly what I'm doing when I'm applying these ops files to my cloud foundry and I can expect what feature set comes out because they're well named and well compartmentalized. The other major benefit in CF deployment with Bosch 2.0 is the idea of a var store. So the var store is a file that hosts all of your secrets for your deployment in one file. So A, it optimizes for you as a user to know exactly where your secrets are being held. Because in the past, you might have had something like a database set here. And your password, maybe you were lazy, maybe you wrote admin. Hopefully you didn't. Hopefully you stored it somewhere else. But then you still had to make sure that you took that value and put it into the manifest when you deploy. So you might have used some tool like Spiff that's really hard to get right. But luckily with a var store, you can now use a new syntax of double parentheses and then give a name for the secret value that you want to access. And that name, in this case the Diego DB password, is going to map to an item in your var store file. And then when you deploy, it will make sure that that value for the password is being applied correctly. Another added benefit is if I added this to my manifest. So I didn't actually have a Diego DB password in my var store. When I deploy my CF, it will actually add an entry called Diego DB password and then will have a randomly generated secure password in place. And this is great because again it goes hand in hand with the idea of making every single system component that needs mutual TLS to be able to have that turned on by default. Because you as a user now no longer have to go and configure all the certs and keys and make sure that they're all correct because Bosch will be taking care of that for you. So that also optimizes for you as a user. So to now use CF deployment to deploy your CF, all you have to do is a Bosch deploy with the path to the main base deployment file and then any additional ops files you may have in your var store. And with that you now have a Cloud Foundry that's ready for you as a user to use and deploy apps too. Cool and for those of you who want to use concourse, bubble also supports concourse so you'll be able to bubble up, do a bubble create all these type concourse and have basically an environment ready for you to do a Bosch deploy concourse easily. So you might be curious about how people are using these tools today. So here's one example of every old use case from the team I'm currently working on, the container networking team. And so in this case we have an environment called pickle helm which is the name of a hat and you have a pickle helm bubble up so that will create your pickle helm Bosch director and then you have a deploy which will create your CF Cloud Foundry before running our acceptance tests against that Cloud Foundry installation. Additionally you can also have a delete pickle helm deployment to get rid of it when we're not actually using the Cloud Foundry for testing, saving us money by getting rid of idle VMs. Great and I wanted to touch a bit on future plans that we have for some of these tools. So first is bubble jump boxes. If you remember back from that first diagram I showed of putting Bosch in a public subnet, most people probably won't want to do that. So the idea here is that we would put a jump box into the public subnet and put your Bosch into the internal subnet. And then you would just use the Bosch CLI to tunnel through the jump box to your Bosch director. Second is credit hub support for bubble. So you might have heard of credit hub but if you haven't it's a credential store that can be essentially stored onto your Bosch director. So you can do a Bosch deploy and have variables stored in credit hub rather than in a file. So this would just be adding support for that. We're also looking at adding Azure support for bubble alongside AWS and GCP. And lastly we're looking at creating a bubble light which if you're testing Cloud Foundry you might not want to spin up the 30 or so VMs that Cloud Foundry requires. So bubble light would create containers on the VM it's on rather than creating VMs in your IS. And also the Relent team is also working on a migration path for CF release to CF deployment for those of you who are stuck on CF release and want to move on to CF deployment. Yeah and with that if you want to take a deeper dive into any of the tools that we discussed here today we have links to the GitHub repositories for all of them. We also have an additional GitHub repository listed here called CF deployment concourse tasks in case you want to stand up your own concourse CI and have any of the tasks we showed in the pipelines here today. And lastly you can always reach out to the teams who are maintaining these tools on the Cloud Foundry Slack. And with that thank you. And does anyone have any questions? Yep. So you mentioned that bubble is... So under the hood we use Terraform which does a lot of the work for us so we don't have to think about it. So if you haven't used Terraform it could essentially look at your existing infrastructure and bring it in line with whatever template that exists so that you could always maintain your infrastructure. Yes. Yeah so we are talking about vSphere although I don't know if we're going to do it any time soon. So again we use Terraform and Terraform doesn't currently support vSphere so it's a little bit of a harder problem. Yes. Nothing's preventing it so we're also talking about that. I don't know if we're going to do it any time soon. Evan or PM is actually here if he wants to speak about it. If we're looking at Open Slack we haven't done any progress on it. With Azure we're actually like signing up for the accounts and starting the pipelines to that. But with Open Slack that will probably be there. Yeah but also we appreciate the feedback if you want to like jump in our Slack or our GitHub page and we also accept the Rs. Yes. Is this going to be the de-fucked way to deploy CIF? Right now yeah we want it to be the de facto way to deploy CIF although Bubble won't fit every use case because it is highly opinionated. So in those cases you would just use Bosch deployment directly and whatever infrastructure you need. Yeah so basically CIF deployment will be the default way going forward in terms of like trying to stand up your CIF. But Bubble is really just for people who might want an ephemeral director for like their pipeline say something more automatable and repeatable. So it's definitely not for like a power user. Yeah right now it's not production ready but we are aiming to get Bubble production ready and you know get more use cases in. Right now it is kind of targeted towards our core open source Cloud Foundry teams using it in their pipelines. But we are looking at ways we could get more users using it. Yep. So if I want to use Bubble how can I install that on my machine? What's an easy way to get Bubble? True we should have added that to the slides but so it's part of the Cloud Foundry tab if you're using a Mac. So you can do a brew install Cloud Foundry slash Bubble. Otherwise you can just download it from the GitHub releases page. We currently support Linux and Mac. Awesome. Thank you again.