Use ansible_local provisioner on all platforms

[joshrickert]

Vagrant's latest 1.8 release adds an ansible_local provisioner which should be able to replace the functionality of the windows provisioner shell script.

[austinpray]

@QWp6t is way ahead of you! We've been waiting for this. We should go ahead and use it on all platforms.

[QWp6t]

Yeah, I think there are a few hangups for Windows users, though. I'll revisit it and submit a PR when time permits (probably not until January). If someone else wants to tackle it before then, feel free. Just keep in mind that the trellis directory name can change, the Vagrantfile can be moved, and users can specify multiple site folders. (The first two we're aware of when in the Vagrantfile, but become less aware of inside the VM.)

I'd really like to get @fullyint or @swalkinshaw to weigh in as well since they're our resident experts on all things related to Ansible.

There are also some issues with Windows that I still want to tackle in Trellis, but I'll wait until after this transition before I bring them up.

[joshrickert]

@austinpray I hope you mean all platforms as a fallback. It's still convenient to use the host Ansible as the primary provisioner.

@geerlingguy also noticed that there are is a minor downside to the new ansible_local provisioner: Since it re-runs ansible-galaxy install every time it runs, it makes the provisioning process take a bit longer. This issue would address that.

[QWp6t]

I personally think we should drop ansible provisioner and only use ansible_local. It's easier to maintain.

[geerlingguy]

@QWp6t - would be slightly easier, but for Ansible power users, it's a bit more painful, because you're requiring them to give up one of the major benefits of Ansible—not having to install extra junk inside your VM/servers.

[joshrickert]

Also since Ansible on the host is a dependency anyway for the staging/production deployments.

[austinpray]

I haven't looked into it, but does using the ansible_local provisioner preclude one from running the server.yml playbook against hosts/development?

I'm confused as to what we are losing if we switch to ansible_local for all platforms.

[swalkinshaw]

@austinpray well correct. This only applies to Vagrant so it's development only. But consider this workflow:

1. User gets Trellis working on development
2. User wants to provision/deploy to a remote server
3. User now needs to figure out how to install Ansible and run it locally

This definitely simplifies things for development but might make it more confusing for remote servers.

[joshrickert]

To avoid the issue that @swalkinshaw points out, it may be better to continue the current workflow where the user installs Ansible on their host machine during the setup process, but it could become an optional step for those who don't intend to deploy using Trellis.

So, the pros of switching to the ansible_local provisioner exclusively:

1. We simplify the Vagrantfile and improve maintainability.
2. Installing Ansible on the host may become an optional step for those who aren't using it to deploy

The downsides are:

1. Longer provisioning time while ansible-galaxy install runs, though we could mitigate that by continuing to run ansible-galaxy install on the host during the setup process (instead of on the guest), but then we have to add some extra configuration to make those roles available to Ansible on the guest. Unfortunately, that nullifies both of the pros above. The permanent solution would be to help Ansible make that command idempotent so that it runs quickly after the first installation.
2. Ansible becomes extra software installed on the Vagrant VM, which some power users may not like. This personally doesn't bother me too much, for what it's worth.

[austinpray]

I disagree that it is making things more confusing for remote servers. The user needs to figure out how to install Ansible and run it locally at some point. Installing the dependencies is not the hurdle, it's understanding the ansible-playbook command and configuring the environment group_vars.

1. We all agreed that we recommend Trellis even for people that are just using it for local development. Why not make it extremely easy for these people to get up and running? These people can "graduate" to provisioning remote servers once they are delighted with how easy it was to get up and running with Trellis locally.
2. Teams are made up of people with differing roles. On any given team I'm assuming that the amount of devops people is smaller than the people working on themes/plugins locally day-to-day. These day-to-day front-end developers and such never run the ansible-playbook command, so why do they need ansible installed on the host? Deploys should be happening from a central deployment server in a team environment anyway.

@joshrickert only the initial provisioning time will take a long time. If you are making config changes and testing locally you should be running ansible-playbook -i hosts/development server.yml --tags "whatever,you,changed".

[geerlingguy]

You can have it both ways, of course (which is what I'm doing for Drupal VM):

  # Provisioning. Use ansible if it's installed on host, ansible_local if not.
  if which('ansible-playbook')
    config.vm.provision "ansible" do |ansible|
      ansible.playbook = "#{dir}/provisioning/playbook.yml"
    end
  else
    config.vm.provision "ansible_local" do |ansible|
      ansible.playbook = "provisioning/playbook.yml"
      ansible.galaxy_role_file = "provisioning/requirements.yml"
    end
  end

If users install Ansible, it uses the ansible provisioner. If they don't install Ansible, it uses ansible_local.

[swalkinshaw]

@austinpray I'm in agreement that the improvement to the development workflow is worth it regardless. That's the first experience almost everyone has with Trellis anyway.

@geerlingguy also a good idea 👍

[mAAdhaTTah]

Just wanted to drop a line here, since we were looking at using ansible_local for Windows support in one of our projects: There's a known bug in Vagrant 1.8.1 w/ the 2.0 version of ansible: hashicorp/vagrant#6793

So you're not going to be able to switch until that all gets sorted :(.