Red Hat OpenShift OpenShift Commons Briefings, 6 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenShift Commons Briefing #106: Service Catalog on OpenShift 3.7 with Paul Morie

Description

A live demo session with Red Hat’s Paul Morie on the Service Catalogs in OpenShift 3.7 with Q/A

A

A

Well, hello, everybody and welcome again to another OpenShift Commons briefing on another session on Service Catalog this time on, Service Catalog in open shifts three point: seven, something we're very excited about here. Right now. We just did a Commons briefing with all earlier this week they gave a great overview and in depth dive into Service Catalog, what's going on in the core than any sig and the latest and greatest release and include the links to that when we post this video up.

A

But right now we want to dive in with Paul and get some hands-on demo portfolio a life of service catalog in action at on open ship. So take it away. Paul.

B

Alright, thanks for the introduction Diane, so today we're going to be focusing on the Service Catalog as it will be present and open shipped 3:7. We have several service worker 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 open ship templates to provision services and the ansible service broker that uses ansible playbook bundles to provision services, there's also a non mass service broker or messaging as a service.

B

But today we're going to focus on the template service worker and ansible service broker.

A

B

Going to whoops did things in the wrong order: that's okay! Oh there we go. So let's take a look at the open shift console and this is the service catalog in the open shift console. This is an open, show, 3.7, release candidate 0 and you can see. We've got all kinds of services in here. We only have two service brokers hooked up to this open ship cluster. One is the ansible service broker and the other is the open ship template service broker.

B

You can see, we've got all kinds of services, 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 a couple different flavors of Postgres nginx, all kinds of stuff.

B

So before I start poking around in the open ship 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.

B

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.

B

So we can see here.

B

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 in civil service.

B

Burger 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.

B

Let's make this font size just a little bigger here.

A

B

A

Eyeballs. Thank you for that. All.

B

Right, sorry about that everybody! So if we look at the status, we've got a 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.

B

So the way that a cluster operator will.

B

Will add a new service broker to the Service Catalog is by creating one of these resources.

B

One of these clusters 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, shipped API server via the kubernetes api aggregator.

B

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 open ship.

B

So, let's take a look back at the console.

B

B

Like chatting with people, Rocket chats like a nice service, so if I were to go in provision a rocket chat instance I'd see here a nice description that tells me that it's rocket chat, backed by a MongoDB which images it uses.

B

I click next and I've got some parameters that I can change, but I'm just gonna leave those in a stock configuration.

B

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 1:48 we started provisioning and then I 149.

B

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.

B

So we can see there's one service instance resource it's in my demo project in its name, is D, H rocket chat, etc, etc. So, let's take a look at what the e mo for this looks like.

B

So you can see the instance here is service instance. It's part of the Service Catalog kate's io d, 1 beta 1 api group, and I got to tell everybody: that's watching this when I see that V 1 beta 1 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.

B

So it's really awesome to see that we're. At that view, 1 beta 1 level. That means we'll be able to support Service Catalog and build shift. So looking at the metadata, we can see here's the name, D, H 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.

B

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.

B

We then have these other fields, cluster service class, rep and cluster service plan RAF, and those have references to the actual kubernetes names of the resources for the service and plan.

B

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 in open service worker 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 resource and due to time constraints, to hit the timelines that the vendors in different organizations working in the kubernetes service.

B

Catalog, say you 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.

B

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 data 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.

B

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.

B

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.

B

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.

B

Now this is really important because being able to reference a secret lets 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.

B

If you watch the comments 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.

B

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.

B

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 are 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.

B

The next thing in the status we're going to look at is this external properties.

B

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 send 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.

B

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, Red Hat stores parameters exclusively in secrets. We're gonna 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.

B

A

Go back to the open chip.

B

B

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 open chip 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.

B

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.

B

Oops I clicked the wrong button. There we go so here's my name: Paul service, catalog, mori,.

B

Hey Mori at redhead, calm super secure password one two, three four five registered a new account, that's pretty amusing. It puts 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 Rocket chat as provisioned by the ansible service broker.

B

Let's go ahead and go back here and I'm going to show a couple more services being provision. 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 gonna choose a Jenkins.

B

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.

B

We've got some parameters that we can set that are going to be included in the provision request of 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.

B

Now, if you've seen other Commons gatherings or other talks, that I've done about Service Catalog you'll be familiar with the concept of a binding, but if you haven't a binding is a way to get via the open, serviceworker API, as mediated by the Service Catalog information about how to use this service, so we're gonna, 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.

B

Alright, 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.

B

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 should the ansible service broker earlier, then, 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 and a central part of the value proposition for the Service, Catalog and open service worker API- is that you can just focus on solving an engineering or business need without having to worry about the details exactly what technologies are being used to fulfill these requests.

B

So, let's take a look at this again. We've got a description here. We've got a list of images that we're going to use.

B

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, post grass, 9.5 and.

B

Just for kicks we're not going to bind to this one at this time, so let's go ahead. We've created that one already.

B

And we're also going to create a MediaWiki instance.

B

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.

B

Let's go ahead and create it so.

B

Let's go back to our demo project.

B

And it looks like our Jenkins was provisioned successfully.

B

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.

B

Gets my certificates aren't set up quite right, but there we go. We've got a Jenkins instance I'm gonna log, in with open shift into that Jenkins that we provision via the open ship template, broker we're going to grant Jenkins permission to access. My OpenShift account on this instance and there we go plunge right into a Jenkins, no clue how it got provision, except that we've got my audio here, letting us know that an open ship template actually created this.

