The Blue/Green Deployment strategy allows you to leverage two environments to update your customer-facing application(s) without any downtime time or user impact. This is achieved by creating two environments that differ only by the most recent application updates, one proven production environment (Blue) and one staged for deployment (Green). These two nearly identical environments allow you to switch production traffic between the environments during deployment, resulting in seamless updates to customers and the ability to rollback quickly if any issues arise.
It's possible to take advantage of Blue/Green Deployments by leveraging StackPath's Edge Computing and DNS platforms. Let's take a look at how this can be done.
Blue/Green Deployments with Edge Computing Containers & Virtual Machines
The example below assumes you already have a production (blue) workload setup utilizing an Anycast IP and serving your customers.
Ensure DNS TTLs are Low
First, ensure that your application DNS TTLs are set to a 2min TTL for your current production (blue) workload. This means that resolvers should not cache the result for more than 2mins. This will result in more DNS queries but also means your end users will see your updates sooner. If you currently have a high TTL you will need to consider this before proceeding with your updates as this could result in downtime for your users if they are still being served a cached query and you remove the old workload prematurely. If you have a high TTL you may want to update your TTL to 2mins and then proceed with the upgrade once the previous TTL has elapsed to ensure the TTL has propagated worldwide.
Create a Duplicate Workload
Next, create a duplicate (green) workload with the exception of the updated application code. For container workloads, this could be as simple as incrementing the version tag of your containers and for Virtual Machine workloads this may involve recreating the environment on all instances and checking out the latest git master. This workload should typically match your current workload spec, however, this could also be a good time to upgrade your workload spec if you think you need extra resources.
Test the New Workload
Once the new (green) workload is active you should test to ensure that your application is responding as expected. If you need a DNS entry for your tests you could set up a staging subdomain or create an entry in your local hosts file to ensure you're testing against the new (green) workload.
Once you're happy that your new (green) workload is functioning correctly it's time to switch your traffic to the new (green) workload.
Switch to the Green Workload and Test Again
Now that your updated application has been tested and confirmed as working as a staging environment it's time to switch the DNS from your Blue Workload to your Green Workload. This moves your production traffic from the Blue workload to the Green workload making application updates visible to your users. Update your primary DNS entry to the new Anycast address and apply the changes and you should then see your instance receiving production traffic within 2mins as DNS caches are refreshed due to our updated TTL. We recommend running your tests against your production workload again to ensure that are no issues.
Verify and Increase DNS TTLs
Once you've verified that your production workload is running with no errors and that no production traffic is seen on the old (blue) workload you can increase the DNS TTLs to increase the number of time queries are cached for and reduce the number of DNS queries being served.
Congratulations, you've successfully completed a Blue/Green Deployment! If you need any assistance with any of StackPath's platform please feel free to reach out to us at email@example.com