haskal
/
vagrant
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

provisioners/ansible: Document new default limit 

- explain new default ansible.limit
- shift `ansible.groups` part to Inventory section
- change/add inventory examples
This commit is contained in:
Gilles Cornu 2014-02-03 11:45:03 +01:00
parent 466cf58476
commit b723f0d43d
1 changed files with 49 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
website/docs/source/v2/provisioning/ansible.html.md
View File

@ -29,20 +29,54 @@ a single page of documentation.
When using Ansible, it needs to know on which machines a given playbook should run. It does
this by way of an inventory file which lists those machines. In the context of Vagrant,
there are two ways to approach working with inventory files. The first and simplest option
is to not provide one to Vagrant at all. Vagrant will generate an inventory file encompassing
all of the virtual machine it manages, and use it for provisioning machines. The generated
inventory file is created adjacent to your Vagrantfile, named `vagrant_ansible_inventory`.
there are two ways to approach working with inventory files.
The second option is for situations where you'd like to have more control over the inventory file,
perhaps leveraging more complex playbooks or inventory grouping. If you provide the
`ansible.inventory_path` option referencing a specific inventory file dedicated to your Vagrant
project, that one will be used instead of generating them. Such an inventory file for use with
Vagrant might look like:
The first and simplest option is to not provide one to Vagrant at all. Vagrant will generate an
inventory file encompassing all of the virtual machine it manages, and use it for provisioning
machines. The generated inventory file is created adjacent to your Vagrantfile, named
`vagrant_ansible_inventory`.
The `ansible.groups` option can be used to pass a hash of group
names and group members to be included in the generated inventory file. For example:
```
[vagrant]
192.168.111.222
ansible.groups = {
"group1" => ["machine1"],
"group2" => ["machine2", "machine3"],
"all_groups:children" => ["group1", "group2", "group3"]
}
```
Note that undefined machines and groups are not added to the inventory.
For example, `group3` in the above example would not be added to the inventory file.
A generated inventory might look like:
```
# Generated by Vagrant
machine1 ansible_ssh_host=127.0.0.1 ansible_ssh_port=2200
machine2 ansible_ssh_host=127.0.0.1 ansible_ssh_port=2201
[group1]
machine1
[group2]
machine2
[all_groups:children]
group1
group2
```
The second option is for situations where you'd like to have more control over the inventory file.
If you provide the `ansible.inventory_path` option referencing a specific inventory file dedicated
to your Vagrant project, that one will be used instead of generating it.
Such an inventory file for use with Vagrant might look like:
```
default ansible_ssh_host=192.168.111.222
```
Where the above IP address is one set in your Vagrantfile:
@ -51,6 +85,9 @@ Where the above IP address is one set in your Vagrantfile:
config.vm.network :private_network, ip: "192.168.111.222"
```
Note that machine names in `Vagrantfile` and `ansible.inventory_path` file should correspond,
unless you use `ansible.limit` option to reference the correct machines.
## Playbook
The second component of a successful Ansible provisioner setup is the Ansible playbook
@ -135,7 +172,7 @@ all of which get passed to the `ansible-playbook` command that ships with Ansibl
* `ansible.sudo_user` can be set to a string containing a username on the guest who should be used
by the sudo command.
* `ansible.ask_sudo_pass` can be set to `true` to require Ansible to prompt for a sudo password.
* `ansible.limit` can be set to a string or an array of machines or groups from the inventory file to further narrow down which hosts are affected.
* `ansible.limit` can be set to a string or an array of machines or groups from the inventory file to further control which hosts are affected (e.g. useful to enable Ansible parallel execution). Note that as Vagrant 1.5, the machine name (taken from Vagrantfile) is set as default limit.
* `ansible.verbose` can be set to increase Ansible's verbosity to obtain detailed logging:
* `'v'`, verbose mode
* `'vv'`
@ -147,14 +184,4 @@ by the sudo command.
* `ansible.raw_arguments` can be set to an array of strings corresponding to a list of `ansible-playbook` arguments (e.g. `['--check', '-M /my/modules']`). It is an *unsafe wildcard* that can be used to apply Ansible options that are not (yet) supported by this Vagrant provisioner. Following precedence rules apply:
* Any supported options (described above) will override conflicting `raw_arguments` value (e.g. `--tags` or `--start-at-task`)
* Vagrant default user authentication can be overridden via `raw_arguments` (with custom values for `--user` and `--private-key`)
* `ansible.groups` can be used to pass a hash of group names and group members to be included in the generated inventory file. For example:
```
ansible.groups = {
"group1" => ["machine1"],
"group2" => ["machine2", "machine3"],
"all_groups:children" => ["group1", "group2", "group3"]
}
```
Note that undefined machines and groups are not added to the inventory. For example, `group3` in the above example would not be added to the inventory file.
* `ansible.host_key_checking` can be set to `false` which will disable host key checking and prevent `"FAILED: (25, 'Inappropriate ioctl for device')"` errors from being reported during provisioner runs. The default value is `true`, which matches the default behavior of Ansible 1.2.1 and later.