I remember looking at Ansible way back in 2012/2013 when I began building out DevOps solutions. I wanted something Python based to make it easier for everyone to adapt to and at the time there were really only two major solutions out there, though they were both in very early development. Salt and Ansible.

At the time, salt wasn’t even a 1.0 release and did have some bugs to it but I really liked how everything was integrated into one package. It was (and is) incredibly fast and it handles cross-platform support reasonably well. Salt has worked out for me quite well over the years as I prefer to treat systems as ephemeral and instead tie their configuration back to my CM systems. It has made system builds and upgrades easy and it makes it simple to track any configuration change. All that being said, it was time to move on after the recent purchase of VMWARE by Broadcom.

After the purchase, I had become increasingly cautious with Saltstack. Development appeared to slow down for a time (though its picked back up again) and several people have left the project. I felt the future was uncertain, which brought me back to Ansible again over ten years later.

Over the years a friend of mine had been mentioning Ansible off and on but there was always something I still preferred with Saltstack. I needed that little extra push to feel the need to rewrite everything. Unfortunately and fortunately this came with the Broadcom acquisition and now I can say I have successfully rebuilt my entire CM infrastructure using Ansible!

Like everything though, there is no perfect tool. After using it for a while I have to say there are a lot of things I really like with Ansible as well as some things I miss in Salt. One of Salt’s strengths is everything is built into its master / minion clients so you can use the same command to run against multiple Linux distributions and sometimes Windows. In Ansible there are some commands that do this and some that dont, though I have mostly given up on more universal commands as the distribution specific stuff appears to work better. Now, while I say that I have to say that Ansible is extremely flexible as I can easily get around these difficulties in my template design. With Saltstack there have been times that I have had to wait for built-in commands to catch up and instead had to design shell commands to accomplish a goal.

One area that still simply seems to outshine in Salt though is Windows support. Using the WinRM support in Ansible just feels unwieldy which has been kind of a pain vs Salt where I just had to install a minion and make sure the port was open. I have since given up on Ansible and Windows, but maybe that will change one day.

Another area that Salt really outshone Ansible is dependency management. Since Ansible relies on built in commands it is easier to run into dependency issues with ones scripts. In Salt you are usually ok as long as you test your Salt release before you upgrade everything and you can always roll back.

So far, the one area that Ansible outshines Salt is it is extremely flexible! It is incredibly easy to make complex management routines. So much so that I feel like I do more with it than I did with Salt. While this has been awesome it also was a bit of a pain to get up and running as I wanted to plan out a maintainable architecture, figuring out where I wanted to store variables, build my template organization, etc. This is always important to me as I like to create things that can be managed by someone else should I leave. It took some time but now that its set I really like it!

Hopefully one day when I have a little time I will create a skeleton directory layout and link to it here. For now though, I just have too much to do!