Sometimes we spend way too long trying to define things in our head when we can get existing configurations from the system. It’s vital to have a full service definition or any promotion of the service through environments will turn up missing components and make your life hell. If you’re building a new service that looks similar to an old one, or evolves the old service, steal the old service’s definition and then modify it.

vSphere

There are a number of ways to gather existing service definitions. If you’re building a new host and you have Enterprise Plus licenses, use Host Profiles. Export an existing host’s config to a host profile, uncheck the irrelevant portions, change what’s relevant but different, and apply to the new host. It might take a few tweaks, but you’ll get it right soon. Then export the new host’s config to a host profile and you’re good to go.

If you don’t have Enterprise Plus, take a look at PowerCLI. It will take more legwork, but there are a ton of cmdlets available to capture networking, storage, and other service definitions from existing hosts which you can then apply elsewhere.

Guest OS

There are a ton of tools here that vary by OS. But, you probably know that I’m a fan of puppet, so we’ll use that. puppet resource <type> [<name>] spits out some Puppet DSL which you can then modify and apply to another device directly or integrate with your modules. For example, if you need to have some local users, take a look at an existing VM and grab your local user:

[rnelson0@puppet ~]$ sudo puppet resource mount
mount { '/':
  ensure  => 'mounted',
  device  => '/dev/mapper/VolGroup-lv_root',
  dump    => '1',
  fstype  => 'ext4',
  options => 'defaults',
  pass    => '1',
  target  => '/etc/fstab',
}
...

Edit as necessary and add this to a module and class, like profile::base to easily replicate this elsewhere. This works for all built-in puppet types across OS’s, which gives you portability as well. I’ve found mount for NFS and cron for scheduling tend to be some of the least-documented but most-important components of service definitions. Be aware that cron type only looks at per-user crontabs, NOT at /etc/crontab, so don’t forget to check that manually.

For anything puppet doesn’t handle, or if you can’t install puppet, use the native OS tools to grab the service definition. A popular definition to miss is static routes. They’re evil, but ever present, so don’t forget to grab them before deleting the old server or you’re in for some fun.

Networking and Security devices

There are far too many networking and security device types to list, but nearly all of them provide CLI output. Get that CLI output, grab the relevant sections, tweak, and apply to the new service. On firewalls you can often decouple the firewall’s network elements from the policy, which lets you migrate the policy to a replacement firewall, or convert it for another vendor’s policy.

Any other tips? Drop a line in the comments. Thanks!