6

What are the downside of cloning vs scripted installation (using Kick-start / Puppet)?

I read a lot of pro-scripted install opinion, where cloning is considered as unreliable method due to ever changing hardware.

In my case the hardware is pretty unified as we use same vendor, and even if it changes, the effort to adapt the cloned image settings (I use SystemImager), wasn't very difficult.

It also much faster, and takes about 5 minutes vs 20 - 30 of scripted installation (without local mirror of course), and is able to capture minor bits which quite difficult to script (MySQL DB securing for example).

But still the cloning gets a lot of flack from what I read, so can anyone share his opinion and experience on this, and if it's worth for me to change our deployment infrastructure to script installation?

Thanks in advance!

SyRenity
  • 3,159
  • 11
  • 55
  • 79

2 Answers2

14

Cloning and kickstart works... once. They are not a solution for perpetually maintaining your systems. Unless you redeploy an entire server every time you need to upgrade a script or apply a patch.

For example, the other day I was having problem with SSH timing out. Adding some options to sshd_config fixed the problem. I edited my standard sshd_config file in my puppet repo and that took care of pushing out the updated file and restarting SSH on every server. Additionally, any new server I setup will get this updated config.

If I only used whole system cloning, I could edit the sshd_config on the master image, but then would have no easy way of updating the existing configuration files on all my servers.

Another big benefit of something like puppet is greater modularity. You may have an "apache" image or a "mysql" image, but what do you do if you need a server with apache AND mysql? This only gets worse the greater combination of services you have to deploy.

with my puppet config this is a simple matter of

include apache
include mysql::server
include ...

Lastly, another benefit puppet has is truly documenting how your servers are setup. Want to know what packages are installed or what files are modified? Just read the puppet configuration. If you use master images, you are constantly trying to keep the documentation in sync with the image.

Justin
  • 3,776
  • 15
  • 20
  • Hi. Thanks for this insight. Actually, I wanted to try puppet for some time - perhaps you know of a good tutorial for CentOS? Thanks again! – SyRenity Jan 02 '10 at 23:18
  • 1
    No.. I run it under debian.. if you google 'centos puppet' the first few hits seem decent enough, and match up pretty well with what I did to get it working under debian. Most of my configs are based on http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration – Justin Jan 02 '10 at 23:36
  • +1 for noting that a clone is a once-off configuration, and can't be easily updated thereafter. – womble Jan 03 '10 at 02:58
  • Just a follow-up question - any sense to set a debian VM machine just for puppet master? Or I should be fine with installing Puppet on CentOS? – SyRenity Jan 03 '10 at 09:21
  • If your other servers are just VM's you could make a clone for each one and delete the old ones easily. Then you have an incentive to update everything to the latest security patches. – Bernard Igiri Feb 04 '15 at 13:59
1

'Global unique' identifiers -- used for all kinds of things, by all kinds of platforms (MSWindows COM, *nix, replicated database) often incorporate nic, mac addresses as one part of ensuring 'unique' across a network. Cloning -- that might ignore that, duplicating -- can result in distributed, networked systems suddenly behaving in strange, non-deterministic ways (aka: race conditions -- which process gets the message first.) Beware!