{"id":3555,"date":"2016-12-26T10:06:51","date_gmt":"2016-12-26T09:06:51","guid":{"rendered":"https:\/\/www.devco.net\/?p=3555"},"modified":"2016-12-29T09:42:39","modified_gmt":"2016-12-29T08:42:39","slug":"choria-playbooks","status":"publish","type":"post","link":"https:\/\/www.devco.net\/archives\/2016\/12\/26\/choria-playbooks.php","title":{"rendered":"Choria Playbooks"},"content":{"rendered":"
Today I am very pleased to release something I’ve been thinking about for years and actively working on since August.<\/p>\n
After many POCs and thrown away attempts at this over the years I am finally releasing a Playbook system that lets you run work flows on your MCollective network – it can integrate with a near endless set of remote services in addition to your MCollective to create a multi service playbook system.<\/p>\n
This is a early release with only a few integrations but I think it’s already useful and I’m looking for feedback and integrations to build this into something really powerful for the Puppet eco system.<\/p>\n
The full docs can be found on the Choria Website<\/a>, but below you can get some details.<\/p>\n Playbooks have a basic flow that is more or less like this:<\/p>\n Today a task can be a MCollective request, a shell script or a Slack notification. I imagine this list will grow huge, I am thinking you will want to ping webhooks, or interact with Razor to provision machines and wait for them to finish building, run Terraform or make EC2 API requests. This list of potential integrations is endless and you can use any task in any of the above task lists.<\/p>\n A Node Set is simply a named set of nodes, in MCollective that would be certnames of nodes but the playbook system itself is not limited to that. Today Node Sets can be resolved from MCollective Discovery, PQL Queries (PuppetDB), YAML files with groups of nodes in them or a shell command. Again the list of integrations that make sense here is huge. I imagine querying PE or Foreman for node groups, querying etcd or Consul for service members. Talking to random REST services that return node lists or DB queries. Imagine using Terraform outputs as Node Set sources or EC2 API queries. <\/p>\n In cases where you wish to manage nodes via MCollective but you are using a cached discovery source you can ask node sets to be tested for reachability over MCollective. And node sets that need certain MCollective agents can express this desire as SemVer version ranges and the valid network state will be asserted before any playbook is run.<\/p>\n Playbooks do not have a pseudo programming language in them though I am not against the idea. I do not anticipate YAML to be the end format of playbooks but it’s good enough for today.<\/p>\n Here we have a web stack and we want to do Blue\/Green deploys against it, sub clusters have a fact cluster<\/em>. The deploy process for a cluster is:<\/p>\n Should the task list all FAIL we run these tasks:<\/p>\n Should the task list PASS we run these tasks:<\/p>\n This example and sample playbooks etc can be found on the Choria Site<\/a>.<\/p>\n There is no such Macros today, I will add a stop gap solution as a task that waits for a certain condition but adding Macros to MCollective is high on my todo list.<\/p>\n Other than that it works, there is no web service yet so you run them from the CLI and the integrations listed above is all that exist, they are quite easy to write so hoping some early adopters will either give me ideas or send PRs!<\/p>\n This is available today if you upgrade to version 0.0.12<\/em> of the ripienaar-mcollective_choria<\/a> module.<\/p>\n See the Choria Website<\/a> for much more details on this feature and a detailed roadmap<\/a>.<\/p>\n UPDATE:<\/B> Since posting this blog I had some time and added: Terraform Node Sets, ability to create GET and POST Webhook requests and the much needed ability to assert and wait for remote state.<\/p>\n","protected":false},"excerpt":{"rendered":" Today I am very pleased to release something I’ve been thinking about for years and actively working on since August. After many POCs and thrown away attempts at this over the years I am finally releasing a Playbook system that lets you run work flows on your MCollective network – it can integrate with a […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","footnotes":""},"categories":[1],"tags":[126,85,78,21],"_links":{"self":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/3555"}],"collection":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/comments?post=3555"}],"version-history":[{"count":12,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/3555\/revisions"}],"predecessor-version":[{"id":3567,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/3555\/revisions\/3567"}],"wp:attachment":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/media?parent=3555"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/categories?post=3555"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/tags?post=3555"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Overview<\/H3>
\nToday playbooks are basic YAML files. Eventually I envision a Service to execute playbooks on your behalf, but today you just run them in your shell, so they are pure data.<\/p>\n\n
Example<\/H3>
\nI’ll show an example here of what I think you will be able to achieve using these Playbooks.<\/p>\n\n
\n
\n
\n
Status<\/H3>
\nAbove is the eventual goal. Today the major missing piece here that I think MCollective needs to be extended with the ability for Agent plugins to deliver a Macro<\/em> plugin. A macro might be something like Puppet.wait_till_idle(:timeout => 600)<\/em>, this would be something you call after disabling the nodes and you want to be sure Puppet is making no more changes, you can see the workflow above needs this.<\/p>\n