B

So that's pretty sweet to me. We've got a good spread so far, Rocket chat, Jenkins. Let's check on our.

B

Postgres service, alright, so this one was provisioned successfully too and then our media wiki was also successfully provisioned. So let's take a look at that media wiki.

B

Interesting I think perhaps the demo gods may not be happy with me here. Let's go back into the open ship console and take a look around and see if we can figure this out.

A

Demo, god I'm pissed.

B

Now the deployment from MediaWiki is actually running right now running right now,.

B

One of the things that I really love about the open ship 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 before I started, taking a look at it.

A

Well, one of the other things that I'd like you to talk about too, if you could is, is how do you get these service catalogs instantiated in on the open ship to have you make open shipped aware of the different catalogs? If you could.

B

So let me decompose that question into the two different things. Well, there's two different aspects: one is how do I get an open ship 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 service, catalog and if I were to hit, enter and I didn't already have an open ship cluster running, which of course I do.

B

We would see that we wind up with an open ship cluster in the service catalog installed into it. It's just that easy. You will get the template broker by default and in the open, shipped installer in 3.7 when you create a new open ship, cluster you'll also get the service catalog installed by default.

B

So the next facet of this question is: how do you connect a service broker to the catalog?

B

The answer to that is that a cluster administrator or somebody with the service broker admin role can create a new cluster service broker source and those.

B

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 in the future. It's very likely that we'll have name spaced versions of broker's service classes and service plans and allow users to register their own brokers just within their namespace.

B

For now, though, just to keep things simple in the first couple of 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.

B

So this is the ansible broker 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?

B

So the two different facets of that 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 in the ansible service broker, client secret in the ansible service broker, namespace and then there's also a CA bundle that I will use to verify the broker's TLS.

B

Now, if you have a, if you have a broker that has a route signed certificate from a certificate authority, Authority that is already in your trust- or you won't need to specify this. But if you're using a broker that has its own self signed certificate, you'll need to use the C a bundle to specify that, so we can verify the broker's TLS. So the workflow for specifying these things is that a cluster administrative rule to give them the permission to create this resource creates a resource.

B

The Service Catalog controller then gets an event and says: hey. There's a new cluster service broker, I'm gonna go to 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.

A

Makes sense for me I hope it does to everybody listening and I think it does. There's no question, so that's pretty good and thanks for doing up so it is MediaWiki you deployed yet yeah looks.

B

Like it what's kind of services here, I'm trying to load up that MediaWiki again, hmm that's weird I wonder if there might be some trouble that we're running into we had a little bit of hiccups. What.

A

Working things: yes, it's it's kind of it's a little hung up.

B

Yeah, it sure does things.

A

Stuck I love that message. It's stuck yeah.

B

Aren't we all aren't we all we're.

A

B

Okay, well, I think we're probably about at time the.

A

One thing I was gonna: ask: is there any documentation on on the open ship site at all for 3/7 that talks about this, or is that still to come? It's very early on I.

B

Didn't think that we published three seven Docs yet yeah.

A

B

Doctor service catalog, the alpha version I, was shipped with the tech preview qualification in open ship. Three six, but there's been a huge amount of I changed since we released that initial alpha version. So.

A

It's something people can go and look at.

B

But it will be fairly different in terms of the actual nitty gritties in the details. So.

A

Advice for people who are thinking about using this, it is very early days. Things will change, 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?

A

That was your very.

B

A

Okay, your very last one, there yeah.

B

I do want to say 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 ship 3:7. So you can try this out with confidence and know that it's not going to change totally out from underneath you so expect those additive changes with more features and more more goodness and more flexibility.

B

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.

B

I 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 to thank again everybody that has contributed to this project so far, whether whether you made good changes, whether you've helped figure out requirements, whether you tried it out and given us some feedback as we've gotten a lot of feedback, especially since we released the beta with people finding bugs that we fixed we've.

B

Actually, if you notice this, the slide deck is called Service, Catalog 1.0. Well, that was released, I believe in October 23rd and since then, we've done two additional releases with fixes for issues that people have found, so we're actually on ODOT, 1.2 I, released that yesterday in the upstream, but anyway, I digress. The last resource on here is a link to information about the kubernetes Service Catalog sake, I.

A

Also want to just add in to thank Paul and that everybody else on this thing 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 talking about getting the service birth or working to actually having this beta available in 3.7.

A

You know, in terms of internet time to go from having conversations with OpenShift customers and end users who wanted to stuff to actually collaborating with the folks from Cloud Foundry to get open service broker worked off into its own repo and getting this this has happened really relatively fast, and it's a testament to the openness and transparency and and all of the goodwill across all these different communities that have on really made this happen and, and just you know, fall I know it's the end of the year and there's lots going on, but this has really been, for example, of good, open source collaboration, so kudos to you and your teeth.

A

B

A lot Diane. That means a lot coming from you and I. Just have one more. Thank you to put out. There 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 within Red Hat working on the stuff that you have seen today and I just want to thank everybody for their collaboration, openness and teamwork on this effort.

B

Thank you. Everybody from OpenShift developer experience open ship, UI, Red, Hat uxd, the OpenShift ansible service broker team. It's all been fantastic! Thank you! A lot everybody and thanks everybody for watching today.

A