Ansible - The HowTo's

Ansible can interact with VMware thanks to its vmware_guest module, which has its own list of requirements.

Instead of using a vSphere administrator account that has full permissions on everything, it is preferable that Ansible has its own account, with limited privileges. To do so, you'll have to :

1. Create a newrole :
   1. Menu | Administration | Roles | +
   2. grant the appropriate permissions
2. create a local user account :
   vSphere knows 3 kinds of accounts :

   • domain accounts : defined in an external Active Directory, for instance
   • OS accounts : defined in the underlying Linux (for local services and stuff... ???)
   • web app accounts : local user accounts defined within vSphere itself. These are also called SSO.
   1. Menu | Administration | Users and Groups
   2. open the Users tab
   3. in the Domain select box, pick vsphere.local
   4. enter the login + password + other information
3. Attach the role to the user account :
   1. Menu | Administration | Global Permissions | +
   2. select the user + the role you just created
   3. tick [x] Propagate to children
4. Test ansible connection to vSphere by adding a dedicated task at the beginning of the playbook below.

---
# ANSIBLE_LOCALHOST_WARNING=false ansible-playbook testVmware.yml -DC
- hosts: 127.0.0.1
  connection: local
  gather_facts: no
  vars:
    vcenter:
      structure:
        hostname: 'vcenter.myCompany.tld'
        datacenter: 'MY_DATACENTER'
        cluster: 'MY_CLUSTER'
      account:
        username: 'kevin'
        password: 'P@ssw0rd'
    virtualMachines:
      - name: 'test_VM_made_with_ansible__1'
        folder: '/development'
        state: 'poweredon'
        datastore: 'DS_DEVELOPMENT'
        template: 'TEMPLATE_RHEL8.4'
        hardware:
          memoryMb: 2048
          nbCpu: 1
        networks:
          - name: 'DvS_DEVELOPMENT'
            ip: 10.27.25.23
            netmask: 255.255.255.224
            gateway: 10.27.25.30
          - name: 'DvS_TESTING'
            ip: 10.27.25.200
            netmask: 255.255.255.224
            gateway: 10.27.25.222
        disk:
        - size_gb: 20
          type: thin
        - size_gb: 1			just trying to create a VM with more disks that the template
          type: thin

      - name: 'test_VM_made_with_ansible__2'
        folder: '/development'
        state: 'poweredon'
        datastore: 'DS_DEVELOPMENT'
        template: 'TEMPLATE_RHEL8.4'
        hardware:
          memoryMb: 2048
          nbCpu: 1
        disk:
        - size_gb: 21			can the 1st disk be larger than the one specified in the template ?
          type: thin
        - size_gb: 2
          type: thin
        networks:
          - name: 'DvS_DEVELOPMENT'
            ip: 10.27.25.24
            netmask: 255.255.255.224
            gateway: 10.27.25.30
          - name: 'DvS_TESTING'
            ip: 10.27.25.201
            netmask: 255.255.255.224
            gateway: 10.27.25.222

  tasks:

  - name: Test connection to vCenter
    vmware_vm_facts:
      hostname: "{{ vcenter.structure.hostname }}"
      username: "{{ vcenter.account.username }}"
      password: "{{ vcenter.account.password }}"
      validate_certs: no

  - name: "Delete all the VMs"			so that I can start clean each time I execute this playbook
    vmware_guest:
      hostname: "{{ vcenter.structure.hostname }}"
      username: "{{ vcenter.account.username }}"
      password: "{{ vcenter.account.password }}"
      validate_certs: no
      name: "{{ vm.name }}"
      state: absent
      force: yes				necessary when trying to delete a powered on VM
    loop:
      "{{ virtualMachines }}"
    loop_control:
      loop_var: vm

  - name: "Create virtual machines"
    vmware_guest:
      hostname: "{{ vcenter.structure.hostname }}"
      username: "{{ vcenter.account.username }}"
      password: "{{ vcenter.account.password }}"
      validate_certs: no
      datacenter: "{{ vcenter.structure.datacenter }}"
      cluster: "{{ vcenter.structure.cluster }}"
      name: "{{ vm.name }}"
      folder: "{{ vm.folder }}"
      state: "{{ vm.state }}"
      datastore: "{{ vm.datastore }}"
      disk: "{{ vm.disk }}"
      hardware:
        memory_mb: "{{ vm.hardware.memoryMb }}"
        num_cpus: "{{ vm.hardware.nbCpu }}"
        scsi: paravirtual
      networks: "{{ vm.networks }}"
      template: "{{ vm.template }}
    loop:
      "{{ virtualMachines }}"
    loop_control:
      loop_var: vm
