As IT systems become larger, and require more frequent updates to leverage new business opportunities and maintain a competitive edge; the time to deploy and outage caused by these updates needs to be kept to a minimum. One of the areas that can improve delivery time and reduce outage is to automate the deployment of systems.
The current approach to provisioning applications particularly to Linux environments uses a combination of custom shell scripts, RPMs and ssh to configure and deploy applications to multiple host environments. This presents a major challenge when managing an ever increasing number of servers as manually driven administration results in a myriad of machine configurations, which all are required to comply with internal policies for security, performance and legal standards.
Server proliferation is a reality that will affect most companies in the future with the introduction of cloud based technologies, which will lead to systems requiring servers, physical or virtual, numbering in the thousands if not tens of thousands. The management of servers on this scale cannot be achieved effectively using a manual process. With an increasing number of servers, the demands on the system administrators will increase as more time is spent on manual configuration and management of servers. To meet these challenges an automated approach is required which allows the software landscape of the server estate to be modelled and stored in a central repository, all under version control, which can be deployed on demand to a large number of servers, in a repeatable, consistent and reliable manner.Puppet (Puppet Labs) and Chef (Opscode) are the two main products available that have been adopted and endorsed by a number of global companies for automating deployment to their large scale IT environments. Hence both are well established and have a number of reference sites that can be used to demonstrate the capability of the products.
There isn’t too much to choose from between Puppet and Chef, they both provide similar functionality and either one would provide a good solution. Puppet is more System Admin friendly due to its straight forwardness; Chef on the other hand has a programmer’s type style more suited to a Dev Ops approach to provisioning systems. Both of these products are available as Open Source or licensed products, offering enhanced features and support as an incentive to buy the products. Puppet has been out in the market longer than Chef so currently has a larger customer base; although Chef is gaining market share with the release of version 11 which has been rewritten in Erlang for increased performance and scaling. Both are supported by a large community base where a large number of common reusable resources are available, helping to reduce the amount of code that needs to be written.Puppet and Chef both have architectures that scale up, and use a client-server model, where the client performs the bulk of the processing on the node they run on, only communicating with the server to retrieve the data objects and code they require to apply the configuration changes to the node. In both cases the communication is based on HTTPS and secured using certificates to authenticate and authorize the connections between the client and the server.
Puppet uses a Domain Specific Language to define the resources and configuration. It provides dependency management, so the order in which resources are defined is not important. On the positive side the language is intuitive to learn and use, but as the language is proprietary has the disadvantage that it’s not as flexible as using a procedural language. Chef on the other hand defines its cookbooks and recipes in a procedural manner using Ruby. This offers a richer, more flexible and powerful environment to create the cookbooks and recipes, but has the downside that the order of the code is written is important in order to define dependencies.
Chef has the edge over Puppet in terms of architecture providing a simpler and more cohesive integration of the components making up the system. Chef has been developed by people from a Dev Ops background, so some of the concerns associated with development have been addressed. These are shown in the Knife tool which provides a better environment for writing and managing the resources and versioning for cookbooks in the Chef server’s repository. Chef stores cookbooks in the Chef server’s repository against a version. A node via an Environment, can reference specific versions of a cookbook in its run list, allowing for a more versatile approach. Puppet on the other hand doesn’t support the concept of versioning of its modules and applies on the latest versions loaded from the manifest path configured on the Puppet Master, so relies on Version Control Software to provide versioning.
Puppet stores the configuration data as files on the Puppet master, which for large complex systems could prove to be cumbersome and hard to manage. Chef stores the configuration data as attributes in cookbooks, roles, environments and data bags, with rules for precedence. The attributes can be created using the Chef console or as JSON files, which are then uploaded to the Chef server. Hence Chef provides a more flexible approach to defining, storing, retrieving and managing configuration data, which is very important when managing large complex infrastructures.
Alan Fryer
C2B2 Principal Consultant