* Ansible Powerplay Powerplay allows you to run multiple Ansible playbooks in parallel. Depending on how you organize your playbooks, this can be a solid win. I basically before this had been doing a playbook with multiple includes for other playbooks representing different servers in our stack. Playbook launching of playbooks is slow and very serial. Basically, the playbooks are all contained, so no interdependencies. And in my case, running in the cloud, so no reason why they can't be running in parallel Powerplay allows you to specify vars common to all playbooks, and also vars specific to some playbooks so by which you can make your setup very DRY. All the Ansible playbooks are executed in seperate processes, and thus avoiding a number of the "side effects" you would normally encounter with running multiple playbooks with Ansible includes. For example, here is Powerplay integrated with tmux: #+CAPTION: Powerplay writing to tmux panes, one pane per playbook. #+NAME: Powerplay Example [[./examples/powerplay_screenshot.jpeg]] ** Release Notes Please see [[RELEASE_NOTES.org][Release Notes]] ** Features and Cavets *** Integration with TMUX When running multiple Ansible Playbooks concurrently, one would like to be able to see the output of each in a reasonable manner. To faciliate this in this initial realse, we shall make heavy use of TMUX panes to dump the output. So basically, you need as many panes as you have concurrent Ansible Playbooks in this initial release. In subsequent releases, Curses will be directly leveraged to create "tabs" for the multiple output streams. We may even do this, still, through TMUX. Your input on this is strongly encouarged. We will not be supporting Screen at all. Sorry. ** DSL Terminology & Documentation *** DSL The DSL is straightforward as possible, simple and elegant to allow you to write your Powerplays in a DRY manner. **** configuration You can intersperse configuration blocks anywhere, and the expected nested scoping will take effect. **** playbooks playbooks are a collection of groups, and each group are normally executed serially. This will allow you to organize your plays in an intelligent manner to deploy and manage resources and assets that may have to be done in a serial manner. **** group A group is a collection of books that all execute in parallel. Books are required to be independent of each other. **** book A book has a direct correspondence to an Ansible playbook, and will execute that Yaml file given the configuration variables as parameters. Here is where var inheritance becomes useful. ** Installation Easy installation. From command-line: #+BEGIN_SRC bash gem install ansible-powerplay #+END_SRC Or from a gemfile: #+BEGIN_SRC ruby gem 'ansible-powerplay' #+END_SRC ** Use Basically, cd to the root of your Ansible directory, and a .play file (see the example at: [[https://github.com/flajann2/ansible-powerplay/blob/master/examples/test.play][test.play]]. You can place a config clause either globally, inside of playbooks, inside of groups, and the variable set up this way are inherited to the inner clauses, thus allowing you to keep your specifications DRYer. For example: #+BEGIN_SRC ruby # This is a global system configuration configuration :system do playbook_directory "playbooks" end #+END_SRC Note that 'playbook_directory' is special, as it allows you to define the directory all of your Ansible playbooks can be found. You can also specify this anywhere you can use the configuration clause, so you may set up different playbook directories for different playbook collections. #+BEGIN_SRC ruby # sṕecific configuration for :development configuration do stack :development krell_type "t2.small" servers 1 rolling 3 krell_disk_size 20 end #+END_SRC The above shows Ansible variables for my specialiezd setup that is geared with work with AWS. You are free to specify any variables here, which will be injected into ansible-playbook through the '--extra-vars' parameter. Here is a group clause with a single book in it: #+BEGIN_SRC ruby # Groups are executed serially. group :first, "our very first group" do # Books within a group are executed in parallel, # and therefore must be independent of each other. book :nat, "nat.yml" end #+END_SRC Which issues the following command to Ansible (based on the earlier configuration): #+BEGIN_SRC bash ansible-playbook playbooks/nat.yml \ --extra-vars "playbook_directory=playbooks stack=development krell_type=t2.small servers=1 rolling=3 krell_disk_size=20" #+END_SRC And if our group had more book entries, as in the second example: #+BEGIN_SRC ruby group :second, "our second group" do book :rabbit, "rabbitmq_cluster.yml" do krell_type "t2.medium" end book :es_cluster, "elasticsearch_cluster.yml" do esver "1.7.4" cluster_name :es servers 3 heapsize "2g" krell_type "t2.medium" krell_disk_size 200 end end #+END_SRC Both the :rabbit and :es_cluster books would be executed in parallel. *** Dividing up your specs in other PowerPlay files Ruby, the underlying language, give you a lot of things for "free", like allowing you to load other powerplay files, for example: #+BEGIN_SRC ruby load 'production.play' #+END_SRC We mention this here for those who may not be familiar with Ruby, but may wish to section off your specifications thusly. You don't really need to know any Ruby, but it could increase the span of what you might want to do. To get a quick taste, please checkout [[https://www.ruby-lang.org/en/documentation/quickstart/][Ruby in 20 Minutes]]. It is also possible to leverage Ruby's metaprogramming techniques to create templates for your specificaitons, but at some point, as time allows, I may directly support this in the DSL. Please let your wishes be known to me for this and any other feature you might want to see. *** Running Powerplay If you type 'powerplay' without parameters, you are greeted with: #+BEGIN_SRC doc Commands: powerplay help [COMMAND] # Describe available commands or one specific command powerplay play