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 python virtual env on and agent (equal to: this is what you could do in a CI/CD pipeline)
- Install Ansible on a separate 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 Ansible)(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 Salt stack 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! For me running an installation of WSL2 with Ubuntu and using this for local Ansible starting point is just good enough. (See also installing WSL2 on Windows10)
Install in a virtual env
This is what I actually use in deployment pipeline where an teamcity Agent or within GitLab’s 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 co-worker doing a 4-eyes check.(somewhere 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 grammatically 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 pushing 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. I do tend to use a venv from within my WSL2 environment to keep that installation clean. (See also Ansible in a venv)
Install on an ESX farm
Maybe you can run stuff like Ansible tower 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. I did actually start some experiments with AWX which is a docker driven upstream project in the same family as Ansible Tower. This you can actually run in a Docker desktop on a Windows10 environment.
Use VirtualBox on your laptop
This has been one of my favourites 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 basically 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 spin 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 somewhat 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 “pollute” my developer system to make it native ready for running docker containers. I might also get around and find a way to actually 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 actually install docker on synology with ansible. Especially the AWX projects which uses docker containers has proper use cases. I am working on some test cases using that too.(see also AWX Automation)
Conclusions
There are quite some hooks to several posts more technical in nature containing code and actual commands to execute. As always I try to separate 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. In the end you’ll be like me and start to be a true ansibalist and run a Python virtual-env where you have installed Ansible in from within Ubuntu on your Windows 10 guest system with WSL2. From there you spin up a ansible script to run docker compose creating some containers running AWX which hold your local development pipeline. From the venv you configure those AWX docker containers with Ansible AWX and you use the “awx_task” docker container to do local testing of your pipelines. While the local development seems still easier and quicker from your Vagrant virtual-box machine which mounts your working directory directly while you can edit it at the same time in Visual Studio Code. Lots of ways to do your stuff and many ways to run your Ansible.
I hope reading the above has given some insight on how you can run Ansible in different ways and why!