Support Ansible “Local Playbooks”

[mxey]

At the moment, the Ansible provisioner only supports running Ansible running over SSH. IMHO, this complicates the setup and requires Ansible on the host system (unlike the Puppet provisioner, for example).

Ansible supports running playbooks on localhost: http://www.ansibleworks.com/docs/playbooks2.html#id20

[mitchellh]

/cc @commandtab

[avtar]

+1 for this

[alanpearce]

Fixing this would allow running vagrant with ansible on Windows (#1946) which is always useful for cross-platform collaboration. It's an issue for us as we're collaborating with a freelancer on a project and we can't get him set up yet. I'm trying to think about a workaround using the shell provisioner, but it's a bit irritating.

For the feature, I think it would be nice if it were switchable, like the multiple modes of Puppet and Chef.

[jaugustin]

I am working on a plugin for this to execute playbook directly in the vm with --connection=local

[jaugustin]

I start writing the plugin vagrant-ansible-local base on shell / puppet plugin, you could give it a try
https://github.com/jaugustin/vagrant-ansible-local

[gildegoma]

I agree that this feature request makes a lot of sense!

@jaugustin are you interested to work on adding this functionality to the main Ansible provisioner?

[jaugustin]

@gildegoma If someone askme I can work on it :)

[gildegoma]

In my opinion, pull request for this should absolutely be accepted. As already said above, local transport mode perfectly suits to Vagrant design.

@mitchellh confirm? First, it would be great to plot the expected architecture for such "multiple transport" support. Below a few thoughts... Many thanks in advance for your review.

Considering that many ssh features do not apply to local transport mode (and vice versa), I think that we could have two separated provisioners (e.g. ansible_local and ansible_ssh [maybe aliased as ansible for backward compatibility]), with a shared code base (similarly to chef_client and chef_solo implementation). This way each Ansible provisioner will provide only the relevant set of parameters, and thus should be easier to learn, use and maintain. But this is my first glance and a "monolithic" provisioner is certainly a possible variant worth to be considered...

Nice to have: optionally bootstrap Ansible installation on the target VM. Though this one could be done independently, maybe later in a following iteration.

[cyrusdavid]

👍 Specially on windows, which ansible does not support as a control machine.

[mitchellh]

Yes, this sounds great. :)

[gildegoma]

FYI: I've started to work on this feature request and plan to a open pull request in the next weeks...

About the design: it will be only one Ansible provisioner, with two possible ansible.mode:

• run Ansible on Vagrant's :host (by default)
• run Ansible on Vagrant's :guest machine(s)

[gildegoma]

I've started to work on this feature request and plan to a open pull request in the next weeks...

Sorry for the delay, but I first want to introduce the specs (#3287). It still on my roadmap though!

[geerlingguy]

I've been using https://github.com/geerlingguy/JJG-Ansible-Windows for running playbooks from within Windows machines, and it seems to work well for either Cygwin or PowerShell-based installs. The only thing that doesn't seem to work that great is terminal colors coming through Cygwin... but that's a small thing.

I'd love to see official support, though!

[afterdesign]

Huge 👍 for this ! And packer is doing the local provisioning with ansible.

[krzysztof-indyk]

+1

[mpolden]

Any update on this?

[gildegoma]

My work in progress is available at https://github.com/gildegoma/vagrant/commits/ansible-on-guest (be aware that this branch might be rebased in the future to be kept "merge compatible" with upstream master). In the current stage, the local (or guest-based) provisioning already works fine, but code, unit tests and docs are unfortunately not enough mature to be proposed as pull request yet.

Before starting to "finalize" this (hum, see all the trailing TODOs), I first need to validate some central points, and be sure that the current direction is good:

• Agree on the new code organization (base, host, guest parts, better ruby style, etc)
• Take naming decisions
  • For instance, do we agree on 'ansible-local' like in packer? :ansible_local would better follow existing :chef_solo or :puppet_server provisioners. I am afraid of confusion with "local", why not something like :ansible_on_guest ?)
• Decide on documentation organization (a single page versus dedicated pages for both ansible provisioners). Even if common options could be shared via a third page (like for Chef Solo and Chef Client), I like the idea to keep it simple with a single page... but as a downside, both Ansible modes won't stand out from titles in the left menu.
• Agree on the level of regression testing required by this "significant" refactoring (the host-based ansible provisioner should behave exactly the same). I have been using this code base on a regular basis for some time now, but later it would be great if some of you could test it before we officially ship it in a Vagrant release.

I am sorry, but at the moment I am lacking of time to further work on all of this, and for that reason I could not ping @mitchellh to make this "intermediate" review. I'll keep you informed, but if someone is interested in helping to accelerate this development, please announce you! You're welcome and I'd be happy to pair/delegate so we can get it in "sooner"!

And as always, ❤️ to your thoughts and feedbacks!

---

For people interested to give a try to the current code, something like that can be used:

Vagrant.configure("2") do |config|
  config.vm.define 'machine1' do |machine|
    machine.vm.box = 'ubuntu/trusty64'
    machine.vm.hostname = 'machine1'

    # Install ansible on the target VM
    machine.vm.provision :shell, :inline => <<EOS
set -e
if ! command -V ansible-playbook >/dev/null 2>/dev/null; then
  sudo apt-get update -qq
  sudo apt-get install -qq ansible
