Running Blue-Green Deployments
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
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.
For more articles, please look here: https://www.deployhub.com/microservices-resources/
