Run Puppet Against Master with Local node.pp Manifest?

[Ralph Bolton]

Does anyone know if it's possible to run Puppet as if it's running with a Master, but using a locally created node.pp manifest?

I'm looking into doing some unit tests on applications that are installed by Puppet. To do this, I'm trying to use a test VM server which I'll deploy applications onto. I figure that the easiest way is probably to synthesise a node.pp manifest file and tell Puppet to use it. The problem is, when I try to do this, Puppet seems to want to work entirely locally and forgets that it's got a Master.

To elaborate on how I think this would work..

1) On the client machine, I generate a node.pp style manifest file, which pretty much just includes a bunch of modules, some with a few parameters
2) On the client I run "puppet magic_apply /my/dir/fake_node.pp"
3) Under the covers, the client machine sends the fake_node.pp file to the Master, and says "use this instead of /etc/puppet/manifests/nodes/clientbox.pp"
4) The Puppet Master build the catalogue and hands it to the client which goes ahead and does a regular Puppet run, installing modules and configs from templates onto the box

Is this possible in any way? So far the best I've come up with is to scp my synthesised node.pp onto the Puppet Master box. This seems awfully cheesy though, so I'd really rather not have to do that! Better ideas are most welcome :-)

[R.I.Pienaar]

----- Original Message -----
> From: "Ralph Bolton" <ra...@coofercat.com>
> To: puppet...@googlegroups.com
> Sent: Tuesday, February 12, 2013 10:06:51 AM
> Subject: [Puppet Users] Run Puppet Against Master with Local node.pp Manifest?
>
> Does anyone know if it's possible to run Puppet as if it's running with a
> Master, but using a locally created node.pp manifest?
>
> I'm looking into doing some unit tests on applications that are installed
> by Puppet. To do this, I'm trying to use a test VM server which I'll deploy
> applications onto. I figure that the easiest way is probably to synthesise
> a node.pp manifest file and tell Puppet to use it. The problem is, when I
> try to do this, Puppet seems to want to work entirely locally and forgets
> that it's got a Master.
>
> To elaborate on how I think this would work..
>
> 1) On the client machine, I generate a node.pp style manifest file, which
> pretty much just includes a bunch of modules, some with a few parameters
> 2) On the client I run "puppet magic_apply /my/dir/fake_node.pp"
> 3) Under the covers, the client machine sends the fake_node.pp file to the
> Master, and says "use this instead of
> /etc/puppet/manifests/nodes/clientbox.pp"
> 4) The Puppet Master build the catalogue and hands it to the client which
> goes ahead and does a regular Puppet run, installing modules and configs
> from templates onto the box

If this was possible it would be a major security concern :)

Best is to copy the code onto the machine and use puppet apply to run it all
locally, then you can make custom node files.

[Ralph Bolton]

Thanks for the suggestion. I did wonder about copying all the modules and configs off the Puppet Master onto the test box. My concern is really just about keeping that lot up to date, and most importantly to make sure that it behaves the same as it would do if it came from the Master. It could be done this way, but I'm worried it seems simple now, but will turn into a headache later on. If this is the only way to do it, then I guess I'll just have to suck it up :-(

This might sound daft, but where's the security issue? If I'm root on a box, and I want to do some wacky install on it, then I already can, regardless of what Puppet thinks. This wouldn't allow me to change anything on the Puppet Master, so I wouldn't be able to alter any boxes except the one I'm on. What additional concern would there be for having this as a feature?

[Brian Lalor]

On Feb 12, 2013, at 5:35 AM, Ralph Bolton <ra...@coofercat.com> wrote:

Thanks for the suggestion. I did wonder about copying all the modules and configs off the Puppet Master onto the test box. My concern is really just about keeping that lot up to date, and most importantly to make sure that it behaves the same as it would do if it came from the Master. It could be done this way, but I'm worried it seems simple now, but will turn into a headache later on. If this is the only way to do it, then I guess I'll just have to suck it up :-(

You may find this helpful: https://github.com/blalor/vagrant-puppet-example

It's an example project I put together a couple of weeks ago to model how you can share the same puppet config across multiple environments, like production and in a Vagrant VM.  There's very little difference between running "puppet apply" and an agent checking into a master (aside from the obvious missing management pieces) but the manifests and modules can (and should) be largely the same.  If you've go the master config checked into version control, you should be able to use that same source locally, albeit with a local nodes.pp "shim" that emulates the classes applied by the master.

I'd recommend designing your config this way from the start :-) but I've gone this route a couple of times, now (I have access to the source for manifests but no influence on the master).  

Brian

[Matthew Black]

You should be versioning all your puppet manifests and modules. You
can then write a simple script to pull down the changes. Once you have
the files you can have the manfiests and modules folder look exactly
like the puppet master and then type something like this to test.

puppet apply /etc/puppet/manifests/site.pp

If you want to test one module you can create that node.pp file, which
imports the module. You will need to create a modules directory and
place your module in that directory then type from command line

puppet apply /path/to/node.pp --modulepath=/path/to/modules/dir

Ensure that modulepath is to the modules directory you created and not
the module itself.

> --
> 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 post to this group, send email to puppet...@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ralph Bolton]

Pulling our whole puppet master from SVN is indeed an option. It seems like a bit of work, but it's possible.

The issue of trying to unit test a puppet install seems to be somewhat addressed by the Puppet solution, although I could see that we could either poke a node.pp manifest onto the real Puppet Master and then run "puppet apply" on our test VM, or else build a 'fake' Puppet Master in the manner you suggest. I guess I could do that on a build box, and then have the it spin up a VM, and have the VM just puppet off the build box.

I see a great deal of funky scripting in my future ;-)

Thanks everyone for your suggestions - it's all been very helpful.

[Matthew Black]

You would not need to pull the entire SVN, puppet modules, to test out
one specific module. The only time you would need to have multiple
modules is if there is inter-dependency.

You do not need to setup a new puppet master or upload files to the
puppet master if your purpose is to test out a new or update module
(puppet apply wont talk to the puppet master).

Even if you have custom facts, functions, providers, and types they
would be executed just the same in puppet apply with the module just
like they would on the master.