Gonzo - Puppet change impact console
Gonzo lets you assess the impact of your Puppet change before rolling it out across your server estate. It takes over after continuous integration tools have run their tests and deployed the release to the Puppet Masters, but before clients have been updated.
Gonzo's goal is to increase confidence in Puppet changes by making it easier to verify that all changes are intentional and understood.
14/04/2014 - I've pulled the CSS file from the repo as it isn't open source. No plans/ETA for a replacement just yet. Sorry.
List Available Releases
See what releases are available to deploy, and current deployment status across tiers (DEV, UAT, PROD):
Initiate dry-run of change across all nodes, and view assessment summary across tiers. Trigger rollout (or change management process):
View all changes and assess as low, medium or high risk:
View changes be node:
View summary of each node:
Changes are implemented using standard Puppet catalogs. Each release becomes a new environment, using dynamic environments on the Puppet Masters.
The web console is used to review releases, initiate "noop" runs, review the results and assess the impact. The console is written in AngularJS with a Ruby on Rails backend. MCollective is used to run pre-flight "noop" Puppet runs and it stores prospective changes in CouchDB, a JSON document store. Portions of the CouchDB database are replicated in real-time to the browser using PouchDB, allowing instant updates to the web console. Replication is bi-directional: risk assessments are remembered across multiple runs.
All development is done on a Macbook Pro running:
- RVM/Ruby 2.1.0 tested/Rails 4+ tested
- CouchDB - Assumes local install.
- Vagrant - Nodes to test on.
- Oscar. Puppet Enterprise used for development, but shouldn't be required.
- MCollective CouchDB Registration agent (recommended, but optional)
The web console requires a modern browser that supports IndexedDB (Chrome, Firefox, IE 10+). Development is against Chrome.
There is currently no authentication or access control model in place. Database replication and API calls are currently in clear text and use default/guessable passwords. It is not suitable for public-facing deployments.
Please help! Documentation is especially poor at this stage, and ideally packages created for easier installation. I'd also like to remove Rails and switch to Sinatra as the server-side API very minimal. See TODO.md for a list of ideas.
Simon Croome / firstname.lastname@example.org