The first thing we want to do when working with Chef is to get the Chef client actually bootstrapped on the targeted remote server. For the Chef client to be able to apply Chef code, it first needs to be configured and registered on the Chef server. Thankfully, this can be very easily done.
To work through this recipe, you will need the following:
- A remote server, with a user with SSH access
- A working Chef DK installation on the workstation
Let's say we already have a server running somewhere available with a user. The minimal command line we can build is as follows:
- The IP or FQDN of the host we want to configure (
1.2.3.4) - The name under which to register the node on the Chef server (
my_node_hostname) - The username to use to connect to the server (
sudoerif not root).
Navigate to the Chef repository on your workstation:
$ cd chef-repo
Now let's remotely install the Chef client on the remote host from your workstation, using an example vagrant user:
$ knife bootstrap 1.2.3.4 -N my_node_hostname -x vagrant --sudo
This will first download the latest available Chef version and install it. Then it will execute an initial chef-client run to register the node on the Chef server under the specified name. Here it will stop.
If we want to run a cookbook right after bootstrap (and we probably want to), just use the -r option to add cookbooks to the run list, so they are executed right away. Let's use the starter cookbook we uploaded earlier in this chapter, but feel free to use any other cookbook you may have already synchronized on the Chef server.
$ knife bootstrap 1.2.3.4 -N my_node_hostname -x vagrant --sudo -r "starter" [...] 192.168.146.129 resolving cookbooks for run list: ["starter"] [...] 192.168.146.129 Recipe: starter::default 192.168.146.129 * log[Welcome to Chef, Sam Doe!] action write
Using Puppet, we need to install the Puppet agent, once our node is created. Let's add a new node into the Vagrantfile we previously used for the Puppet server:
vm_memory = 2048
vm_cpus = 2
unless Vagrant.has_plugin?("vagrant-hostmanager")
raise 'vagrant-hostmanager is not installed!'
end
Vagrant.configure("2") do |config|
config.hostmanager.enabled = true
config.hostmanager.manage_guest = true
config.hostmanager.manage_host = true
config.vm.define "puppet.pomes.pro" do |puppet|
puppet.vm.box="bento/ubuntu-16.04"
puppet.vm.hostname="puppet.pomes.pro"
puppet.vm.provider :virtualbox do |vb|
vb.memory = vm_memory
vb.cpus = vm_cpus
end
puppet.vm.network :private_network, ip: "192.168.50.10"
puppet.hostmanager.aliases = %w(puppet)
puppet.vm.provision :shell, :path => "puppet_master.sh"
puppet.vm.synced_folder "puppetcode", "/etc/puppetlabs/code/environments/production"
end
config.vm.define "web.pomes.pro" do |web|
web.vm.box="bento/ubuntu-16.04"
web.vm.hostname="web.pomes.pro"
web.vm.network :private_network, ip: "192.168.50.11"
web.vm.provision :shell, :path => "puppet_node.sh"
end
endAs you can see, there is now another shell script puppet_node.sh used for the provisioning of this new node:
#!/usr/bin/env bash
# Exit immediately if a command exits with a non-zero status
set -e
# puppetlabs URL
DEBREPO="https://apt.puppetlabs.com/puppetlabs-release-pc1-xenial.deb"
# Install the PuppetLabs repo
echo "Configuring PuppetLabs repo..."
debrepo=$(mktemp)
wget --output-document=${debrepo} ${DEBREPO}
dpkg -i ${debrepo}
apt-get update
# Install Puppet Agent from puppetlabs
# This will remove puppet-common package provided by the vagrant box
echo "Installing Agent..."
apt-get install -y puppet-agent
# Ensure puppet agent is stopped for our tests
/opt/puppetlabs/bin/puppet resource service puppet ensure=stopped enable=false
echo "Puppet agent installed!"We now also have an Ubuntu Puppet node with FQDN web.pomes.pro with IP 192.168.50.11. By default, the Puppet agent is looking for a server named puppet—that's why this name has been defined as an alias to the puppet server.