Installation
This chapter discusses the Installation and configuration of open source chef server.
Install the Chef Server
Prerequisite
System Requirements
Some of the important system requirements that need to be fulfilled before we install the chef server are
- Users: Chef server requires a local user and group to be created. It will create them automatically if proper privileges are given, but if we don’t have a restricted access to the environment then we need to create them manually.
- FQDN: The server should have a complete and fully qualified domain name (FQDN), and it should be resolvable. If we are working in a production environment we should go for a DNS (Domain Name System) entry.
- Git: Git must be installed on the server so that it is able to maintain the revisions of internal services.
- NTP: As the chef server is sensitive to click drift, the server should be connected to an NTP server.
- Apache Qpid: The daemon should be disabled on CentOS and Red Hat systems.
- Make sure your firewall is configured properly.
Hardware Prerequisite
If we are going to use our chef server for testing purposes, it can be installed on an m1.small instance on AWS (Amazon Web Services). It can also be installed on a local virtual machine with 1GB of RAM.
If we are going for a production environment, then the desired configuration is
- RAM—4GB
- Cores—4 with 2.0GHz Intel/AMD CPUs
- Disk space—5GB in /opt and 5GB free in /var
The following operating systems support the chef server:
Operating System |
Version |
Architecture |
|---|---|---|
Ubuntu |
10.04, 10.10, 11.04, 11.10, 12.04, 12.10 |
X86_64 and i686 |
Enterprise Linux |
5,6 |
X86_64 |
Hostname
The main prerequisite for chef server is that the hostname of the server should be set before installing the server. The hostname should meet certain conditions.
- The hostname should be an FQDN and should include the domain suffix as well.
- It should be resolvable. For a production environment, we should go for a DNS entry; in a testing environment we can make an entry in /etc/hosts to ensure that the hostname is resolvable.
To check whether you have configured the hostname properly, run the "hostname"command. The output should be similar to what we see in Figure 3-1.
Figure 3-1. Verifying a hostname
To check whether your hostname is resolvable, run the "hostname –f" command. The output should be similar to what we see in Figure 3-2.
Figure 3-2. Verifying that a hostname is resolvable
Installation
In this section we demonstrate the Installation of chef server version 11.x.
Steps
Several steps need to be taken to install the open source chef server.
The first step is to download the chef server installer available on the chef web site.
Go to the following link and download the OS-relevant setup as shown in Figure 3-3.
Figure 3-3. Downloading the chef server(1)
In the chef server tab, select the operating system (OS), its version, and its architecture. A list of the chef server versions will come up. Select a version. The download link for the selected version will come up as shown in Figure 3-4. Click the link to start downloading. Make the selections as shown in Figure 3-4 as we will be installing the chef open source version on RHEL (Red Hat Enterprise Linux).
Figure 3-4. Downloading the chef server(2)
We will be installing the chef server on a machine with the RHEL OS. Install the rpm downloaded on the machine as shown in Figure 3-5.
Figure 3-5. Installing the chef server
When the rpm is installed the next step is to run a command that will configure the chef server. Run the following command (see Figure 3-6):
$ Chef-server-ctl reconfigure
Figure 3-6. Configuring the chef server
The foregoing command will install the chef server with default settings. If we need some custom settings, then we need to create a file from which the chef server will fetch the settings. We discuss this topic in detail in the section “Configuration.” When the configuration is complete you will see a screen similar to the one in Figure 3-7.
Figure 3-7. Configuration completed
To check whether our Installation completed successfully, run the following command (see Figure 3-8):
$ Chef-server-ctl test
Figure 3-8. TestingInstallation of chef server
This is a built-in command that comes with chef. Whenever you invoke the command, it will run a test against the installed chef server and verify whether everything is working fine.
Figure 3-9. Testing successful
A screen similar to the one in Figure 3-9 will let you know if the Installation is working properly.
Now, open the WebUI of the chef server using the IP (Internet protocol) address or the FQDN of the server. You will find a screen similar to the one in Figure 3-10.
Figure 3-10. Web interface of chef server
Installation on a Virtual Machine
In this scenario we will install the chef server on a virtual machine. The following requirements are necessary to proceed with the Installation:
- A computer running VMware workstation with a configured virtual machine running RHEL 6.0.
- A working browser on the computer running the workstation.
- A bridged adaptor to configure our chef server.
- The IP or the FQDN of the virtual machine in order to access the chef server.
Steps
The steps are similar to those of installing the chef server on a server.
First, download the chef server package on the virtual machine.
Go to the following link and download the OS-relevant setup as shown in Figure 3-11.
www.getChef.com/Chef/install/
Figure 3-11. Selection an appropriate Version of Chef-Server
In the chef server tab, select the OS, its version, and its architecture. A list of the chef server versions will come up. Select a version. Figure 3-12 shows the download link that will come up for the selected version. Click the link to start downloading. Make the selections as shown in Figure 3-11, as we will be installing the chef open source version on RHEL.
Figure 3-12. Downloading the chef server
We would be installing the chef server on a machine with RHEL OS. Install the rpm downloaded on the machine as shown in Figure 3-13.
Figure 3-13. Installing the chef server
Once you have installed the rpm, the next step is to run a command that will configure the chef server. Use the following command, as shown in Figure 3-14:
$ Chef-server-ctl reconfigure
Figure 3-14. Configuring the chef server
The aforementioned command will install the chef server with default settings. If we need some custom settings we need to create a file from which the chef server will fetch the settings. We discuss this topic in detail in the section “Configuration.” When the configuration is complete you will get a screen similar to the one in Figure 3-15.
Figure 3-15. Configuration completed
To check whether our Installation completed successfully, run the following command as shown in figure 3-16:
$ Chef-server-ctl test
Figure 3-16. TestingInstallation of chef server
This is a built-in command that comes with chef. Whenever the command is invoked, it will run a test against the installed chef server and will verify whether everything is working fine or not.
You will see a screen similar to the one in Figure 3-17 if the Installation is working properly.
Figure 3-17. Testing successful
Now the next step would be to set the network adapter of your virtual machine to bridged. It should look similar to what we see in Figure 3-18.
Figure 3-18. Set network adapter as bridged
Restart the network services of the virtual machine and run ifconfig command to get the IP address of the virtual machine as shown in Figure 3-19.
Figure 3-19. Restarting network services
Open the web browser and access your chef server. You will see a screen similar the one in Figure 3-20.
Figure 3-20. Web interface of the chef server
Use the default login credentials available to access the chef server. Now we have set up a chef server on a virtual machine.
File System locations
Chef server uses the following file locations for installing chef.
- /opt/Chef-server: This directory is used for Installation.
- /etc/Chef-server: This directory is used for storing the key files and the API configuration.
- /var/opt/Chef-server: All the services in chef are here.
- /var/log/Chef-server: This directory is used for storing the logs.
Configuration
The chef server is installed with default configuration settings. If we need to update any configuration settings, then we need to create a Chef-server.rb file and specify the settings that we need to modify.
After specifying the settings, we need to run the Chef-server-ctl reconfigure command to apply these settings.
The configuration file is located at /etc/Chef-server/Chef-server.rb.
These settings are optional and are required only if we want to change the default settings.
Some of the important settings that can be modified are mentioned in the Table 3-1.
The following settings can be added to the Chef-server.rb file to tune it:
Table 3-1. Settings available in chef-server.rb
Setting |
Description |
|---|---|
api_fqdn |
It is used to define the FQDN of the server. The value should be same as the FQDN for the server. |
bookshelf[‘vip’] |
The virtual IP address. Default value: node[‘fqdn’]. (This setting is related to the bookshelf service.) |
Bootstrap |
Default value: true. |
notification_email |
Default value: [email protected]. |
Optional Settings
The following settings are often used for performance tuning open source chef in largerInstallations. When changes are made to the Chef-server.rb file, the open source chef must be reconfigured by running the Chef-server-ctl reconfigure command.
Bookshelf
Bookshelf services can be tuned by changing the following setting:
Setting |
Description |
|---|---|
bookshelf[‘vip’] |
The virtual IP address. Default value:node[‘fqdn’]. |
Chef Expander
The following setting is often modified from the default as part of the tuning effort for the opscode-expander service:
Setting |
Description |
|---|---|
Chef_expander[‘nodes’] |
The number of allowed worker processes. The opscode-expander service runs on the back end and feeds data to the opscode-solr service, which creates and maintains search data used by the server. Additional memory may be required by these worker processes depending on the frequency and volume of chef client runs across the organization, but only if the back-end machines have available CPU and RAM. Default value: 2. |
Chef Solr
The following settings are often modified from the default as part of the tuning effort for the opscode-solr service:
Setting |
Description |
|---|---|
Chef_solr[‘heap_size’] |
The amount of memory available to Apache Solr. If there is not enough memory available, search queries made by nodes to Apache Solr may fail. The amount of memory that must be available also depends on the number of nodes in the organization, the frequency of search queries, and other characteristics that are unique to each organization. In general, as the number of nodes increases, so will the amount of memory. |
Chef_solr[‘max_field_length’] |
The maximum field length (in number of tokens/terms). If a field length exceeds this value, Apache Solr may not be able to complete the building of the index. Default value: 100000 (increased from the Apache Solr default value of 10000). |
Update Frequency
At the end of every chef client run, the node object is saved to the server. From the server, each node object is then added to the SOLR search index. This process is asynchronous. By default, node objects are committed to the search index every 60 seconds or every 1000 node objects, whichever occurs first.
When data is committed to the Apache Solr index, all incoming updates are blocked. If the duration between updates is too short, it is possible for the rate at which updates are asked to occur to be faster than the rate at which objects can be actually committed.
For open source chef, the following settings are configurable in the Chef-server.rb file:
Setting |
Description |
|---|---|
Chef_solr[‘commit_interval’] |
The frequency (in seconds) at which node objects are added to the Apache Solr search index. Default value: 60000 (every 60 seconds). |
Chef_solr[‘max_commit_docs’] |
The frequency (in documents) at which node objects are added to the Apache Solr search index. Default value: 1000 (every 1000 documents). |
erChef
To tune the opscode-erChef service, the following settings can be changed:
Setting |
Description |
|---|---|
erChef[‘db_pool_size’] |
This setting specifies the number of open connections to the database server that are maintained by opscode-erChef service. The default value is 20. This should be changed along with the postgresql[‘max_connections’] setting. |
erChef[‘s3_url_ttl’] |
This setting specifies the timeout for chef client. The default time out is 900. |
Postgresql
The tuning of postgresql service can be done by changing the following settings:
Setting |
Description |
|---|---|
postgresql[‘max_connections’] |
The setting specifies the maximum number of allowed concurrent connections to the database server. This value should only be tuned when the ErChef[‘db_pool_size’] value used by the opscode-erChef service is modified. Default value for the max_connections is 200. |
WebUI
The following setting can be modified from the default as part of the tuning effort for the opscode-webui service:
Setting |
Description |
|---|---|
Chef_server_webui[‘worker_processes’] |
This setting specifies the number of allowed worker processes. This setting should be increased or decreased based on the number of users in an organization who use the server web user interface. The default value for the worker_processes is 2. |