Chef is a very complex system, with a lot of notions and vocabulary that can be very discouraging at first. In this chapter, we'll go through all the most important notions, so it can also serve as a quick cheat sheet or reminder.
Chef can be used in multiple ways, the most important are the following:
- Client/server mode: An agent runs on every managed client, regularly getting updates from the server, and applying them. In this mode, all Chef code is distributed from the Chef server.
- Chef-Solo: In this mode, the need for a Chef server is removed at the cost of less features, including important ones such as search, API, persistent storage of nodes information, and more. All Chef code needs to be sent over in some way to be applied manually.
The multi-platform client is written in Ruby, while its server counterpart is written in Erlang. The Chef server is open source (Apache License at the time of this writing) and everyone can host it, and the company behind Chef is also proposing their own hosted version, with added features and support.
Chef is also highly modular, with a great number of plugins available either directly from Chef, vendors, or the community. Plugins range from IaaS support such as AWS, OpenStack, VMware, or Digital Ocean to hardware management from Dell, HP, or IPMI interfaces, team workflow integration, or system-related concerns such as logs handling, security, and other similar features.
At the very top of a Chef hierarchy, we find an organization. Nothing can be shared between organizations and this is usually where is defined a company, different business units, or even deliberately isolated corporate departments. It's really up to everyone to know what has to be shared with whom to know what the Chef organization will be.
A node, in Chef terminology, is anything managed by Chef, be it physical or virtual, and every node has a number of characteristics or parameters that we'll set or change during the lifetime of the node.
Every node runs inside an environment. Environments are usually matching notions such as development, staging, or production, but it's not uncommon to see creative uses to manage different applications or other groups of interest. Environments also have a set of characteristics set.
Roles are usually functional and generic, more than centered around a product. For example, we'll see a database role way more often than a MySQL role. Other roles can be monitoring-server or loadbalancer.
This is the single most important notion in Chef: a resource is any part of a system to be set in a desired state. This includes a package to be installed or removed, a service to be enabled or started, a file to be generated from a template, a user to be created or banned, and other expected elements of a system.
Recipes are simply plain Ruby files including a number of Chef resources describing a coherent desired state, such as a package to be installed, its configuration file written, and a service to be restarted.
Puppet is a configuration tool published by Puppet Labs, and is an alternative to Chef.
Puppet can also work in a standalone mode like Chef, but we will focus on a client/server architecture.
The Puppet infrastructure is mainly composed of:
- A Puppet server acting as a main configuration server, which contains all the configuration code
- A Puppet agent running on all infrastructure nodes, applying configurations
Communication between agents and the server is done through HTTPS, and Puppet has its own PKI for the server certificate and for client certificates (client certificates are used to authenticate nodes to the server).
Puppet has its own Domain Specific Language (DSL). As for Chef, Puppet is using resources for installing packages, managing services, creating files, and more. A Puppet piece of code is called a manifest, and is a file with a .pp extension. The code is structured using modules. For example, we can imagine an apache module containing resources for Apache installation and service management. We can also have a mysql module for the MySQL server, with its own resources.
There is also a main manifest, outside any module, which is the list of nodes of the infrastructure. For each node, we can specify which module(s) to use to perform the complete node installation. When a node is requesting its configuration from the server, the server compiles a catalog of this node, and the Puppet agent applies this catalog.
We can write our own modules or use existing modules from GitHub of Puppet Forge. Puppet Forge hosts a lot of community modules, and some of them are supported by Puppet Labs.
In this chapter, we will first write our own code in order to learn some basics of the Puppet DSL. We will then use a module from Puppet Forge.