Automate VMware deployments with RedHat Ansible

This article will guide you implement automation on the deployment procedure of a VMware infrastructure. In more detail the ansible project that is listed on the bottom of the page will deploy VMs from a list that you provide on your VMware hypervisor.

The dependencies that are necessary for this solution to work are:

The community.vmware plugin which can be installed with:

ansible-galaxy collection install community.vmware

the PyVmomi package which can be installed with pip or pip3 with the command:

sudo pip3 install pyvmomi

The project consists of the below components:

  • deploy.yml which is the base script that performs the deployment.
  • ansible.cfg and inventory which are not useful for this example
  • secrets.yml which is an ansible vault that contains secrets and passwords
  • vms.yml which is the list of the VMs that we want to create.

You can run the example by using prompt so that you input the ansible vault password.

ansible-playbook deploy.yml --vault-id=@prompt

After the successful run you will get the newly created vms on the folder you specified (in my example ansible folder within the vcenter server)

https://github.com/geralexgr/ansible-vmware

https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_guest_module.html

Authenticate windows servers with Ansible domain user – kerberos configuration

If you try to connect with Ansible on a Windows machine with your active directory account you will get the error -> the specified credentials were rejected by the server

In order to connect through a domain account you should add some inventory variables and also install some additional components.

If you do not have the appropriate libraries installed, you should get the error shown on the below screenshot.

By trying to install kerberos and requests-kerberos through pip3 I got the error that is listed below.

sudo pip3 install requests-kerberos
Command "/usr/bin/python3.6 -u -c "import setuptools, tokenize;file='/tmp/pip-build-2v_1srr8/pykerberos/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /tmp/pip-nkj0fa0v-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-2v_1srr8/pykerberos/

In order to resolve, first upgrade your pip3 setup tools

pip3 install --upgrade setuptools

Install python3-devel package and other required packages

yum -y install gcc python-devel krb5-devel krb5-libs krb5-workstation

Run setup with pip3 once again. The result should be successful.

Your inventory file should contain the below variables:

ansible_user = admin@DOMAIN.COM (capital letters)
ansible_connection = winrm
ansible_winrm_server_cert_validation = ignore
ansible_password = 
ansible_become_user= admin@DOMAIN.COM
ansible_become_method= runas
ansible_winrm_transport = kerberos

You should also edit Kerberos config file:

vi /etc/krb5.conf

Adjust

[logging]
                 // nothing to edit here
 [libdefaults]
     default_realm = DOMAIN.COM (capital letters)
 [realms]
  DOMAIN.COM (capital letters) = {
      kdc = dc1.domain.com
      kdc = dc2.domain.com
      admin_server = dc1.domain.com
  }
 [domain_realm]
  .domain.com = DOMAIN.COM

Grap a session for your user:

kinit -C admin@EXAMPLE.COM

And you finally can communicate with your Windows machines through an Active Directory account.

https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html

Combine Windows and Linux inventory hosts on Ansible for Logging purposes

Lets assume you have configured ansible on multiple Windows hosts in order to massively perform patches installation or execute commands. As explained in detail on my previous articles in order to be successful the connection method must be set as winrm (see below)

 ansible_connection = winrm
 ansible_winrm_server_cert_validation = ignore
 ansible_user = administrator
 ansible_password = 
 ansible_become_user = administrator
 ansible_become_method = runas

However if you state this connection method, you cannot connect to linux machines and delegate tasks. One example of this scenario is a windows patching mechanism with wsus and ansible. You can deploy the patches using winrm method but you cannot log output on your localhost as the connection must be changed to ssh.

In order to bypass this problem I added a new group on my inventory for localhost entry for which I specify the connection method and user

[local]
localhost ansible_connection=ssh ansible_become_user=root ansible_become_method=sudo ansible_user=root

Then one will be able to perform a logging action with the below task.

 name: write output to file
   shell: echo "{{ result.stdout }}" >> /root/ansible/something.log
   delegate_to: localhost 

Result is the registered output of the patching procedure.

I am using shell command in order to append a new entry every time I have a result from my previous actions.

Ansible Privilege Escalation win_command – refresh Windows Update Service

When you have ansible deployed it is easy to perform massively actions on your inventory hosts. On a previous article I have explained in detail how you can easily manage Windows machines with Ansible.

In order to refresh Windows update service and make it connect to WSUS reporting console one should execute the below commands on a range of machines.

wuauclt /resetauthorization
wuauclt /reportnow
wuauclt /detectnow

In order to perform this task automated and avoid logging in on each machine, you can execute the below playbook.

---
- name: deploy commands on servers
 hosts: test
 become: true
 tasks:
 name: win_command resetauth
 win_command: wuauclt /resetauthorization
 name: win_command report
 win_command: wuauclt /reportnow
 name: win_command detect
 win_command: wuauclt /detectnow 

If you run this playbook without elevated privileges, it will fail. The necessary variables that must be included in your inventory or another appropriate location are listed below (folder variables, etc). The become keyword is a must but the escalation method must be changed instead of sudo as we handle windows machines.

 [all:vars]
 ansible_connection = winrm
 ansible_user = administrator
 ansible_become_user=administrator
 ansible_become_method=runas