On 15 February 2016 at 17:44, Toni Schmidbauer <toni+puppet-us...@stderr.at> wrote:
> Jeff Abrahamson <j...@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 <https://stackoverflow.com/questions/10859671/webrick-as-production-server-vs-thin-or-unicorn>) 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. -- 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/CAM4Y7zwyqBFKHYTqgphjsUnA%3Dx439g%2B0csDogeDCgLGHJ8HesA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
