New Relic : Driving Canary releases with New Relic and Argo Rollouts

When you deploy new code, there's always the potential for issues to come up. Many developers use Canary deployments to incrementally release new features to subgroups of users. If problems arise, only a small group of users is affected.

While Canary deployments are lower risk than deploying to all users at once, it's still important to monitor your deployments. In this post, you will learn how to use New Relic to drive your Canary releases, making your application deployment safer, faster, and easier to set up, and ensuring that only healthy versions of your application go into production.

This post assumes you are already using Kubernetes (also known as K8s), Docker, Service Mesh, and Canary. You'll get an overview of Argo Rollouts Analysis powered by New Relic AIOps Proactive Detection. All examples presented are specific to this demo application. You will need to create your own recipe for your Canary releases. You can follow along with this tutorial using this GitHub repository.

Requirements

Installing Argo Rollouts

Argo Rollouts is described as "a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes." Learn more about Argo Rollouts' features.

To install Argo Rollouts, input the following commands:

This creates a new K8s namespace named argo-rollouts where the Argo Rollouts controller will run. The kubectl plugin can be installed using Brew by running on the terminal . More instructions on how to install the Argo Rollouts can be found in the official documentation.

Setting up host-level traffic splitting for Canaries

This tutorial will use a host-level traffic splitting approach that splits the traffic between a Canary and a stable service. To use this approach, you will need to create the following Kubernetes resources:

• Istio Gateway
• Service (Canary)
• Service (stable)
• Istio VirtualService
• Rollout

The ingress Istio gateway receives our application connections on port . For simplicity's sake, it is bound to all hosts (*):

Next, run the following command:

This manifest creates two K8s for both versions, and . The selector of these () will be modified by the during an update to target the Canary and stable pods.

Next, you need to create a VirtualService () that defines the application traffic routing rules. Argo Rollouts continuously modifies this virtual service, such as when you set the desired Canary weight. Initially, 100% of the traffic will be routed to the stable version. Run this command to create the virtual service:

Argo Rollouts New Relic Analysis requires a K8s containing your Account ID, Personal Key, and Region ( or ) to run the analysis against your account's data. New Relic also needs another K8s to enter your New Relic License Key and pass it over to the demo application with an environment variable.