Deploying a blue-green infrastructure

This guide demonstrates a specific use for the OVHcloud Load Balancer service: configuring a service to facilitate seamless traffic switching between production and new production candidate environments, also known as a blue-green infrastructure.

With a blue-green infrastructure, you can stop your infrastructure from experiencing any downtime. The main benefit of this deployment type is that you can prepare updates and/or maintenance in an environment that is isolated from your production environment. This way, you can test your changes before they are put into production, undo them quickly if you detect any faults, and do all of this with virtually zero downtime.

Requirements

• Access to the OVHcloud Control Panel or OVHcloud API
• An OVHcloud Load Balancer service
• Two dedicated servers, one hosting your production environment, and a similarly configured server hosting your staging environment

Instructions

Scenario

You have an infrastructure that you can use to put your website online.

This environment hosts the website’s code, in addition to all essential applications (web servers, database servers, etc.). You need to update your applications and/or your code regularly. You want to be able to test your updates without impacting the website's availability or functionality for end-users.

One way to achieve this is by deploying a blue-green infrastructure.

The principle of a blue-green deployment involves being able to switch easily from a development infrastructure to a production infrastructure, and vice versa. This switch must be done in a way that is transparent to your users. To do this, public traffic will be routed to the standard HTTP port 80 for access to the production infrastructure, and a non-standard port, such as 8888, will be used to access the development infrastructure.

Deploy the infrastructures

In the scenario, your IP Load Balancer service plays a central role. It is the element you use to expose your two infrastructures (production and development) to different users at the same time.

The production infrastructure can be accessed by your customers on the standard HTTP service (port 80), and your development infrastructure can be accessed by developers and admins on the non-standard port 8888.

During the initial setup phase, we will arbitrarily assign a role to each of the parts of our infrastructure. Infrastructure A serves as the initial production environment, while Infrastructure B serves as the staging environment. At this stage, we will consider them to be similar to one another.

A blue-green infrastructure involves switching from infrastructure A to infrastructure B, once infrastructure B has been fully updated and validated. The Load Balancer will manage this switch.

The diagram below gives a general idea of the architecture:

Infrastructure A

This infrastructure is made up of a server cluster that will later be associated with a front-end of your IP Load Balancer. This server cluster will expose an HTTP or a TCP service to the front-end. It also balances loads by sending the front-end’s incoming traffic to the servers. For more details on the role of various components of the OVHcloud Load Balancer service, you can read the following guide: Introduction to the OVHcloud Load Balancer.

In our scenario, we will declare a server cluster of servers for the HTTP service. Please note that you can create as many clusters (as well as TCP services) as are required for your final service to be exposed to your customers.

Link a dedicated server to your farm if it hosts your production infrastructure. The service exposed to the front-end is supplied by the server’s port 8080. You can link one or more servers with each cluster (for example, to balance the load or offer higher fault tolerance).

Infrastructure B

Functionally, this second infrastructure is identical to the first. It is also composed of a server cluster that will later be associated with a second front-end of your IP Load Balancer. This server cluster exposes the same service to the front-end as the first server cluster. This service is supplied on the servers by port 8080.

Deploy the server cluster for the HTTP service (and/or any other TCP services required for your final service to be exposed to your customers).

Associate a server with your server cluster. Here, it involves one or more physical servers hosting your development infrastructure.

Front-ends

The magic of blue-green deployment lies in the configuration of your front-ends. At this stage, we have configured two functionally identical infrastructures. For both infrastructures, you have declared one or more server clusters, each with its own set of associated servers.

To switch simply from one infrastructure to another, we will use front-ends.

To do this, we need to declare two front-ends. The first one will give you access to your production infrastructure, whereas the second will give you access to your development infrastructure. You can control access to one infrastructure or the other using the ports you expose to your customers.

Blue front-end

This front-end is dedicated to accessing the production infrastructure. The ports exposed to your customers are the standard ports for accessing the service. In this case, we are exposing an HTTP service, so we will use port 80 (443 if you would like an SSL termination).

Green front-end

This front-end is dedicated to accessing the development infrastructure. The ports exposed to your customers will be non-standard ports that you can choose arbitrarily. In this case, we will expose the HTTP development service on port 8888.

Manage the deployments

Initial deployment

Once you have finished configuring the components of the OVHcloud Load Balancer service, you now just need to apply your changes.

The production/staging switch

At this stage, our initial environment is deployed and ready to use. Now, you need to switch over your front-ends from one server cluster to another.

Let’s take a look at our scenario:

• The production infrastructure (A) is deployed on the cluster Infra A (id 2359), which in turn is attached to Server HTTP A. This infrastructure can be accessed through the blue front-end.
• The development infrastructure (B) is deployed on the cluster Infra B (id 2360), which in turn is attached to Server HTTP B. This infrastructure can be accessed through the green front-end.

Once you have modified/applied updates to infrastructure B and checked that the service is working properly, you decide to put it into production.

To switch between the two clusters, you can simply update your different front-ends by modifying the ID of the server cluster it is attached to, and applying the modification.

The blue front-end (id 2473) will then be associated with Infra B (new production, id 2360).

The green front-end (id 2474) will then be associated with Infra A (new development, id 2359).

Conclusion

You now have an infrastructure you can use to simply and efficiently manage blue-green deployments.

Developers have access to a development environment on port 8888 (or any configurable non-standard port), while your customers continue to access the service in production via the standard HTTP port (80).

The infrastructure presented here is limited to just one port, but it can be expanded by adding other ports. For example, you can also expose your website on the standard HTTPS port (443). You can do this by defining new clusters dedicated to each port you want to expose and associating them with their corresponding front-ends (one for the standard port exposed in production, the second for the arbitrary port dedicated to development).

Another way to consolidate your infrastructure even further is by multiplying the servers attached to your clusters. This way, you can make your services more redundant (guaranteeing availability as a result), and also add a load balancing capacity.

Go further

For more information and tutorials, please see our other OVHcloud Load Balancer guides or explore the guides for other OVHcloud products and services.