Where and how to run Ansible

So here you are. You have been using Ansible for a while and have walked already different paths is using and installing it naming a few:

  • Install Ansible on your host development system (equal to: your laptop)
  • Install Ansible inside a pyhton virtual env on and agent (equal to: this is what you could do in a CI/CD pipepline)
  • Install Ansible on a seperate system where you run your playbooks from (equal to: fine if you have an ESX farm or something)
  • Install Ansible in VM on your host development system (equal to: use virtualbox on your laptop)
  • INstall Ansible in Container (equal to: use docker to run Asnible)(ATM under investigation)

All the above use cases have their own implementations and of course pros and cons.

Install on your laptop

I myself keep getting Windows like laptops from my employers. Since me and python versions and installations on windows have never been friends I stepped out of installing frameworks on my guest developer OS. Another reason not to do your installation on your developer system is. Sure you like Ansible, maybe you are a true Ansibalist, but there might come a time that you want to try other things Saltstack for example or just some native python code. Do you want you developer system to be contaminated with every new project? And what about the different ways you work. Maybe you need some different way to to do things for example at home and at work. So never been a big fan of pushing an automation framework directly onto your development system!

Install in a virtual env

This is what I actually use in deployment pipeline where an teamcity Agent or within Gitlabs there are python virtual env’s setup. What you do here is install Ansible inside a virtualenv with every deploy. It prevents having a permanent system running like the below install on a ESX farm. Frankly speaking this is great when you have your automated deployment pipeline worked out. But in the speed of development phase it gets annoying quickly to have a PR checked disturbing your coworker doing a 4-eyes check.(somehwere between 5-120 minutes) Have the automated linting processes go over your code(1.5 minutes). And then deploy your build (0.5 - 1 minutes) just to see that you made a grammaticaly correct mistake in your code that passed correct through your linting but results in state of not being able to deploy at the moment and this might again cause havoc in another persons workflow also. So testing stuff is an essential part before pusing into an operational pipeline. And last but not least as this blog is mainly about private projects, there is now deployment pipeline so far in my home projects.

Install on an ESX farm

Maybe you can run stuff like Ansibletower in your work environment but like I mentioned I am considering these posts here being about “testing and at home automation”. I don’t have a ESX farm at my house, nor will I get one because with great power comes a great electricity bill. I use just one single synology NAS system for everything that needs to be permanently available and that’s it. All other things need to be deployable on my developer system for testing purposes. Beside the footprint of such a dedicated system just for Ansible is quite a lot so probably you are not starting of with this option unless you already have an ESX farm with spare capacity and big plans to run lots of Ansible code.

Use virtualbox on your laptop

This has been one of my favorites for a over a year basically in 2019 and 2020. I have used it in several projects. You can find some already on github I use vagrant to spin up one or more virtual machines and at least one holds the Ansible running environment. To do this the environment is described in a Vagrantfile. The box running Ansible is basicaly bootstrapped after start of the Vagrant machine by a bash script install.sh. After this is done you can of course use ansible to further provision your to be tested systems. What this does for me is basically keep my development system clean. It makes sure that I can version pin my installation used in a project, causing stuff not to break if I return to it after a while because the next or in between project needed some different toolset or versions. However the spinn up of the vagrant machines can be kind of annoying especially when working with different projects say, at home and in the office. Pausing your systems with vagrant suspend is forgotten or after a suspend you find that vagrant resume just doesn’t return your system in a working state again. Anyway a clean way of working but the waiting times of staging the Ansible VM is takes about 2-3 minutes and switching between projects can be sowmwhat tedious. Usually when you work on just one project and you just put your laptop into sleep mode before closing down this works pretty good.

Use docker to run Ansible

As I am doing more and more things with docker at home and getting further into kubernetes. I seen also quite some interesting stuff being done with Ansible to stage Kubernetes clusters. I thought it might be a good thing to try and see how I like running Ansible from inside a docker container on my host system. So no feedback on how that worked out so far but make sure to check out my post about Ansible and Docker I do have good hopes knowing the speed of spinning up a docker is quite good and I am willing to “polute” my developer system to make it native ready for running docker containers. I might also het around and find a way to actualy build a deployment pipeline to use in my home setup running Docker on Synology. But then again that runs quickly into a chicken and egg kind of issue as I was planning to actualy install docker on synology with ansible

Conclusions

I hope reading the above have given some insight on how you can run Ansible in different ways and why! There are quite some hooks to several posts more technical in nature containing code and actual commands to execute. As always I try to seperate the PhylosITy from the configuration and setup instructions. That is why this post once again contained Only words and is more about the thought processes and choices you can make when setting up an environment using Ansible.

comments powered by Disqus