multiple VMs from a single node.pp file

[randal cobb]

Hello, all...

I have a scenario where all of our developers (spread geographically around the world) use a VMWare or VirtualBox VM on their local desktop to develop portions of a single product.  I've seemed to inherit this nightmare of a process and believe I can make it much simpler, quicker, and cleaner using Puppet.  Currently, they have to download an 80Gb VM image from a single server in the US; so, because of the massive size of the VM, most developers never upgrade their VMs to the latest image.   I know that Puppet can fix this for me, but I have a few questions I'm hoping y'all can help answer (I've used puppet for a few months to manage some infrastructure servers, so concepts aren't alien to me).  Here are my questions:

Supposed I have 200 different machines (VMs) sitting on each developer's desktop (rather in their VMware hypervisor)... 

1) can they all have the same certname, so I only have to maintain a single node.pp manifest?

2) If so, how are SSL certs maintained, given there would be 200 different VMs trying to use the same set of certs.  Or, does that even matter from a node perspective?

3) If not, do I REALLY have to maintain 200 different manifests; all identical to each other?

I've been able to put together a single node.pp file that sets up everything for them, so they only download a 2.8Gb bare VM image and puppet does the rest.  But, when firing up subsequent VMs, of course the client gets all confused because the generated certs don't match up.

Any suggestions for a better solution, or workaround to this one?  (I've thought about using NAT and a fixed MAC address, but with so many developers out there, I'm sure some will re-create MAC addresses at some point during their initial setup, or change their networking type for the VM and start flooding the network with duplicated mac errors).  

I'm sure I'm not the first person who's wanted to do something like this, so I turn to the seasoned puppet veterans for guidance!   I HAVE googled for solutions, but I may just not be using the right terminology to search with; because I keep coming up blank on how best to tackle this.

Thanks in advance!

Randy

[Peter Bukowinski]

On Jul 15, 2014, at 3:09 PM, randal cobb <rco...@gmail.com> wrote:

> Hello, all...
>
> I have a scenario where all of our developers (spread geographically around the world) use a VMWare or VirtualBox VM on their local desktop to develop portions of a single product. I've seemed to inherit this nightmare of a process and believe I can make it much simpler, quicker, and cleaner using Puppet. Currently, they have to download an 80Gb VM image from a single server in the US; so, because of the massive size of the VM, most developers never upgrade their VMs to the latest image. I know that Puppet can fix this for me, but I have a few questions I'm hoping y'all can help answer (I've used puppet for a few months to manage some infrastructure servers, so concepts aren't alien to me). Here are my questions:
>
> Supposed I have 200 different machines (VMs) sitting on each developer's desktop (rather in their VMware hypervisor)...
> 1) can they all have the same certname, so I only have to maintain a single node.pp manifest?

No. Each vm/puppet agent needs a unique cert.

> 2) If so, how are SSL certs maintained, given there would be 200 different VMs trying to use the same set of certs. Or, does that even matter from a node perspective?
> 3) If not, do I REALLY have to maintain 200 different manifests; all identical to each other?

You don't need to maintain 200 different manifests. If you organize the resources you wish to manage into one or more classes (or modules), you can solve your problem without having to specify any puppet clients.

> I've been able to put together a single node.pp file that sets up everything for them, so they only download a 2.8Gb bare VM image and puppet does the rest. But, when firing up subsequent VMs, of course the client gets all confused because the generated certs don't match up.
>
> Any suggestions for a better solution, or workaround to this one? (I've thought about using NAT and a fixed MAC address, but with so many developers out there, I'm sure some will re-create MAC addresses at some point during their initial setup, or change their networking type for the VM and start flooding the network with duplicated mac errors).

A simple way to take what you have now and make it work for all 200 instances of the VM is to wrap all the resources you have now in your nodes.pp file into a class. Then include that class in the default node definition. Your new nodes.pp file should resemble this:

class vm_config {
# All your existing puppet code
# should go inside here. You may wish to subdivide
# the resources logically into separate classes.
# If you do this, also include those classes
# below.
}

node default {
include vms
}

The default node definition will apply to any node that hasn't matched any other node definition. Since this is the only one -- remove any other node definitions -- it will apply to all puppet nodes.

> I'm sure I'm not the first person who's wanted to do something like this, so I turn to the seasoned puppet veterans for guidance! I HAVE googled for solutions, but I may just not be using the right terminology to search with; because I keep coming up blank on how best to tackle this.

My suggestion above isn't the best way to go about it, either. If you ever want to manage anything besides these VMs, you'll need to modify the nodes.pp file. However, at that time, you may have a better grasp of puppet.

> Thanks in advance!
> Randy

--
Peter Bukowinski

[Brian Mathis]

