Chef
This chapter introduces Chef, which is a configuration management tool, and its integration with IBM PureApplication System. You can find more information about Chef, including its terminology, by going to the following website:
This chapter covers the following topics:
14.1 What is Chef
Chef is a configuration manager that lets users automate the build and configuration of servers. A standard Chef framework is composed of the following components:
•Chef workstation: The development node. The Chef workstation maintains the Chef repository, which holds the developmental copies of the cookbooks. Users can develop cookbooks and add them to the Chef local repository on a workstation, or synchronize the Chef repository with a version control system, such as Git. Alternatively, users also can download community maintained cookbooks. Cookbooks, roles, and data bags are uploaded to the Chef server from the workstation.
•Chef server: The centerpiece of the Chef framework. The Chef server stores all configuration data (such as cookbooks, roles, and data bags) and makes them available to the Chef client that is hosted on the nodes.
•Chef client: A configuration agent that runs on the nodes. The Chef client is installed at deployment time and is used to configure the node per the specified cookbook definition that is retrieved from the Chef server. After the initial configuration, the Chef client maintains communication with the Chef server. If the Chef client receives cookbook configuration changes (such as a cookbook update) from the Chef server, it reconfigures the node per the new cookbook definition.
•Node: The server that is configured and maintained by the Chef client by using a cookbook definition that is retrieved from the Chef server.
14.2 Chef integration with PureApplication System
PureApplication System supports the Chef framework. On PureApplication System, a Chef server shared service can be deployed to a cloud group. This shared service acts as an abstract pointer to an organization entity on a Chef server. This action creates a separation of concerns between the PureApplication System hardware and resource administrator, pattern deployer, the pattern developer, and the Chef administrator.
•The PureApplication System hardware and resource administrator continues to manage PureApplication resources without exposure to the Chef framework.
•The pattern developer is responsible for defining and testing the nodes, pattern parameters, chef roles, and recipe at deployment time.
•The pattern deployer’s role remains unchanged. The pattern deployer can redefine deployment-time parameters and recipes of a pattern, or deploy the pattern as defined by the pattern developer.
•The Chef administrator is responsible for developing and maintaining the cookbook from the Chef workstation, and for indirectly managing the workload by updating the cookbook repository on the Chef server.
14.3 Configuring the external Chef server shared service
To begin integrating an existing Chef infrastructure with PureApplication System, configure and deploy an external Chef server shared service. You must meet the following prerequisites:
•The Chef workstation must be installed and configured by following the instructions that are found at the following website:
•The Chef server must be installed and configured by following the instructions that are found at the following website:
To deploy an external Chef server shared service, the following items are required:
•A Chef server HTTPS URL, with a path to the organization, for example:
•An organization validation key, which can be found in the organization’s Starter Kit that is generated from the Chef Management UI after the compressed file is downloaded and unpacked. The validation key file is in the following directory:
chef-repo/.chef/<organization-name>-validator.pem.
•A Chef server SSL certificate, which is in the following directory:
/var/opt/opscode/nginx/ca/<chef_server_fqns>.crt on the Chef server.
The following fields are optional:
•Proxy URL for the Chef client (optional): Needed if the Chef client on the workload nodes cannot reach external resources, such as the Chef server.
•No proxy for (optional): A comma-separated list of servers for which the Chef client does not use the proxy (for example, resources on the same network).
•Gem repository URL for Chef recipes (optional): A URL pointing to the Gem repository (the default is http://rubygems.org/).
•Proxy URL for Gem repository (optional): The proxy URL that is used exclusively to access the Gem repository.
Before your first Chef deployment, you must load an appropriate package to the Chef client plug-in configuration window from your local machine by completing the following steps:
1. Click Catalog → System Plug-ins.
2. Select the chefclient/x.x.x.x plug-in from the pattern type Chef Pattern type x.x.x.x.
3. Click Configure and upload the appropriate package for your operating system (OS).
14.4 Sample Chef deployment
You can add the Chef client to the nodes of any virtual system pattern (VSP). Whether you have an existing Chef infrastructure and configuration assets or not, integrating Chef with PureApplication System is easy. By using the Chef client pattern type, PureApplication System users can install the Chef client on any nodes that must receive periodic configuration updates or nodes that can benefit from automated configuration.
Complete the following steps:
1. Click Virtual System patterns and select or clone one of your existing patterns.
For clarity, Figure 14-1 demonstrates a simple pattern. It is composed of a Base OS node named workstation. Drag the Chef client from the Software component palette. The Debug component is useful because you can use it to resume on error during deployment, if needed.
Figure 14-1 Example deployment with the Chef client
Figure 14-1 shows the following terms:
•Environment
In this field, you can specify the Chef environment and the constraints to which the node is to adhere. A blank Environment field places the node in the Chef’s _default environment. A node takes only one environment.
•Tags
This field specifies the tags to be associated with the node. These tags are custom descriptions that the Chef administrator can use to find, group, and manage nodes easily. The example in Figure 14-1 on page 384 has a single tag, but the field can take multiple tags that are separated by commas.
•Install run list
– The term run list is a Chef concept. PureApplication System further divides the run list into three separate lists to be run at different times during the node lifecycle.
– The install run list is run one time only in the node’s lifecycle during the middleware configuration step, just after the Chef client is installed. This is a special use of run list because users can use it to pass in dynamic attributes. In Example 14-1, cookbook FTP3 has only one simple default recipe.
Example 14-1 FTP3/recipes/default.rb - the default recipe in the FTP3 cookbook
#
# Cookbook Name:: FTP3
# Recipe:: default
#
# Copyright 2015, My Corporation
#
# All rights reserved - Do Not Redistribute
#
execute 'ftp3_bootstrap' do
command "wget -qO- --no-check-certificate https://companyx.net/pub/bootstrap/bootstrap.sh | /bin/bash"
end
execute 'ftp3_reg' do
command "register_bootstrap_mode --force --username=#{node['FTP3']['user']} --password=#{node['FTP3']['pass']}"
end
– The install run list should include any recipe for which the configurations are expected to persist after a system restart or are not idempotent (for example, direct modifications to /etc/sysconfig/ip tables).
– The recipe in Example 14-1 runs two commands. The second command passes in two attributes: user and pass. These Chef attributes are defined in the FTP3/attributes/default.rb file, as shown in Example 14-2. However, they are set to empty strings to not include hardcoded login credentials.
Example 14-2 FTP/attributes/default.rb
# FTP3 username and password attribute
# default is blank
# must pass in via IPAS JSON or middleware config will fail due to Install run list failing
default['FTP3']['user'] = ""
default['FTP3']['pass'] = ""
– To pass in these attributes at deployment time, you can use the JSON attributes for overriding field or the Attributes file in JSON format field. Example 14-3 shows an example of the JSON that can be passed in for this particular example. The syntax of the JSON depends on how you define the attributes in your cookbook. The top level of the JSON defines the recipe. (In this sample cookbook, only one default recipe is included, and its name is the same as the cookbook name.) The second level defines the attributes. The use of double quotation marks is expected here. Otherwise, an exception is thrown at deployment time (for more information about debugging, see 14.5, “Debugging a deployment by using a Chef client on PureApplication System” on page 386).
Example 14-3 JSON with overriding attributes
{
"FTP3": {
"user": "testuser",
"pass": "myftppass"
}
}
•Default run list
– This run list is run after the node finishes starting and after every node restarts. If the Chef client is running as a daemon, the run list runs periodically. The interval is defined in the Periodic intervals field.
– This run list is appropriate for any idempotent configurations and configurations that might not persist through restart. This run list also runs when you run chef-client.
•Stop run list
This run list is run when the node is stopped.
The deployment in Example 14-1 on page 385 runs the FTP3 recipe and point a deployment to a YUM package repository at deployment time. Then, it runs the recipe nginx and hardens to install and configure the nginx http server and hardens the node SSH configuration by disallowing SSH access by password login. Then, it updates the authorized_keys file with only authorized users’ public keys.
Because the Chef client is running as a daemon with 1800-second intervals (30 minutes), the chef-client command runs every 30 minutes to pick up and apply any configuration changes of the cookbooks in the default run list. If the node run list is modified by a Chef administrator that uses either the Management UI on the Chef server or the knife command on the Chef workstation, these chef-client actions also apply those cookbook changes.
14.5 Debugging a deployment by using a Chef client on PureApplication System
If a cookbook was reasonably tested and all dependencies resolve, they also work without any problem on PureApplication System. However, do not overlook slight environment differences because they can cause one or more dependencies to not resolve as expected. In a PureApplication System deployment, the Chef client installation and configuration occurs as the last step of middleware configuration. If your deployment hangs or fails at this step, one or more Chef cookbooks from either the install run list or the default run list are the likely culprits. To aid debugging and testing effort, add the Debug component to your pattern.
Figure 14-2 shows the location of the Debug component on the IBM Pattern Builder. You can drag it to anywhere within the canvas. It is a stand-alone component and does not need to be connected to any other components or nodes.
Figure 14-2 The debug component can be added to any pattern by using the IBM Pattern Builder
After you add the debug component, you can explore additional options on the right side of the canvas by clicking the component within the canvas, as shown in Figure 14-3.
Figure 14-3 Additional options for the debug component
The settings in Figure 14-3 on page 387 suspend the deployment on error so that the deployer can review the error logs and correct any recoverable errors (for example, missing or invalid parameters or file system permissions issues). You can use the Resumable on script error function to resume the deployment after correcting the issues by running the following script within the problem virtual machine (VM):
/0config/nodepkgs/common/scripts/pdk-debug/resume.sh
Deployment
Here is an example problematic deployment attempt and how it can be debugged.
First, start the deployment of the pattern, as shown in Figure 14-4.
Figure 14-4 Example of a problematic deployment
The pattern in Figure 14-4 on page 388 was deployed as is, with the exception of the user name and password attributes for the FTP3 recipe that is shown in Example 14-3 on page 386.
Deployment error on the GUI
After a few minutes, the deployment progresses to Step 4 of 4: Preparing middleware (see the Status field and progress bar in Figure 14-5). An error is encountered here, so the debug component suspended its run. The middleware perspective in Figure 14-5 indicates which node is hung. This information is especially useful when a deployment has multiple nodes.
Figure 14-5 Virtual system instance detail window showing the Debug component in action
From this same view (Figure 14-5 on page 389), you can scroll down to the History section, where you can find more information. Figure 14-6 shows the deployment history of this instance. If a failure occurs on multiple nodes, the History section indicates the specific nodes to view.
Figure 14-6 The deployment history is useful during debugging
Now, you know that the deployment encountered an error during the installation and configuration of the Chef client. The Chef client is contained in the Chef_Client part of the middleware role of the workstation node. Look at the relevant logs for this role to proceed.
Log review
To view the logs for a particular virtual system deployment, click the Manage icon at the upper right corner of the virtual system instance detail window, as shown in Figure 14-7. The instance console opens.
Figure 14-7 The Manage icon opens the Instance Console
Click the Logging tab to open the log viewer, which is shown in Figure 14-8.
Figure 14-8 Logs of interest from the log viewer
|
Tip: With the exception of the 0config directory, the logs in the blue boxes in Figure 14-8 represent other middleware roles of the deployments. If there are errors during the middleware configuration step, look at these places.
Note: The 0config directory contains logs that pertain to the VM configuration step of the deployment. The state of the VM status column in the UI correlates to this 0config.log file.
|
The scripts.log log file logs data that pertains to the script files that run the chef-client commands. Example 14-4 shows an excerpt of the scripts.log file. The error message is highlighted in red. The offending command is highlighted in blue.
Example 14-4 Excerpt of scripts.log
[Fri 24 Jul 2015 02:52:46 PM UTC] Chef_Client-Part Part/start.py 139911279023936 pid=14426 DEBUG Invoking script: /opt/IBM/maestro/agent/usr/servers/workstation.11437749249623/scripts/ChefClient/start.py
[Fri 24 Jul 2015 02:52:46 PM UTC] Chef_Client-Part Part/start.py 139911279023936 pid=14426 DEBUG Working dir: /opt/IBM/maestro/agent/usr/servers/workstation.11437749249623/pyworkarea/requests/1450500946818800934
[Fri 24 Jul 2015 02:52:46 PM UTC] ChefClient/start.py 139911279023936 pid=14426 INFO Executing Chef Client ...
[Fri 24 Jul 2015 02:52:46 PM UTC] maestro 139911279023936 pid=14426 DEBUG VM_INSTALLED == False (node part)
[Fri 24 Jul 2015 02:52:46 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 INFO knife command is:knife tag create s2iwd-214_workstation.11437749249623 workstation -u s2iwd-214_workstation.11437749249623 -c /etc/chef/client.rb -y
[Fri 24 Jul 2015 02:52:46 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 INFO Executing: su - -c "knife tag create s2iwd-214_workstation.11437749249623 workstation -u s2iwd-214_workstation.11437749249623 -c /etc/chef/client.rb -y"
[Fri 24 Jul 2015 02:52:46 PM UTC] maestro 139911279023936 pid=14426 DEBUG WARNING: shell=True used for subprocess command execution; might be insecure.
[Fri 24 Jul 2015 02:52:49 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 DEBUG Created tags workstation for node s2iwd-214_workstation.11437749249623.
[Fri 24 Jul 2015 02:52:49 PM UTC] ChefClient/start.py 139911279023936 pid=14426 INFO Register Chef Client Environment and Attribute...
[Fri 24 Jul 2015 02:52:49 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 INFO Executing: su - -c "chef-client -j "/etc/chef/attributes.json" --logfile /var/chef/cache/chef-client.out"
[Fri 24 Jul 2015 02:52:49 PM UTC] maestro 139911279023936 pid=14426 DEBUG WARNING: shell=True used for subprocess command execution; might be insecure.
[Fri 24 Jul 2015 02:53:01 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 INFO knife command is:knife node run_list set s2iwd-214_workstation.11437749249623 "recipe[harden], recipe[python]" -u s2iwd-214_workstation.11437749249623 -c /etc/chef/client.rb -y
[Fri 24 Jul 2015 02:53:01 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 INFO Executing: su - -c "knife node run_list set s2iwd-214_workstation.11437749249623 "recipe[harden], recipe[python]" -u s2iwd-214_workstation.11437749249623 -c /etc/chef/client.rb -y"
[Fri 24 Jul 2015 02:53:01 PM UTC] maestro 139911279023936 pid=14426 DEBUG WARNING: shell=True used for subprocess command execution; might be insecure.
[Fri 24 Jul 2015 02:53:01 PM UTC] ChefClient/chefutil.py 139911279023936 pid=14426 DEBUG su: user recipe[python] -u s2iwd-214_workstation.11437749249623 -c /etc/chef/client.rb -y does not exist
According to the debug message in Example 14-4 on page 392, the su command is evaluating part of the knife command (see the blue text and the white space in recipe[harden], recipe[python]) as the user parameter. In Example 14-5, a quick test is run on the CLI to confirm this behavior.
Example 14-5 Linux console test to confirm the behavior or the su command
[root@playbox recipes]# su - -c "echo "hello, world""
su: user world does not exist
[root@playbox recipes]# su - -c "echo "hello,world""
hello,world
[root@playbox recipes]# su - root -c "echo "hello, world""
hello,
From the output that is shown in Example 14-5, it is apparent that the code does not handle white space between recipes. If you see Figure 14-4 on page 388, you can see that there is white space between two of the recipes in the Default run list.
To correct this issue, either delete the deployment and redeploy it without white spaces between recipes, or modify the parameters directly in the JSON files from which the code is reading. The first option is easier and safer, but requires redeployment. The second option requires modification of the parameter.json file on the server side (PureApplication System Storehouse Browser) and client side (the VM downloaded the parameter.json file from the server during the initial deployment).
In this example, choose the second option to see how you can resume from an error by using the debugging component. To edit parameter.json on the server-side, click System → Storehouse Browser and expand user → deployments → [deployment id], as shown in Figure 14-9. The deployment ID can be found on the virtual system instance detail page (ID field).
Figure 14-9 Storehouse browser location where the server-side parameter,json is found
Alternatively, you can download parameter.json by using an HTTP GET request, as shown in Example 14-6.
Example 14-6 HTTP GET request to download parameter.json from the storehouse
GET /storehouse/user/deployments/d-ea72c920-8cfd-4dae-b416-305c0c035110/parameter.json
In this example, save two copies of the parameter.json file (one as parameter.json.bak). Make the edit that is shown in Example 14-7 to the parameter.json file to remove the white space between the two recipes in the Default run list.
Example 14-7 Stream edit to remove white space
-bash-4.2# sed -i 's/recipe[harden], recipe[python]/recipe[harden],recipe[python]/g ./parameter.json
After fixing parameter.json, use an HTTP PUT command to upload it back to the storehouse, as shown in Example 14-8.
Example 14-8 HTTP PUT command to upload the fixed parameter.json to the storehouse
PUT /storehouse/user/deployments/d-ea72c920-8cfd-4dae-b416-305c0c035110/parameter.json
Body: { <content of the json> }
Before you can resume the failing script, you must edit parameter.json and any references of the Default run list on the client side. Access the VM by using SSH. Run the commands in Example 14-9 to fix all references of the Default run list on the VM and resume deployment.
Example 14-9 Fix all references of the Default run list on the VM and resume deployment
-bash-4.2# grep -rl --include="*.json" "recipe[harden], recipe[python]" / | xargs sed -i 's/recipe[harden], recipe[python]/recipe[harden],recipe[python]/g'
-bash-4.2# /0config/nodepkgs/common/scripts/pdk-debug/resume.sh
the dump file: /opt/IBM/maestro/agent/usr/servers/workstation.11437746372282/pyworkarea/requests/3381167376413375974/dump.json has been removed, the execution should be resumed in seconds...
In Example 14-8, The grep command finds all *.json files with the recipe reference, and the sed command removes the white space between the recipes.
After the deployment resumes, it completes and goes into the Running state, as shown in Figure 14-10.
Figure 14-10 Deployment complete
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.