fi
EOS

    # run ansible from the guest VM
    machine.vm.provision 'ansible-local' do |ansible|
      ansible.playbook = "your-playbook.yml"
    end
  end
end

[afterdesign]

@gildegoma awesome work ! I would help but ruby is not on my "known languages" list right now.

[magnetik]

Would love to see this integrated. 👍

[podarok]

Vagrantfile

  # Install ansible at remote host.
  config.vm.provision "shell", path: "provisioning/init.sh", keep_color: true
  # Copy ansible playbook to guest machine
  config.vm.provision "file", source: "provisioning/guest/inventory", destination: "/home/vagrant/inventory"
  config.vm.provision "file", source: "provisioning/guest/playbook.yml", destination: "/home/vagrant/playbook.yml"
  # Run it!!!
  config.vm.provision "shell",
    path: "provisioning/ansible.sh",
    keep_color: true

init.sh

#!/bin/sh
sudo apt-get -yq install software-properties-common
sudo apt-add-repository -y ppa:ansible/ansible
sudo apt-get -yq update
sudo apt-get -yq install ansible
sudo apt-get -yq install python-mysqldb
sudo apt-get -yq install libnotify-bin

ansible.sh

#!/bin/sh
sudo ansible-playbook -i /home/vagrant/inventory /home/vagrant/playbook.yml

playbook.yml

---
# This playbook will be executed at guest host.
- hosts: 127.0.0.1
  connection: local
  gather_facts: no

  tasks:
  -name: ...

The only issue is ansible output has no echo till the end of full process.

https://github.com/podarok/vansible

[gildegoma]

Hello Guys! Please have a look at #5340, and let us know if it would meet your needs (or not) 😄

[gildegoma]

Just a "collaboration workflow" precision, please put your comments here on #2103, so we can keep the discussion of #5340 focused on the PR review. Thanks!

[mkuzmin]

This is great news!
I've tested basic scenarios, and it works - Ansible runtime is installed, and basic playbooks are applied.
I'll continue my tests, and let you know on any issues.

Thank you for this work, that's really a big feature.

[geerlingguy]

This is looking awesome! I didn't have a chance to test locally yet, but glanced through the proposed workflow and it makes sense to me—I especially like that it basically mirrors Packer's usage/terminology, making the metal shift from Packer->Vagrant->Packer less annoying :)

[gildegoma]

@mkuzmin Thanks for jumping into testing it so quickly :) Please keep us informed if you hit any bug or trouble! Do you run it on Windows?

@geerlingguy Thanks for your vote for Packer's terminology! Please let us know if you do some beta testing as well :)

[mkuzmin]

Yes, I have Windows on a host, and Ubuntu inside a box.

[warrenseine]

I'm supporting PR /pull/5340, though I've got a simple question: why do we need a new provisioner? Can't we add a local option to the ansible provisioner?

[gildegoma]

@warrenseine asked:

Can't we add a local option to the ansible provisioner?

Warren, thanks for asking. I also initially thought about a single provisioner. But while working further on this feature, it turns out that splitting in two provisioners was (certainly) the best approach. The first reasons that lead to this decision were purely technical. But from the end-user perspective, I think that it also makes sense since the location of the Ansible control machine implies different capabilities and constraints. Here are the main reasons for this design:

• Unsupported options are automatically checked by the Vagrant plugin architecture (no additional code required). With a single provisioner approach, we should implement a set of ad-hoc validators to refuse invalid configurations (e.g. the install option could not be enabled in remote mode, etc.).
• It forces to think carefully about the shared or specific functions. For instance, the upcoming support of WinRM for configuring Windows-based guests (Ansible provisioner should support WinRM settings #5086) will be added to ansible remote provisioner, but certainly not to the ansible_local provisioner.
• Support of Puppet and Chef also provides multiple provisioners for similar reasons and with similar design (and documentation organization).
• It mimics the current Packer's naming and "kindly invite" the Vagrant user to decide where Ansible must be installed and executed.
• Having these two dedicated provisioners doesn't prevent to easily build a "flexible" Vagrantfile (i.e. able to switch between the two modes, depending on external conditions).

Note that all the common stuff is stored in a shared codebase, and we'll take care to keep things clean with the upcoming additions ;-).

I hope this answer your question... and I keep all ears to more ideas and critics!

[mkuzmin]

The arguments sound reasonable.

Speaking on Ansible runtime installation, I have another feature request. Are you going to support requirements.yml files?
With remote provisioner I was able to run ansible-galaxy explicitly, but now it has to be done within your plugin: roles must be downloaded after runtime installation, but before playbook execution.

[gildegoma]

@mkuzmin good catch about ansible-galaxy integration. This feature request is tracked by #2718, and you're right this is a must have for Vagrant 1.8.0. I add it to the pending tasks for PR #5340, thanks!

[warrenseine]

@gildegoma Thanks for the detailed explanation. It makes sense.

[gildegoma]

FYI: ansible-galaxy support is still not implemented. With a little chance I can find the time to fix it before 1.8.0 release, otherwise I'll do my best to ship it "asap" (e.g. in one of the next minor releases). If someone want to pick this item and work on it, feel free to announce in #2718.