So far this week has been very productive and exciting. There are still many things up in the air right now, but my priority for this week is to integrate Ansible Tower with the vCenter, create spin up and provision a windows 2012R2 server.
I started the week by upgrading Tower from 2.4.5 to 3.0.1. Running the ./setup.sh took it right through without a hitch. Logging into the tower front end I was pleased with the cleaner more professional dashboard and icons. Not just that but the layouts of some of the forms are far better than in previous versions. Well done RedHat!
Ops gave me my own vCenter to play with last week and with only 11 days left of my tower license I felt it prudent to get cracking. As I have come to expect from Ansible, the documentation was clear enough with good examples that I could copy and paste into a playbook. Edited in Atom and pushed into the git repository I was good to go.
The tower project has already been set up to point to a locally hosted bitbucket SCM and when I created my first test playbook to create the vcenter guest, it pulled those changes and I was able to select the playbook in the job template.
To generate the right amount of dynamic information for the vSphere guest I have added fields to the custom survey. Some already filled in but available to edit. But on my first run, I hit a snag. It told me I had to install pysphere.
pip install pysphere
Run again and now it’s cooking. After about 5 minutes, it passed and going into my vSphere client it had indeed created the guest VM from the predefined template Ops put there.
This is a successful first stage but still a ways to go. I still have to provision the guest!
Initially the Guest is sitting there with no network connectivity. The vCenter resides in a server VLAN which does not have access to a DHCP server. So the box automatically picks a 169 address. How do you get an IP address onto a guest VM which can’t be connected to directly from Ansible Tower?
Some emails to redhat and googling brought me up with the wonderful module vmware_vm_shell. Ok! Now we’re talking. I now have a way to interface with the guest through vCenter direct to it’s shell.
Before I continue, I will mention another dependancy. vmware_vm_shell uses pyVmomi so you will have to install that.
pip install pyvmomi
We can now access PowerShell and set the IP address through that with this handy role and one liner :
- name: Configure IP address local_action: module: vmware_vm_shell hostname:"{{ vcenter_hostname }}" username: "{{ vcenter_username }}" password: "{{ vcenter_password }}" datacenter: "{{ vcenter_datacenter }}" vm_id: "{{ vguest_name }}" vm_username: {{ vguest_admin }} vm_password: {{ vguest_password }} vm_shell: "C:\Windows\System32\WindowsPowershell.0\powershell.exe" vm_shell_args: " -command (Get-NetAdapter -Name Ethernet |New-NetIPAddress -InterfaceAlias Ethernet -AddressFamily IPv4 -IPAddress {{ vguest_ipv4 }} -PrefixLength {{ vguest_mask }} -DefaultGateway {{ vguest_gateway}} )-and (Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses {{ vguest_dns }})" vm_shell_cwd: "C:\Windows\Temp"
Now we have an IP address on the Windows server, Ansible can talk to it. Or can it?
In my earlier experiments with vagrant and ansible, one of the first things I did in the provisioning shell command was to run a WinRM PowerSHell script to enable PowerShell remoting. And we hit another hurdle. The vCenter I’m developing against does not have access to the domain, so I’m stuck for accessing any network resources. But I have to run a powershell script on the guest, which is in the playbook assets on the tower server.
It’s a multiple line shell script so I can’t just pass it through the args on vm_shell. Or can I?
Turns out I can. Placing the ConfigureRemotingForAnsible.ps1 script into the $role/files directory makes it available to the role for funky things like I’m about to do.
So as not to duplicate the above block I added a with_items and moved the shell_args I’d written earlier into the list to join it’s siblings :
vm_shell_args: {{ item }} vm_shell_cwd: "C:\Windows\Temp" with_items: - " -command (Get-NetAdapter -Name........" - " -command @' lookup('file', 'files/ConfigureRemotingForAnsble.ps1') '@ | Set-Content ConfigureRemotingForAnsible.ps1" - " -File ConfigureRemotingForAnsible.ps1"
Lets talk about what I’ve done here and why the 2nd command looks so odd. You’ll notice that I’m using something called a Here-String (which is what the @’ ‘@ is all about. This allows you to insert formatted multi line text into a variable. But why the double line feed?
Ansible tower should be running on a Centos 7 box. If you managed to get it running on Ubuntu then well done you, but I didn’t have the time to figure it out so Centos 7 is what I’m working on. Windows and Linux handle line feeds and carriage returns differently so this is why you get all kinds of odd behaviour opening up some files in Notepad that look fine in other editors.
The Here-String requires you to start the text block on a new line (at least on 2012R2 it does) but because of the LR/LF discrepancy, a single feed to windows would be classed as the same line. So double feed and you now have a Here-String that is piped into Set-Content and stored in a .ps1 in the C:\Windows\Temp folder.
The 3rd line then runs that file, setting up the PowerShell remoting. It sounds easy, but believe me, it took me the better half of the day to get this figured out.
Final step was to prove that Ansible could provision the Guest environment. Again not a straight forward task, but with a very easy solution. The simplest method of provisioning is to add a feature. There is already an IIS example on win_feature so I copied it into a new role and added the role to the create playbook. But this is not going to work. This is because currently the playbook is using Hosts: localhost but we need to point it to the guest for the next stage of provisioning.
This is how my top level playbook looks :
---
- hosts {{ target_host }} # set to localhost
gather_facts: no
roles:
- vsphere
- networking
- gather_facts
- hosts: virtual
roles:
install_iis
Did I just change hosts in the middle of a playbook? I done did! Yes you can change hosts in the middle of the playbook. But where does it get the virutal hosts from?
See the 3rd role in the 1st block? Gather_facts. There’s a neat trick I did here.
- vsphere_guest:
vcenter_hostname: "{{ vcenter_hostname }}"
username: "{{ vcenter_username }}"
password: "{{ vcenter_password }}"
guest: "{{ vguest_name }}"
vmware_guest_facts: yes
- name: Add Guest to virtual host group
add_host: name="{{hw_eth0.ipaddresses[0]}}" groups="virtual"
Using the same vsphere_guest module, I got facts about the guest, and used those facts to add it dynamically to the virtual host group. Theoretically I could have gotten it from the variable {{ vguest_ipv4 }} but this way looks a lot more awesome.
We’re not out of the woods yet though. Simply trying to add the guest to the virtual group won’t get you a connection. It will try to connect, but with ssh. We need to remind Ansible that this is a winrm connection. The best way to do that is with group_vars. Create a new $projectroot/group_vars/virtual.yml and add this option
--- ansible_ssh_connection: winrm
No further configuration needed after that and ansible tower connects to the guest via winrm over IP and without as much as breaking a sweat added via the win_feature module an IIS server.
- name: Install IIS win_feature: name: "Web-Server" state: present restart: yes include_sub_features: yes include_management_tools: yes
So in summary I now have :
- Ansible tower running on a Linux Centos 7 server
- Communicating to a vmware vcenter hypervisor
- Pulling playbooks for a locally hosted bitbucket (stash)
- Spinning up a Guest VM from an existing template
- Setting up the IP credentials
- Enabling powershell remoting
- Adding features
All with a few clicks of a mouse button. I would say that today has been a good day.