Blue/Green Deployment

Blue/Green Deployment is a technique that enables a team to make changes to their infrastructure without coordinating with customers for a maintenance window.

As an example we provide the Blue/Green implementation for a BastionHost, any existing templates can be updated as needed using the methodology we will discuss in this post.

A Bastion Host is a server whose purpose is to provide access to a private network from an external network, such as the Internet. Because of its exposure to potential attack, a bastion host must minimize the chances of penetration.

Download Example

File Organization:

• single-ec2-bastion-blue-green-deploy:
  • Ansible:
    • ansible.cfg
    • hosts
    • public_keys:
      • id_rsa
    • localhost-configure.yml
    • remote-configure.yml
  • bastion-parameters.json
  • bastionhost.yaml
  • dns.yaml

The Ansible folder contains everything you need to configure the Bastion Host without having to change the user-data, and thus being forced to update the CloudFormation stack. The files localhost-configure.yml can be launched directly from the Bastion Host, while the remote-configure.yml file can be used to configure the Bastion Host from the local machine.

The Bastion Host at startup clones the Git repository and configure itself using localhost-configure.yml.

The bastion-parameters.json file contains the configuration parameters of the Bastion Host, it is in common between the two *.yaml templates. The bastionhost.yaml file is a standard CloudFormation template to which has been added the Ansible configuration and the Version parameter. And, the dns.yaml template, for each stack we have an additional one for the DNS mapping part only.

WARNING: AWS identifies some resources by name, so the version number also appears in the name of the resource to be duplicated.

Procedure

Step 1: Create the stack Version 1

Use the bastionhost.yml template to create the CloudFormation stack associated with the Bastion Host resource. The stack will output a DNS of the following type:

v<Version>.bastion.<Environment>.<HostedZoneName>

which by substituting the parameters becomes: v1.bastion.development.awscliente.com

The newly created Cloud Formation stack name will carry the suffix *-v1.

Step 2: DNS Mapping Creation

Compared to not using Blue/Green Deploy an additional stack should be created that defines a mapping between the previous DNS and the Nominal DNS agreed with the customer, it could be:

bastion.<Environment>.<HostedZoneName>

which becomes: bastion.development.awscliente.com

The output of this step is the following configuration in Route53:

bastion.development.awscliente.com → v1.bastion.development.awscliente.com

v1.bastion.development.awscliente.com → 1.2.3.4 (EIP del BastionHost v1)

which by substituting the parameters becomes: v2.bastion.development.awscliente.com

The newly created Cloud Formation stack name will carry the suffix *-v2.

The output of this step is the following configuration in Route53:

bastion.development.awscliente.com → v1.bastion.development.awscliente.com

v1.bastion.development.awscliente.com → 1.2.3.4 (EIP del BastionHost v1)

v2.bastion.development.awscliente.com → 5.6.7.8 (EIP del BastionHost v2)

Step 4: Test Version 2

We will move on to the testing phase of the new deployment, reporting two cases:

• The v2 version fails the tests, and the newly created v2 stack is deleted.
• The v2 version passes the tests.

Step 4: DNS Mapping Update

If version 2 passes the tests, then it will be necessary to update the DNS stack by setting version equal to 2. After the update of the dns.yml stack the configuration in Route53 will be the following:

bastion.development.awscliente.com → v2.bastion.development.awscliente.com

v1.bastion.development.awscliente.com → 1.2.3.4 (EIP del BastionHost v1)

v2.bastion.development.awscliente.com → 5.6.7.8 (EIP del BastionHost v2)

Step 5: Delete previous version

At the end of the operations the v1 version can be deleted as it is no longer referenced. In this world the client will not have visibility to point to a different BastionHost. After the deletion of the *-v1 stack the configuration in Route53 will be the following:

bastion.development.awscliente.com → v2.bastion.development.awscliente.com

v2.bastion.development.awscliente.com → 5.6.7.8 (EIP del BastionHost v2)

Conclusions

Blue/Green Deployment is an effective technique for making changes to infrastructure without interrupting customer operations. The procedure we have discussed involves creating two CloudFormation stacks and a DNS mapping to ensure a smooth transition to the new version. The Ansible folder provided in the example can help configure the Bastion Host without changing the user-data, making the process more efficient.

The steps involved in Blue/Green Deployment include creating the Version 1 stack, creating a DNS mapping, creating the Version 2 stack, testing Version 2, updating the DNS mapping, and finally deleting the previous version. By following these steps, it is possible to ensure a seamless transition to a new version of infrastructure, minimizing any potential downtime or disruptions.