I wanted to share some of the example Ansible playbooks used during last Wednesday’s US #vBrownBag. During the show I went over examples of how you can use Ansible to create, clone, and update virtual machines in vCenter without the need for other provisioning tools. Based on my testing (and I’m still learning as well), the items noted in the comments are the bare minimum needed to run the playbook, even though the official documentation may currently state otherwise. If you are already using Ansible for configuration management, this is a handy option to have as you can perform the provisioning tasks without leaving Ansible.
All playbooks have been uploaded to my GitHub Ansible-Test-Playbooks repository (https://github.com/jfrappier/ansible-test-playbooks/).
Posted in Tech Tagged with: #vbrownbag, ansible, ansible with vcenter, automation, clone, Cloud, devops, GitHub, Home, Linux, podcast, professionalvmware.com, provision, Shared, Technology, vcenter, Virtualization, VMware, vSphere
During the #vDM30in30 challenge I started playing with Ansible to get to know it a bit better. One of the things I was curious about is the ability for Ansible to provision virtual machines directly to vCenter. After all if I am using Ansible to manage the configuration of my servers, it would certainly be nice to have a playbook that also deploys my virtual machine, rather than another provisioning tool.
If you don’t already have Ansible up and running, you can get the dependencies installed and Ansible project cloned from GitHub pretty easily with a vanilla CentOS box. Once Ansible is running and you have a playbook or two under your belt you can take a read at the Ansible vsphere_guest docs. This particular module is a bit lacking, I hope to add some updates soon and see if they get accepted.
As they mention in the docs, you will need to have pysphere installed; PySphere being a Python API to support interaction with vSphere/vCenter. PySphere is easy to install if you were able to follow along with my Installing Ansible from Git post; simply run
sudo pip install -U pysphere
With PySphere installed, you are now ready to create your playbook. The playbook example in the Ansible docs seemed to be missing something. Recall from my other posts you typically specify a host (linux box, not vSphere host) in your inventory file and direct the playbook that that host or groups of hosts, for example:
--- - hosts: db remote_user: virtxpert sudo: yes tasks: - name: update mysql-libs-latest yum: pkg=mysql-libs state=latest
But, as you can see in the document ion, you specify the vSphere/ESXi host and vCenter server in the vsphere_guest task. So after a few iterations of trying to get that to work, I came across this page on GitHub. It shows what appears to be essentially dummy text to satisfy the host requirements in the playbook. So my playbook ends up looking like this:
- hosts: 127.0.0.1 connection: local user: root sudo: false gather_facts: false serial: 1 tasks: - vsphere_guest: vcenter_hostname: vxprt-vc01.vxprt.local username: [email protected] password: ******** guest: testansible state: powered_on vm_disk: disk1: size_gb: 1 type: thin datastore: vxprt-esxi01-gold-local vm_nic: nic1: type: vmxnet3 network: vm network_type: standard vm_hardware: memory_mb: 1024 num_cpus: 1 osid: centos64Guest scsi: paravirtual esxi: datacenter: dc01 hostname: vxprt-esxi01.vxprt.local
With this playbook format in place, I am now able to run the playbook and have the virtual machine created in vCenter.
Up next, play around with vars_prompt in place of some of the item names so when the playbook is run, it will prompt the user for input and using Ansible to clone an existing vSphere template.
Now that Nagios Log Server is installed, it’s time to get some log files in there. I got myself all fired up ready to comb through page after page of documentation to figure out how to set it up… then those nice folks over at Nagios did this…
That’s right, if you click on Linux Source from the home screen, it gives you scripts to download and run to set it all up. They even pulled the IP address from the Nagios Log Server…it was like they wanted you to succeed in making this all work! It can’t be that easy right? Let’s try!
That was easy, no way there are actually logs showing up in Nagios Log Server though, right? Almost, SELinux was preventing log files from being shipped as you can see in the middle of the above screenshot. So…
cp /etc/selinux/config /etc/selinux/config.bak && sed -i s/SELINUX=enabled/SELINUX=disabled/g /etc/selinux/config && shutdown now -r
And BOOM goes the log file goodness after a reboot!
In probably less than 5 minutes, you can have a fully functional Nagios Log Server, based on ELK, deployed and receiving log files from a remote source – that is damn impressive. Of course in this example we haven’t looked at which logs we are sending – maybe you only want specific log files being sent from Apache or Ansible for instance, but that is a finer art form that we can save for another blog post. Happy logging!
In my last video, we walked through how to install VMware Tools for CentOS 6.x. Now we are going to prepare the virtual machine for cloning. This requires we remove a specific file; /etc/udev/rules.d/70-persistent-net.rules. This file contains the MAC address for the virtual machine. Once removed, the file will be created during the initial boot with the matching MAC address for the cloned virtual machine.
This is a video demonstration on installing VMware Tools in CentOS 6.x. The assumptions for this walk through are you have access to VMware Workstation or the vSphere Client to initiate the VMware Tools installation and at least 1 E1000 network card to provide internet access. VMware Tools is needed for VMXNET3, so you will at least initially need an E1000 to provide network access for Perl, or local Perl installers to run the installer.
Posted in Tech Tagged with: Home, install vmware tools linux, Linux, network, Shared, Technology, Training, vcenter, Vendors, Virtualization, VMware, vmware tools, vmware tools install, vmware vsphere, vmware workstation, vSphere, workstation