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
--
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/41B3B810-11C5-4B36-BA0D-F5383D0E07A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