Off the top of my head I would think that you could either use the 'default' node, which would apply to all clients, or use a regular expression to match the node names.  With the regex you'll need to ensure that each VM follows a naming convention and you probably also want to make sure you don't have multiple machines with identical names.  You can read more about that here:
    http://docs.puppetlabs.com/puppet/latest/reference/lang_node_definitions.html#the-default-node

You really don't need to do anything special with the certname -- they can all be different.  You'll have to sign the cert for each new node as a developer brings it online, unless you use the autosign option (which has potential security implications).  After all, Puppet is meant to manage many nodes with the same configuration.

❧ Brian Mathis

@orev

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/be08e15f-44da-43f4-9f6a-8d10630ebefa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Tuesday, July 15, 2014 2:09:57 PM UTC-5, randal cobb wrote:

Hello, all...

I have a scenario where all of our developers (spread geographically around the world) use a VMWare or VirtualBox VM on their local desktop to develop portions of a single product.  I've seemed to inherit this nightmare of a process and believe I can make it much simpler, quicker, and cleaner using Puppet.  Currently, they have to download an 80Gb VM image from a single server in the US; so, because of the massive size of the VM, most developers never upgrade their VMs to the latest image.   I know that Puppet can fix this for me, but I have a few questions I'm hoping y'all can help answer (I've used puppet for a few months to manage some infrastructure servers, so concepts aren't alien to me).  Here are my questions:

Supposed I have 200 different machines (VMs) sitting on each developer's desktop (rather in their VMware hypervisor)... 

1) can they all have the same certname, so I only have to maintain a single node.pp manifest?

Yes, they can.  I'm doubtful of the wisdom of this idea, but there is no actual constraint against nodes using the same cert.  As far as the master is concerned, all the machines using that cert are the same machine.

With that said, it is by no means necessary for nodes to share identities in order to share configuration.  There are multiple ways to make all your machines share the same node block -- for instance, you can give them distinct certnames that fit a consistent pattern, so that you can use a regex node name to match them all.  Or you could use the 'default' node block to match them all.  Or if you're serving only these machines then you don't actually need node blocks at all -- just put all the declarations at the top level of site.pp.

 

2) If so, how are SSL certs maintained, given there would be 200 different VMs trying to use the same set of certs.  Or, does that even matter from a node perspective?

If you want the VMs to share certs, then you would set it up in the master VM image.  Then people would automatically get it with the VM.  There are alternatives, but none that I would recommend.

 

3) If not, do I REALLY have to maintain 200 different manifests; all identical to each other?

No.  See above.

 

I've been able to put together a single node.pp file that sets up everything for them, so they only download a 2.8Gb bare VM image and puppet does the rest.  But, when firing up subsequent VMs, of course the client gets all confused because the generated certs don't match up.

As I said, you can set up Puppet inside the master VM image, certs and all.  Then it won't generate new certs.  This is a pretty natural approach, provided that you actually want all the VM instances to share certs.

If you don't want that, then you probably need to ensure that every VM instance uses a distinct certname.  There is a config setting where by which you can specify which certname that instance should use.  The default is to use the machine's hostname, but if cloning a VM results in an instance with the same hostname then you must ensure either that they share a cert or that they use different certnames.

 

Any suggestions for a better solution, or workaround to this one?  (I've thought about using NAT and a fixed MAC address, but with so many developers out there, I'm sure some will re-create MAC addresses at some point during their initial setup, or change their networking type for the VM and start flooding the network with duplicated mac errors).  

Use UUIDs for certnames if there's nothing else you can be confident will be unique.  Set up a UUID server if need be, though you could probably just distribute a little UUID generator instead of centralizing.

John

[jcbollinger]

On Tuesday, July 15, 2014 3:14:42 PM UTC-5, Peter Bukowinski wrote:

On Jul 15, 2014, at 3:09 PM, randal cobb <rco...@gmail.com> wrote:

No. Each vm/puppet agent needs a unique cert.

That is incorrect.  Agents absolutely may use the same cert.  What they may not do is use the same certname but different certs.


John

[Felix Frank]

On 07/16/2014 03:04 PM, jcbollinger wrote:
> Supposed I have 200 different machines (VMs) sitting on each
> developer's desktop (rather in their VMware hypervisor)...
> 1) can they all have the same certname, so I only have to maintain a
> single node.pp manifest?
>
>
>
> Yes, they can. I'm doubtful of the wisdom of this idea, but there is no
> actual constraint against nodes using the same cert. As far as the
> master is concerned, all the machines using that cert are the same machine.

Just don't. The master will get confused by the (potentially) different
fact values from the separate agents and your results can become
unpredictable. This depends on your manifest of course, and whether you
rely on facts at all.

> Use UUIDs for certnames if there's nothing else you can be confident
> will be unique. Set up a UUID server if need be, though you could
> probably just distribute a little UUID generator instead of centralizing.

Facter actually comes with a UUID generator - see `facter uniqueid`.

Cheers,
Felix

