Running Blue-Green Deployments with DeployHub
According to Cloud Foundry, “Blue-green deployments is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.” The ability to easily perform Blue-green deployments is easily supported by DeployHub through the definitions of DeployHub Environments. Your DeployHub Application (collection of components like microservices) can be assigned to multiple Environments and deployed in a ‘rolling’ fashion or in this popular Blue-Green Deployments round-robin process. With DeployHub, you define both Environments for your Application and push your deployments accordingly.
DeployHub will track the endpoint history, of each Environment, including versions of each component that was released, Application Version, date, time, and User. It is important to understand that in order for your Blue-Green deployments to become ‘active’ to your end-users, you will need a load balancer that redirects users after the deployment has been successfully completed. DeployHub is not a load balancer, but it can communicate with your load balancer as a ‘post’ deployment step to re-route users.
DeployHub Blue-Green Deployments and Cloud Foundry
Blue-Green deployments are most commonly associated to Cloud Foundry. Cloud Foundry is an open-source cloud platform as a service (PaaS) on which developers can build, deploy, run and scale applications on public and private cloud models.
Developers interact with Cloud Foundry by running a command line tool (cf) which then interacts with the Cloud Foundry Endpoint. With DeployHub, you release a new Application (or make changes to an existing Application) using the “cf push” command to upload the Application to the Cloud Foundry Endpoint. Cloud Foundry supports multiple “spaces”. Each space can be configured individually and can be used as different target types (for example, Dev, Test, and Production).
Since DeployHub is an agentless solution, it can deploy to Cloud Foundry by executing the ‘cf’ command automatically as part of the deployment process. DeployHub can extract your Application code from any Repository and push the changes up to the Cloud Foundry Endpoint. It can then track which version of the Application and associated Components is installed in which Cloud Foundry space.
Installing Cloud Foundry’s ‘cf’ Command Line Interface (cf CLI) on the same server as DeployHub allows the execution cf commands easily. An Application contains one or more Components, any one of which can have a Custom Action containing a cf command that targets the designated Cloud Foundry Endpoint. For instance, a Cloud Foundry application named my_app could be started by writing a script named startMyApp.sh that looks like:
cf api https://myexample.com
cf auth myname mypassword
cf target -o myorg -s myspace
cf push `my_app` -c null
If this script resides within the /scripts directory of the DeployHub installation, it can be called by putting “/scripts/startMyApp.sh” into a Procedure, placing it within an Action, and putting the name of the Action into a Component’s Custom Action field. Deploying the Application that contains the Component causes the Action to be called, which runs the script and starts the Cloud Foundry Application named my_app.
Cloud Foundry is ideal for Blue-Green deployments strategies. In such a scenario, Production is mirrored across two distinct environments – “blue” and “green”. End Users point to one of these Environments whilst deployments are made to the other. Once testing is complete on the deployed Environment, users are switched over to this Environment and the deployment is performed again to the other Environment. This maximizes uptime and minimizes the risks in performing a Rollback.
DeployHub microservice catalog supports such Blue-Green deployments strategy. Both Environments can be targeted individually as part of two separate deployments or you can deploy to both with DeployHub deploying to the second Environment automatically following successful test and switch-over.
DeployHub Key Features
- Microservice Catalogs Explored
- Microservice Supply Chain
- A Microservice Service Catalog for Incident Response
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Ship Microservices Safely – Know Your Blast Radius
- Simplifying Microservice Applications
- Microservice Configuration Management
- Database Updates Pushed Across Your CD Pipeline