solo.io Product Demos, 22 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Gloo Portal demo

Description

A quick demo of core Gloo Portal features. Gloo Portal is an advanced, database-less API developer portal built for Istio and Envoy Proxy. Fully integrated with Gloo Mesh Enterprise and Gloo Edge Enterprise, the portal abstracts the complexity and enables developers to publish, document, share, discover, and use APIs with rich controls, detailed configuration information, and comprehensive security. You can define application policies that affect the service mesh itself, including access, routes, policies, and configurations, making self-service a reality. Gloo Portal improves API-producer and -consumer developer productivity for both Kubernetes and traditional environments.

A

Hi everyone casey wiley here from solo, I o and today I'm here to talk about the glue portal. The glue portal provides a framework for managing api docs protobuf files, and you can easily share your apis specs across teams and collaborate easier.

A

The glue portal can run on top of glue edge enterprise, which I'm running bluewedge enterprise under the covers today, but it can also run on top of istio. The glue portal supports monetization rate, limiting on your apis and is a very feature-rich product, but now we're going to start from installing the glue portal. I'm going to talk to you guys about four custom resource definitions that come in the glue portal and to illustrate this, I have a go, laying app that I wrote it uses rest.

A

It has an open api, spec version three, so let's go ahead and jump into it. So the first part is to install the helm repository for the dev portal. The next part is to create a helm overrides file. This file. If you're, looking on line 12, you see it's glue, dot enabled set to true. This is necessary for integration, with blue edge enterprise.

A

Okay, we've created a helm, overrides file and now, lastly, we're going to create the dev portal namespace and install through hell.

A

A

So the next part we're going to make sure the pods are up in the dev portal name, space.

A

So the admin server is running, it has three containers and the dev portal is also running. Okay, the first custom resource definition that we're going to talk about is called the api dock. The api docs purpose is to point to a swagger, spec or proto file, so the dev portal also supports grpc, but due to the fact that we have a rest service, we're pointing to this open api spec that we referenced earlier once we apply this api dock called task schema. It's actually going to discover the operations from the open api, spec.

A

Okay, so now we've applied this one thing we always want to do after we apply an api dock. Is we want to check the status dot state and make sure it's in a succeeded state we're going to get the api dock.

A

Dot status, dot state- and we should see, succeeded here if all goes correct, okay, so status. That state has succeeded, but I also want to point out that blue portal will also discover endpoints.

A

So under the status you see open api, it has discovered the operations from the open api stack, and this is going to be the same if you're running a proto file.

A

Okay, so we just discussed that the api dock is really for pointing to your api definition. In this case, it's an open api.

A

The very next um custom resource definition is called an api products here, we're creating an api product called task product. It's also going to exist in the default name space. We have a description, which is the task product also title, but the real purpose behind the api product is to define versions.

A

So you can have different versions in in cloud environments, it's very common to be rolling out enhancements and new versions of your of your back-end services. Perhaps you have developers that are still using a prior version and they need uh the specs too, and then you have a new version rolling out. You have to communicate that with people.

A

For the sake of this, let's just remember that the api products, real purpose, is to define versions. So we have version number one defined here: v1, it's referencing the api.cast schema in the default namespace, which we just created in the api doc, and then this api product is actually backed by a kubernetes service. It's called task. It exists in the default name, space on port 8080 and I've already deployed the task application that I wrote in golang, and we can verify that here.

A

It's also running at 8080., okay, so let's go ahead and apply the api products so that we can have a version.

A

Okay, the api product has been created now.

A

Let's look at the api products.

A

And similar to the api dock, the api product does have the v1 and actually shows the routes. We can delete a task. We can get the all all tasks. We can create a new task. We can delete a task by the id we could get a test by the id. So this looks good. Our api product is good. Now, let's move on to the next custom resource definition, which is an environment.

A

So the purpose of the environment is to house your api products. Just like the api product references, the api doc, the environment is going to reference the api products. This environment is called dev and, through this environment, we're going to be able to actually use our our api definition and actually curl against it. That's kind of out of the scope of this video, but we could do that.

A

So this dev environment exists in the default namespace. It has a domain associated with it. The domain is api.task.com, it has a description and a display name, and then we have the api products that we are referencing.

A

If we had more than one version of our api product, we would put it in this array right here under published versions. But for now our api product is referencing. The sorry our environment is referencing. The task product api products.

A

Okay, so we created our environment now, let's type the manifest of the environment out to yaml and check its status and make sure it.

A

Succeeded, okay, so again we see the routes were discovered and we can tell that this is in a good state, because status dot state is equal to succeeded.

A

Perfect so now the last custom resource definition that we're going to talk about is called a portal. This portal is named task portal. It exists in the default namespace, it has a display name and a description, but it has a little bit more interesting context to it in that it has a banner.

A

The banner is what's going to be on the very background of your portal behind the title, it has a favicon which is a very tiny icon that sits in the browser tabs on the top, and it has a primary logo. You could also add custom, styling or static pages. There is a domain and we also have our published environments, which we're referencing the dev environment that we just created.

A

Now I have went ahead and uploaded my custom images to a website called img.ur.com. It seems like a meme website. This is the banner, but it works uh for this example, because we're able to upload static images here so logo favicon banner we're gonna, go ahead and apply this portal.

A

Okay, so we've just created our portal, now we're going to check portal and to make sure it's in a good state.

A

We can see the status that state is in succeeded state, so we know that this portal is working and we're in actually good shape here.

A

Okay, so now you're, probably asking well, how do I actually access the portal that I've created? Where do I go to actually see my api spec, so we're going to go ahead and cover that right now before we can share our api specs, we have to create groups and users and we'll basically be adding users to a group which will create api access when they sign in to your portal.

A

So the first thing we're going to do is: if we look at the pods in the dev portal, namespace we'll see this api server, so we're actually going to port forward the api server to our local host to 8080.

A

And from here, oh I'm, sorry, I said api server but I meant to say admin server and now we have our admin server on localhost 8080.

A

Okay, so now we're actually looking at our portal, we can see we have this task portal defined. We have the apis. We can look at our api products, the api dock routes. We don't have any api keys if we had created them, but what we're mostly interested in in is. We want to be able to access this task portal.

A

So if we look at this task portal in a new tab, we hit the home page. We want to log in the problem. Is we don't have a user created, so we're not going to be able to log in so let's go ahead and fix that the first thing we want to do in this admin server is create a group we'll call the group devs.

A

Next users, we haven't created a user yet so we'll go ahead and pass. We want this group to access the task product api products.

A

We have no plans right now, but we could theoretically set a rate limiting plan if we wanted to and we want access to the task portal. So now we created group devs that has access to the api product.

A

The last thing we need to do is create a user. My username is going to be called casewiley email use, kate, boiley, gmail.com password, whatever you want, and it's going to be changed as soon as you log in the first time, we're going to add this user to the depths group, we're going to give this user access to the task product api and then we're going to add our portal to this user.

A

So perfect, amazing. Now we've created the user in the group. Let's go ahead and sign into our.

A

A

It's going to ask us to update our password.

A

Updated from here we have access to actually view our apis. We see our task products, we see our version, one, which is the only version we have. In this case we had a defined host, which we can actually see here, api.task.com and then we can actually look at our swagger spec and see what we're expecting when users want to interact with this api.

A

So that includes this very quick wrap up of the glue portal. I hope you all enjoyed. If you want more information on the portal, go to solo.I o, you can request a demo and you can look at our docs. Thank you all so much. I appreciate.

A