...

• if a newly created VM only boots in Emergency Mode :
  • you should see an error message suggesting things like running journalctl -xb to have an idea of what's going on
  • if your VM has less disks than the template used to build it, its /etc/fstab will refer to a missing disk, causing the Emergency Mode. Just comment the extra disk(s) and the VM will boot normally
• about disks :
  • a VM can have more disks than the template used to build it
  • a VM disk size can be equal or greater than the size of the corresponding template disk but not smaller
  • about the datastore parameter :
    • despite the per-disk value, all disks of a VM will be created on the same datastore than the first disk, whatever value is given to this parameter for the 2^nd (and next) disk(s) (including a non-existing datastore name)
    • changing its value on an existing VM :
      • will NOT affect the disk(s)
      • the corresponding task will have a ok (no change) status
  • not sure whether it is possible to remove a disk from an existing VM
• about templates :
  • before using my own RHEL 8.4 template in my playbook, I had to :
    1. download a RHEL 8.4 DVD ISO
    2. upload it to our ISO datastore
    3. manually create a VM in vSphere
    4. perform a minimal install on this VM
    5. clone this VM into a template
    but I could not customize the VMs built with this template : the main symptom was that the network starts disconnected after deploying a VM.

---
#	ANSIBLE_LOCALHOST_WARNING=false ansible-playbook test.yml
- hosts: 127.0.0.1
  connection: local
  gather_facts: no

  vars:
    myList: [ 'a', 'b', 'c', '4', 'd', '9' ]
    groceryList: [ 'fruit', 'vegetables', 'milk', 'FAT', 'SALT', 'SUGAR' ]
    unhealthyFood: [ 'FAT', 'SALT', 'SUGAR' ]

  tasks:

  - set_fact:
      rejectSingleItem: "{{ myList | reject('search', '4') | list }}"
      rejectNonMatching: "{{ myList | reject('match', '[^a-z]') | list }}"
      healthyGroceryList_forLoop: "[ {% for item in groceryList if item not in unhealthyFood %}'{{ item }}'{{ ', ' if not loop.last else '' }}{% endfor %} ]"
      healthyGroceryList_reject: "{{ groceryList | reject('in', unhealthyFood) | list }}"
      healthyGroceryList_difference: "{{ groceryList | difference(unhealthyFood) }}"

  - debug:
      var: "{{ item }}"
    loop:
      - rejectSingleItem
      - rejectNonMatching
      - healthyGroceryList_forLoop
      - healthyGroceryList_reject
      - healthyGroceryList_difference
...

TASK [debug] *****************************************************
ok: [127.0.0.1] => (item=rejectSingleItem) => {
    "ansible_loop_var": "item",
    "item": "rejectSingleItem",
    "rejectSingleItem": [
        "a",
        "b",
        "c",
        "d",
        "9"
    ]
}
ok: [127.0.0.1] => (item=rejectNonMatching) => {
    "ansible_loop_var": "item",
    "item": "rejectNonMatching",
    "rejectNonMatching": [
        "a",
        "b",
        "c",
        "d"
    ]
}
ok: [127.0.0.1] => (item=healthyGroceryList_forLoop) => {
    "ansible_loop_var": "item",
    "healthyGroceryList_forLoop": [
        "fruit",
        "vegetables",
        "milk"
    ],
    "item": "healthyGroceryList_forLoop"
}
ok: [127.0.0.1] => (item=healthyGroceryList_reject) => {
    "ansible_loop_var": "item",
    "healthyGroceryList_reject": [
        "fruit",
        "vegetables",
        "milk"
    ],
    "item": "healthyGroceryList_reject"
}
ok: [127.0.0.1] => (item=healthyGroceryList_difference) => {
    "ansible_loop_var": "item",
    "healthyGroceryList_difference": [
        "fruit",
        "vegetables",
        "milk"
    ],
    "item": "healthyGroceryList_difference"
}

• The in test was added in Jinja2 2.10 (unfold Changelog or see changelog in release notes), so you may not be up-to-date.
• Check it :
  dpkg -l | grep jinja2

