2013-09-03 18:08:28 +00:00
---
2016-01-19 18:08:53 +00:00
layout: "docs"
2013-09-06 16:50:43 +00:00
page_title: "Ansible - Provisioning"
2013-09-03 18:08:28 +00:00
sidebar_current: "provisioning-ansible"
2016-01-19 18:08:53 +00:00
description: |-
The Vagrant Ansible provisioner allows you to provision the guest using
Ansible playbooks by executing "ansible-playbook" from the Vagrant host.
2013-09-03 18:08:28 +00:00
---
# Ansible Provisioner
2015-02-10 14:28:00 +00:00
**Provisioner name: `ansible` **
2013-09-03 18:08:28 +00:00
2016-01-19 18:08:53 +00:00
The Vagrant Ansible provisioner allows you to provision the guest using [Ansible ](http://ansible.com ) playbooks by executing ** `ansible-playbook` from the Vagrant host**.
2013-09-03 18:08:28 +00:00
2016-01-19 18:08:53 +00:00
< div class = "alert alert-warning" >
< strong > Warning:< / strong > If you are not familiar with Ansible and Vagrant already,
I 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.
2013-09-07 13:58:11 +00:00
< / div >
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
## Setup Requirements
2016-01-19 18:08:53 +00:00
- **[Install Ansible](https://docs.ansible.com/intro_installation.html#installing-the-control-machine) on your Vagrant host**.
2015-01-13 18:08:46 +00:00
2016-01-19 18:08:53 +00:00
- Your Vagrant host should ideally provide a recent version of OpenSSH that [supports ControlPersist ](https://docs.ansible.com/faq.html#how-do-i-get-ansible-to-reuse-connections-enable-kerberized-ssh-or-have-ansible-pay-attention-to-my-local-ssh-config-file ).
2014-02-03 10:45:03 +00:00
2016-01-19 18:08:53 +00:00
If installing Ansible directly on the Vagrant host is not an option in your development environment, you might be looking for the < a href = "/docs/provisioning/ansible_local.html" > Ansible Local provisioner< / a > alternative.
2014-02-03 10:45:03 +00:00
2015-02-10 14:28:00 +00:00
## Usage
2014-02-03 10:45:03 +00:00
2016-01-19 18:08:53 +00:00
This page only documents the specific parts of the `ansible` (remote) provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant ](/docs/provisioning/ansible_intro.html ).
2014-02-03 10:45:03 +00:00
2015-02-10 14:28:00 +00:00
### Simplest Configuration
2014-02-03 10:45:03 +00:00
2015-02-10 14:28:00 +00:00
To run Ansible against your Vagrant guest, the basic `Vagrantfile` configuration looks like:
2015-01-13 18:08:46 +00:00
2015-02-10 14:28:00 +00:00
```ruby
2016-02-02 14:43:28 +00:00
Vagrant.configure("2") do |config|
2013-09-03 18:08:28 +00:00
2015-02-10 14:28:00 +00:00
#
# Run Ansible from the Vagrant Host
#
config.vm.provision "ansible" do |ansible|
ansible.playbook = "playbook.yml"
end
2013-09-03 18:08:28 +00:00
2015-02-10 14:28:00 +00:00
end
2013-09-03 18:08:28 +00:00
```
2015-02-10 14:28:00 +00:00
## Options
2015-01-13 18:08:46 +00:00
2016-10-21 23:05:50 +00:00
This section lists the _specific_ options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners ](/docs/provisioning/ansible_common.html ).
2014-02-03 10:45:03 +00:00
provisioners/ansible(both): Add compatibility mode
With this change, it is now possible to get rid of many deprecation
messages successively introduced in Ansible 1.9, and 2.0. More
interesting, the generated inventory will contain the recommended
variable names (e.g. `ansible_host` instead of `ansible_ssh_host`)
when the compatibility mode is set to '2.0'.
Details:
- Add `compatibility_mode` option to control the Ansible parameters
format to be used. The value corresponds to the minimal version
supported. For the moment, possible values are '1.8' (corresponding to
Vagrant's former behaviour) or '2.0'.
Note that a dynamic inventory generated in compatibility mode '2.0'
is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far
supports inventory format generated by the compatibility mode '1.8'.
- Add compatibility mode auto-detection, based on the available Ansible
version. This is the default behaviour in order to bring a maximum of
user friendliness. The drawback of this approach is to let potential
compatibility breaking risks, for `ansible` provisioner setups that
already integrate Ansible 2.x **AND** rely on the existence of
the generated `_ssh` variable names. Thanks to the vagrant warnings
(and its release notes), I argue that it is worth to offer
auto-detection by default, which offers a sweet transition to most
users.
- Add `become`, `become_user` and `ask_become_pass` options and their
backwards compatible aliases. The legacy options are now deprecated.
Note that we intentionally didn't provide a '1.9' compatibility mode,
as it would add extra-complexity for practically no added-value.
To my knowledge, the Ansible 2.x series haven't introduced yet any major
changes or deprecations that would motivate to introduce a higher
version compatibility mode (to be confirmed/verified).
Resolve GH-6570
Still Pending:
- Optimization: Reduce the number of `ansible` command executions.
Currently two exec calls will be performed when the compatibility
mode auto-detection is enabled (i.e. by default). We could make the
provisioner a little bit smarter to only execute `ansible` only once
in any situation (by combining "presence" and "version" checks).
- User-friendliness: Add better validator on `compatibility_mode`
option, and shows a warning or an error instead of the silent
fallback on the auto-detection modus.
- Test coverage: All the added behaviours are not fully covered yet.
2016-11-13 19:58:26 +00:00
- `ask_become_pass` (boolean) - require Ansible to [prompt for a password ](https://docs.ansible.com/intro_getting_started.html#remote-connection-information ) when switching to another user with the [become/sudo mechanism ](http://docs.ansible.com/ansible/become.html ).
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
The default value is `false` .
2013-09-03 18:08:28 +00:00
provisioners/ansible(both): Add compatibility mode
With this change, it is now possible to get rid of many deprecation
messages successively introduced in Ansible 1.9, and 2.0. More
interesting, the generated inventory will contain the recommended
variable names (e.g. `ansible_host` instead of `ansible_ssh_host`)
when the compatibility mode is set to '2.0'.
Details:
- Add `compatibility_mode` option to control the Ansible parameters
format to be used. The value corresponds to the minimal version
supported. For the moment, possible values are '1.8' (corresponding to
Vagrant's former behaviour) or '2.0'.
Note that a dynamic inventory generated in compatibility mode '2.0'
is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far
supports inventory format generated by the compatibility mode '1.8'.
- Add compatibility mode auto-detection, based on the available Ansible
version. This is the default behaviour in order to bring a maximum of
user friendliness. The drawback of this approach is to let potential
compatibility breaking risks, for `ansible` provisioner setups that
already integrate Ansible 2.x **AND** rely on the existence of
the generated `_ssh` variable names. Thanks to the vagrant warnings
(and its release notes), I argue that it is worth to offer
auto-detection by default, which offers a sweet transition to most
users.
- Add `become`, `become_user` and `ask_become_pass` options and their
backwards compatible aliases. The legacy options are now deprecated.
Note that we intentionally didn't provide a '1.9' compatibility mode,
as it would add extra-complexity for practically no added-value.
To my knowledge, the Ansible 2.x series haven't introduced yet any major
changes or deprecations that would motivate to introduce a higher
version compatibility mode (to be confirmed/verified).
Resolve GH-6570
Still Pending:
- Optimization: Reduce the number of `ansible` command executions.
Currently two exec calls will be performed when the compatibility
mode auto-detection is enabled (i.e. by default). We could make the
provisioner a little bit smarter to only execute `ansible` only once
in any situation (by combining "presence" and "version" checks).
- User-friendliness: Add better validator on `compatibility_mode`
option, and shows a warning or an error instead of the silent
fallback on the auto-detection modus.
- Test coverage: All the added behaviours are not fully covered yet.
2016-11-13 19:58:26 +00:00
- `ask_sudo_pass` (boolean) - Backwards compatible alias for the [ask_become_pass ](#ask_become_pass ) option.
< div class = "alert alert-warning" >
< strong > Deprecation:< / strong >
The `ask_sudo_pass` option is deprecated and will be removed in a future release. Please use the [**`ask_become_pass`** ](#ask_become_pass ) option instead.
< / div >
2016-01-19 18:08:53 +00:00
- `ask_vault_pass` (boolean) - require Ansible to [prompt for a vault password ](https://docs.ansible.com/playbooks_vault.html#vault ).
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
The default value is `false` .
2013-09-03 18:08:28 +00:00
2016-01-19 18:08:53 +00:00
- `force_remote_user` (boolean) - require Vagrant to set the `ansible_ssh_user` setting in the generated inventory, or as an extra variable when a static inventory is used. All the Ansible `remote_user` parameters will then be overridden by the value of `config.ssh.username` of the [Vagrant SSH Settings ](/docs/vagrantfile/ssh_settings.html ).
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
If this option is set to `false` Vagrant will set the Vagrant SSH username as a default Ansible remote user, but `remote_user` parameters of your Ansible plays or tasks will still be taken into account and thus override the Vagrant configuration.
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
The default value is `true` .
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
**Note:** This option was introduced in Vagrant 1.8.0. Previous Vagrant versions behave like if this option was set to `false` .
2013-09-03 18:08:28 +00:00
2016-01-19 18:08:53 +00:00
- `host_key_checking` (boolean) - require Ansible to [enable SSH host key checking ](https://docs.ansible.com/intro_getting_started.html#host-key-checking ).
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
The default value is `false` .
2013-09-03 18:08:28 +00:00
2015-02-10 14:28:00 +00:00
- `raw_ssh_args` (array of strings) - require Ansible to apply a list of OpenSSH client options.
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
Example: `['-o ControlMaster=no']` .
2013-09-03 18:08:28 +00:00
2016-06-08 21:44:58 +00:00
It is an *unsafe wildcard* that can be used to pass additional SSH settings to Ansible via `ANSIBLE_SSH_ARGS` environment variable, overriding any other SSH arguments (e.g. defined in an [`ansible.cfg` configuration file ](https://docs.ansible.com/intro_configuration.html#ssh-args )).
2014-02-17 21:36:46 +00:00
## Tips and Tricks
### Ansible Parallel Execution
2016-01-19 18:08:53 +00:00
Vagrant is designed to provision [multi-machine environments ](/docs/multi-machine ) in sequence, but the following configuration pattern can be used to take advantage of Ansible parallelism:
2014-02-17 21:36:46 +00:00
2016-01-19 18:08:53 +00:00
```ruby
2015-06-07 15:59:33 +00:00
# Vagrant 1.7+ automatically inserts a different
# insecure keypair for each new VM created. The easiest way
# to use the same keypair for all the machines is to disable
# this feature and rely on the legacy insecure key.
# config.ssh.insert_key = false
#
# Note:
# As of Vagrant 1.7.3, it is no longer necessary to disable
# the keypair creation when using the auto-generated inventory.
N = 3
(1..N).each do |machine_id|
config.vm.define "machine#{machine_id}" do |machine|
machine.vm.hostname = "machine#{machine_id}"
machine.vm.network "private_network", ip: "192.168.77.#{20+machine_id}"
2015-07-10 15:36:05 +00:00
# Only execute once the Ansible provisioner,
# when all the machines are up and ready.
2015-06-07 15:59:33 +00:00
if machine_id == N
machine.vm.provision :ansible do |ansible|
2015-07-10 15:36:05 +00:00
# Disable default limit to connect to all the machines
2016-01-19 18:08:53 +00:00
ansible.limit = "all"
2015-07-10 15:36:05 +00:00
ansible.playbook = "playbook.yml"
2015-06-07 15:59:33 +00:00
end
end
2014-02-17 21:36:46 +00:00
end
2015-06-07 15:59:33 +00:00
end
```
2014-02-17 21:36:46 +00:00
2015-06-07 15:59:33 +00:00
**Caveats:**
2014-02-17 21:36:46 +00:00
2016-01-19 18:08:53 +00:00
If you apply this parallel provisioning pattern with a static Ansible inventory, you will have to organize the things so that [all the relevant private keys are provided to the `ansible-playbook` command ](https://github.com/mitchellh/vagrant/pull/5765#issuecomment-120247738 ). The same kind of considerations applies if you are using multiple private keys for a same machine (see [`config.ssh.private_key_path` SSH setting ](/docs/vagrantfile/ssh_settings.html )).
2014-02-25 05:57:10 +00:00
2015-06-07 15:59:33 +00:00
### Force Paramiko Connection Mode
The Ansible provisioner is implemented with native OpenSSH support in mind, and there is no official support for [paramiko ](https://github.com/paramiko/paramiko/ ) (A native Python SSHv2 protocol library).
2016-06-02 00:01:10 +00:00
If you really need to use this connection mode though, it is possible to enable paramiko as illustrated in the following configuration examples:
2015-06-07 15:59:33 +00:00
With auto-generated inventory:
```
ansible.raw_arguments = ["--connection=paramiko"]
```
With a custom inventory, the private key must be specified (e.g. via an `ansible.cfg` configuration file, `--private-key` argument, or as part of your inventory file):
```
ansible.inventory_path = "./my-inventory"
ansible.raw_arguments = [
"--connection=paramiko",
"--private-key=/home/.../.vagrant/machines/.../private_key"
]
2016-01-19 18:08:53 +00:00
```