Chef – Search

Training Architect
In this lab we will demonstrate an understanding of Chef search in a recipe. First, we are going to install the ChefDK tools on a server, make sure that Docker is working, and ensure that Git is installed and has some basic configuration. We will then create a cookbook and recipe that utilizes the search function to look for users in a provided data bag. There will be a group created for the users that our recipe finds. At the end of this hands-on lab we will have installed ChefDK tools, configured it, and will have a working cookbook. We'll perform any testing by using docker
and kitchen
commands.
Chef - Search
Introduction
In this lab we will demonstrate an understanding of Chef search in a recipe.
First, we are going to install the ChefDK tools on a server, make sure that Docker is working, and ensure that Git is installed and has some basic configuration.
We will then create a cookbook and recipe that utilizes the search function to look for users in a provided data bag. There will be a group created for the users that our recipe finds.
At the end of this hands-on lab we will have installed ChefDK tools, configured it, and will have a working cookbook. We'll perform any testing by using docker
and kitchen
commands.
Instructions
We have several tasks that need to be completed:
- Set up the environment for use with the rest of the tasks by installing Chef, Docker, Git and the Chef gem for Docker:
- Install version 2.4.17 of the ChefDK tools.
- Install Docker CE and all that it requires, start it up, then make it start at boot:
- Modify our group membership so we don't need to run
sudo
all the time.
- Modify our group membership so we don't need to run
- Install Git, and configure a name, email, and default editor.
- Install the gem allowing Kitchen and Docker to work together.
- Set SELinux to allow us to work through the rest of the steps.
- Create a cookbook called
la_search
. - Examine our default cookbook's contents.
- Create a new cookbook, called
la_search
. - Edit our
kitchen.yml
:- Change our driver name so that we're using Docker
- Make it run in a privileged manner
- Set it up so that we don't have to use
sudo
- Add a provisioner name and version
- Add the data bag location
- Remove any platforms so that it's just set to work on CentOS 7
- Edit our recipe so that it will create an administrator when there's not one present
- Build the kitchen
- Test the kitchen by logging in
- Clean up our Kitchen instances
Logging In
Using the credentials provided in the hands-on lab page, log into the server as cloud_user
and we can get going.
Examine the Existing chef
Directory Contents
Get into the chef
folder (with a cd chef/
) and let's take a look at what's in there. An ls
will show a data_bags
directory, and in there (we'd see it with an ls data_bags
) is an admin
folder. In the admin
folder are three json files: joe.json
, mike.json
, and tom.json
.
If we run cat
on those, we'll see that the only big difference is that mike is an administrator, while the other two are developers (judging by the groups they are each members of)
What we need to do is make a recipe that creates an administrator type user, if one doesn't exist.
Create a Cookbook Called la_search
Then Move into That Folder
Create a new cookbook with this command:
chef generate cookbook la_search
Now let's get into it so we can start working on it:
cd la_search
Edit Our Kitchen File
We need to change some things in kitchen.yml
, so let's edit it:
vim .kitchen.yml
In the top section, we're going to replace vagrant
with docker
, and add some things. When we're done, that top section should look like this:
---
driver:
name: docker
privileged: true
use_sudo: false
Remember that this is YAML, so we need to make sure we have the right number of spaces in spots. Those lines under driver
are all indented two spaces.
Down in the provisioner
section, we need to add a name and version. We've also got to refer to the data bag location. It should look like this when we're done:
provisioner:
name: chef_zero
# You may wish to disable always updating cookbooks in CI or other testing environments.
# For example:
# always_update_cookbooks: <%= !ENV['CI'] %>
always_update_cookbooks: true
product_name: "chef"
product_version: "13.8.5"
data_bags_path: ../data_bags
We're on a CentOS machine, so we need to get rid of ubuntu
from the file. Just delete (or comment out) the line in the platforms
section that reads:
- name: ubuntu-16.04
That's it for kitchen.yml
edits. Write and quit, so that we can get back to the command prompt.
Edit Our Recipe
We need to get the recipe in a state that will do that administrator user installation, if there's not already such a user. We'll edit the file:
vim recipes/default.rb
Then we need to add these contents after the comment lines that are already in there:
admins = []
search(:admins, "gid:administrators").each do |admin|
group admin['gid']
login = admin["id"]
admins << login
home = "/home/#{login}"
user(login) do
uid admin['uid']
gid admin['gid']
shell admin['shell']
comment admin['comment']
home home
manage_home true
end
end
Once we're finished, we can write and quit the file.
Build the Kitchen with Our Recipe
To see if this all works, run kitchen converge
. If all goes well, we can keep going. Otherwise, we'll have to troubleshoot any typos we might have made.
Test by Logging Into the Kitchen
Let's log into the kitchen with kitchen login
, and see how things look. Run these:
cat /etc/group
cat /etc/passwd
We should see an administrators
group in /etc/group
, and we should see mike
was added in as a user. That user, if you remember was an administrator in the mike.json
file we looked at earlier.
Conclusion
We did it! Our new cookbook created an administrator type user because there wasn't one there, which is exactly what we wanted to happen. We can type exit
to get out of the kitchen, then run a kitchen destroy
to clean up after ourselves, and we're done! Congratulations!