I recently returned from a week in Las Vegas at the VMworld 2017 conference. Besides the pleasure of speaking about Chef solutions with VMworld attendees, I had the honor of speaking with Alan Renouf of VMware about some new technology that VMware and Chef were bringing to market. It was an unbelievable experience and I wanted to take a couple moments here to share some of my key takeaways from the event.
New #ChefFriends at my talk at @VMworld with @alanrenouf pic.twitter.com/AAbnyiaanX
— JJ Asghar (@jjasghar) August 28, 2017
Configuration as Code
First off, the VMware community is abuzz with the idea of configuration management. The thought of “heavyweight” VM templates are a thing of the past, and configuration as code is something that enterprises want to bring across their organizations. As I spoke to members of teams looking to bring “configuration as code” to their organizations, Chef resonated strongly in these conversations. Chef is an amazing answer for configuration management with VMware, leveraging built-in idempotency, delivering scale to support VMs in the 10,000s, providing built-in testing to validate changes, and much more.
Compliance as Code
Along with these configuration management capabilities, the need for compliance management was a common theme in these conversations. This is where I had the chance to tell them about InSpec as a means to manage compliance as code as well. This opened many eyes of the engineers, CIOs, CTOs, and other leadership team members as they realized they can codify their security practices and have compliance earlier in their development pipeline. This allows for significantly less costly security compliance checks and has the ability to “shift left” these practices, bringing security teams into the organization’s DevOps process.
The combination of Chef and InSpec gives application teams the power to detect and correct early in the application lifecycle. As VMware teams start to use InSpec to detect out-of-compliance VMs, and use Chef to correct the outliers, team resources can be reallocated to other key tasks, allowing for insane growth in velocity. Just think: if you could send your security team to a single dashboard that provides the current compliance status of every VM in your infrastructure it gives them confidence in the state of the infrastructure. This gives your security team the ability to spend their time working on larger problems and growth opportunities instead of focusing solely as a risk mitigator and reporter for the business.
Chef and InSpec provide the foundation for VMware teams to correct and detect issues. With the bread-and-butter of core Chef, you gain huge productivity advantages found in your ability to automate system setup processes. For example idempotency is an amazingly powerful way of doing your deployments and configurations. The ability to declare something like this:
package ‘tomcat’ do action :install end
And have know that every machine it runs on will install tomcat if it isn’t there, but if it is there just skip it, opens up huge velocity opportunities. With this you can create your Day 1 and Day 2 cookbooks and know that as you push changes through your Development Pipeline if they are using those cookbooks they will be testing exactly what is in production mitigating risk or possible drift that would only show up when you promote to production.
Day 1 and beyond with Chef
I mentioned Day 1 and Day 2 but this is probably the time I should talk about where Chef’s automation platform can fit inside of the VMware story. As a VMware shop you know that VMware’s claim to fame is Day 0. You need a machine, you put ESXi on some hardware, you ask VMware’s suite of applications to give you a machine, it gets you that VM and you are ready to go. The next challenge is getting it ready for someone to use it.
Day 1, the initial bootstrapping of a machine (ie: installing tomcat and the dependencies for tomcat) can be extremely challenging, especially in a consistently repeatable fashion. You could use VMware templates but can suffer from configuration drift and security drift very quickly. This is where core Chef comes into play. You build the machine via VMware, then hand it off to Chef and it will get you to the desired and required. Take it one step farther with Day 2, and that’s where InSpec and Chef play hand in hand. After your machine has been up for a few days/weeks/months, you need to verify that it’s updated and in the state you need, running Chef and InSpec for your long term Day 2 operations.
Moving from Day 0 to Day 1 and beyond is where the magic of Chef plus VMware becomes clear to application teams. To help make this as seamless of a process as possible, Chef has multiple plugins providing integration with VMware environments, ranging from just talking to the vCenter instances you are running, to demo blueprints inside of vRA. We want to make the Day 1 and Day 2 story delightful and encourage higher compliant velocity for organizations.
Next Steps
If this has piqued your interest, try the plugins out, or come by the VMware{code} Slack team and talk to us real time on the #chef channel.
- Discover more on Chef + VMware
- knife-vsphere pre 6.5 VCSA: https://github.com/chef-partners/knife-vsphere
- knife-vcenter 6.5+ VCSA: https://github.com/chef/knife-vcenter
- knife-vrealize: https://github.com/chef-partners/knife-vrealize
- vRA Blueprint for installing chef-client for Windows: https://code.vmware.com/samples?id=1390
- vRA Blueprint for installing chef-client for Linux: https://code.vmware.com/samples?id=1371
