At the recent announcement we talked a lot about the Puppet integration. But how do you set it up? I want to show this in this blog entry.
However this example i’m using is even useful in practice. Due to the extremely low overhead of zones i’m frequently seeing really large numbers of zones on a single system. Changing /etc/hosts or changing an SMF service property on 3 systems is not that hard. Doing it on a system with 500 zones is … let say it diplomatic … a job you give to someone you want to punish.
Puppet can help in this case making of managing the configuration and to ease the distribution. You describe the changes you want to make in a file or set of file called manifest in the Puppet world and then roll them out to your servers, no matter if they are virtual or physical. A warning at first: Puppet is a really,really vast topic. This article is really basic and it doesn’t goes more than just even toe’s deep into the possibilities and capabilities of Puppet. It doesn’t try to explain Puppet … just how you get it up and running and do basic tests. There are many good books on Puppet. Please read one of them, and the concepts and the example will get much clearer immediately.
To show this, i have a relatively simple setup. A global zone and three non-global zones. In this example i will set up the global zone as a Puppet master and will configure three non-global zone with the Puppet agent, the component that gathers information from the Puppet master in order to do something on the server running the agent.
The Puppet master is called master, the agents are called agent1, agent2 and agent3. This tutorial assumes that you have already set up the zones and that they have working network connection.
Okay, at first it’s really important that you have a working resolution of the hostnames. The resolution is key to get Puppet working. This is what i did in the global zone and in the non-global zones.
The /etc/hosts of all zones (either global or non-global) is now like this.
Further i’ve set the hostname on all servers.
Installing and configuring Puppet
Okay, now install Puppet in all zones. This is quite easy as since 11.2 beta , puppet is in the standard repository . You just have to execute pkg install puppet
Ensure that the package has been installed on all zones you want to work with.
When you have installed the puppet package on all zones, login as root on the master At first bring up the master.
Afterwards you should see the puppet master service running on your system.
Now we have prepare the agent systems. At first log into agent1 system
The connection between the agent and the master is protected by SSL. At the first execution the agent creates a key and and certificate request.
You have to repeat the steps in the zones agent2 and on agent3 as well. At first on agent2
Now on agent3:
Now we have to sign this certificates on the master. Please go back to your shell of master
So we have three requests to sign. Let’s sign them.
Okay, let’s check if there is something left:
Now you can check on each agent system the connectivity. You will see quite a long output
Do the same in the other zones. At first agent2
Afterwards on agent1:
Do something slightly useful with the installation
Okay, now we are ready to try this our puppet installation. I won’t start with the basic help world feature, but something slightly more useful. However we have to some configuration first. I won’t explain much, as when i start to explain everything about it, this article will be veeeeery long. Basically the following stuff is creating a Puppet module called etchosts which delivers an /etc/hosts file (thus the name) to the system. The files is at /etc/puppet/modules/etchosts/files, which can be accessed by Puppet under the URL puppet:///modules/etchosts/hosts. The module code is located in a file init.pp (a convention in Puppet) inside the modules manifest directory at /etc/puppet/modules/etchosts/manifests directory.
Afterwards i’m creating nodes.pp file which essentially says “By default - when there is no node definition that matches - execute the function etchosts imported from the module etchosts and so the /etc/puppet/modules/etchosts/files/hosts is moved to </code>/etc/hosts</code> if necessary (something has changed).” This file is invoked by the site.pp file.
At first we need some additional structure in some filesystems
Now we will give some life to the module /etc/hosts
Afterwards we creating a file just including the nodes definition file:
At last we define the behaviour for the “default” node:
In order to have something to play i just add a line to the /etc/puppet/modules/etchosts/files/hosts file.
Okay, now log into one of the zones with an agent and check the current /etc/host
At the moment there there isn’t the additional line in the file. You can now wait for 1800 seconds at maximum (because the agent checks every 1800 seconds if there is something to do by default) or you can force the check. Let’s force it.
Now let’s check the file again … et voila … you find the line you have added into the /etc/puppet/modules/etchosts/files/hosts in the /etc/hosts of you file.
When go for a coffee and wait the mentioned 1800 seconds you will find the change in all your zones.
One of the points of the puppet integration into Solaris 11.2 was the development of a lot of solaris specific modules for managing boot environments or configuring VNICs. This example doesn’t touch those topics at all. But now you have a foundation for follow on articles going into details about Solaris specific modules.