Part of our goal for this quarter is to get puppetDB up and running in our puppet infrastructure. Actionables:
- Acquire a box to run the software on
- Decide on how to ship the software to production
- Migrate from the deprecated activerecord to puppetDB
Part of our goal for this quarter is to get puppetDB up and running in our puppet infrastructure. Actionables:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | akosiaris | T139471 Goal: Modernize puppet configuration management infrastructure | |||
| Resolved | akosiaris | T139476 Install puppetDB at WMF | |||
| Resolved | Joe | T142363 create puppetDB puppet role + debian package | |||
| Resolved | Joe | T142365 eqiad+codfw: 1 VM request for puppetDB | |||
| Resolved | Joe | T142846 Create replacement for our scripts that depend on exported resources |
Since we're using puppet 3.x, we need to use puppetDB 2.3.
A debian package for it is available for trusty and can be easily adapted to jessie - it's a pretty raw package as it's basically just packing toghether a .jar file and some docs toghether, but it seems an acceptable shortcut to me for experimenting at least.
Migration from activerecord seems easy:
https://docs.puppet.com/puppetdb/2.3/migrate.html
We surely need to use postgres as a backend, and probably have a replicated db in codfw for possible failover/avoiding creating a SPOF.
As far as puppetization goes, it shouldn't be too hard to do: there are already modules from puppetlabs we can use as a starting point; I think we should work on SSL termination at nginx too from the start.
Ideally, the puppetdb server(s) and the backend postgres servers should communicate via SSL as well, so that it would be possible to keep at least puppetdb active-active in the two datacenters (both pointing at the same db backend).