[randal cobb]

Thanks, all!

I took highlights from all your posts and came up with the following solution:

I wrote a relatively simple shell script that users of the VM image will run at launch to set up their VMs.  It does the following:

1) requires them to enter a domain userId

2) formulates a certname using their ID concatenated with "-dev-vm"

3) passes that formulated certname as an environment variable that facter can read (later via augeas to set the certname in the VM's puppet config)

4) calls the puppet agent --onetime -w... <blah> command to request a cert

5) waits for me to approve the cert on the master

6) uses regex in the nodes.pp file to look for a hostname containing "-dev-vm", then applies that machine's class

7) uses the passed in certname to populate (via augeas) the vm's /etc/puppet/puppet.conf certname

I also set up a script on the master to send and respond to Jabber messages whenever a new cert request came in, so I can simply respond to the message with "approve" or "deny" the cert request without having to SSH to the master just to approve certs!

It works pretty slick!  I knew asking the experts would lead me to a good solution!  You all rock and I owe you all a beer!

Thanks again!

Randy

[José Luis Ledesma]

El 16/07/2014 16:06, "Felix Frank" <felix...@alumni.tu-berlin.de> escribió:
>
> On 07/16/2014 03:04 PM, jcbollinger wrote:
> >     Supposed I have 200 different machines (VMs) sitting on each
> >     developer's desktop (rather in their VMware hypervisor)...
> >     1) can they all have the same certname, so I only have to maintain a
> >     single node.pp manifest?
> >
> >
> >
> > Yes, they can.  I'm doubtful of the wisdom of this idea, but there is no
> > actual constraint against nodes using the same cert.  As far as the
> > master is concerned, all the machines using that cert are the same machine.
>
> Just don't. The master will get confused by the (potentially) different
> fact values from the separate agents and your results can become
> unpredictable. This depends on your manifest of course, and whether you
> rely on facts at all.
>

I don't think this is true. Master compiles a catalog based on facts, it does not mind if there is a previous compilation with a complete list of different fact values.

> > Use UUIDs for certnames if there's nothing else you can be confident
> > will be unique.  Set up a UUID server if need be, though you could
> > probably just distribute a little UUID generator instead of centralizing.
>
> Facter actually comes with a UUID generator - see `facter uniqueid`.
>
> Cheers,
> Felix
>

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53C686D9.2030402%40alumni.tu-berlin.de.

[Felix Frank]

On 07/16/2014 08:34 PM, José Luis Ledesma wrote:
> I don't think this is true. Master compiles a catalog based on facts, it
> does not mind if there is a previous compilation with a complete list of
> different fact values.

One would assume that. One would not be right, necessarily ;-/

Note that I have not yet "tried" this scenario with a 3.x master. The
glitches are hopefully a 2.x issue that is long solved.

Cheers,
Felix

[David Schmitt]

On 2014-07-16 20:34, José Luis Ledesma wrote:
>
> El 16/07/2014 16:06, "Felix Frank" <felix...@alumni.tu-berlin.de

> <mailto:felix...@alumni.tu-berlin.de>> escribió:

> >
> > On 07/16/2014 03:04 PM, jcbollinger wrote:
> > > Supposed I have 200 different machines (VMs) sitting on each
> > > developer's desktop (rather in their VMware hypervisor)...
> > > 1) can they all have the same certname, so I only have to
> maintain a
> > > single node.pp manifest?
> > >
> > >
> > >
> > > Yes, they can. I'm doubtful of the wisdom of this idea, but there
> is no
> > > actual constraint against nodes using the same cert. As far as the
> > > master is concerned, all the machines using that cert are the same
> machine.
> >
> > Just don't. The master will get confused by the (potentially) different
> > fact values from the separate agents and your results can become
> > unpredictable. This depends on your manifest of course, and whether you
> > rely on facts at all.
> >
>
> I don't think this is true. Master compiles a catalog based on facts, it
> does not mind if there is a previous compilation with a complete list of
> different fact values.

Even if the master is able to handle quickly changing facts, every
module that relies on export/collect will be terminally broken.



Regards, David

[jcbollinger]

Not so fast.  In the first place, comparatively few modules do rely on export/collect, and there's no particular reason to think that any of those are relevant.  In the second place, breakage of such modules assumes that the specific facts they rely on would change from one (virtual) machine to another among those sharing a cert.  Inasmuch as the discussion is about a collection a VMs originating as clones of the same master image (and, as initially conceived, each having the same hostname), I would suppose that many of the core facts would anyway be identical among this collection.

As I said earlier, it's probably not a wise plan to share certs.  Issues such those we've been discussing are why.  It is likely easier to just give each VM instance its own cert than to undertake the effort to ensure that sharing a single cert works smoothly.  But if you were determined to share a cert, and you were willing to accept the limitations that imposed, then it could be made to work.


John