Start using Puppet with the help of Golden Images

This post is part of a blog series which tries to simplify the adoption of configuration management frameworks.

Many admins are already excited about configuration management frameworks like Puppet, that’s good! With these frameworks it is possible to implement all sorts of automation for many operating systems. But does this mean you should automate every task from the beginning to the end with a single tool?
If you can do it, then of course! It has some advantages, for example you need fewer different automation skills in the company. But there is always the big risk that automating a task takes just too long.

Many times provisioning of new servers is an early target for using configuration management frameworks. But implementing the whole process with Puppet can take a long time, because there are just many tasks like OS installation, security updates, OS configuration, etc.

So how to automate server provisioning with Puppet on the fast way?

In my opinion: By not using Puppet so much in the first phase. The very old idea of “Golden Images” in combination with Puppet makes it a lot easier to build an automated server provisioning process shortly. This combination also allows you to improve the automation degree in later phases with Puppet, easily.

Golden Images

The idea of Golden Images is that you build a “Master” server (installing OS, updates, etc) and make a “Gold” copy of it. Now you can deploy this copy (image) on many other servers. Of course a part of the configuration, like the network address, needs to be adopted.

This process is easy because you don’t need real automation tools, you can configure the Master server manually as slow as you like it. Deploying the Gold Image is usually very fast, because many times it’s just a single archive file which is extracted to the target server. Configuration mangement files and scripts usually walk sequentially over each file which needs to be modified, which is a lot slower.

Of course there are disadvantages. If you need to change a tiny bit in the Gold Image, you need to rebuild the image. And some operating systems and applications are easier to use with this approach than others. For example, applications which write the server name in 100 hidden files, are a pain for this method. Additionally you should keep the amount of the images low, because OS images easily need some GB on the disk.

Depending on the platform different supporting technologies are available:

Golden Images + Puppet = Quick Win

Now just use Puppet to fight the disadvantages of Golden Images. If you use Golden Images for the static parts and Puppet for the fast changing configuration, you get the server provisioning on a quick way automated.

For example you can put the following into the Golden Image:

  • Operating system + Updates
  • Standard software, dependency handling is easy on the master server
  • Static configuration, e.g. kernel paramters, filesystem layout, etc

The Puppet manifests can handle:

  • Dynamic configuration, e.g. DNS server configuration which varies per data center
  • User based configuration, e.g. user accounts

The nice feature of this method is, that you can move every configuration which is wrong in the static Golden Image into a Puppet manifest. By and by the Golden Image will become more and more generic and the Puppet manifests will grow. And you will get the return on your invested time early.

Because of the multi-platform support of Puppet it’s natural that the static configurations of the different OS Golden Images move into a combined Puppet manifest.

Did you also automate the server provisioning? Would you like to share your experience or your pain? Just leave a comment or ping me.

Share Comments