The post Updating your application with MCP DriveDrain appeared first on Mirantis | Pure Play Open Cloud.
Providing complete lifecycle management for an application involves more than simple Continuous Integration and Continuous Delivery (CI/CD). When done right, there’s orchestration involved, as well as oversight, auditability, and even, on occasion, manual approvals. Here at Mirantis, we find that the Mirantis Application Platform, based on Spinnaker, provides a way to take advantage of all of those capabilities for a complete application lifecycle management solution.
But what if you don’t have a complete solution? What if you only have the CI/CD portion? What if your application is not cloud native?
Can you still do lifecycle management?
For example, if you have Mirantis Cloud Platform, you already have the ability to do CI/CD. (In fact, MCP is based on it). So why not dip your toe into the water and get started with that?
Today, I am going to show you how you can do CI/CD (continuous integration, continuous delivery) of a sample application deployed to an Openstack-based cloud using the Jenkins component in MCP DriveTrain. If you’re running a Kubernetes-based cloud instead, don’t worry, the principles are essentially the same, at least from the Jenkins standpoint.
First, a little background on DriveTrain.
DriveTrain is the heart of Mirantis Cloud Platform (MCP), giving you the flexibility to adapt your private cloud to on-the-ground application reality without significant investment in professional services. You can continuously tune the services, versions, configuration, and topology of your clouds to suit the changing needs of your business – all while delivering critical updates with minimal interruption.
Just like the public cloud providers do with their own clouds, DriveTrain uses an infrastructure-as-code approach for your private clouds, helping you to reduce the cost of manual steps and the risk of delivering change quickly.
In this way, you can fully automate the delivery, testing and maintenance of your infrastructure so you can achieve efficient, day-2 operations, zero-downtime upgrades, and stay current with the latest open source features and fixes.
With DriveTrain, you can manage your private clouds with:
Code – programmatic deployment/changes
Automation – continuous integration, delivery, and validation
Control – configuration change auditing
In the following example, we have a simple web application that is being maintained on a git repository. The master branch is currently deployed into production, and we will demonstrate how to orchestrate a test environment to build, deploy, and test a development version of that same application. Once the tests have passed, the production environment can be upgraded using those same tools and mechanisms.
All of the above is achieved via automation, which not only provides extreme agility, but also minimizes errors and failures.
It is assumed that the reader is familiar with CI/CD and orchestrations tools such as git, jenkins, heat, and so on. Links are provided at the end for your convenience as well.
The staging view
Of course you’d never deploy right into production, so the first step is to build the application, deploy it to a dev/test or staging environment, and test it. In the Jenkins component of MCP, that process looks something like this:
Let’s take a brief look at how that works. (If you want the details, you can scroll down to the embedded video which shows the step-by-step process.)
Here is how the typical stages would be defined and executed by using the Jenkins component in MCP DriveTrain.
To build your application, typically you integrate a build system (such as Maven) with a repository (such as Git). Jenkins provides capabilities for source code management, build triggers, build environments, and so on, and you can easily configure them.
You typically have the prod/master branch running in production, so in this example, you would choose a dev/feature branch of your application in the code repository to start with.
Once the build process Jenkins triggers completes, you’re ready to deploy the application.
Deploy
In this example, we’re deploying the application to OpenStack, so we’ll do it using Heat Orchestration Templates (H.O.T.) that triggered from the Jenkins pipeline. (If you were deploying to Kubernetes, you might use Helm instead, for example.)
You can perform the Initial configuration of Jenkins for H.O.T by specifying the connection parameters to the Openstack configuration:
You specify the actual heat template that you want use for orchestration in the deploy stage of the pipeline. You configure the environment details within the heat template itself, as well as passing any parameters (such as branch, floating ip addresses, and so on) as inputs or outputs.
Test
Once the application has been deployed, you can test it by integrating various automation tools with Jenkins. In this example, we have just used curl commands to validate the http output from the test application. You can also use the outputs from the heat templates in the previous step as inputs to drive the test automation in this stage as well.
This is what the dev application looks like in this test environment.
Note that because the Heat template was directed at the dev/test environment, the production environment is not impacted at all, and you can now plan and schedule the upgrade to the new version.
Promoting to production
At its simplest level, promoting these changes to production is a straightforward matter of performing the same steps, but with a Heat template that deploys to production rather than dev/test or staging.
But is that really how it should be?
In an ideal world, the process of promoting code to production would be integrated into a more complex pipeline that includes not just deploying to and testing on staging, but also automated or even manual approvals. You can do this manually, of course, or you can use a tool that provides that level of orchestration and auditability support, such as Mirantis Application Platform’s Spinnaker component.
Why bother with CI/CD?
Of course, in some ways it seems like CI/CD makes things more complicated, but continuous integration and delivery provides various benefits that make it worth the effort
Continuous delivery provides benefits such as:
Integration bugs are detected early and are easy to track down due to small change sets. This saves time, money, and countless hours of aggravation over the lifespan of a project.
CI/CD avoids last-minute chaos at release dates, when everyone tries to check in their slightly incompatible versions of the overall code.
When unit tests fail or a bug emerges, if developers need to revert the codebase to a bug-free state without debugging, only a small number of changes are lost because integration happens frequently.
Continuous delivery means constant availability of a “current” build for testing, demo, or release purposes.
Frequent code check-in pushes developers to create modular, less complex code.
It enforces the discipline of frequent automated testing.
Additional benefits of continuous automated testing include:
It provides immediate feedback on the system-wide impact of local changes.
It allows for efficient use of resources. For example, a small dev/test environment can be created and destroyed on demand.
Software metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and feature completeness) focus developers on developing functional, quality code, and help develop momentum in a team.
In summary, CI/CD via automation delivers extreme agility and efficient use of resources via automation, whether you use the basic version built into MCP, or you provide more complex pipelines using MAP and Spinnaker..
Interested in learning more about how to get the best from your Mirantis Cloud Platform? Check out our 3 day MCP training course.
Additional resources
What OpenStack is and how it works
What Heat is and how it works
What Jenkins is and how it works
Mirantis DriveTrain lifecycle management
Link to demo
The post Updating your application with MCP DriveDrain appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis
Published by