 My name is Cameron Stewart. Thanks for coming out to my talk today. I work for Pivotal. At Pivotal, I'm a partner solutions architect. So that means that I lend technical support to our partners. Before working at Pivotal, I went through the Galvanize full-stack immersive program. So it's really cool to see Galvanize sponsoring this event, and to hear all about the amazing work that they're doing with Allstate. That is my Twitter handle if you do the Twitter and you want to find me, that's how I can be found on Twitter to be perfectly honest. I'm a little bit of what I would call a Twitter late bloomer, but I am on the bandwagon now. So that's how you can find me. Of course, I am available through other platforms of communication, LinkedIn, WhatsApp, or good old-fashioned email. So if you want to stay in touch or if you have questions, please don't hesitate to stay in touch. I would love to talk to you. So I have to be honest, that I picked out a pretty decent outfit for you all today, but then I was in the Expo Hall, and I was talking with the awesome folks at Grapebub, and I noticed they had these really cool t-shirts. I thought that it's fitting for the name of this track that I get a t-shirt. So I definitely encourage you to go and talk to the Grapebub folks. They offer professional services around Cloud Foundry. So you should talk to them because they're experts in Cloud Foundry, and also because they have really awesome t-shirts. But we didn't come here to talk about t-shirts, because obviously mine takes the cake. We came here to talk about technology. These technologies specifically, today we're going to discuss Bosch and using Bosch to deploy concourse onto Google Cloud Platform. The reason why we're going to talk about all of these technologies is because everyone is trying to go faster. I think as organizations and as developers, we're all trying to go faster. We're all trying to get code out the door into the hands of our end users as fast as possible. I don't hear anyone in the keynote saying, we were actually doing things too fast and getting features into the hands of our end users a little too quickly, so we decided to slow things down. That's not what you hear in the keynotes. It's obvious that what everyone is after is that rocket fuel. We're all looking for what it is that's going to give us the ability to go faster, not only to go faster but to be able to go fast and still innovate with confidence. What gives you that rocket fuel is the combination of different technologies and also processes and methodologies that support those technologies. I like to talk a lot about Cloud Native and what the characteristics of Cloud Native are, and what companies that you would consider Cloud Native, some of the aspects of those companies and how they're doing what they do. I think that some of the aspects are building applications into microservices architecture or having continuous integration, continuous delivery, and that's one that we're definitely going to talk about a lot today. You absolutely must automate your path to production. This is something that we all know, well, I don't think this should come as a surprise to anybody at this point, but one of the core things that you're going to need in order to be successful or to be Cloud Native and to assist you on your digital transformation is to have high levels of automation in place. What that accomplishes is that automation will give you that confidence, that confidence to make changes or to introduce new features without running the risk that it'll break other parts of your code. Having automation in place is really the safety net that allows you to innovate at a rapid pace. We're going to talk about different methods of automation and different levels of automation that will give you that confidence and that security. First, we're going to talk about concourse because we just mentioned that you absolutely have to automate your path to production if you even want to stand a chance at your digital transformation, your digital journey at being Cloud Native, automating your path to production is the first step. We're going to talk about concourse. Concourse was originally designed as a tool for the deployment of Cloud Foundry. We're going to take a look at some of the contracts of concourse. First one is resources. These are the three main concepts within concourse. Before I actually dive in, I wanted to do a quick poll of the audience. Who here has played with concourse or is currently using concourse? Just about everybody, that's awesome. We're at a Cloud Foundry summit, so I imagine that just about everybody has heard about Bosch. What about GCP? Has anyone using Google Cloud platform? Awesome. Just wanted to get a sense of where we were in the audience. Jumping back into concourse, there's three main concepts within concourse. There are resources, jobs, and tasks. Resources you can think of as anything that can be versioned and that you can pull down. A great example of a resource is a GitHub repo. We're going to take a look at an example later on of a concourse pipeline. Within that concourse pipeline, we're just pulling down a GitHub repo. From that GitHub repo, we are running tasks. Tasks are usually described within a job. A job is all of these things really come together to make your overall pipeline. A task is usually a shell script or some script that is run that accomplishes a single task. A job will describe how tasks and resources interact with each other. If we talk about Bosch, those are the overarching concepts within concourse. If we talk about the main concepts within Bosch, we have stem cells, releases, and deployments. Stem cells are the base OS image that Bosch uses to create VMs. It's an OS image, but it also includes basic utilities and an agent. The agent is responsible for a number of functions, not only for sending out a heartbeat of the VM, but when Bosch is deploying a distributed system, the agent will go to the blob store to pull down the packages to install the specific software on those VMs. The stem cell is basically that OS image that Bosch uses to create your VMs of your deployment. The release describes all of the packages and the start-stop scripts that are needed for whatever you are deploying. Bosch was originally the tool that was responsible for the deployment and lifecycle management of Cloud Foundry, but Bosch in general is a great tool chain for deployment and lifecycle management of any kind of large-scale distributed system. In this case, obviously, we're going to deploy concourse. So there are many uses outside of Cloud Foundry that Bosch can be used for. It's really good for any large-scale distributed system. Bosch is really going to give you the capabilities that you need in order to handle some of the challenges that those large systems will present. So you start with a stem cell and then you layer your release on it. And a release is, again, whatever you are going to be deploying the software that you are actually using Bosch to deploy. And a deployment then describes the VMs that will get created with that software. And the deployment requires a manifest. Bosch operates on the notion of manifests. And a manifest describes the deployment that you will end up creating. So we see all these things together. I want to give you a high-level overview of how I've set up what we're going to walk through. So first, let's take a look at kind of a high-level overview of all of the things that you need in order to use Bosch to deploy concourse onto GCP. And we're going to start with our GCP environment. So I have a GCP account. And the first thing that you're going to need is you're going to need a project. That's pretty basic. Step one for anything you're going to want to do with GCP. Within that, you're going to want to have a user that is an owner of that project. And you're going to want to create a service account that has editor access for your project. Once you have your GCP environment configured, these are the steps that we're going to walk through in order to get Bosch up and running. The first thing is that we're going to use Terraform to create the required infrastructure that Bosch is going to need. And the first step is creating the Bash MVM that will become your Bosch director. The Bosch director is a server that orchestrates your Bosch deployment. So the Bosch director is really the boss you can think of. And so the first step in deploying Bosch is to get your Bosch director set up. So we're going to use Terraform in order to stand up the Bosch director. Once the director is stood up, then we can turn our attention towards deploying concourse. So we're going to deploy our Bosch director on the infrastructure that Terraform has set up for us. Then once we have the director, we're going to upload the stem cells and then upload the releases that concourse will require. Once we have those things uploaded to the Bosch director, it's as simple as uploading one additional file, which is your cloud config. The cloud config is basically all of your IaaS specific configuration that you will need. So previously, all of your cloud configuration was in a single file, which could be very problematic if you were using multiple IaaSes, which Bosch is definitely the tool that gives you the ability to be IaaS agnostic to have multiple clouds that you're deploying your applications to. So if you're deploying your applications to multiple clouds, it made sense within Bosch to have separate cloud configs that would contain that IaaS specific configuration. So you will upload and Bosch will update the cloud configuration, and then you will simply deploy concourse with the simple command Bosch deploy. So that is a high level of the process that you would go through in order to use Bosch to deploy concourse onto GCP. And so now we're going to take a quick look at that. Okay, so the first thing that I'm going to do is I'm going to SSH to my Bosch bastion. And what we're going to look at first is we're going to look at the manifest file for our Bosch director. Initially, I had an ERB file, and what this is essentially doing is this is capturing the environment variables, and then I just populate my manifest, my YAML file, with the values that I captured here in the ERB file. But we can take a look at this version as fine. So if we take, I mentioned that a manifest will describe the, a manifest describes how Bosch will create the resulting resource. And so if we take a look at the Bosch director manifest, we see a number of things. We're going to talk about some of the things that are consistent across all manifests. When you see here cloud properties, that is always what is unique to your, the IS that you may be using. So in this case, I'm using GCP. We're always going to have the notion of the releases. So this is the manifest for my Bosch director. So the releases that I'm using here are Bosch and the Bosch Google CPI. The CPI is the cloud provider interface, and that is the API that Bosch uses to communicate with your underlying IaaS. So we have to have that in place so that when we go to deploy concourse, Bosch has a communication channel to communicate with your underlying IaaS to create the required resources that we need for whatever distributed system that we are deploying. So we see our releases here. We also see the URL of the release. This is where you can access that release. The release can also, the Bosch team manages all of, well, Bosch release can be available as either a tarball or as a URL, as you see here. Then we have our resource pools. So this is what ends up getting created for us once we hit Bosch deploy. We see our networks, and then we have the number of jobs. So with Bosch, a number of things get deployed, and so there are a number of components in the Bosch architecture, and you can really see those here. You have a health monitor. You have the CPI. Again, that's the way that Bosch communicates with the underlying IaaS. The health monitor is the tool or the way that Bosch understands the health of VMs and understands if they are online and healthy or if they are down and need to be resurrected. The Blob Store and PostgreSQL database to persist both VM states. The Blob Store holds the packages, and that's where the agent will actually go to, when VMs are being created, the agent will go to the Blob Store and grab the packages to install the necessary software on the different VMs that are being created. The database, the PostgreSQL database is just to persist the state of the VMs. And then there are different network configurations and things like that that you can see here. Again, we specify here what our cloud provider is. We're using the Google CPI because we're communicating with Google Cloud Platform. So that is a look at the Bosch manifest. Now I want to take a quick look at the concourse manifest. So for the concourse manifest, we see in the releases that we have two things. We have concourse and we have garden run C. Again, for the instance groups, we see something very similar that we did in the Bosch manifest. Every manifest has releases and instance groups and defines the jobs. This instance group is for the web interface that we'll be interacting with once we have concourse set up. So you can see here that we have the external URL that we'll access concourse from, how you will authenticate against it. And then there are other jobs that Bosch will execute in order to stand up the necessary components that concourse will require. Last thing is I wanted to take a look at the cloud config. So again, this is all of the IA specific properties that Bosch will use in order to set up the infrastructure for your particular IA. So initially when you are setting up your workstation to deploy concourse or to deploy your Bosch director, excuse me, you will need to explicitly export your project ID and different compute zone and regions in order for those to be available via your environment. So those are being captured here. And then you define the specific VM types and the different VM extensions that you will need for the VMs that are being created. Within compilation is where you will put your cloud properties, which are again just the properties that are specific to your underlying IAs. So that's a look at the manifests for each of those things. Once you have your concourse manifest set up after you've uploaded your stem cell and your release, it's as simple as the command Bosch deploy. And Bosch will kick off creating all the necessary VMs with the required software for whatever your distributed system may be. In this case, again, it's concourse. So once we have that all up and running, then you are free to use concourse. So I have a concourse pipeline set up over here for you. And I wanted to kick it off because I have a little application that we're gonna run through this pipeline. So I have some code here on the branch of my local machine. It's ahead of my master by one commit. So I'm going to push this code up to my GitHub repo. While that's happening, I wanted to take a, or excuse me. So that is going to kick off our concourse pipeline. And while that is kicking off, I wanted to just take a look at that pipeline. Pardon me, just keep zooming in. Okay, so we're gonna watch that. And in a minute, we should see that it is going to start pulsing yellow. And you notice that there are a number of hands in the room. So it seems like we have a lot of concourse users out there. So we're all familiar with what this is gonna look like once our pipeline has picked up that our repo has changed. So while we're waiting for that, there it goes, kicks off. We're gonna take a look at the pipeline. So this, as you can tell, is a very baby pipeline. There's not a lot going on here. And that is intentional to highlight exactly what the different components that we're interacting with. So as I mentioned, concourse, the concepts that come together to create a concourse pipeline are jobs, resources, and tasks. So if we take a look at my pipeline over here on your left, the first thing that I'm defining is my job. And in this job, I have two, well, three things that are really going on. The first is that I'm going to get my get repo. My first resource that I am using is the GitHub resource. And I am able to parameterize the repo that I'm using, the branch, and then my private key. So I have a trigger here that's set to true. So concourse is going to wait for my GitHub repo to pick up a change. So I just committed a change. And so concourse has that trigger set, so it's going to kick off as soon as there's a change to my source code. Once that change is picked up, we're going to kick off a task. I have a task here called build artifact. It is a very simple task. It's just pointing to a shell script, which basically just takes my, this is a Spring Boot application. So it just takes my Java app and packages it up into an artifact. Once I have that artifact, which is saved, then I can use the CF resource to deploy that application. I have an instance of Cloud Foundry running, so I'm going to deploy that application to Cloud Foundry. So the CF resource is awesome because it handles everything for me. So as a developer, I don't have to interact with Cloud Foundry at all. Concourse is automating and doing all of that for me. So it's handling, targeting my instance of Cloud Foundry, authenticating with my username and my password, targeting my org and my space, and then going through issuing the commands that are necessary in order to deploy my application. So it picks up the manifest that I'm using for that application and pushes that out to Cloud Foundry for me. So if we, again, this is a very small pipeline. Concourse is great because it can be used for things big and small. It can be used for small, little, this is really two very small, three very small tasks, or it can be used on mega scale, where you can deploy to multiple different clouds, you can do fan-in, you can do fan-out, you can do rolling deployments. It's really powerful in terms of the capabilities of concourse. So if you want to see an example of concourse at scale, this is the concourse pipeline for concourse. So I'm sure that you all have come here before ci.concourse.ci. It's really awesome that you can kind of see this live, see it in action, as it's happening. And what's great about concourse is it's very elegant in its UI. It has the yellow pulsing to let you know that a job is in progress. This allows developers to have immediate feedback on the overall state of their applications as they're moving through this pipeline. So if there's something that's big and red, they know that they can drop everything and have to go and fix whatever it is broke that pipeline. So concourse at scale definitely has more going on than the little pipeline that I'm using here. And if we jump into my output here, this is the part of concourse that is actually interfacing with Cloud Foundry and deploying my application for me. So I'm going to grab my URL of my actual application and I'm going to pop it in here. And that's actually all I have for you. So if you have any questions, I will be around and thank you all very much. I appreciate your time. Thank you.