上QQ阅读APP看书，第一时间看更新
Getting to know Chef
As with any other tool or system, there are new concepts and terminologies to be learned. Here are some terms that you may have seen or will see in this chapter:
- Node: A node is a system that is managed by Chef. These can be servers, desktop systems, routers, and anything else that is capable of running the Chef client and has a supported operating system.
- Workstation: A workstation is a special node that is used by a system administrator to interact with the Chef server and with nodes. This is where the command-line tools are executed, specifically the knife command-line tool.
- Bootstrap: This is a process of setting up a node to be used as a Chef client. This involves performing any work required to install the dependencies for Chef as well as Chef itself.
- Bootstrap Script: There are a number of possible ways to install Chef, Ruby, other core requirements, as well as any additional configuration that is needed for your specific systems. To provide this level of flexibility, the bootstrap process is scripted; on Windows, this is a batch file.
- Recipe: Recipes provide the instructions required to achieve a goal, such as installing a software package, configuring a firewall, provisioning users, installing printers, or managing other system resources. These are written in Ruby and executed on the nodes specified by the system administrator through the Chef console.
- Cookbook: A cookbook is a collection of recipes; typically, a cookbook provides one specific group of actions such as installing Apache or MySQL, providing Chef resources for a specific software tool, and so on.
- Attributes: Various components of the system have their own attributes and properties that describe how the software is to be configured. These properties are defined at various levels, ranging from node-specific settings to general defaults for a cookbook or a role.
- Role: A role is a collection of recipes and configuration data that describe how a resource should be configured in order to play that role in your overall system architecture. Examples of roles might include MSSQL Servers, Exchange Servers, IIS Servers, file servers, and so on. A role does not contain any knowledge of resources (systems) to apply the role to, only the configuration data.
- Run List: A run list is a list of recipes to be applied to a given node in a certain order. A run list can be composed of zero or more roles or recipes, and the order is important as the run list's items are executed in the order specified. Therefore, if one recipe is dependent upon the execution of another, you need to ensure that they run in the correct order.
- Resource: Resources are a way of describing what a recipe is performing. Some examples of resources would include files, directories, printers, users, packages, and so forth. A resource is an abstraction of something that is concretely implemented in a provider.
- Provider: A provider is a concrete implementation of a resource. For example, a user is a generic resource, but LDAP users or Active Directory users are concrete implementations of a user resource. The type of provider being selected will depend on some factors, such as the platform.
- Data bags: Data bags contain shared data about your infrastructure. Information that is not specific to a role or a resource, such as firewall rules and user accounts, will be stored in data bags. This is a good place to store system-wide configuration data.
- Environments: Environments provide a level of encapsulation for resources. For example, you may have two identical environments, one for testing and one for production. Each of these may have similar setups but different configurations, such as different IP addresses and users.