Gloo UI

Review how the Gloo user interface (UI) server backs up data and your setup options to make the backing database more resilient. For more information about the feature, see Gloo UI.

What data gets stored

The Gloo UI displays the information that the Gloo management server stores in a snapshot in the database. This information includes discovered Gloo, Kubernetes, and other open source custom resources in your cluster environment. As such, you must set up both the Gloo management server and the Gloo UI to use the same backing database.

The Gloo UI additionally stores the following information in the backing database. For an example of how to check the data that gets stored, see Review data in Redis.

Backing storage options

Review the following options for setting up backing storage.

Option Use case Benefits Drawbacks
Built-in local Redis Proof of concept and staging environments
  • Default setup, automatically works
  • Fast read/write speed as the database is local to the management server
  • Updatable via Gloo Platform Helm chart
  • Only as highly available as your cluster setup
  • Has the same disaster recovery as your cluster setup
  • Might not meet your organization's compliance requirements
Bring your own Redis Production environments
  • Enhanced high availability and disaster recovery (HA/DR)
  • Service level agreement (SLA) from your provider
  • Meet your organization's compliance requirements
  • More complicated setup
  • Not covered by Solo support (contact your external Redis provider)

Built-in local Redis

By default, a local Redis instance gloo-mesh-redis is set up in the gloo-mesh namespace of the management cluster when you install the Gloo management server and UI components. The Gloo management server replicas and the Gloo UI are automatically configured to read from and write data to this Redis instance for a global view of your Gloo environment.

Using a local Redis instance is not a recommended practice for production. To achieve higher availability, disaster recovery and add other security features, bring your own Redis instance instead.

To enable the local Redis, you use the following Helm values during the Gloo management server installation:

redis:
    deployment:
        # Enable the creation of the local Redis deployment and service.
        enabled: true

You can further configure the default Redis values, such as to modify the Kubernetes deployment's resource limits and requests. For more information, see the following docs:

Bring your own Redis

Instead of using the built-in local Redis instance, you can achieve higher availability, disaster recovery, and enhanced control and security by bringing your own Redis cluster. You can choose between installing the Redis cluster within the Gloo management cluster and run it alongside the Gloo UI and Gloo management server, or to use a Redis cluster that is hosted outside the management cluster, such as by using a cloud provider service like AWS ElastiCache.

Redis settings to customize

When you bring your own Redis cluster, you can customize the following settings.

Keep in mind that by bringing your own Redis instance, you configure both the Gloo management server and Gloo UI to read from and write to the same Redis database. Any settings for your Redis instance, such as the maximum number of retries, are shared between these components.

Provider considerations

Using a Redis or AWS ElastiCache instance in cluster mode is currently not supported.

AWS ElastiCache

When setting up your AWS ElastiCache instance, consider the following deployment options:

Steps to bring your own Redis

