Three common scenarios for development teams:

• An engineer is stirred from sleep by her phone chirping an alert: “[URGENT][PROD]: # of dropped connections exceeds threshold.”
• A project manager considers slipping a deadline because his team suddenly has to deal with targeting a group of over 120,000 users.
• Redis metrics showing increased load and high contention have your infrastructure team scrambling for a solution.

What do all of these situations have in common? They can be addressed by introducing LaunchDarkly’s Relay Proxy into your infrastructure, a process that just got a whole lot easier.

For those deploying their services on dedicated hosts, compiling and running the Relay Proxy is a simple binary download away. Those teams leveraging containers can take advantage of our published Docker image. But what about customers relying on Kubernetes?

Traditionally, a Kubernetes-based deployment required a non-trivial amount of upfront effort. Infrastructure teams had to spend time learning how the Relay Proxy operates so they could write custom YAML configurations for the container, deployment, service, and other resources.

This manual configuration can be greatly reduced through the use of LaunchDarkly’s Relay Proxy Helm Chart that is now generally available.

What are Helm charts

"Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application." – https://helm.sh/

Helm is a package manager for Kubernetes. Each package, or chart, is a collection of files that describe a set of resources in a Kubernetes cluster. Helm provides chart authors with templating support to allow basic control flow like conditional branching and loop constructs. This in turn allows chart users to influence the shape of the resulting Kubernetes resource configuration.

The Relay Proxy chart allows a wide range of control over the resulting deployment, including the deployed docker image, scaling options, and all Relay Proxy configuration options. These options are detailed in the chart’s README file.

Deploy the Relay without the delay

Let’s see what it takes to deploy the Relay Proxy to address one of the cited concerns from earlier:

"Redis metrics showing increased load and high contention have your infrastructure team scrambling for a solution."

If your SDKs are configured to use Redis, each flag update results in the SDK attempting to update the Redis data store. While this concurrent update is safe from overwrites, at scale it can become inefficient and unnecessarily tax your cluster. To solve this, the Relay Proxy will be responsible for updating Redis. SDKs are then configured in LDD mode where they treat the Redis instance as read only and no longer receive updates directly. Let’s see it in action.

First install the Relay Proxy Helm Chart.

While there are multiple ways of controlling the input into a helm chart, we find it's easiest through value files.

To use the Relay Proxy with Redis, we need three pieces of information – a LaunchDarkly SDK key, the Redis password, and Redis hostname. For this demonstration, we are specifying the SDK key and Redis password directly from the command line. Normally you would load these values from a secret. See our getting started guide for an example of how to do this.

In our values.yaml file, we enable Redis support and configure the hostname to the Redis cluster. Our file looks like:

We can now install an instance of this chart into our cluster using values.yaml.

And just like that we have a working deployment of the Relay Proxy into our Kubernetes cluster!

Get Started

The Relay Proxy Helm chart is publicly available for all customers of LaunchDarkly. Get started by reading the documentation. To learn more about the Relay Proxy itself, visit the official LaunchDarkly docs site.

We love hearing your feedback and insights. If you have suggestions or ideas for future improvements, please email us at feedback@launchdarkly.com.