Ansible/VMware modules - first steps
Overview
Ansible is a well known software to automates software provisioning, configuration management, and application deployment. In concrete terms, it's possible to manage infrastructure deployment and configuration during life cycle from sets of configuration files.
In the following post, I will try to explain how to use it with some VMware modules from ansible installation to the management of a vCenter based infrastructure.
Ansible installation
I suggest to use Ansible from the github repository to be able to use the most recent modules from the repository as there is a lot of work in progress on the VMware related modules:
1git clone https://github.com/ansible/ansible.git && cd ansible/
Personally, I prefer to use a python virtual environment to manage a test or stable environment:
1sudo pip install virtualenv
2virtualenv --system-site-packages venv
3. venv/bin/activate
Install the ansible requirements, and the VMware python sdk:
1pip install -r requirements.txt
2pip install pyvmomi
We are now ready to use ansible with VMware modules.
Ansible usage with VMware vCenter
The following sample consist of VM deployment in a existing vCenter infrastructure from a linked-clone operation.
A linked clone is made from a snapshot of the parent. All files available on the parent at the moment of the snapshot continue to remain available to the linked clone. Ongoing changes to the virtual disk of the parent do not affect the linked clone, and changes to the disk of the linked clone do not affect the parent.
Inventory
We will create a simple inventory with virtual machines items representing a scalable 2 tiers application with:
- web frontend
- backend workers
1 [10.10.10.107.0/24] External Network
2 +--------------------+-------------+-------------------+
3 | |
4 | |
5 +-----+----+ +-----+----+
6 | | | |
7 | | | |
8 | Web | | Web |
9 | Frontend | | Frontend |
10 | # 1 | | # 2 |
11 | | | |
12 | | | |
13 +-----+----+ +-----+----+
14 | |
15 [10.10.10.108.0/24] | | Internal Network
16 +----------+---------+----+--------+-----+-------------+
17 | | |
18 | | |
19 +----+----+ +----+----+ +----+----+
20 | | | | | |
21 | | | | | |
22 | Backend | | Backend | | Backend |
23 | Worker | | Worker | | Worker |
24 | # 1 | | # 2 | | # 3 |
25 | | | | | |
26 | | | | | |
27 +---------+ +---------+ +---------+
To simplify the sample, all virtual machines will not be configured at the application level: we will only cover the deployment of new VM with OS ready for usage.
We create an INI-like (one of Ansible's defaults) inventory file named sample-app01.inv with the following content:
1[frontweb]
2web01 ip="10.10.107.1"
3web02 ip="10.10.107.2"
4
5[workers]
6worker01 ip="10.10.108.1"
7worker02 ip="10.10.108.2"
8worker03 ip="10.10.108.3"
9
10[app01:vars]
11datastore='Datastore01'
12memory='256'
13cpucount='1'
14guest_id='ubuntu64Guest'
15folder='app01'
16respool='prod'
17snapshot_name='20180129'
18dns_domain='lri.lcl'
19netmask='255.255.255.0'
20dns_server='10.10.10.99'
21os_password='VMware1!'
22datacenter='DC-Rennes'
23cluster='Cust01'
24
25[frontweb:vars]
26network1='pg_frontweb'
27network2='pg_frontweb'
28gateway='10.10.107.254'
29template='LinkedCloneRef_Ubuntu16.04_frontweb'
30
31[workers:vars]
32network1='pg_backend'
33gateway='10.10.108.254'
34template='LinkedCloneRef_Ubuntu16.04_worker'
In the sample inventory file we have:
- A frontend and workers categories with details about hosts members (including a specific parameters for each one: the IP address):
[frontweb]+[workers] - An app01 category including both frontend and workers sub categories:
[app01:children] - a group a variables used for all the app01 members:
[app01:vars] - a group a variables used for frontweb members
- a group a variables used for backend members
Playbook
From Ansible Docs about Playbooks:
Playbooks are Ansible's configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process. If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material.
Dynamic input for some values
To manage VM in the vCenter inventory, it's necessary to have credentials for the target. In the following playbook part, we ask user to enter credentials when running the playbook:
1---
2- name: Credentials for vCenter API
3 hosts:
4 - workers
5 - frontweb
6 gather_facts: no
7 vars_prompt:
8 - name: "vcenter_hostname_tmp"
9 prompt: "Enter vcenter hostname"
10 default: "vcsa01-rennes.lri.lcl"
11 - name: "vcenter_user_tmp"
12 prompt: "Enter vcenter username"
13 default: "administrator@vsphere.local"
14 - name: "vcenter_pass_tmp"
15 prompt: "Enter vcenter password"
16 private: yes
17
18 tasks:
19 - set_fact:
20 vcenter_hostname: "{{ vcenter_hostname_tmp }}"
21 vcenter_user : "{{ vcenter_user_tmp }}"
22 vcenter_pass : "{{ vcenter_pass_tmp }}"
This playbook part will be applied for both workers and frontweb servers and we set up global facts to be used in other parts of the playbook.
Clone specification with vmware_guest module
Ansible's vmware_guest module is used to manages virtual machines in vCenter or standalone ESXi. It allows to check the presence and configuration of VM and to proceed changes according to the result: clone, reconfiguration...
Here is a sample task based on the vmware_guest to deploy a worker's VM from a linked-clone operation:
1- hosts: workers
2 gather_facts: no
3 connection: local
4
5 tasks:
6 - name: Deploy workers nodes
7 vmware_guest:
8 hostname: "{{ vcenter_hostname }}"
9 username: "{{ vcenter_user }}"
10 password: "{{ vcenter_pass }}"
11 name: "{{ inventory_hostname }}"
12 datacenter: "{{ datacenter }}"
13 cluster: "{{ cluster }}"
14 state: poweredon
15 template: '{{ template }}'
16 resource_pool: '{{ respool }}'
17 validate_certs: no
18 folder: "{{ datacenter }}/vm/{{ folder }}"
19 guest_id: "{{ guest_id }}"
20 networks:
21 - name: "{{ network1 }}"
22 ip: "{{ ip1 }}"
23 netmask: "{{ netmask }}"
24 gateway: "{{ gateway }}"
25 device_type: "vmxnet3"
26 dns_servers:
27 - "{{ dns_server }}"
28 snapshot_src: "{{ snapshot_name }}"
29 linked_clone: yes
30 customization:
31 dns_servers:
32 - "{{ dns_server }}"
33 domain: "{{ dns_domain }}"
34 dns_suffix: "{{ dns_domain }}"
35 password: "{{ os_password }}"
36 wait_for_ip_address: yes
We do the same for the frontweb servers with 2 network attachement. See this gist for the full playbook content : file-create_linked_vms_2tiers-yml.
Run an Ansible playbook on inventory
To run the playbook:
1./bin/ansible-playbook -i sample-app01.inv create_linked_vms_2tiers.yml
2Enter vcenter hostname [vcsa01-rennes.lri.lcl]:
3Enter vcenter username [administrator@vsphere.local]:
4Enter vcenter password :
5
6PLAY [Credentials for vCenter API] *****************************************************************
7
8TASK [set_fact] ************************************************************************************
9ok: [worker01]
10ok: [worker02]
11ok: [worker03]
12ok: [web01]
13ok: [web02]
In the first part of the execution, credentials are requested to continue. Then Ansible will check if inventory VM's are well poweredon are requested in the playbook and if not, will start creation task :
1PLAY [workers] *************************************************************************************
2
3TASK [Deploy workers nodes] ************************************************************************
4changed: [worker03]
5changed: [worker02]
6changed: [worker01]
7
8PLAY [frontweb] ************************************************************************************
9
10TASK [Deploy frontweb nodes] ***********************************************************************
11changed: [web01]
12changed: [web02]
13
14PLAY RECAP *****************************************************************************************
15web01 : ok=2 changed=1 unreachable=0 failed=0
16web02 : ok=2 changed=1 unreachable=0 failed=0
17worker01 : ok=2 changed=1 unreachable=0 failed=0
18worker02 : ok=2 changed=1 unreachable=0 failed=0
19worker03 : ok=2 changed=1 unreachable=0 failed=0
Idempotency
Modules should be idempotent, that is, running a module multiple times in a sequence should have the same effect as running it just once. One way to achieve idempotency is to have a module check whether its desired final state has already been achieved, and if that state has been achieved, to exit without performing any actions. If all the modules a playbook uses are idempotent, then the playbook itself is likely to be idempotent, so re-running the playbook should be safe.
In our case, if VMs are already present, re-run the playbook with same settings won't produce new changes.
By replacing the state: poweredon by state: absent for VMs, it's possible to unprovision the deployed infrastructure.
In the next post(s) I will try to explain the management of vCenter and ESXi hosts configuration through ansible playbooks.