Set up Gloo Portal
Set up the Gloo Portal and some initial apps to get started.
To use Gloo Portal, you install or upgrade Gloo Gateway to deploy the portal server. Then, you use the Kubernetes Gateway API to create a gateway listener for the API traffic that you want to expose to end users through the portal. Finally, you deploy some sample apps to get started.
Before you begin
Complete the Get started guide to set up Gloo Gateway.
Set up Gloo Portal
Set the Gloo Gateway Enterprise version for your upgrade. Gloo Portal for Gloo Gateway is available in version 1.17.0-beta1 and later.
export UPGRADE_VERSION=1.18.0-beta2
Get the Helm values files for your current version.
helm get values gloo-gateway -n gloo-system -o yaml > gloo-gateway.yaml open gloo-gateway.yaml
Add the following sections to your Helm values file to include the Gloo Portal plugin and portal server.
When enabling or disabling the Portal plugin, you must set both theGG_PORTAL_PLUGIN
deployment custom environment variable and thegateway-portal-web-server.enabled
subchart value to avoid any issues.gloo: gloo: deployment: customEnv: # The Gloo Portal plugin is disabled by default # You can use the plugin with Gloo Gateway and the Kubernetes Gateway API (not classic Gloo Gateway) - name: GG_PORTAL_PLUGIN value: "true" # Enable the subchart for the portal server gateway-portal-web-server: enabled: true
Upgrade your release. For more information about the upgrade process, see the Upgrade guide.
helm repo update helm upgrade -i gloo-gateway glooe/gloo-ee \ --namespace gloo-system \ -f gloo-gateway.yaml \ --set-string license_key=$GLOO_GATEWAY_LICENSE_KEY \ --version $UPGRADE_VERSION
Confirm that the Gloo components are healthy.
glooctl check
Example output:
... No problems detected.
Confirm that the portal server is running.
kubectl get pods -n gloo-system -l app=gateway-portal-web-server
Verify that you have a Kubernetes Gateway API. Your gateway must be configured with an HTTP listener that can server HTTP resources from the namespaces that you want to use for your portal. If you followed the Get Started guide, you have an
http
gateway.kubectl get gateways -n gloo-system
If not, you can create an HTTP gateway with the following command.
kubectl apply -n gloo-system -f- <<EOF kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: http namespace: gloo-system spec: gatewayClassName: gloo-gateway listeners: - protocol: HTTP port: 8080 name: http allowedRoutes: namespaces: from: All # Setting to all to allow for Same namespace routing as well as the petstore namespace EOF
Deploy sample apps
Now that you have Gloo Portal installed, deploy some sample apps. Later, you expose these apps in a frontend developer portal.
You create two apps, Petstore and Tracks.
- Petstore is a collection of API microservices that together represent a Petstore. Different microservices perform different functions, providing information about pets, stores, and users.
- Tracks is a single API that provides information about a catalog of learning resources, or “tracks.”
The apps both consist of a deployment of a REST API and a matching service. Their services include several annotations that Gloo can use to automatically discover the service and create an ApiDoc for you. You learn more about ApiDocs later.
Keep in mind that because Gloo Gateway uses the Kubernetes Gateway API, you have to follow Kubernetes namespace practices. This means that later, you create ReferenceGrants for resources such as Services and HTTPRoutes that need access to Kubernetes resources in other namespaces.
Create a namespace for the apps.
kubectl create ns tracks kubectl create ns users kubectl create ns pets kubectl create ns store
Deploy the apps. The following sample files include the Kubernetes deployment and service for the app. The services include custom annotations that allow Gloo to automatically discover the services and create ApiDocs for them.
kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/portal/tracks-api.yaml kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/portal/users-api.yaml kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/portal/pets-api.yaml kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/portal/store-api.yaml
Check that your apps are running
kubectl get all -l demo=portal -A
Set up routes to your apps
Set up routes to the sample apps that you created.
- One HTTPRoute for the Tracks app with a
api.tracks.com/tracks
route - One HTTPRoute for the Petstore app with three routes for each of its apps:
api.petstore.com/users
for the Users appapi.petstore.com/pets
for the Pets appapi.petstore.com/store
for the Store app
Later, you create ApiProducts that target these routes. The ApiProducts are then shared in the developer portal so that your end users can access your services through the ApiProducts.
Create an HTTPRoute to expose each app on a domain with a unique route per app. The
http
gateway that you previously created listens for this route.Because the HTTPRoute is in a different namespace than the app, create a Kubernetes ReferenceGrant for the HTTPRoutes to each app’s Service.
Verify that the routes are created. In the status section, check for
Accepted
andResolvedRefs
in the reason output.Example output:
[...] status: parents: - conditions: - lastTransitionTime: "2024-04-17T19:36:16Z" message: "" observedGeneration: 1 reason: Accepted status: "True" type: Accepted - lastTransitionTime: "2024-04-17T19:36:16Z" message: "" observedGeneration: 1 reason: ResolvedRefs status: "True" type: ResolvedRefs
Next steps
Next, bundle your apps into ApiProducts that you can expose in a frontend developer portal.