2015-02-10 14:28:00 +00:00
---
2016-01-19 18:08:53 +00:00
layout: "docs"
2015-02-10 14:28:00 +00:00
page_title: "Ansible Local - Provisioning"
sidebar_current: "provisioning-ansible-local"
2016-01-19 18:08:53 +00:00
description: |-
The Vagrant Ansible Local provisioner allows you to provision the guest using Ansible playbooks by executing "ansible-playbook" directly on the guest
machine.
2015-02-10 14:28:00 +00:00
---
# Ansible Local Provisioner
**Provisioner name: `ansible_local` **
2016-01-19 18:08:53 +00:00
The Vagrant Ansible Local provisioner allows you to provision the guest using [Ansible ](http://ansible.com ) playbooks by executing ** `ansible-playbook` directly on the guest machine**.
2015-02-10 14:28:00 +00:00
2016-01-19 18:08:53 +00:00
< div class = "alert alert-warning" >
2017-08-24 16:30:11 +00:00
< strong > Warning:< / strong >
2019-04-01 23:18:29 +00:00
If you are not familiar with Ansible and Vagrant already, we recommend starting with the < a href = "/docs/provisioning/shell.html" > shell provisioner< / a > . However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
2015-02-10 14:28:00 +00:00
< / div >
## Setup Requirements
2016-01-19 18:08:53 +00:00
The main advantage of the Ansible Local provisioner in comparison to the [Ansible (remote) provisioner ](/docs/provisioning/ansible.html ) is that it does not require any additional software on your Vagrant host.
2015-02-10 14:28:00 +00:00
2016-01-19 18:08:53 +00:00
On the other hand, [Ansible must obviously be installed ](https://docs.ansible.com/intro_installation.html#installing-the-control-machine ) on your guest machine(s).
2015-02-10 14:28:00 +00:00
**Note:** By default, Vagrant will *try* to automatically install Ansible if it is not yet present on the guest machine (see the `install` option below for more details).
## Usage
2016-01-19 18:08:53 +00:00
This page only documents the specific parts of the `ansible_local` provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant ](/docs/provisioning/ansible_intro.html ).
2015-02-10 14:28:00 +00:00
2016-01-19 18:08:53 +00:00
The Ansible Local provisioner requires that all the Ansible Playbook files are available on the guest machine, at the location referred by the `provisioning_path` option. Usually these files are initially present on the host machine (as part of your Vagrant project), and it is quite easy to share them with a Vagrant [Synced Folder ](/docs/synced-folders/ ).
2015-02-10 14:28:00 +00:00
### Simplest Configuration
To run Ansible from your Vagrant guest, the basic `Vagrantfile` configuration looks like:
```ruby
2016-02-02 14:43:28 +00:00
Vagrant.configure("2") do |config|
2015-02-10 14:28:00 +00:00
# Run Ansible from the Vagrant VM
config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "playbook.yml"
end
end
```
**Requirements:**
- The `playbook.yml` file is stored in your Vagrant's project home directory.
2016-01-19 18:08:53 +00:00
- The [default shared directory ](/docs/synced-folders/basic_usage.html ) is enabled (`.` → `/vagrant` ).
2015-02-10 14:28:00 +00:00
## Options
2016-10-21 23:05:50 +00:00
This section lists the _specific_ options for the Ansible Local provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners ](/docs/provisioning/ansible_common.html ).
2015-02-10 14:28:00 +00:00
- `install` (boolean) - Try to automatically install Ansible on the guest system.
2016-06-08 21:44:58 +00:00
This option is enabled by default.
2015-02-10 14:28:00 +00:00
2016-06-08 21:44:58 +00:00
Vagrant will try to install (or upgrade) Ansible when one of these conditions are met:
2015-02-10 14:28:00 +00:00
- Ansible is not installed (or cannot be found).
2017-08-29 03:32:38 +00:00
- The [`version` ](/docs/provisioning/ansible_common.html#version ) option is set to `"latest"` .
- The current Ansible version does not correspond to the [`version` ](/docs/provisioning/ansible_common.html#version ) option.
2015-02-10 14:28:00 +00:00
2017-08-24 16:30:11 +00:00
< div class = "alert alert-warning" >
< strong > Attention:< / strong >
There is no guarantee that this automated installation will replace a custom Ansible setup, that might be already present on the Vagrant box.
< / div >
2015-02-10 14:28:00 +00:00
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
- `install_mode` (`:default`, `:pip` , or `:pip_args_only` ) - Select the way to automatically install Ansible on the guest system.
2016-06-08 20:59:47 +00:00
- `:default` : Ansible is installed from the operating system package manager. This mode doesn't support `version` selection. For many platforms (e.g Debian, FreeBSD, OpenSUSE) the official package repository is used, except for the following Linux distributions:
2018-05-29 06:36:33 +00:00
- On Ubuntu-like systems, the latest Ansible release is installed from the `ppa:ansible/ansible` repository. The compatibility is maintained only for active long-term support (LTS) versions.
2016-06-08 20:59:47 +00:00
- On RedHat-like systems, the latest Ansible release is installed from the [EPEL ](http://fedoraproject.org/wiki/EPEL ) repository.
2017-08-29 03:32:38 +00:00
- `:pip` : Ansible is installed from [PyPI ](https://pypi.python.org/pypi ) with [pip ](https://pip.pypa.io ) package installer. With this mode, Vagrant will systematically try to [install the latest pip version ](https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py ). With the `:pip` mode you can optionally install a specific Ansible release by setting the [`version` ](/docs/provisioning/ansible_common.html#version ) option.
2016-06-08 20:59:47 +00:00
2019-08-02 15:18:20 +00:00
Example:
```ruby
config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "playbook.yml"
ansible.install_mode = "pip"
ansible.version = "2.2.1.0"
end
```
With this configuration, Vagrant will install `pip` and then execute the command
```shell
sudo pip install --upgrade ansible==2.2.1.0
```
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
2019-01-28 19:59:00 +00:00
As-is `pip` is installed if needed via a default command which looks like
2019-07-08 17:22:50 +00:00
```shell
curl https://bootstrap.pypa.io/get-pip.py | sudo python
```
2019-01-28 19:59:00 +00:00
This can be problematic in certain scenarios, for example, when behind a proxy. It is possible to override this default command by providing an explicit command to run as part of the config using `pip_install_cmd` . For example:
2019-07-08 17:22:50 +00:00
```ruby
config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "playbook.yml"
ansible.install_mode = "pip"
ansible.pip_install_cmd = "https_proxy=http://your.proxy.server:port curl -s https://bootstrap.pypa.io/get-pip.py | sudo https_proxy=http/your.proxy.server:port python"
ansible.version = "2.2.1.0"
end
```
2019-01-28 19:59:00 +00:00
In this case case `pip` will be installed via the command:
2019-07-08 17:22:50 +00:00
```shell
https_proxy=http://your.proxy.server:port curl -s https://bootstrap.pypa.io/get-pip.py | sudo https_proxy=http://your.proxy.server:porpython
```
2019-01-28 19:59:00 +00:00
If `pip_install_cmd` is not provided in the config, then `pip` is installed via the default command.
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
- `:pip_args_only` : This mode is very similar to the `:pip` mode, with the difference that in this case no pip arguments will be automatically set by Vagrant.
2019-07-08 17:22:50 +00:00
Example:
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
2019-07-08 17:22:50 +00:00
```ruby
config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "playbook.yml"
ansible.install_mode = "pip_args_only"
ansible.pip_args = "-r /vagrant/requirements.txt"
end
```
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
2019-07-08 17:22:50 +00:00
With this configuration, Vagrant will install `pip` and then execute the command
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
2019-07-08 17:22:50 +00:00
```shell
sudo pip install -r /vagrant/requirements.txt
```
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
The default value of `install_mode` is `:default` , and any invalid value for this option will silently fall back to the default value.
2016-06-08 20:59:47 +00:00
2017-03-23 07:16:45 +00:00
- `pip_args` (string) - When Ansible is installed via pip, this option allows the definition of additional pip arguments to be passed along on the command line (for example, [`--index-url` ](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-i )).
By default, this option is not set.
2017-01-06 13:19:44 +00:00
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
Example:
```ruby
config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "playbook.yml"
ansible.install_mode = :pip
2017-12-27 05:58:56 +00:00
ansible.pip_args = "--index-url https://pypi.internal"
ansible_local: Add the :pip_args_only install mode
With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
2017-03-23 22:10:56 +00:00
end
```
With this configuration, Vagrant will install `pip` and then execute the command
```shell
sudo pip install --index-url https://pypi.internal --upgrade ansible
```
2016-04-23 22:26:59 +00:00
- `provisioning_path` (string) - An absolute path on the guest machine where the Ansible files are stored. The `ansible-galaxy` and `ansible-playbook` commands are executed from this directory. This is the location to place an [ansible.cfg ](http://docs.ansible.com/ansible/intro_configuration.html ) file, in case you need it.
2015-02-10 14:28:00 +00:00
2016-06-08 21:44:58 +00:00
The default value is `/vagrant` .
2015-02-10 14:28:00 +00:00
- `tmp_path` (string) - An absolute path on the guest machine where temporary files are stored by the Ansible Local provisioner.
2016-06-08 21:44:58 +00:00
The default value is `/tmp/vagrant-ansible`
2015-02-10 14:28:00 +00:00
## Tips and Tricks
2018-05-25 06:29:12 +00:00
### Install Galaxy Roles in a path owned by root
< div class = "alert alert-warning" >
< strong > Disclaimer:< / strong > This tip is not a recommendation to install galaxy roles out of the vagrant user space, especially if you rely on ssh agent forwarding to fetch the roles.
< / div >
Be careful that `ansible-galaxy` command is executed by default as vagrant user. Setting `galaxy_roles_path` to a folder like `/etc/ansible/roles` will fail, and `ansible-galaxy` will extract the role a second time in `/home/vagrant/.ansible/roles/` . Then if your playbook uses `become` to run as `root` , it will fail with a _"role was not found"_ error.
To work around that, you can use `ansible.galaxy_command` to prepend the command with `sudo` , as illustrated in the example below:
```ruby
Vagrant.configure(2) do |config|
config.vm.box = "centos/7"
config.vm.provision "ansible_local" do |ansible|
ansible.become = true
ansible.playbook = "playbook.yml"
ansible.galaxy_role_file = "requirements.yml"
ansible.galaxy_roles_path = "/etc/ansible/roles"
ansible.galaxy_command = "sudo ansible-galaxy install --role-file=%{role_file} --roles-path=%{roles_path} --force"
end
end
```
2015-02-10 14:28:00 +00:00
### Ansible Parallel Execution from a Guest
With the following configuration pattern, you can install and execute Ansible only on a single guest machine (the `"controller"` ) to provision all your machines.
```ruby
2016-02-02 14:43:28 +00:00
Vagrant.configure("2") do |config|
2015-02-10 14:28:00 +00:00
config.vm.box = "ubuntu/trusty64"
config.vm.define "node1" do |machine|
machine.vm.network "private_network", ip: "172.17.177.21"
end
config.vm.define "node2" do |machine|
machine.vm.network "private_network", ip: "172.17.177.22"
end
config.vm.define 'controller' do |machine|
machine.vm.network "private_network", ip: "172.17.177.11"
machine.vm.provision :ansible_local do |ansible|
ansible.playbook = "example.yml"
ansible.verbose = true
ansible.install = true
ansible.limit = "all" # or only "nodes" group, etc.
ansible.inventory_path = "inventory"
end
end
end
```
You need to create a static `inventory` file that corresponds to your `Vagrantfile` machine definitions:
```
controller ansible_connection=local
2018-12-31 16:02:33 +00:00
node1 ansible_host=172.17.177.21 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node1/virtualbox/private_key
node2 ansible_host=172.17.177.22 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node2/virtualbox/private_key
2015-02-10 14:28:00 +00:00
[nodes]
node[1:2]
```
2016-01-19 18:08:53 +00:00
And finally, you also have to create an [`ansible.cfg` file ](https://docs.ansible.com/intro_configuration.html#openssh-specific-settings ) to fully disable SSH host key checking. More SSH configurations can be added to the `ssh_args` parameter (e.g. agent forwarding, etc.)
2015-02-10 14:28:00 +00:00
```
[defaults]
host_key_checking = no
[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes
```