Navigation :

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.

User session information (such as access and ID tokens) when you also enable external auth for Gloo UI.

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:

Check the Helm reference for the redis component.
Follow the Upgrade guide for instructions on how to upgrade your installation after modifying the Helm fields.

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.

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

When you bring your own Redis cluster, you can customize the following aspects:

Authentication: To authenticate with your Redis instance, you can configure Gloo Mesh to use a username and password when connecting to Redis. Depending on your Redis provider, you might only need to specify a password to authenticate with Redis. You store these credentials in a Kubernetes secret on the management cluster.
TLS certificates: For enhanced security, you can use TLS certificates to authenticate with your Redis cluster. Note that your Redis instance must be configured to accept TLS connections. You store the certificate that you want to use in a Kubernetes secret on the management cluster.
Connection: You can optionally set connection parameters, such as the maximum number of active connections, retries, or number of idle connections.
Database: You can optionally specify the database instance within your Redis cluster that you want to connect to.

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.

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

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>"

Follow the Upgrade guide to get your Gloo Platform Helm installation configuration file.

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

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

Continue with the Upgrade guide to reinstall Gloo Mesh with your own Redis instance.