Examples below :

• are given in the context of ad-hoc commands, but you should get the idea very easily to use them in a play
• specify no inventory file, which is ok as long as its name can be determined implicitly (default name, default location, specified in a personal settings file, ...). Otherwise, specify it explicitly with -i :
  ansible -i myInventoryFile
• should also apply to the --limit directive

Target	Syntax	Comment
by name
a list of hosts	ansible host1,host2,host3
a list of hosts matching a regular expression	ansible '~server0[12]\.acme\.org'	matches server01.acme.org and server02.acme.org make sure you're not limiting the effective target with the ansible-playbook -l flag
by group
all hosts of a single group	ansible groupName
all hosts known to Ansible	ansible all
hosts of several groups	ansible group1:group2:group3	The colon : actually means a logical OR. This command above applies to any host belonging either to group1 or to group2 or to group3 When it comes to complex rules with intersections and exclusions (see examples), it may not be a REAL "logical OR"
hosts belonging to the 2 specified groups	ansible 'group1:&group2'	aka intersection of groups
by name + group
all hosts except those matching an expression	ansible 'all:!expression*' ansible 'groupName:!badHost'	can be an expression with a wildcard or a regular expression the whole !... string must be single-quoted (details)
all hosts of a group except several of them	ansible 'groupName:!~(host1|host2)'	~ is used to introduce a regular expression you get the idea to exclude as many hosts as necessary

- hosts: 127.0.0.1
  connection: local
  gather_facts: no
  tasks:

  - set_fact:
      fruits: [
        'apple',
        'orange',
        'banana',
        ]

  - debug:
      var: item
    loop:
      - fruits

  - debug:
      var: item
    loop:
      - "{{ fruits }}"

  - debug:
      var: item
    loop:
      "{{ fruits }}"

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=fruits) => {
    "item": "fruits"
}

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=[u'apple', u'orange', u'banana']) => {
    "item": [
        "apple",
        "orange",
        "banana"
    ]
}

TASK [debug] ********************************************************************
ok: [127.0.0.1] => (item=apple) => {
    "item": "apple"
}
ok: [127.0.0.1] => (item=orange) => {
    "item": "orange"
}
ok: [127.0.0.1] => (item=banana) => {
    "item": "banana"
}

- fruits

• this passes the string fruits, not the fruits variable
• use "{{ }}" to pass a variable

- "{{ fruits }}"

• the leading dash - introduces a list item
• _HERE_ it's a one-item list, and this item happens to be a list
• Anyway, this is why the loop turns only once and displays all fruits at once

"{{ fruits }}"

this is what we expected

So far, I've found no exception to this rule : when using fail, the playbook execution stops. Period.
However, I've been amazed once, when —despite fail— the execution continued (... or at least _seemed_ to continue). Here's what happened then :

1. RedHat.yml is a role task file having a fail task, everything should go extremely well
2. the role RedHat.yml belongs to is applied by myPlaybook.yml
3. I run myPlaybook.yml on a group of hosts (myGroup has MANY hosts) :
   ansible-playbook myPlaybook.yml -l myGroup
4. the execution starts normally, I can see a series of expected fatal: [hostname]: FAILED! => {"changed": false, "msg": "Execution stopped on purpose for whatever reason"}, then the output continues with the following tasks ()

Explanation (this is highly specific to my context / code) :

1. when myPlaybook.yml starts running the role having the RedHat.yml task file, it starts executing main.yml
2. main.yml makes a conditional include_tasks of RedHat.yml, meaning some hosts get it, some don't. This is where the trick happens :
   • RedHat.yml is included by Red Hat servers
   • but there is also Debian.yml, with a similar set of tasks (hence tasks names) for Debian servers
3. the hosts who actually included RedHat.yml fail as expected (and are removed from the list of the playbook targets)
4. the other hosts continue normally, which is what I can see
   the tasks running at that time are not from RedHat.yml anymore but from Debian.yml
5. reasons why I've not been able to see what was happening :
   • large number of hosts in myGroup : the execution lists all of them and scrolls fast
   • cryptic hostnames : pretty difficult to spot that some hosts have disappeared after the fail
   • identical task names in RedHat.yml and in Debian.yml : when the playbook execution showed the name of the task right after the fail, I thought the execution of the task I edited file continued.