Running Blue-Green Deployments with DeployHub
According to Cloud Foundry, “Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.” The ability to easily deploy between two environments 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 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 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 Clound 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 deployment 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 supports such a Blue-Green deployment 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’s Key Features
- Blueprint your application’s logical view
- Publish and Catalog Microservices
- Version Microservice Configurations
- Release and Track Microservices
- Manage Database Deployments
- Microservice Configuration Management Blogs
- What is Configuration Management?
- How to Navigate the Deathstar
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- Versioning Lambda Functions
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- How are Microservices and Applications Related?