last week I asked a question on how to sensibly structure
a puppet setup:
I received a quite sensible request, even though it's not
what I wanted to hear. The reason it's not, might be because
I haven't been quite able to get my point across:
Let's go with the example of hosting and develop that:
We have (among other things) a hosting service. Each customer
gets their own instance of httpd running on a seperate port
and a seperate user. They can have any number of vhosts, but
most only have one. They can have any kind of setup, but most
choose PHP + MySQL, the rest has static pages. Each of these
vhosts has a separate scp-user. (The db/user and scp-user for
each vhost have the same name). The web is terminated by a
caching proxy (Apache Traffic Server).
If I were to express this as data of its own, not data that
will fill a puppet apache, or puppet trafficserver or mysql
module, I'd express it like this in yaml:
- servername: www
- servername: beta
- servername: www
- servername: mail
With the implicit defaults in mind for this service, we
specify only when something deviates from them. With 90% of
vhosts being PHP, we specify that the `www` vhost is `static`
This `static` may in turn overwrite other defaults such as
`db_provider => mysql` with `db_provider => none`.
What I'm trying to say here is: Rather than building this data
as each puppet module would expect it, I build it such that
it makes sense to us admins and developers.
* * *
This whole aproach has a number of implications. First of
which is that we don't treat hiera as a nice-to-have tack on,
but that we intristically rely on it.
Second, the data in hiera does in no way reflect what a puppet
module that finally writes the configuration would expect.
This in turn means that we need a puppet module which can make
sense of the data, enriching it and filling the gaps where
If we continue from the hosting example, we can roughly split
it in `hosting::lb` (for trafficserver), `hosting::web` (for
handling the httpd config, as well as the creation of users as
necessary), and `hosting::db` module (which, as we've seen can be
optional in some cases where the site is static).
There are two competing solutions to my problem:
#1: have the "parsing" code in each of those classes
#2: have the "parsing" code in an über class. This would be the
web class, and it would dispatch the data to the other two
The first solution has the obvious problem of code-duplication.
The second doesn't scale with large numbers when customer grow
beyond a couple of thousand, as export/collect will be very slow.
However, this is not a problem we're facing right now… ;)
I'm leaning towards the über-class, but would love to hear some
feedback on whether I'm making any sense at all and how you
would aproach such problems!
Thank you very much in advance,
Tel: +43 (0) 664 886 22 883
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE