 All right. Good morning and welcome to the open shift on Azure session here in the pavilion or the partner theater here. My name is Harold Wong. I'm with Microsoft and I am part of the team that manages the global partnership with Red Hat. We do a lot of work with Red Hat on open shift running in Azure. I'm going to hand it over to my teammate Jim for him to introduce himself. Hello, everyone. Sorry, I just had to say it. Yeah. My name is Jim Zimmerman. I'm a Principal SE in Microsoft. I'm helping lead the managed open shift offering that we announced yesterday at the keynote. I figure I go over a few things that we covered yesterday for those that missed it. We announced a jointly managed open shift on Azure. So basically, this is going to be managed by both Red Hat and Microsoft as a first-party service. So you'll get better support and you'll be able to provision things very quickly. We also have the Windows Container Support in OpenShift as a private preview. Patrick did that. Then we also have OpenShift Support in Azure Stack. So Harold's going to show a demo of that working. It's pretty cool. For those of you that you want to run a private Cloud on-prem. Then lastly, we'll go over the open service broker for Azure that runs on OpenShift. So basically, a service broker is a way to provision Azure first-party services from within OpenShift. So I'll hand it back to Harold and you can go through a few things. Okay. So I figured we'd walk through some of the deployment options because if you are super interested in the managed or jointly managed OpenShift offering in Azure, it is only in private preview. Even the Windows Container Support in OpenShift is preview. So they're not GA yet. So if you want to be running OpenShift in Azure today, what are your options? So we have different ways that you can test out, you can try out OpenShift in Azure. There's something called the Test Drive. So if you don't have OpenShift already, maybe you don't even own Azure. But you're interested in running and trying it out for four hours. You can go to the marketplace website, do a search for OpenShift, you can find the Test Drive and then you can deploy it. You don't have no accounts necessary, just your email. It'll run for four hours. You'll have the ability to test it out, run it, see how it works. If you like it, then you can contact Microsoft and or Red Hat and get going. The other one is if you already own Azure, you already own OpenShift and you want to deploy it easily into the Azure environment. You can go to the Azure Marketplace once again, and there is an offer there where you answer some questions, input in your Red Hat subscription information, whether it's your username, password, or activation key or guide as well as your pool ID, and then it will go deploy a OpenShift cluster for you. It will have three master nodes, three infer nodes and then you get to select how many app nodes that you want to deploy. Then you wait about an hour, 45 minutes to an hour or so, and come back and you'll have your 10 node, 20 node cluster up and running ready to go. Another way to deploy things is if you don't want that opinionated install but you want to install a OpenShift cluster with your own parameters, we do have what we called Azure Resource Manager templates, ARM templates that are available. There's the ARM templates directly from Red Hat, that's part of the reference architecture. We also have, we being Microsoft or me, Harold, have GitHub repos on the github.com Microsoft, and then we have OpenShift Origin and OpenShift Container Platform Repos, so that you can actually go deploy your own cluster and have the ability to customize different things. I don't care about HA right now, I only want to deploy a simple cluster to test out something. So you can select one master, one infer node and one app node. I want to deploy metrics or I don't want to deploy metrics. So there's a bunch of configuration options that you have in terms of deploying using these templates. The other thing you could also do flexibility, options. You can go deploy your own VMs into Azure. By the way, that ARM template deploys all the VMs for you, sets up all the storage, all the networking, everything so that when the template is done, you have a fully functional cluster. The other option is to use Ansible Playbooks natively. So you just want to deploy everything yourself. You can create your own Ansible Playbooks that deploy the Azure VMs, deploys the VNets, the networking and everything. Or you can deploy somehow, deploy all the VMs and the infrastructure in Azure, and then run the Ansible Playbooks to install OpenShift. So there is all kinds of options available. The last one is the one that will be coming soon, the ability to use that managed OpenShift. At that point, you can use the Azure CLI. If you were at the keynote with Scott Guthrie and Brendan yesterday, then you saw that you could do AZ OpenShift Create, and literally create an OpenShift cluster using the Azure CLI command. That process, hopefully, by the time it GAs will take like five to 10 minutes to deploy a fully functional 10, 20, 30 node cluster. So that's exciting. So that's all we really have in terms of slides. What we really wanted to do was do demos and then also get questions or answer your questions. So if you have questions for the few of you that are here, feel free to ask and we'll take those questions. So what I have up and running right now is multiple OpenShift environments. I've got OpenShift Origin. I also have OpenShift Container Platform running. And what I'll show you first is in my Azure portal, so this is my Azure portal, I've got an environment that has quite a few disks, a bunch of VMs that hosts my cluster. So if we come over here and look, you can see what is it about a 10 node cluster or something like that, masters, infer nodes, app nodes, and that cluster right now is this cluster. So I've logged into the cluster already just to save time, kind of hard to hold a mic and type too much stuff all at the same time. But the key here that I wanted to show is integration with Azure. So if I wanted to deploy an application that uses persistent storage, where does that persistent storage get created, right? Is it ether? Is it out in outer space? No, it's using Azure disks. So what I wanna do right here is let's just create a new project. We'll call it demo. And then if I go to this demo project, we'll create just something simple, right? I don't wanna do something that takes too long. There is this cake PHP example, real simple. If I do cake PHP, MySQL, step through this, and just let it go create, go to overview, you'll see that this is starting to spin up a MySQL database. But if I look at storage, it is trying to provision storage, a PVC called MySQL. Ultimately, that will generate a disk in Azure that gets mounted to the VM. And I just wanna quickly show that. So hopefully this won't take too long for it to provision. Come on. Storage, sure. It's not gonna work fast when I'm trying to do a demo, right? What we're waiting, are there any questions? Okay, so while we're waiting for that to create, I'll show you Azure Stack as well, right? So I have an Azure Stack environment. We'll ignore that failure one. But I have OpenShift Origin running in Azure Stack. You can see this is in my Azure Stack environment. It's not in Azure full. But I've got an Origin cluster that's deployed over there. And if I come back over here, this other tab has Origin and you can see it does say OpenShift Origin. If you look at the URL, it is pointing to cloudapp.stackpoc.com. So it is not an Azure, like Azure commercial environment, right? Otherwise it would look like cloudapp.azure.com. But same similar concept here. If I show you, actually I probably should. So what I have over here in this particular environment is CNS. So I've got cloud native storage integrated with this cluster because in Azure Stack today, the cloud provider does not function. So I can't do disk attach, but I do need persistent storage. So if I want to run persistent storage, you can deploy CNS as part of your Origin or container platform cluster. And if you're doing container platform, one of the things that I think was announced or will be announced this week, because it's already working, is your OpenShift entitlements. If you're doing CNS, also include CNS. So your Gluster entitlements are part of your OpenShift entitlements. You don't have to buy Gluster separately. I think that's cool. Yeah. I don't know if it's announced, but it's working. Because I did deploy it and it does work. It didn't ask me for my entitlements. All right. So I'll go back to my container platform, and you can see that it provisioned a PVC. And can you hold the control key down? Thank you. Hard to do two things with one hand holding a mic. But if you look here, there is a PVC. If you look at the name of that PVC, right, it's a 424A something and ends in ADC. If I go back to my portal over here and go back up where the disks are, let me refresh this real fast. We ought to be able to see a disk called Kubernetes PVC. What was it? 424 ending in ADC, right? So that disk got created automatically on the back end and was mounted to a VM called... So it got mounted to Node 1, right? And that's the one that then is running this particular workload. So if you look, you'll see that the pod is spinning up and if we wait another minute or so, I'm sure that thing will go live, right? But in Azure Stack, because we don't have access to the cloud provider, we're using CNS. So you can deploy CNS, the entitlements are automatically there. Don't want to get too engrossed into that, but just want to make sure everybody understands, you can or you do have the flexibility of deploying OpenShift Origin and Container Platform in Azure Stack as well as in Azure, Azure Commercial, Azure Gov, Azure Germany, right, all the different sovereign clouds and take advantage of all the integrations with Azure or Azure Stack. And so I'll go ahead and turn this back over to Jim to talk about some of the OSBA integrations as well. So we're probably the only people that know what OSBA means. And I noticed that on our title, it says OSBA and OpenShift. OSBA is Open Service Broker for Azure is what it is. So is anybody here familiar with the service catalog and OpenShift? Okay, so basically what we did is we took our Open Service Broker that works in Kubernetes, Cloud Foundry and OpenShift, same binary basically. And we ported that to make it work with OpenShift. And as you can see here, we have about 15 services integrated now to OSBA. And so you can see that here, we have our Cosmos DB service, our Azure Database for MySQL Postgres. These are really useful for those of you that don't wanna manage data in a cluster. I don't know too many companies that actually wanna manage their database. This is inside of OpenShift or inside of Kubernetes. So this is really useful to be able to provision our first-party services from within OpenShift and then automatically creates a connection string, a secret, if you will, for your developers to use inside of the cluster. So it's very easy to provision these services for your developers without them even having to call you up basically and say, oh, can you set me up a SQL server for me? So anyway, I'm gonna take you through a couple of these right now. You see here, we have, you know, that's a SQL server I was talking about, Azure Search, Service Bus. I'll take you through a Cosmos DB one. This is one of our more popular ones. The Cosmos DB has different API shims on top of it, so you can do MongoDB, Graph API, Table API. I think we also have Cassandra coming too. Yeah, I think it's in private preview or whatever, but anyway, you get the idea. So I'm gonna go here and walk through this wizard. One thing I love about OpenShift is that it takes our metadata that we spent back to it and creates this awesome UI on the fly. It makes Oswa look actually really good. So I'm gonna type with one hand while I hold the mic. Z Cosmos, all right. So, and then here, we have this metadata that we spent back to the service catalog that automatically creates these dropdowns. So do I wanna allow access or measure? I'm gonna go ahead and enable that. Allow access from the portal. These are just different things that different parameters that we offer. I could put an IP range, I only want a specific IP to be able to access this Mongo service. I'm gonna just go ahead and exit out because I don't need that. And then I can say what location I want it. So obviously I want it to be in the same region as my OpenShift cluster, so I'm gonna go ahead and put ECUS. And then if I wanted, I could have a defined resource group so I can put all my services in one area. It's more for organizational purposes, but for here, I'm not gonna actually put a resource group in. And then here, this will create a binding. So once the service is actually provisioned, it's gonna create a binding, it's gonna grab all your connection string properties, create a secret in the cluster, and then that secret can be used by your applications. I'm gonna go ahead and do that. And no errors, that's awesome. Hey, that's weird, I logged in as you. I was wondering why all my settings weren't there. Yeah, yeah, yeah. So this is the managed cluster. So Red Hat OpenShift on Microsoft Azure is why you see that. And it looks like the internet's not being very friendly. Yeah, internet died, awesome. Yeah, are you connected to Wi-Fi? Yeah, it's dead. Awesome. All right, well, we have another question. All right, cool. So maybe I pull up my iPhone and we'll show you how to connect to my hotspot here. Yeah, everything went down. Okay, so anyway, I can finish this. There wasn't really much more to show there, but anyway, so what's going on in the background is it created the Cosmos service, created a secret, and then you can give that secret path to your developers to put in their PodSpec for their OpenShift deployment, and then all of a sudden now when they deploy their app they can use an actual first-party service from the cluster instead of creating in our own. It's back up, I don't know what I would really show anyway. All right, I don't see the project here. Yeah, let's not worry about it. So, I may have any questions. It may use Azure today. All right, good, okay. You don't count. You have to use it for your job. Then we use OpenShift. All right, okay, same to people, this is weird. So if you don't use OpenShift you probably didn't know about the service catalog then. So what I would say is when you do look at using OpenShift the service catalog is awesome because then your developers can actually provision services on their own and you don't have to manage it. So it makes it really useful then giving them the keys to like Azure, AWS or whatever. You can control their access through OpenShift. It's actually pretty nice. One interesting thing about that OpenService broker for Azure is I'm running my origin cluster in my Azure stack. I kind of mentioned that earlier. I also installed the OpenService broker for Azure in my origin cluster running on Azure stack and I can deploy Azure related services up in Azure that connect with my containers or my pods that are running in cluster. So that integration in the hybrid model works very well as well. So we're just about out of time, 50 seconds left. Any other questions or comments or jokes you wanna tell? All right, well thank you very much for your time.