testing a puppet master

[Jeff Abrahamson]

[Apologies if this posts twice.  I'm pretty sure I messed up posting earlier, and it's now been two days without the message appearing on the web view.]

I'm new to puppet.  I read a bunch, managed to write a simple (and probably clumsy) manifest to configure a host.  Great, so time to be more serious.  I configured a puppet master under apache2.  (I'm on ubuntu 14.04 with packages at version 3.8 thanks to the deb from puppet labs...)  So far, so good, but I'm stuck on a couple points now.

1.  The puppet master is running under apache2.  I assume it's healthy, in so much as it doesn't complain and I'm serving on 8140.  But I'd love a better way to confirm that than absence of errors.  Is there a way to enquire about the master's health?

2.  I would like to be able to do automated testing.  For the agents (individual hosts in my (tiny) fleet) I can bring up vagrant vm's, tell them their name is X, and then do a puppet apply.  So then I can see if the host comes up the way I expect for host X.  Then I can run a script on the vm that checks whatever I think the host should actually be doing.  But I'd like to automate that, yet I oddly haven't found common recipes for doing so.  I bet this isn't something I need to invent.  Any pointers?

3.  In a similar vein, I'd like to do automated testing for the master as well.  So this is (1) and (2) together, since I'm not sure how to test the master.

4.  Our github repository is private.  Is standard (best) practice to give the puppet master ssh keys to github without passphrase?  Can/should I do better?

Thanks much for any tips.

Jeff Abrahamson
+33 6 24 40 01 57

+44 7920 594 255    <-- only when I'm in the UK
http://ml-week.com/     prochaine edition, 2016

http://jeff.purple.com/
http://blog.purple.com/jeff/

[Toni Schmidbauer]

Jeff Abrahamson <je...@purple.com> writes:
> 1. The puppet master is running under apache2. I assume it's healthy,
> in so much as it doesn't complain and I'm serving on 8140. But I'd
> love a better way to confirm that than absence of errors. Is there a
> way to enquire about the master's health?

i would strongly recommend running puppetserver instead of
apache+passenger. it's way easier to setup (just start the
puppetserver) and scales well (1500 nodes in our setup).

the logfile of the puppetserver is a first start. also as puppet uses
regular http(s) for the master/node communication, there's also a status
url

https://docs.puppetlabs.com/puppet/3.8/reference/http_api/http_status.html

which could be queried by you monitoring software.

> 2. I would like to be able to do automated testing. For the agents
> (individual hosts in my (tiny) fleet) I can bring up vagrant vm's,
> tell them their name is X, and then do a puppet apply. So then I can
> see if the host comes up the way I expect for host X. Then I can run a
> script on the vm that checks whatever I think the host should actually
> be doing. But I'd like to automate that, yet I oddly haven't found
> common recipes for doing so. I bet this isn't something I need to
> invent. Any pointers?

currently there are two recommended ways to test you puppet code:

- rspec-puppet which uses puppet to compile a catalog and checks
resources within that catalog (aka unittest)

