How do you keep hostnames out of the manifest?

[Kenton Brede]

We're a small organization and all my servers are pets.  I've made an effort to keep site specific data out of the manifest, but I haven't been able to completely.

Hiera has been a big help in getting us most of the way.

Is it even possible to have a clean manifest, when a person has pets to mange? 

I'm still ending up with hostnames as variables in erb files, assigning classes like "files::servername" and something like the following: 

 

  # manage index.html
  file { '/var/www/html/index.html':
    owner           => apache,
    group           => apache,
    mode            => '0640',
    source          => $::hostname ? {
      default       => undef,
      $::hostname   => "puppet:///modules/httpd/${::hostname}.index.html",
    }
  }

Any advice is appreciated.
Thanks,

--

Kent Brede

[Ryan Anderson]

You could make a custom fact that indicates each site based on the IP subnet that your pets reside on. Something as simple as an external fact like:

#!/bin/sh

MYIP=`ifconfig | grep 'inet ' | grep -v 127.0.0.1 | awk '{ print $2 }' | sed 's/addr://'`

case $MYIP in

10.1.3.*) my_site=minneapolis

  ;;

10.2.4.*) my_site=washdc

  ;;

esac

Then, your code could use site-specific facts, instead of host-specific, eg

source => "puppet:///modules/httpd/${::mysite_.index.html",

[jcbollinger]

On Monday, November 3, 2014 9:53:29 AM UTC-6, kbrede wrote:

We're a small organization and all my servers are pets.  I've made an effort to keep site specific data out of the manifest, but I haven't been able to completely.

Hiera has been a big help in getting us most of the way.

Is it even possible to have a clean manifest, when a person has pets to mange?

Maybe.  The highest-priority level of your hiera hierarchy should be a node-specific level keyed on %{hostname} or %{clientcert}.  Data that vary or may need special values on a per-node basis can be handled there.  Choose data keys that are generic.

 

I'm still ending up with hostnames as variables in erb files, assigning classes like "files::servername" and something like the following: 

 

Using $hostname in ERB files is a completely separate question.  There are perfectly good reasons for that, even with servers that are ordinary silicostock rather than pets.

Per-node classes are not particularly worse or different than per-node node blocks.  Some people even recommend using node classes instead of node blocks altogether.  If you have no suitable generic identifier for or description of your servers then perhaps you should work toward that in you infrastructure plan, but for the mean time it is perfectly sensible for your manifests to use the natural identifiers of your hardware.

 

  # manage index.html
  file { '/var/www/html/index.html':
    owner           => apache,
    group           => apache,
    mode            => '0640',
    source          => $::hostname ? {
      default       => undef,
      $::hostname   => "puppet:///modules/httpd/${::hostname}.index.html",
    }
  }

I don't understand the point of that particular selector, though.  Surely you can always rely on $::hostname == $::hostname, so you might as well just write

source => "puppet:///modules/httpd/${::hostname}.index.html"

If you don't want to assume separate per-host index.html files, then you could read the index file name from hiera.  Perhaps the key would be "httpd::main_index_html".  If you read that into a class parameter or ordinary class variable $main_index_html then the above might become

source => "puppet:///modules/httpd/${main_index_html}"

John