Creative data center engineers at two well-known Web companies have brought Opscode’s Chef automated configuration tool into new territories, including disaster recovery planning and continuous application delivery.
Edmunds.com, a publisher of automotive information websites based in Santa Monica, Calif., began using Chef when it made the move to cloud computing with Citrix Systems Inc.’s CloudStack about a year ago.
Configuring systems for the cloud, one of Chef’s customary use cases, is also one of the primary scenarios for use at Edmunds. But it was a demonstration with implications for disaster recovery that ultimately sold the business on using Chef, according to senior systems engineer KC Braunschweig.
“We were able to provision 20 or 30 servers into CloudStack, bring those up, bootstrap them into Chef, have Chef configure our entire application and … in a period of 20 minutes, have the actual site up and running,” Braunschweig said.
“From a disaster recovery perspective, it means we could lose everything except for our data backups and our source code repository, and if we had to go into some other environment … Chef can rebuild our environment from scratch,” he added.
Cloud provisioning wasn’t an out-of-the-box Chef feature; instead, Braunschweig and his staff developed a command-line tool called knife-cloudstack for CloudStack for that part of the process.
Now that it’s been demonstrated as possible, Braunschweig said he’d like to see building up and tearing down the environment happen as a part of the daily routine — at least, in the development side of the house. This would minimize risk from manual errors, he said.
Ultimately, the goal is to move all of the company’s systems virtualized with Red Hat KVM into the CloudStack private cloud infrastructure and automate it using Chef and the Knife Chef plug-in. From there, the company will work toward an automated hybrid cloud model and run workloads wherever it’s cheapest, Braunschweig said.
Ancestry.com cooks up continuous delivery
Ancestory.com, a popular genealogy website that specializes in historic documents and information, perpetually changes.
Because of that, continuous application delivery, a set of practices in which small changes to an application are made as frequently and quickly as possible, has been built in to Ancestry’s application development process over the last nine to 10 months as the company has grown more proficient at DevOps. It incorporated Chef into the application deployment process after a series of automated tests.
A year ago, this was a partially manual process that involved people copying files from one place to another, according to John Esser, director of engineering productivity and agile development. But today, if an engineer checks in a new piece of code, Ancestry’s homegrown automation system steps in, builds all the files that are needed, then runs the code through a series of automated quality gates.
Then, “somebody would push a button to release that into production,” Esser said. “That’s where Chef would take over.”
Through a series of configuration files, Chef knows which servers the application files are bound for, and it deploys them to each of the servers that need deploying to, orchestrating that whole process. It takes the servers out of the load balancer, deploys the new code, does some high-level testing to make sure everything is deployed correctly, and then puts those servers back in the load balancer to take live traffic.
“In our old system, that would typically take about three to four hours to deploy code,” Esser said. “Now, that cycle could be anywhere from 10 to 15 minutes, maximum, sometimes even less than that.”
Less manual intervention and more small changes to code means fewer errors, easier error isolation, and more frequent deployments — multiple times a day, usually — where before, deployments were done at best once every two weeks.
Continuous delivery is also a goal for Edmunds.com. As in Ancestry’s case, it will also have to build a more holistic automated testing system around Chef.