Canary release allows applications of early and late versions to be deployed in the same environment at the same time. In this case, some users can use the late version and others can continue to use the early version. Then, the proportion of late version users will be adjusted based on user feedback.

Scenarios

You want to frequently update your services and ensure high service quality at the same time. To ensure that you can control the impact if the late version is not working as expected, you must design a canary release system. In canary release, some users can use the late version and others can continue to use the early version. Then, you can evaluate the late version based on user feedback and metrics such as logs, performance, and stability. Based on your evaluation, you can determine whether to roll out the late version to more users until the early version is phased out. Alternatively, you can roll back the late version to the early version if the late one is not working as expected.

Prerequisites

  1. Deploy the services of the late version and early version on different servers. To ensure service availability, we recommend that you deploy the services on multiple servers.
  2. Create an Application Load Balancer (ALB ) instance. For more information, see Create an ALB instance.
  3. Create server groups and add the servers where the early and late version services are deployed to different server groups. For more information, see Manage server groups.
  4. Create a listener and set the default server group of the listener as the server group where the early version service is deployed. For more information, see Add an HTTP listener, Add an HTTPS listener, and Add a QUIC listener.

    In this case, all requests are forwarded to the early version. This topic provides the following ways to implement canary release. You can choose one or combine them based on your business requirements. In the following examples, the late version service is deployed in Server Group A and the early version service is deployed in Server Group B.

Canary release based on HTTP headers

In this example, the requests whose HTTP header key is user-agent and whose HTTP header value is *Mozilla/4.0* are forwarded to the late version.

header
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance.
  4. On the Listener tab, find the listener and click View/Modify Forwarding Rule in the Actions column.
  5. Choose Forwarding Rules > Inbound Forwarding Rules, and click Add Forwarding Rules.
  6. Set the parameters and click OK.
    • Forwarding Condition: Select HTTP Header from the drop-down list, set the key to user-agent, and then set the value to *Mozilla/4.0*.
    • Forwarding Action: Select Forward from the drop-down list and select Server Group A.
    For more information about the parameters, see Manage forwarding rules for a listener.
  7. You can add more forwarding conditions to forward more requests to the late version. If the late version is stable and working as expected, you can phase out the early version and forward all requests to the late version.

Canary release based on cookies

This example shows how to forward the requests whose cookie is key: value to the late version.

cookie
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance.
  4. On the Listener tab, find the listener and click View/Modify Forwarding Rule in the Actions column.
  5. Choose Forwarding Rules > Inbound Forwarding Rules, and click Add Forwarding Rules.
  6. Set the parameters and click OK.
    • Forwarding Condition: Select Cookie from the drop-down list and set the value to key: value.
    • Forwarding Action: Select Forward from the drop-down list and select the Server Group A.
    For more information about the parameters, see Manage forwarding rules for a listener.
  7. You can add more forwarding conditions to forward more requests to the late version. If the late version is stable and working as expected, you can phase out the early version and forward all requests to the late version.

Canary release based on different server groups

In this example, 80% of the requests to www.test.com are forwarded to the early version and the other 20% of requests are forwarded to the late version.

Diagram
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance.
  4. On the Listener tab, find the listener and click View/Modify Forwarding Rule in the Actions column.
  5. Choose Forwarding Rules > Inbound Forwarding Rules, and click Add Forwarding Rules.
  6. Set the parameters and click OK.
    • Forwarding Condition: Select Domain Name from the drop-down and set the value to www.test.com.
    • Forwarding Action: Select Forward from the drop-down list, and select Server Group B (set the weight to 80) and Server Group A (set the weight to 20).
    For more information about the parameters, see Manage forwarding rules for a listener.
  7. You can add more forwarding conditions to forward more requests to the late version. If the late version is stable and working as expected, you can phase out the early version and forward all requests to the late version.