 So, hello everyone, welcome to my talk, Automating Cloud Foundry on OpenStack. I'm Xiu Jiao Gao, a cloud engineer from Stack and Win. Most of my coworkers call me, I'm going to use this fancy tool, XJ, because my Chinese name easily sounds like plastic, go to sleep, pedicure in Chinese. I don't prefer to sound like that, so I'm happy with XJ as my name. That's enough about myself. I want to simply introduce the company I work at, Stack and Win. Stack and Win is a consultancy. We help our customer being a superhero, oh, a super girl, by succeeding with their Cloud Foundry story. So basically we have everything from infrastructure, operation automation to 12 factors applications also including services, how they integrate service with their apps, all that. Oh, I forgot this, I can do this. So what is Cloud Foundry? Even you didn't know what is Cloud Foundry, probably now you know because it's the end of the CFD. So, oh, I know why you laugh at me because I should use this. So Cloud Foundry is a pass, pass, did I say it right, yeah, pass for Cloud applications. It automates, manage, scales, Cloud applications, I forgot, through their lifecycle, it's good I have notes. So application can be written in just about any language and it can be deployed in image containers on top of any infrastructure like OpenStack. So what we will talk about in today's talk today, here is the outline. I know it looks like a long list, but please don't worry. I clearly know that dinner time is right after this talk, so I will keep it short. Okay, first we will look at the ecosystem like CF and IAAS. Cloud Foundry, in this picture you can see Cloud Foundry is a pass for Cloud applications. It has many great features, so developers only need to worry about their applications. Also it provides a service broker can integrate service with their applications. Then Cloud Foundry is deployed by Bosch, which enables this a lot of great features again. Also it separates CF and infrastructure through CPI, which means Cloud provider interface. This actually is how we can deploy CF on OpenStack. So in this talk, we are going to share with you, like, start a way to do things. We have gained many years of experience with this CF ecosystem. We have helped lots of customers like Intel, Swisscom, Ultimate Software, with their CF platform and applications. So here today in this talk, we are going to share those best practices with you. So whoever didn't go to dinner early come here is lucky. I hope you will agree what I said after this talk. So the first question is, how do we deploy CF? Deploy Ultimate CF on OpenStack. So first we need to make sure that your OpenStack is ready for deploying CF by running the OpenStack validator. From there, then we can set up like infrastructure resources like networking, security groups. Then we can deploy the CF. Before we use the Python to set up OpenStack networking, now we use Terraform. If you want the details, you can go to our GitHub. So most of the things in CF world probably you already know is deployed by Bosch. In order to deploy and manage CF, we have to deploy Bosch director first. There are a lot of great documentation, certainly include our blog, to introduce you how to deploy Bosch. So I will not talk about that here. We will focus on how to deploy and automating CF on OpenStack or any other infrastructure. So how do we automate multiple deployments? So deploy a single CF is pretty easy. The challenge is how do we automate multiple CF deployment across multiple environments and the data centers? We use Conqueror's pipeline. Conqueror's pipeline is a tool probably you already know is a CI CD tool like for both infrastructure or application or CF, our pipeline generally goes through dive environment, then staging, then production. We have a project is a live-in or live-in? Live-in? Live-in. Live-in documentation called Codex. So if you are interested, you can go to check out that. And oh, thanks for bearing with me with my chinglish because some words, you know, I don't pronounce it perfectly, but maybe you'll still get my message. So this is a... What's funny? Okay, so this is a screenshot for one of our pipelines. So in here, you can see, I don't know if the people sitting in the back can see or not, but I will explain. So first it will deploy to Bosch Lite. Bosch Lite is a lightweight all-in-one VM Bosch director. After it pass all the tests here, it will automatically deploy to development environment. Then in this environment, after all the test pass, it also automatically go to the staging environment. But from here to Pratt, we set it in a way that you have to manually click in order to deploy to Pratt because probably you always prefer you can let some operator watching your deploy in production instead of being surprised at 3 a.m., right? Yeah. Oh, I see someone shared his pain. What? So next topic, how do we handle credentials and certificates? So they are safe, which means they are not stored on disk. They are not in your git reports, right? Even worse, some day you just accidentally git push and you didn't git ignore. You generously shared your credentials with the world. Your boss will be mad. So in addition, you also want easily rotate your credentials because some bad guy may just figure out things, right? So you want to rotate them. How we deal with this? We use vault. And the safe. I bet all the people here know what vault is. Safe is the two-way road. It's a CLI to interactive with vault. But what benefits the safe has, if we use safe, we can generate, rotate, provide either SSH keys or certificates or random secret passwords. In addition, the safe can also manage multiple vaults. That is nice, huh? Your credentials may be safe if you use safe. But that doesn't mean your platform will not feel. Why? Because networking. When your apps or your CF or maybe your underlying infrastructure, they may go through a downtime. I see someone nod his head. Thank you. In this case, you want your whole project become operational as soon as possible without losing any important data. That brings us our next topic. We want to convert this failure to success. How we do that? Handle disaster recovery efficiently in a good way. How do we do that? We use a shield. Yep, we hired all of them. Now I know how many people watched this movie. So now I'm being more serious. So what is a shield? Shield is a distributed framework that starts when built. The purpose is to be the guardians of CF Galaxy. Galaxy? Yeah. OK, now I'm really being serious. So the shield we built can protect your CF, the apps in your CF, and the service in your CF. Mars basically can protect your CF core. What I mean by that? It can backup and restore your CCDB, UADB, and DiegoDB after it migrated to Diego, right? It also protects service in CF. Like you may have a PostgreSQL service, MongoDB, MySQL, or Redis, or Redbit, MQ. Shield can backup and restore all those. Shield also protects any Bosch deployment. As you may know, most of the things in CF world can be deployed by Bosch. Or I should say, are being deployed by Bosch. So that makes Shield very powerful also, because it can literally backup and restore any Bosch deployment. A tricky part is about the Bosch itself, because Shield is also deployed by Bosch. Now, Bosch deploy Shield, Shield backup Bosch. There is a story. Let's say you have your CF running. You have lots of apps and the service in your CF platform. Someone just burned down your day center. So now if your software works, then what are you going to do? Probably the first step, you're going to set up hardware, right? Then next, you may deploy a Bosch. You deploy a Bosch, then you use the Bosch deploy the Shield. Then you want to use this Shield to bring back all your other services, apps, all that. Sounds good. But be careful, because you may wipe out your Bosch database. The Shield you deployed with Bosch is often, often, often, you know, often. So to avoid that, actually, we make Shield can recover Bosch without require the Shield running. Is that cool? So basically, you spin up a Bosch. You somehow Shield just can use a CLI to recover your Bosch without spinning up a Shield. So in this way, everything you had before is brought back. So that's very cool, huh? Yeah. So Shield is awesome. Awesome things is really simple. Now you can see the framework of Shield is pretty simple. There is a core diamond, which deal with all the metadata, deal with, like, schedules, like how you are going to, how often you want to back up your stuff, retention policy, how long you want to keep your backups, right? Then target plug-in is just you specify what you want to back up. It's a Postgres, or it's a Mexico, or it's what. Then storage plug-in, where do you want to store your backup? Local file system? That sounds good. S3, Swift, all that. As long as you have the plug-in, you can make it work. Certainly a good software will have a nice user interface and a cool CLI, most basically in the Bosch world. If you want, let's say you want to back up to restore CF, you only need to configure Shield agent on your CF deployment, same way for the RabbitMQ and the Redis. Then for where you want to store your backup, then you can configure your storage plug-in here. Then you can backup and restore your stuff. Another nice thing about this Shield is it's very easy to write your own plug-in. It's like a piece of cake, like cheesecake, ice cream cake, or strawberry. Yeah, that's my favorite. So while writing plug-in is like a piece of cake, the reason actually is just because what I shared with you earlier, we said we have this framework because we've taken care of all the things in here, like a metadata management, schedule, retention, all that. You only need to worry about the piece you are writing. You only need to worry about your solution. Let's say maybe we don't have a MongoDB actually, we have it now. Let's say we don't have some plug-in, but you need it. Hey, you can just write your own. Only write your own piece of solution. What's this? Oh, it didn't show up on your show up on mine. So, but if you don't want to make a piece of cake, you can also ask us to do it, pay us to do it. So, yeah, sweet. Shield is awesome, but it can be better. Like if you can catch the failure before it happens, then we don't need to deal with disaster, right? For this, we need monitoring. I'm expecting some laugh for this. So monitoring, we use promises to monitor like CF, Bosch, and many other Bosch deployments, our databases, all that. In order to be able to monitor things, you need to write your own exporter, like this exporter should be able to extract the metrics for the things you want to monitor. We deploy these promises with Bosch. We use it to monitor deployments in CF across several environments and the data centers. This report, this is how we take advantage of this report. We made this, then we deploy promises using this. So for more details, you can go here. Actually, I'm doing good because we will finish early. You will be happy because you will have dinner early. The last piece I want to share is that how do we deal with logs? We ship the logs using Somio. Somio is another tool we created. I know we created lots of tools. So what is that? It basically just aggregates the logs to a single stream. Then you can just connect to one node in the Somio cluster, then your logs will be sent there, then it will help with your live debugging. So basically, you can watch your logs while the error happens, help you debug that way. And of course, it also deployed by Bosch. And again, we have this release. So it can be deployed by Bosch. Oh, the cloud community is one of our GitHub logs. We have lots of cool things there. So I shared a lot about how do we do things, like lots of cool tools. Now I'm going to share some information about how do you do things? How do you find out more? You can go to our blog. juststarkandwin.com blog, slash blog. We do get feedback from people, like at a conference they will mention, oh, recently a blog saved my day because a similar bug happened. Then they googled our blog showed up, just to really help them debug their problem. At least I'm very happy when that happens. Because usually no one notices me. Then there are times that people say, I see your company, a female rotor blog, blah, blah, blah. Then I said, what is the blog, then start talking, then, oh, that's me. Yeah. Second is our GitHub. Except this cloud community, we have this Starkandwin cloud community. Yeah, those are true. We have lots of stuff in these two GitHub logs. We also can be reached by email, be a hero. Maybe we should have another one, be a super girl at thestarkandwin.com. Also, we have a CF ambassador booth is in the marketplace, C18. So feel free to stop by anytime. We will have people there talk with you, answer questions, all that. Thank you. Yeah, that's all. If you have any questions, you can ask. One requirement is that you have to use the mic there. Thank you. Thank you.