Here’s my first post for a while, and in this post, will talk about my journey with using Configuration Management with the overview of the 2 technologies, that I started working on a couple of years ago. Below are the topics I will cover in the next 4 articles, this being the first 

• Technology Overview
• SaltStack
• Ansible
• Conclusion

Technology Overview

Over the past few years I have been introduced to SaltStack as one of the configuration managers through our OpenStack installations for a customer. During this process, I learnt a new way of working, and how configuration management could be used in this context. I was drawn into this, and realised this throughout this project.

From my initial introduction to the new technology, I was intrigued, and what else was out there, that can do a similar job. I only really found one that was similar, i.e. Ansible. So, I chose a specific way to test both applications. Over the years I had accumulates several scripts that would enable me to quickly re-configure my laptop once a new distro was installed. I thought, let’s try a config management process, hence then I tried both Ansible and SaltStack.

The key applications I configured were:

• apt repos
• installation of packages
• conky
• samba config to authenticate against AD
• autofs, to mount storage from central storage

Both of the technologies used YAML for all the configs, so were similar in how things were being configured. Also, both technologies used Python as their base language, and had the facility of adding complexities via jinja too.

One of the key differences I found from the initial stage was that, Ansible used SSH to connect to the clients, whereas SaltStack uses server client daemons. There are advantages and disadvantages of either approach, but I will talk more of my findings on that in the conclusion of this series.

My next article will talk about my SaltStack experiences, followed by Ansible, and finally conclude with my findings, and what I decided.