On Thursday, 25 August 2016 13:31:17 UTC+1, Marc Haber wrote:
>
> On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote:
> > The template will create udev rules from two sources. The first is
> > @interfaces, which is the giant multi-level hash of network interfaces
> that
> > our old designs use. A VM might look like this in Hiera:
> >
> > networking::interfaces:
> > eth0:
> > ipaddr: 1.1.1.1
> > hwaddr: 52:54:00:11:22:33
> >
> > The second source of udev rules is also a Hash and also from Hiera, but
> > rather than it be embedded in the giant hash of networking information,
> it
> > is there to compliment the newer role/profile approach where we don't
> > specify MAC addresses. This is purely a cosmetic thing for VMs to make
> our
> > interface names look sensible. Here is a sanitised Hiera file for a VM
> with
> > the fictitious "database" profile:
> >
> > profile::database::subnet_INTERNAL_slaves:
> > - 'eth100'
> > profile::database::subnet_CLIENT_slaves:
> > - 'eth214'
> > networking::extra_udev_static_interface_names:
> > eth100: '52:54:00:11:22:33'
> > eth214: '52:54:00:44:55:66'
>
> So the "database" machine wouldn't have an entry in
> networking::interfaces at all, or could one define, for example, the
> management interface in networking::interfaces and the database
> interfaces in the machine-specific hiera tree?
>
That's technically possible with our module, yes, although I personally
don't want to mix the styles. It has to do with our Hiera hierarchy being
mostly based on physical location and entire "instances" of our
application, where what we're talking about here is functionality based. If
we had a business rule where "every server in this data centre has
management interface eth76" then yeah, that would match our Hiera hierarchy
perfectly. We don't have those hard and fast rules though, we've got
several management networks, with different levels of security applied,
appropriate for different layers of our application. So our management
networks are a function of defence in depth security design alongside our
software, rather than a simple physical location or group of VMs. Since
they're a function of design or "business logic", rather than location, our
management networks are defined in profiles (on new systems) because it's
only at the role/profile level do you know that a "database" server should
have a certain type of management network.
In my current profiles though I started with the management interfaces
inside the same software profiles. Turns out this was not the best idea as
they are not directly related, and what our roles should really look like
is this:
*******************
class role::database {
include profile::mandatory #Everything mandatory
on EL6
include profile::authentication #Authentication is not
mandatory
include profile::database #The profile that does
most of the work for our software
class { 'profile::management': #management network
definition and dependent services (sshd, etc)
type => 'database' #but for a specific
type of machine
}
}
*******************
So management would be separate. This would allow me to do smarter ordering
of Puppet classes for management services like SSH (and remove a little bit
more Hiera glue).
Greetings
> Marc
>
> --
> -----------------------------------------------------------------------------
>
> Marc Haber | "I don't trust Computers. They | Mailadresse im
> Header
> Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224
> 1600402
> Nordisch by Nature | How to make an American Quilt | Fax: *49 6224
> 1600421
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/651d7a2d-8eac-49d6-aaac-8e03937dc7c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
