My colleague and good friend, Jimmy Conner, gave me a demonstration on CI/CD with VMWare, so I did the only logical thing…and copy his presentation. He also contributed some of the playbooks to make it all happen, so big thanks to him!

What is CI/CD and why should I care? I’ll keep this short as I’m sure you are here to see the demo and check out the playbooks. As per wikipedia “CI/CD generally refers to the combined practices of continuous integration and either continuous delivery or continuous deployment.” In short it’s the idea that on your dev side you can do something like make a commit to your git repository, and it will then automatically kick off a series of actions that will take that new code commit and put it into production. Most folks think this is something only done in containers or in the cloud, but it can be utilized in your virtualized environments too(VMWare, Proxmox, etc.). The phrase heard a lot is “treat your servers like cattle, not pets.” It’s the idea that to deliver an update to my app I spin up a new instance(server, vm, container, whatever), do any config necessary to it, test it, add it to the path so it will be used, and last, decommission the old instances.

In this demo I will update an HTML page in my github repo and it will kick off the rollout. The repo holding the playbooks can be found here.

Demo Video

Workflow Overview

In the Ansible Automation Platform(AAP), the user interface(currently known as tower) has the ability to tie multiple job templates together in what’s called a workflow. Here’s the workflow for my example:

I’ll quickly step through it here.
App-test-web-deploy is the playbook that connects to VMWare and creates a linked clone of a Centos8 image. After the image is booted it will create a host entry in my AAP inventory based on the DHCP IP that was pulled. This could be done via statics with something like Infoblox DDI.
Coming off of this template is a green line which indicates “if the template succeeds go here” and a red line that indicates “perform this template if the previous failed.”

Something of note in this playbook is the use of the set_stats module. When you want to set a variable, you usually do it via the standard set_fact module. Keep this in mind. A set_fact only is relevant to the local job template. If you have a workflow and want to use a variable between job templates, you need to use the set_stats module.

1
2
3
4
5

  - set_stats:
      data:
        newip: "{{ newvm.instance.ipv4 }}"
        newuuid: "{{ newvm.instance.hw_product_uuid }}"
        newvmname: "{{ newname }}"

On fail of any of the operations the app-test-web-deploy template is run which deleted the new VM and removes it from AAP inventory.

On success app-test-nginx-install is run. This is a simple playbook that opens port 80 in the firewall(and restarts it), installs nginx, and disabled SELinux(this is just a lab example after all).

The next template to run is app-test-web-config. This job will install git(this is how the new web app is pulled), it then places the nginx config file on the server, it then wipes the web folder and uses git to pull a fresh copy, and last it restarts nginx.

I’ll now run the app-testp-web-http-test template that will make sure the required files exist, then it will do a test to the web server and ensure the proper page contents are returned.

The app-test-lb-config template is now run. This will (double check that the firewall settings are correct on the LB(the loadbalancer is persistent, but this doesn’t hurt)), it then replaces the nginx config file to include the new server and remove the old. Last it will reboot any necessary services.

As a last step the app-test-final-cleanup job template is run. This will delete the old MyApp VM(the active web app VM), rename the new VM as MyApp(since it is taking over the role), then it will update the AAP inventory with the new IP for MyApp.

Conclusion

It’s realllly satisfying to watch it all move in concert, which I suppose ultimately is the goal of automation to begin with(have everything smoothly lock together). I had fun putting this together, so I hope you find it of use. If you have any questions or comments, please let me know.

Thanks and happy CI/CDing.