In our last blog post, we gave you an introduction and high-level overview of how Chef Automate and HPE OneView work together to enable cloud-like speed on bare metal hardware. In this post, we’ll explore a bit deeper with technical details and code examples.
There are the three main requirements to run most modern applications. You need a network to serve up your application’s traffic, compute resources to run your application, and storage to retain important data and content. Traditionally, separate teams handle each of these areas. If you want to bring up a brand new environment the process might look something like this:
Two weeks! Some organizations take up to two months or more simply to deliver some virtual machines. These delays lead to frustrated users, who often create their own “shadow IT” environments using their company credit card and public cloud provider environments. This is a nightmare for organizations who care about security and cost controls. But who can really blame the poor developers? They simply want to get their work done on time. Moving everything into the cloud is usually not a viable option for legacy applications and workloads.
HPE and Chef have partnered together to bring the world of Infrastructure as Code right down to the layer of bare metal. You can easily provision network, storage, and compute resources right in your own data center. Sensitive data stays secure and controlled within your own physical network, but you still gain the speed and efficiency that your users demand.
Let’s say you need to stand up a new ethernet network for your application. In a traditional data center this would usually require logging onto a network device and running some commands to create the network and add all the correct routing data. With the OneView Chef cookbook it’s a simple Chef resource like the example below:
oneview_ethernet_network 'Eth1' do client my_client data( vlanId: 1001, purpose: 'General', smartLink: false, privateNetwork: false ) end
You’re not just limited to network configurations. You can also add a storage pool like the example below:
oneview_storage_pool 'CPG_FC-AO' do client my_client storage_system 'ThreePAR7200-8147' end
Network and storage wouldn’t be complete without their friend compute. We’ve got you covered there too. This example brings up a new physical server in enclosure 1, bay 2:
oneview_server_profile 'ServerProfile2' do
client my_client
data(
description: 'Override Description',
boot: {
order: [],
manageBoot: true
}
)
server_profile_template 'ServerProfileTemplate1'
server_hardware 'Encl1, bay 2'
endChef recipes are easy to write and easy to read. Think of them as “executable documentation”. You simply string together the building blocks, or resources, that are required to stand up each part of your application stack. Once you have your Chef recipe ready you can run it with the proper login credentials, then sit back and watch your infrastructure build itself. After your infrastructure is built you can use Chef Automate to view the build status and compliance status of each part of your infrastructure.
Our story begins at Spacely Space Sprockets, the world’s leading manufacturer of Space Sprockets. We’ll be following along with the lead systems engineer George as he and his team begin their journey on the path of continuous automation.
The systems engineering team configure most of their machines using scripts and manual processes. As a result it can take several hours to deploy a new machine. Developers have complained about long lead times to get their dev environments set up properly, and sometimes the machines are delivered with the wrong settings or missing packages.
Our team has started a pilot project to speed up delivery times and gain better control over bare metal server deployments. Chef and the HPE OneView cookbook will be used to build and deploy their infrastructure and applications. The cookbook exposes all of the configuration settings of a Synergy rack via simple, declarative Chef resources. There are plenty of examples you can copy to configure your own devices.
Find the code samples here: https://github.com/HewlettPackard/oneview-chef/tree/master/examples
George used the OneView cookbook to whip up a Chef recipe to create fibre channel networks, an ethernet network and an enclosure group. You can see a copy of the entire recipe here. For the sake of brevity, we’ll show the part of the recipe that stands up our blade server in the bottom rack of our enclosure, in bay 4:
oneview_server_profile 'Chef-Node-1' do client my_client server_hardware 'BOT-CN75150107, bay 4' server_hardware_type 'SY 480 Gen9 CNA Only' enclosure_group 'EnclosureGroup1' server_profile_template 'RedHat 7.3' end oneview_server_hardware 'BOT-CN75150107, bay 4' do client my_client power_state 'on' # action [ :set_power_state, :update_ilo_firmware ] action :set_power_state end
Note how you can even update firmware using Chef!
See how easy that was? You simply declare where you want the machine deployed and name a server profile template to build the machine with. The next resource powers on the machine for us after it has been built.
George runs this Chef recipe from a special infrastructure node that is used expressly for configuring the Synergy rack. It can be inside the rack itself, or external to it. As long as you have valid API credentials you can configure your HPE Synergy infrastructure. OneView Chef recipes are a little different from normal Chef recipes, because they are meant for configuring infrastructure and not operating system configs. Current Chef users will feel right at home because they already speak the language. New users will also find it easy to build and maintain their infrastructure using the Chef DSL.
Let’s take a look at what happens when George ran his Chef recipe. Here’s a screenshot of the Composer UI that shows the new server being built. Note that it was put exactly where the code said it should be located, on the bottom rack in bay number 4. With Chef you have fine-grained control over every part of the hardware and software.
Now you might be wondering how to configure the machine once it’s up and running. Since it’s a bare-bones Red Hat 7.3 OS, George still needs to install some packages and middleware before we can get the application running. In order to bootstrap the machine with Chef and get all of that set up correctly, he needs to add a simple bash script to the OS build plan. All of the Synergy and Image Streamer API endpoints can be configured using Chef. Our installation script goes toward the end of the build process as shown below:
Step number 7 will install Chef, bootstrap our node to the Chef Automate server, and then execute the run list, or list of instructions that Chef uses to build the machine. In this case we are standing up an instance of the company’s ecommerce site. This is a Linux/Java/Tomcat/Apache stack with a MySQL database on the back end. Remember that building these servers used to take George and his team anywhere from a few hours to a couple of days. Now they are able to do it with Chef in less than twenty minutes, on bare metal hardware. What an improvement! The dev team is thrilled that they can have new environments set up so quickly. New hires are able to be productive on their very first day at work. Senior devs are no longer hoarding machines because they are afraid of long rebuild times. The sysadmins are happy because they are no longer wasting time fixing broken dev environments. Because a brand new environment is never more than twenty minutes away, it’s often quicker to simply wipe and re-provision.
Now that we’re using infrastructure as code to build our environments, let’s take a look at the Chef Automate dashboard to get an overall health check:
See how there are two nodes? One is the helper node that builds and manages the Synergy rack, and the other node is the ecommerce server that we just built. All our Chef recipes are running successfully which means everything was built exactly to code. From this point forward the Chef client will run every 30 minutes on each node, ensuring that any configuration drift is caught and remediated quickly. No more worrying about sysadmins or developers changing settings by hand. Instead our syseng team is able to build everything from source.
But what about security and compliance? For that we head over to the Compliance tab of Chef Automate. Chef Automate is not just for building machines. You can also use it to scan your entire fleet for compliance and audit status. The compliance dashboard is powered by Chef’s compliance-as-code tool, InSpec. InSpec is a language and framework for describing audit, security, compliance and QA requirements. You can use it to ensure that all your infrastructure is built correctly and stays compliant with internal and external security regulations.
First let’s take a peek at the Synergy node which is passing all its tests. Below is the InSpec code that was used to make sure our application was deployed onto the correct hardware. InSpec is even easier to learn than Chef, so you can quickly develop rule sets for all your QA and audit needs:
We’re also able to collect compliance data on our OS and applications. In the ecommerce-prod-1 report we see the results of a Linux security baseline scan. Sysadmins can take action on each item and remediate them according to the severity level.
This was a simple example of how you can leverage Chef to move faster and more efficiently in your own data center. If you have more complex use cases, Chef can scale to support hundreds of thousands of machines across multiple data centers. Join the ranks of the Chef community and learn more at: http://learn.chef.io