 Well, hello everybody and welcome again to another OpenShift Commons briefing Another session on service catalog this time on service catalog in OpenShift 3.7 something we're very excited about here at Red Hat We just did a commons briefing with Paul earlier this week They gave a great overview and in-depth dive into service catalog. What's going on in the Kubernetes SIG And the latest and greatest release and we'll include the links to that when we post this video up But right now we want to dive in with Paul and get some hands-on demo hopefully live of Service catalog in action at on OpenShift. So take it away, Paul All right, thanks for the introduction Diane So today we're going to be focusing on the service catalog as it will be present in OpenShift 3.7 We have several service broker implementations that we've been working on at Red Hat The two that I'm going to focus on today are the template service broker That uses OpenShift templates to provision services and The Ansible service broker that uses Ansible playbook bundles to provision services There's also an on-mass service broker for messaging as a service, but today We're going to focus on the template service broker and Ansible service broker I'm going to Whoops did things in the wrong order. That's okay. Oh, there we go So let's take a look at the OpenShift console And this is the service catalog in the OpenShift console. This is an OpenShift 3.7 release candidate zero And you can see we've got all kinds of services in here We only have two service brokers hooked up to this OpenShift cluster One is the Ansible service broker and the other is the OpenShift template service broker You can see we've got all kinds of services here We've got a couple different flavors of Jenkins. We've got MediaWiki We've got Python. I think Diane likes Python. We've got Rocket Chat Couple different flavors of Postgres, Nginx, all kinds of stuff So before I start poking around in the OpenShift console, I want to take a look at the cluster service broker resource, which is how Service brokers are registered with the service catalog So The resource, as I said, is called cluster service brokers And we can see here we've got the Ansible service broker and the template service broker Let's take a look at the Ansible service broker. So we can see here The name of this resource is the Ansible service broker As part of its spec, it has a reference to a secret called Ansible service broker client that lives in the Ansible service broker namespace and This has the bearer token that we're going to use to authenticate from the service catalog controller to the Ansible service broker We've also got a CA bundle here Which contains the certificate authority that we're going to use to verify the Ansible service brokers TLS and Then finally There's the URL for where the service catalog controller Should talk to the Ansible service broker Make this font size just a little bigger here. So if you look my eyeballs, thank you for that. All right. Sorry about that everybody So if we look at the status We've got Ready condition here with status true And that tells us that The service catalog controller has fetched the catalog entries from this broker and populated them into the cluster service class and cluster service plan resources So the way that a cluster operator will Will add a new service broker to the service catalog is by creating one of these resources One of these cluster service broker resources in the service catalog API server now if you saw the OpenShift Commons gathering earlier this week where I did the service catalog overview you might remember that the service catalog API server is Aggregated with the main open-shift API server via the Kubernetes API aggregator so when I'm talking to The service catalog API server and doing operations on the command line here against the service catalog resources I don't have to know anything special about how to Talk to that because I'm just talking to it like it's part of OpenShift. So let's take a look back at the console Now I like chatting with people rocket chats a nice service So if I were to go and provision a rocket chat instance I'd see here a nice description that tells me that it's rocket chat Back by a MongoDB Which images it uses I? Click next and I've got some parameters that I can change But I'm just going to leave those in the stock configuration now I've actually already provisioned a Rocket chat instance. So let's take a look at my project in The project overview you can see this provision services section is about services that have been provisioned via the service catalog So let's take a look here. We can say we can see that it's already ready. It's been provisioned successfully Which configuration values we sent as part of that provision and We can see events associated with it. So we can see here at 148 We started provisioning and then at 149. It was provisioned successfully Now I'm going to switch back to The command line and let's take a look at the at the API resource for this so we can see There's one service instance resource It's in my demo project And its name is DH rocket chat etc. etc So let's take a look at what the YAML for this looks like so you can see The instance here is service instance It's part of the service catalog that kates.io V1 beta one API group and I got to tell everybody that's watching this when I see that V1 beta one on there It's really satisfying to me. It took quite a bit of work for us in the Kubernetes service catalog SIG and the open service broker API working group and everybody working on this project here at Red Hat across The various engineering teams and Red Hat UXD to get to this point together So it's really awesome to see that we're at that V1 beta one level That means we'll be able to support service catalog in OpenShift So looking at the metadata we can see here's the name DH rocket chat etc. etc The namespaces demo project And then looking at the spec We can see here that there's this field called cluster service class external name This has the human readable name of the Service in the open service broker API and then cluster service plan external name Which is the name of the plan that we're on now We then have these other fields cluster service class ref and cluster service plan ref and Those have references to the actual Kubernetes names of the resources for the service and plan If you saw the commons gathering gathering on Monday You might remember that I touched on this a little bit The reason that the human readable name and the Kubernetes names are different is that an open service broker API It's possible for a broker to change the name of a plan or a service however in Kubernetes, we don't support changing names of resources and Due to time constraints to hit the Timelines that the vendors in different organizations working in the Kubernetes service catalog SIG wanted to hit to get this software out in front of users At a beta level What we decided to do initially is to use the open service broker immutable IDs as the Kubernetes names But as a user when you work with this you can still use the human readable names. So In the future, it's very likely that we'll have a naming strategy Where the human readable names are the Kubernetes names, but for now, this was a compromise that we had to make in order to To get this beta release out in a timely manner So the next thing we're going to look at here is this external ID field This is the ID of this service instance in the open service broker API So all of the operations that the controller makes against the service broker that this service comes from Are going to be made in terms of this ID This isn't something that you're going to be exposed to as a user But since we're drilling into the resource, I thought it would be good to call out So next piece of information here is the parameters from element It has a reference to a secret key a key of a Kubernetes secret That has the parameter values that we're going to send or that the service catalog is going to send to the broker during provision Now this is really important because Being able to reference a secret let's us send sensitive information to the broker without Putting it directly into this service instance resource and making that resource an escalating one So the advantage here is that you can grant View access to this resource To somebody that might not be permissioned to see the sensitive information that you're sending and since it comes from a secret and Doesn't show up directly in the resource. They won't be able to see it Now there's also and you may remember this seeing an example of this if you watch the commons gathering from earlier this week There's also the ability to put parameters directly into The resource the service instance resource you should never do that with sensitive information But it is another flavor of being able to specify parameters So last interesting thing in the spec is the user information. We can see my username down there good old P. Mori the groups that I'm in and some extra information from the OpenShift authorizer Now the reason that these are captured in this resource is that we have to be able to send them via the originating identity Part of the provision message to the service broker and what it lets the service broker do is Make checks about whether Myself as P. Mori should actually be able to provision that rocket chat So let's take a look at the status and I'm highlighting things just to make sure that people can see them But the first condition that we have here or the first thing we're going to take a look at here is the ready condition its status is true and there's a reason a message on there letting us know that the instance was provisioned successfully The next thing in the status we're going to look at is this external properties These are this is information about what the Service broker that offers the service knows about for this service instance So we've got to check some of the parameters that we sent and we also have a list of the parameters and their values Now because these parameters were Sent from a Kubernetes secret the only value you're going to see for those is redacted If we had some inline parameters that were part of the instance you'd be able to see those values there But since the OpenShift console being security conscious as we are here at Red Hat Stores parameters exclusively in secrets We're going to just see for this one this redacted value and Then finally we've got the user information that the service broker knows about For that we sent it for provision so This is very useful as a user because it gives you a good idea of exactly What information the service broker has about the service instance? so let's go back to the OpenShift console and We're back in this provision services view You'll notice the same Configuration parameters here MongoDB admin password database name etc. You can see in the OpenShift console Now I'm going to go back to the services these are the Kubernetes services and There's one that that Ansible playbook bundle deployed for our rocket chat service So let's click on this and We've got a link that we can click here And there we go rocket chat so Let's go ahead and create an account and I'll prove to you all that this Actually works Oops, I clicked the wrong button. There we go. So here's my name Paul service catalog Mori P mori at redhat.com Super secure password one two three four five Registered a new account That's pretty amusing it put service catalog into my username. Yes, we are definitely going to use that username And now I'm I'm in here chatting around with myself so That's rocker chat as provisioned by the Ansible service broker Let's go ahead and go back here and I'm going to show a couple more services being provisioned. So we've got We're back in the view of my project and I'm going to add a new service so I'm going to go up here to add to project and go browse catalog and I'm going to choose a Jenkins So similar to what we saw with the other service The rocket chat service We've got a description of what this is and some information about it We've got some parameters that we can set That are going to be included in the provision request to the broker Let's go ahead and I don't feel the need to change these So let's go ahead and click next and now we are on this binding view now If you've seen other commons gatherings or other talks that I've done about service catalog Be familiar with the concept of a binding, but if you haven't A binding is a way to get via the open service broker api As mediated by the service catalog information about how to use this service So We're going to say yeah, let's do a binding And this is going to give us a secret that contains coordinates and credentials that would allow us to program against this Jenkins instance All right, so this is being provisioned now and since we've already looked at this I am going to Cross my fingers and offer My eternal allegiance to the demo gods And I'm going to try Doing something pretty cool So while that Jenkins is provisioning I'm going to make a Postgres database This is another one from the ansible service broker And by the way, if I didn't If I didn't specify before This Jenkins instance that I'm provisioning comes from the open ship template broker Now one thing I'll call out is that If if you were watching this without audio you would not have any idea Well, you might have some idea since I showed the ansible service broker earlier That maybe the rocket chat came from the ansible service broker But as far as what you would see as a user You wouldn't have any idea what provisioning technology we were using to create these service instances Which I think is really powerful An essential part of the value proposition for the service catalog and open service broker api Is that you can just focus on solving your engineering or business need Without having to worry about the details of exactly what technologies Uh are being used to fulfill these requests So let's take a look at this again We've got a uh description here We've got a list of images that we're going to use Uh This service has multiple plans. So we get to choose a plan. We're going to choose the development plan And again, there's some parameters that we can set. We're going to go with good old post postgres 9.5 And Just for kicks, we're not going to bind to this one at this time So let's go ahead. We created that one already And we're also going to create a media wiki instance So this view is probably getting familiar for now Since this one doesn't have multiple plans. We don't have to pick one. We're going right to configuration And let's go ahead and create it So let's go back to our demo project And it looks like our Jenkins Was provisioned successfully So if you remember we created a binding For this Jenkins instance Now on the provision services page for that Jenkins service instance, we can see that there's a bindings a binding already for it We can also see some events Let's go back to our kubernetes services And see if we can actually navigate to that Jenkins Yes, my certificates aren't set up quite right, but there we go We've got a Jenkins instance I'm going to log in With OpenShift into that Jenkins that we provisioned via the OpenShift template broker We're going to grant Jenkins permission To access my OpenShift account on this instance And there we go Plunt right into a Jenkins No clue how it got provisioned except that we've got my uh Audio here letting us know that an OpenShift template actually created this So that's pretty sweet to me We've got a good spread so far rocket chat Jenkins Let's check on our Postgres service All right So this one was provisioned successfully too And then our media wiki was also Successfully provision So let's take a look at that media wiki Interesting. I think uh, perhaps the demo gods May not be happy with me here Let's go back into the OpenShift console and take a look around and see if we can figure this out I think the demo guys I'm just Now the deployment for media wiki is actually running right now running right now One of the things that I really love about the OpenShift console is that You can just easily view the logs For all kinds of different things builds deployment Looks like the deployments running So maybe I didn't give myself enough time here Uh Before I started taking a look at it Well, one of the other things that I I'd like you to talk about too if you could is um Is how do you get these service catalogs? instantiated in on OpenShift too. Have you make OpenShift aware of The different catalogs if you could So let me decompose that question into the two different things Uh, there's two different aspects. One is how do I get an OpenShift cluster with the service catalog? Yes, and to answer that there are two different ways. I think probably people are Familiar with OC cluster up If you want to use OC cluster up all you have to do is say OC cluster up dash dash service catalog And if I were to hit enter and I didn't already have an OpenShift cluster running, which of course I do We would see That we'd wind up with an OpenShift cluster in the service catalog installed into it. It's just that easy Uh, you will get the template broker by default um And in the OpenShift installer In 3.7 when you create a new OpenShift cluster, you'll also get the service catalog installed by default So the next facet of this question is how do you connect a service broker to the catalog? the answer to that is that A cluster administrator or somebody with the uh service broker admin role Can create a new cluster service broker resource and those Those look just like we've already shown Take a look at one again Just to drive the point home So here's a cluster service broker. They're called it's called cluster service broker because it's cluster scoped um in the future It's very likely that we'll have namespaced versions of brokers service classes and service plans And allow users to register their own brokers Just within their namespace For now though, uh, just to keep things simple in the first couple iterations of the service catalog We made service brokers and service classes and service plans cluster scoped Which means they don't live in a namespace So this is the Ansible broker that that we're looking at the important parts of the spec are Where do I talk to it, which is this url field? and How do I authenticate to it? So the the two different facets of that Uh authentication and security For communicating with the broker Are the bearer token that we're going to use to talk to it, which is in the in this case. It's a secret Uh in the Ansible service broker client Secret in the Ansible service broker namespace And then there's also a c8 bundle that I Will use to verify the brokers tls Now if you have a If you have a broker that has a root sign certificate From a certificate authority authority that is already in your trust store. You won't need to specify this but if you're using, uh A broker that Has its own self sign certificate You'll need to use the ca bundle to specify that so we can verify the broker's tls So the workflow for specifying these things is Uh that A cluster administrator somebody with a role to give them the permission To create this resource creates a resource The service catalog controller then Uh gets an event and says hey, there's a new cluster service broker I'm going to go contact that broker Get its catalog payload Which contains the services and plans that that broker offers And then transform that into our cluster service class and cluster service plan resource Does that make sense diane? That makes sense to me. Um, I hope it does to everybody listening And I think it does there's no questions. So that's pretty good and thanks for doing that So it is media wiki. Is it deployed yet? There you go. It looks like it's uh, let's go to services here I'll try to load up that media wiki again Hmm. That's weird. I wonder if there might be some, uh trouble that we're running into We had a little bit of hiccups networking things yes It's it's kind of it looks a little hung up Yeah, it sure does It's been stuck. I love that message. It's stuck Yeah, aren't we all aren't we all Friday, we're stuck Yeah, we're stuck Um, okay. Well, I think we're probably about at time so what One thing I was going to ask, um, is there any documentation on on the open shift site at all for three seven that talks about this? Or is that still to come it's very early on I don't think that we've published the three seven docs yet Yeah, uh, this doc for service catalog that alpha version Uh, that was shipped with the tech preview qualification in OpenShift three six but there's been a huge amount of Uh changed since we released that initial alpha version So it's something that people can go and look at but it will be fairly different In terms of the the actual nitty gritties in the details So, um advice for people who are Think about using this It is very early days things will change Um, but we do really want you to Give us your feedback on it try it out Let us know where the shortfalls are what's missing What you love about it. We like to hear good things too And where can they find out more maybe Pop back into that slide deck of yours and tell a little bit about the kubernetes sig Whoops That was your very no That's okay your very last one there Yeah, uh, I do want to say Uh Things may change but they will change additively Since this is now a beta api We will make all future changes in a way that's backward compatible With what we ship in open shift three seven So you can try this out with confidence and know that It it's not going to change totally out from underneath you um So expect those additive changes with more features and more Uh more goodness and more flexibility Uh, but the fundamentals here are pretty much baked at this point And that's what allowed us to put the beta API level on it. So if you want to learn more about this you can You can check out the open service broker api There's also a link here to the service catalog Source repository in the kubernetes incubator organization And like I always do When I do talks like this, I will say That I'd be really happy to have anybody that wanted to make a contribution Uh come and attend a sig meeting or poke around In the service catalog repository We're a pretty friendly group At least we try to be so I'm very very interested in having new contributors And I also want to take this opportunity To uh to thank again everybody that has contributed to this project so far whether Whether you've made code changes whether you've helped figure out requirements Whether you've tried it out and given us some feedback As we've gotten a lot of feedback, uh, especially since we released The beta with people finding bugs that we've fixed we've actually, uh If you notice this the slide deck is called Service catalog o dot one dot o. Well, that was released. I believe october 23rd And since then we've done two additional, uh releases with fixes For issues that people have found so we're actually on o dot one dot two. I released that yesterday in the upstream Uh, but anyway, I digress the last resource on here is a link to Uh information about the kubernetes service catalog sig Yeah, I also want to just add in to thank Paul and and everybody else on the sig For all the work that you guys have been doing. It's a wonderful Cross-community collaboration It's been a conversation that I know it feels like it's been a lot of you know work and taking a long time But actually relatively quick time to go from Um talking about getting the service broker working to actually having this beta Available in 3.7, you know in terms of internet time To go from having conversations with open shift customers and end users who wanted this stuff to actually Collaborating with the folks from cloud foundry to get open service broker Forked off into its own repo and getting this this has happened really relatively fast And um, it's a a testament to the openness and transparency and and all of the goodwill across all these different communities that have really made this happen and Um and just you know Paul, I know it's the end of the year and there's lots going on but this has really been you know a wonderful Example of good open source collaboration. So kudos to you and your team Thanks a lot Diane that means a lot coming from you and I just have one more thank you to put out there Uh is I want to thank everybody from red hat We've had so many different teams. I want to say at one point we had six teams Uh within red hat working on the stuff that you have seen today and uh, I just want to thank everybody for their collaboration openness and uh Team work on this effort Thank you everybody from open shift, uh developer experience open shift ui red hat uxd Uh the open shift ansible service broker team It's all been fantastic. Thank you a lot everybody and thanks everybody for watching today Take care all