(For more resources related to this topic, see here.)
In order to provide the instructions for this article to work without modification, you will need administrative access to a system running Ubuntu 12.04 LTS with SSH service running and accessible via a network. Additionally, the system will need to be able to access the Chef Server and the public Internet for package updates and gem installation.
Bootstrapping servers
Bootstrapping is the process of setting up something without external intervention. Chef uses bootstrap scripts that are executed (over SSH) on a remote server to perform any initial configuration that you desire. These scripts are written using ERB (a Ruby template language) and serve as a launching pad to setting up a new server. Typically these scripts would be run on a brand new server, but can be applied to any server that you can SSH into.
Additionally, bootstrap files are Linux-distribution and Ruby-distribution dependent because they have commands that are specific to particular distributions. For example, an Ubuntu Linux server with Ruby 1.9 installed from source, or a RedHat Enterprise Linux server with Ruby 1.8.7 installed from EPEL.
In addition to any initial configuration, bootstrapping registers the node with the Chef Server so that it becomes a member of the infrastructure and can have configurations and roles applied to it.
How the process works
The bootstrapping begins with developing a bootstrap script that targets the distribution and version of that distribution that is running on the server you are looking to provision. Once the script is written, the knife tool is used to remotely log into the new system and run the script to perform the initial configuration.
Knife does some interpolation locally of the bootstrap script before it is run on the server. This means that you can leverage Chef’s data and configuration during the bootstrap process. Common uses here would include setting up initial firewall rules, routes, users, or other mandatory initial provisioning.
Chef provides some pre-written bootstrap scripts for the following platforms, making it easy to get started:
-
centos5-gems
-
fedora13-gems
-
ubuntu10.04-gems
-
ubuntu10.04-apt
-
ubuntu12.04-gems
Examining the bootstrap script
If you are looking for an example of what a bootstrap file contains, you can find the ones provided with chef in lib/chef/knife/bootstrap inside the directory containing your Chef gem (which, if you used the Opscode packages on a Debian system, would reside in /usr/lib/ruby/vendor_ruby/chef).
I strongly suggest reading over the bootstrap script you will be using so that you have a good idea of what you’re running on your system as root before doing so.
Performing the bootstrap
Bootstrapping a server is quite simple and involves a single invocation of knife (once your bootstrap script is complete). Knife looks for bootstrap files in a directory called bootstrap in your local Chef directory. Good names for bootstrap files would include the distribution name as well as the version and type of Ruby installation you are performing (that is, centos5-ruby19, ubuntu11.10-rvm-ruby19, and so on).
In our case, we will be using the pre-supplied bootstrap script that configures Ubuntu 12.04 with gems to bootstrap our new system. For example:
export SERVER_IP="11.22.33.44" export USER="ubuntu_user" knife bootstrap -x $USER --sudo $SERVER_IP -d ubuntu12.04-gems
This is where the environment variable, $SERVER_IP, is set to the IP address of your newly setup server and $USER is set to the user you created on your Ubuntu server that can execute sudo.
When executed, this command tells knife to execute the bootstrap command, which is responsible for loading the bootstrap script specified by the -d flag (-d is for distribution) over SSH logging into the remote server specified by the environment variable, $SERVER_IP using the remote user specified by the -x flag. In this case, it would run the following steps:
-
SSH as ubuntu_user to 11.22.33.44
-
Execute the contents of ubuntu12.04-gems.erb on the remote server using sudo
Once that is complete, the server will be bootstrapped according to the steps in the bootstrap file, which, if you were to look at the provided bootstrap script, you would see the following:
-
Update the APT repository
-
Install Ruby 1.8 and some development dependencies from APT
-
Install the latest version of RubyGems
-
Update the local Ruby gems
-
Use gem to install ohai, the system-reporting agent
-
Use gem to install Chef
-
Copy the validation certificate file to the server
-
Copy the encrypted data bag secret (if applicable)
-
Generate any ohai hints needed
-
Copy the Chef Client configuration to the server
-
Copy the first-run JSON data to the server
-
Execute the Chef Client in order to:
-
Register the node
-
Run any initially configured run list data
-
Verifying the registration
Once this has been completed, we can verify that the node has been registered with the Chef Server in either of two ways: using knife, or using the web console.
Using knife
To verify the node was registered with the Chef Server, we will be using the client command provided by knife. This can be accomplished with the list subtask like this:
user@server:$> knife client list host1 host2 new-host-name
Where new-host-name would be the hostname of the node you just bootstrapped (Chef Client will automatically determine the hostname when it registers itself using the bootstrapped machine’s FQDN as you set it up).
Via the web console
To verify that the node was registered using the web console, we must first log into our Chef Server using the administrative credentials that were configured during setup. Once logged in, there will be a set of tabs along the top where you can switch between the different data collections you can manage. The URL of the web console will vary between installations, but if you followed the instructions earlier, it would be accessible at http://chefserver.yourdomain.com:4040.
As you can see, there are tabs for managing environments, roles, nodes, cookbooks, data bags, clients, and users. Additionally, there is a tab for performing searches, which is useful for validating search queries to be used in recipes.
Once you are on the Nodes tab, you will see a list of nodes that Chef knows about, which will look like the following screenshot:
In our case, chef-server is the Chef Server itself that we registered during the installation phase, and monitoring-production is the hostname of the newly registered server.
Summary
In this Article, we have discussed the process of getting started with Chef.
Resources for Article :
Further resources on this subject:
- OpenAM: Backup, Recovery, and Logging [Article]
- Starting Up Tomcat 6: Part 1 [Article]
- SQL Server 2008 R2: Multiserver Management Using Utility Explorer [Article]
