Today, most of the major cloud computing players provide an easy-to-use UI to build your IT infrastructure on the cloud. However, unlike provisioning once on on-premise infrastructure, you may have to dynamically provision (or deprovision) dozens of virtual machine (VM) instances, a few instances of dynamic storage and some SaaS-based services. In addition, software releases need to be pushed regularly (weekly, daily or even hourly in some cases).
One way to go about it is to create VM images for every change and create a new VM instance to push it. However, this is laborious and prone to errors especially if different instances have different application data. Add to that, What about the storage? Databases? Network configuration?
What about architecture? As your usage of cloud infrastructure for Dev/QA/Production environments grow, it becomes an operational challenge to manage the entire infrastructure. Operational tasks listed below becomes a nightmare for a System admin.
• Creating instances
• Configuring instances with storage, services, firewall, software
• Monitoring and deleting instances
• Ensuring all instances in a layer (web/app) are in the same state.
This is when you would need a configuration management system which basically gives you the ability to deploy, update, and repair your entire application infrastructure using nothing but pre-defined, automated procedures. Ideally, you want to automatically provision your entire environment from bare metal all the way up to running business services completely from a pre-defined specification, including the network configuration.
Chef is an infrastructure automation framework that makes it easy to set up, configure, deploy, and manage servers and applications to any environment (physical/virtual/cloud).
With Chef you can code your infrastructure (called ‘recipes’) and use the recipes to set up the infrastructure.
Once automated, you hold a blueprint for your infrastructure, enabling you to build (or rebuild) automatically in minutes or hours – not weeks or months. Better still, in case of disasters (network, hardware or geographical) Chef makes disaster recovery job easier.
Chef has become one of the widely used tools for configuration management. Apart from Chef, tools supporting cloud environments are Puppet, Ansible, Salt. AWS OpsWorks is an application management service that makes it easy for DevOps to model and manage the entire application from load balancers to databases. Amazon OpsWorks supports Chef.
With Chef you will be able to:
• Manage servers by writing recipes.
• Integrate tightly with applications, databases and more.
• Configure applications that require knowledge about your entire infrastructure
• Create perfect clones of QA environments, pre-production environments, partner preview environments and more.
Before we get started working with Chef, let us run through the terms used frequently.
|recipe||Configuration element within an organization. Recipes are used to install, configure
software and deploy applications
|cookbook||A fundamental unit of configuration and policy distribution. Each cookbook defines a scenario, such as everything needed to install and configure MySQL.|
|knife||Knife is a command-line tool that provides an interface between a local chef-repo and the Chef server. Knife helps provisioning resources, manage recipes/cookbooks, nodes & more.|
|chef-repo||Chef-repo is located on the workstation and contains cookbooks, recipes, roles. Knife is used to upload data to the chef server from the chef-repo.|
|workstation||A workstation is a computer that is configured to run Knife, to synchronize with the chef-repo, and interact with a single server. The workstation is the location from which most users will do most of their work.|
|node||A node is any physical, virtual, or cloud machine that is configured to be maintained by a chef-client|
|run_list||A run_list is an ordered list of roles and/or recipes that are run in exact order.|
|chef-client||A chef-client is an agent that runs locally on every node.|
Chef comprises three main elements: a server, one (or more) nodes, and at least one workstation.
• The server acts as a hub that is available to every node. All chef-client nodes will be registered with the server. The server holds all the cookbooks, recipes and policies. Clients communicate with the server to get the right configuration elements from the server and apply it to the nodes.
• The workstation is the development machine from which configuration elements like cookbooks, recipes, and policies are defined. Configuration elements are synchronized with the chef-repo and uploaded to the server with knife command.
• Nodes contain chef-client which performs all the infrastructure automation.
There are 3 types of Chef Servers
1. Hosted Chef: Hosted Enterprise Chef is a version of the Chef server that is hosted by Chef. Hosted Enterprise Chef is cloud-based, scalable, and available service with resource-based access control. Makes life easier, you will not have to run an additional server and manage it.
2. Enterprise Chef: is similar to hosted chef but the chef server will be located on premise.
3. Open Source Chef is a free version of Chef Server.
We’ve recently written a blog post on getting started with Chef.