- beaker, used for acceptance tests
(https://github.com/puppetlabs/beaker)

for learning how to use this tests i strongly recommend looking at
existing puppet modules. the puppetlabs modules are well tested and also
provide acceptance tests, e.g.:

https://github.com/puppetlabs/puppetlabs-ntp/tree/master/spec/acceptance

https://github.com/puppetlabs/puppetlabs-ntp/tree/master/spec/classes
for unittests.

> 3. In a similar vein, I'd like to do automated testing for the master
> as well. So this is (1) and (2) together, since I'm not sure how to
> test the master.
>
> 4. Our github repository is private. Is standard (best) practice to
> give the puppet master ssh keys to github without passphrase?
> Can/should I do better?

we've implemented the following workflow for internal modules:

- each module in a separate git repo
- push to module repo triggers jenkins which runs unit and acceptance
tests (could also be done via travis)
- releases of modules is done via tags (e.g. 1.1.0)
- r10k (https://github.com/puppetlabs/r10k) is used for deployments

hth,
toni

[Jeff Abrahamson]

On 15 February 2016 at 17:44, Toni Schmidbauer <toni+pup...@stderr.at> wrote:

Jeff Abrahamson <je...@purple.com> writes:
> 1. The puppet master is running under apache2. I assume it's healthy,
> in so much as it doesn't complain and I'm serving on 8140. But I'd
> love a better way to confirm that than absence of errors. Is there a
> way to enquire about the master's health?

i would strongly recommend running puppetserver instead of
apache+passenger. it's way easier to setup (just start the
puppetserver) and scales well (1500 nodes in our setup).

the logfile of the puppetserver is a first start. also as puppet uses
regular http(s) for the master/node communication, there's also a status
url

https://docs.puppetlabs.com/puppet/3.8/reference/http_api/http_status.html

which could be queried by you monitoring software.

This is the puppetserver that is included in PE but not in the open source version?  (We're using the open source puppet atm.)

I'd understood (though the reasons are not well spelled out except maybe here) that Webrick, anyway, is not such a good idea.

 

> 2. I would like to be able to do automated testing. For the agents
> (individual hosts in my (tiny) fleet) I can bring up vagrant vm's,
> tell them their name is X, and then do a puppet apply. So then I can
> see if the host comes up the way I expect for host X. Then I can run a
> script on the vm that checks whatever I think the host should actually
> be doing. But I'd like to automate that, yet I oddly haven't found
> common recipes for doing so. I bet this isn't something I need to
> invent. Any pointers?

currently there are two recommended ways to test you puppet code:

- rspec-puppet which uses puppet to compile a catalog and checks
  resources within that catalog (aka unittest)

- beaker, used for acceptance tests
  (https://github.com/puppetlabs/beaker)

for learning how to use this tests i strongly recommend looking at
existing puppet modules. the puppetlabs modules are well tested and also
provide acceptance tests, e.g.:

https://github.com/puppetlabs/puppetlabs-ntp/tree/master/spec/acceptance

https://github.com/puppetlabs/puppetlabs-ntp/tree/master/spec/classes
for unittests.

Cool, thanks!  I'll poke through those.

On first glance, that seems to let me do unit testing without being able to confirm that a fresh vm will properly come up with the desired functionality.  Did I miss something?

 

> 3. In a similar vein, I'd like to do automated testing for the master
> as well. So this is (1) and (2) together, since I'm not sure how to
> test the master.
>
> 4. Our github repository is private. Is standard (best) practice to
> give the puppet master ssh keys to github without passphrase?
> Can/should I do better?

we've implemented the following workflow for internal modules:

- each module in a separate git repo
- push to module repo triggers jenkins which runs unit and acceptance
  tests (could also be done via travis)
- releases of modules is done via tags (e.g. 1.1.0)
- r10k (https://github.com/puppetlabs/r10k) is used for deployments

Thanks, Toni, very good pointers.

 

[Toni Schmidbauer]

Jeff Abrahamson <je...@purple.com> writes:
> This is the puppetserver that is included in PE but not in the open
> source version? (We're using the open source puppet atm.)

puppetserver is also available in the opensource version (which we are
using as well). e.g. for puppet 3 on rhel 7 it's available via
http://yum.puppetlabs.com/el/7/products/x86_64/ as a single package.
puppet 4 change to so called all-in-one packaging
(https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html),
but nevertheless puppetserver is available as well.

> I'd understood (though the reasons are not well spelled out except
> maybe here) that Webrick, anyway, is not such a good idea.

webrick is single threaded, so not an option in a prod environment
(except you are running just a few (5-10) nodes).

> Cool, thanks! I'll poke through those.
> On first glance, that seems to let me do unit testing without being
> able to confirm that a fresh vm will properly come up with the desired
> functionality. Did I miss something?

beaker is a tool to boot vm's or containers, do a puppet run and
afterwards verify via serverspec (http://serverspec.org/) that the host
conforms to your code.

you could also use native serverspec without beaker to verify your
regular nodes conform to your requirements.

toni