Earlier this summer I had the opportunity to participate in strategic meetings with VMware customers to discuss data center transformation, hyper-converged architectures and the relevance and suitability for large development environments.
These were large customers whose business depends on consistent delivery of services. I reviewed the business value, the transformational capabilities provided by the Software-Defined Datacenter and the use of VMware’s hyper-converged solution as the building block. To address their network and security, we presented NSX and vSphere Integrated OpenStack (VIO) as their development facing infrastructure service. There were consistent questions around accessibility to programmable APIs, as these customers have bought into and adopted DevOps culture within their enterprise. With the exponential growth of DevOps in industry, it is no secret that companies and customers from all verticals are looking to the potential outcomes of this type of operating model.
The importance of programmable APIs has become of extreme value and importance for enterprise customers as they consider the adoption of DevOps operating models. Modern software products and frameworks are expected to be accompanied by a well-defined and fully accessible set of programmable APIs. VMware has an API-first approach to their development lifecycle. In fact, VMware APIs are one of the most utilized sets of programmable APIs in the industry. At VMware, we have a portfolio composed of a multitude of products, solutions, and frameworks. Some of which are partially integrated, others are fully integrated, and some others are not integrated at all. Either way, each solution possesses its deployment and configuration procedures depending on what resource domain they are part of in the data center.
As an advocate of DevOps culture and operating model, I feel that individual functions and procedures for different resource domains of the data center are required and needed. I also believe that VMware products should include and leverage richer operating methods that should also cater to, and facilitate DevOps operating models. Great to hear that VMware’s flexibility was what our customers were looking for: they wanted to manage their infrastructures with a set of tools that matched their DevOps operating model. Essentially, the customers expressed interest in not having to worry about the specific deployments and configuration of infrastructure artifacts but simply to get to their personnel to their development environments.
We discussed many possibilities for which I started to consider the use of DellEMC VxRAIL appliances. I could see overcoming some of the challenges they were presenting from the engineered appliance and the core compute, storage, and network perspective. I still needed to deal with vSphere Integrated OpenStack, and NSX. We have many different ways to automate the deployments of these solutions, one of them PowerCLI. However, this was not one of the preferred DevOps tools in this case since we were discussing Linux environments.
My plan was to design a solution based on all the requirements and feedback discussed during the customer meetings. I needed the right tools and approach to make this work as a scalable and reliable solution with DevOps principals for the enterprise.
For this solution, I decided to utilize an Open Source deployment and configuration automation toolkit developed by VMware called Chaperone. Chaperone “aka El Chapo” as I like to call it, is an Ansible based tool that is intended to expedite and standardize “typical” deployments and configuration of VMware solutions. VMware open source software projects can be found on the VMware Open Software page on GitHub. For those that are not familiar with Ansible here is a brief definition for context and to get you started:
Ansible – is an automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration. Designed for multi-tier deployments and its used to model IT infrastructure by describing how all systems inter-relate, rather than just managing one system at a time. Ansible uses a simple language (YAML) to form playbooks. Ansible Playbooks are the configuration, deployment, and orchestration artifacts that provide the ability to describe the automation tasks.
Chaperon provides everything that I needed for what I was trying to accomplish. To validate what I was working on, I reached out to Jake Dupuy, a colleague who is one of VMware’s most talented consultant’s in VMware’s Hybrid Cloud and Cloud Native Applications team who has extensive experience working with this tool in production environments. With Jake, I was able to achieve what I was looking to accomplish from an automation perspective and more.
My initial goal was to develop the solution to complement the deployment model of VxRAIL appliances. This solution would completely automate the deployment and configuration of the resources and service domains that were not handled by the VxRAIL automated configuration procedures. I know that making modifications to the deployment and configuration procedures of the VxRAIL engineered appliances are not supported. That is something that is out of my control and up to the DELLEMC VxRAIL product and support teams to make product enhancement decisions.
Instead, we went ahead and created the solution in a way that could be used for any hyper-converged environment that was powered by either VxRAIL or vSAN Ready Nodes. For vSAN Ready Nodes, the solutions can be used to perform complete end-to-end deployment and configuration of all of the resources, and service domains (vSphere, Virtual SAN, NSX, VIO). For VxRail powered environments, a portion of the solution could be used as a post VxRAIL deployment and configuration process via an out-of-band configuration to access the NSX and VIO appliances.
I decided to proceed and present this approach instead of my initial idea. Take a look at the demo of the process below:
While my intentions were to make this specifically for VxRAIL, I’m not able to make that happen. I would like to see this type of capability available on the VxRAIL Manager, where customers can have solutions like NSX, and VIO automatically deployed and configured by choosing them from a management screen.
Justin King “aka Mr. @VxJustinKing and team it’s on you guys to enable this type of capability or solution for VxRAIL. 😀
Jake Dupuy, thank you very much for sacrificing your weekends to help me create and validate this idea. You are the man!!! my friend. Also Richard Boswell for pointing me in the right direction.
– Enjoy
For future updates on Virtual SAN (VSAN), vSphere Virtual Volumes (vVols) and other Storage and Availability technologies, as well as vSphere Integrated OpenStack (VIO), and Cloud-Native Applications (CNA) be sure to follow me on Twitter: @PunchingClouds
