Ansible and Vagrant
The information below is applicable to both Vagrant Ansible provisioners:
ansible
, where Ansible is executed on the Vagrant hostansible_local
, where Ansible is executed on the Vagrant guest
The list of common options for these two provisioners is documented in a separate documentation page.
This documentation page will not go into how to use Ansible or how to write Ansible playbooks, since Ansible is a complete deployment and configuration management system that is beyond the scope of Vagrant documentation.
To learn more about Ansible, please consult the Ansible Documentation Site.
The Playbook File
The first component of a successful Ansible provisioner setup is the Ansible playbook which contains the steps that should be run on the guest. Ansible's playbook documentation goes into great detail on how to author playbooks, and there are a number of tips and tricks that can be applied to use Ansible's powerful features effectively.
A playbook that installs and starts (or restarts) the NTP daemon via YUM looks like:
You can of course target other operating systems that do not have YUM by changing the playbook tasks. Ansible ships with a number of modules that make running otherwise tedious tasks dead simple.
Running Ansible
The playbook
option is strictly required by both Ansible provisioners (ansible
and ansible_local
), as illustrated in this basic Vagrantfile
configuration:
Since an Ansible playbook can include many files, you may also collect the related files in a directory structure like this:
In such an arrangement, the ansible.playbook
path should be adjusted accordingly:
The Inventory File
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.
Auto-Generated Inventory
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 machines it manages, and use it for provisioning machines.
Ansible provisioner example
Example with the ansible
provisioner.
Note that the generated inventory file is stored as part of your local Vagrant environment in
.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory
.
Ansible local provision
Example with the ansible_local
provisioner
Note that the generated inventory file is uploaded to the guest VM in a subdirectory of tmp_path
, e.g. /tmp/vagrant-ansible/inventory/vagrant_ansible_local_inventory
.
Host Variables
As of Vagrant 1.8.0, the host_vars
option can be used to set variables for individual hosts in the generated inventory file (see also the notes on group variables below).
With this configuration example:
Vagrant would generate the following inventory file:
Groups and Group Variables
The groups
option can be used to pass a hash of group names and group members to be included in the generated inventory file.
As of Vagrant 1.8.0, it is also possible to specify group variables, and group members as host ranges (with numeric or alphabetic patterns).
With this configuration example:
Vagrant would generate the following inventory file:
Notes:
Prior to Vagrant 1.7.3, the
ansible_ssh_private_key_file
variable was not set in generated inventory, but passed as command line argument toansible-playbook
command.The generation of group variables blocks (e.g.
[group1:vars]
) is only possible since Vagrant 1.8.0. Note however that setting variables directly in the inventory is not the preferred practice in Ansible. If possible, group (or host) variables should be set inYAML
files stored in thegroup_vars/
orhost_vars/
directories in the playbook (or inventory) directory instead.Unmanaged machines and undefined groups are not added to the inventory, to avoid useless Ansible errors (e.g. unreachable host or undefined child group)
For example,
machine3
andgroup3
in the example below would not be added to the generated inventory file:Host range patterns (numeric and alphabetic ranges) will not be validated by Vagrant. As of Vagrant 1.8.0, host range patterns will be added as group members to the inventory anyway, this might lead to errors in Ansible (e.g unreachable host).
Static Inventory
The second option is for situations where you would like to have more control over the inventory management.
With the inventory_path
option, you can reference a specific inventory resource (e.g. a static inventory file, a dynamic inventory script or even multiple inventories stored in the same directory). Vagrant will then use this inventory information instead of generating it.
A very simple inventory file for use with Vagrant might look like:
Where the above IP address is one set in your Vagrantfile:
Notes:
- The machine names in
Vagrantfile
andansible.inventory_path
files should correspond, unless you useansible.limit
option to reference the correct machines. - The
ansible.inventory_path
option by default is only scoped to apply to a single guest in the inventory file, and does not apply to all defined guests. To allow access to all available machines in the inventory, it is necessary to setansible.limit = "all"
. - The SSH host addresses (and ports) must obviously be specified twice, in
Vagrantfile
andansible.inventory_path
files. - Sharing hostnames across Vagrant host and guests might be a good idea (e.g. with some Ansible configuration task, or with a plugin like
vagrant-hostmanager
).
The Ansible Configuration File
Certain settings in Ansible are (only) adjustable via a configuration file, and you might want to ship such a file in your Vagrant project.
When shipping an Ansible configuration file it is good to know that:
- as of Ansible 1.5, the lookup order is the following:
- any path set as
ANSIBLE_CONFIG
environment variable ansible.cfg
in the runtime working directory.ansible.cfg
in the user home directory/etc/ansible/ansible.cfg
- any path set as
- Ansible commands don't look for a configuration file relative to the playbook file location (e.g. in the same directory)
- an
ansible.cfg
file located in the same directory as yourVagrantfile
will be used by default. - it is also possible to reference any other location with the config_file provisioner option. In this case, Vagrant will set the
ANSIBLE_CONFIG
environment variable accordingly.