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

  1. 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.17.0-rc5
      
  2. 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
      
  3. Add the following sections to your Helm values file to include the Gloo Portal plugin and portal server.

      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
      
  4. Upgrade your release.

      helm repo update
    helm upgrade -i gloo-gateway glooe/gloo-ee \
      --namespace gloo-system \
      -f gloo-gateway.yaml \
      --version $UPGRADE_VERSION
      
  5. Confirm that the Gloo components are healthy.

      glooctl check
      

    Example output:

      ...
    No problems detected.
      
  6. Confirm that the portal server is running.

      kubectl get pods -n gloo-system -l gloo-mesh=gloo-mesh-portal
      
  7. 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.

  1. Create a namespace for the apps.

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

  3. 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 app
    • api.petstore.com/pets for the Pets app
    • api.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.

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

  2. Because the HTTPRoute is in a different namespace than the app, create a Kubernetes ReferenceGrant for the HTTPRoutes to each app’s Service.

  3. Verify that the routes are created. In the status section, check for Accepted and ResolvedRefs 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.