To bring your own Redis instance:

  1. Create or use an existing Redis cluster, such as AWS ElastiCache, and make sure that you can connect to your instance from the Gloo management cluster. For example, if the cluster is behind a firewall, you might need to add the public IP address of the Redis cluster to your allowlist.

  2. Choose how to authenticate with your Redis cluster. Depending on your Redis provider, you might be required to use a specific authentication method, such as TLS certificates or a username and password.

  3. Create a Kubernetes secret to store your credentials.

    • Username and password:
      kubectl apply --context $MGMT_CONTEXT -f- <<EOF
      apiVersion: v1
      kind: Secret
      type: Opaque
      metadata:
         name: redis-auth-secrets
         namespace: gloo-mesh
      data:
        username: "<username>"
        password: "<password>"
      EOF 
      
    • TLS certificates:
      kubectl apply --context $MGMT_CONTEXT -f- <<EOF
      apiVersion: v1
      kind: Secret
      type: Opaque
      metadata:
        name: "redis-certs"
        namespace: gloo-mesh
      data:
        redis.crt: "<TLS_certificate>"
      
  4. Follow the Upgrade guide to get your Gloo Platform Helm installation configuration file.

  5. In your Helm values file, add the following information:

    • redis.address: The address to use to connect to your Redis cluster.
    • redis.auth: Add this section if you want to authenticate with your Redis cluster by using a username and password. To authenticate by using TLS certificates, remove this section and configure redis.certs instead.
    • redis.certs: Add this section if you want to authenticate with your Redis cluster by using TLS certificates. To authenticate by using a username and password, remove this section and configure redis.auth instead.
    • redis.connection: You can optionally override the default connection settings, such as the maximum number of retries.
    • redis.db: You can optionally override the index to connect to a specific database in the Redis cluster.
    • redis.deployment.enabled: Set this option to false to disable the built-in local Redis deployment.
    • redis.deployment: If you used the local Redis deployment before and customized the deployment, remove any custom settings in the redis.deployment section.
    redis:
        # Address to use when connecting to the Redis instance. To use the default Redis deployment, specify 'redis.gloo-mesh.svc.cluster.local:6379'.
        address: gloo-mesh-redis.gloo-mesh:6379
        # Optional authentication values to use when connecting to the Redis instance
        auth:
            # Connect to the Redis instance with a password
            enabled: false
            # The secret key containing the password to use for authentication
            passwordKey: password
            # Name of the k8s secret that contains the password
            secretName: redis-auth-secrets
            # The secret key containing the username to use for authentication
            usernameKey: username
        # Configuration for TLS verification when connecting to the Redis instance
        certs:
            # File name that contains the ca cert
            caCert: redis.crt
            # Enable a secure network connection to the Redis instance via TLS
            enabled: false
            # Name of the k8s secret that contains the certs
            secretName: redis-certs
        # Optional connection parameters
        connection:
            # Dial timeout for establishing new connections. Default is 5 seconds.
            dialTimeout: 5s
            # Frequency of idle checks made by idle connections reaper. Default is 1 minute. -1 disables idle connections reaper, but idle connections are still discarded by the client if IdleTimeout is set.
            idleCheckFrequency: 1m0s
            # Amount of time after which client closes idle connections. Should be less than server's timeout. Default is 5 minutes. -1 disables idle timeout check.
            idleTimeout: 5m0s
            # Connection age at which client retires (closes) the connection. Default is to not close aged connections.
            maxConnAge: ""
            # Maximum number of retries before giving up. Default is 3. -1 disables retries.
            maxRetries: 3
            # Maximum backoff between each retry. Default is 512 milliseconds. -1 disables backoff.
            maxRetryBackoff: 512ms
            # Minimum number of idle connections which is useful when establishing new connection is slow.
            minIdleConns: 0
            # Minimum backoff between each retry. Default is 8 milliseconds. -1 disables backoff.
            minRetryBackoff: 8ms
            # Type of connection pool. true for FIFO pool. false for LIFO pool. Note that FIFO has higher overhead compared to LIFO.
            poolFifo: false
            # Maximum number of socket connections. Default is 10 connections per every available CPU as reported by runtime.GOMAXPROCS.
            poolSize: 0
            # Amount of time client waits for connection if all connections are busy before returning an error. Default is ReadTimeout + 1 second.
            poolTimeout: ""
            # Timeout for socket reads. if reached, commands will fail with a timeout instead of blocking. Default is 3 seconds. -1 disables timeout. 0 uses the default value.
            readTimeout: 3s
            # Timeout for socket writes. If reached, commands will fail with a timeout instead of blocking. Default is ReadTimeout.
            writeTimeout: ""
        # DB to connect to
        db: 0
        deployment:
            # Enable creation of the deployment/service.
            enabled: false
    
  6. If you enable external auth for Gloo UI, update the following glooUi settings to match your Redis instance.

    glooUi:
      auth:
        oidc:
          session:
            backend: "redis"
            redis: 
              host: "<redis-host>" #accessible hostname or IP address to your external Redis
    
  7. Continue with the Upgrade guide to reinstall Gloo Mesh with your own Redis instance.