⨯ 🔍

Why Ansible?

by alex

Updated: 2024-05-11

in 2024

ansible logo

As part of an effort of standardising my home lab I decided to migrate my ad-hoc configuration scripts into a more standard tool set. So I looked at:

At the end I opted for ansible, as it was closer in operation to my configuration scripts. The main points for me where:

  1. Central control node, with push semantics
  2. No agent needed, all communications via ssh. But it has python dependancies.
  3. Written in python
  4. Configuration mostly in YAML files.
  5. Very wide acceptance in the IT community.

Later I found about cdist, while it is closer to my ad-hoc scripts, it is a bit niche and not well known. However, like ansible has a central control node push model, all communications via ssh and has no python dependancies, requiring only a compatible shell.

Configuration of cdist is written in essentially shell scripts. According to this wikipedia article:

Ansible makes a distinction between roles, written in a declarative YAML-based language, and modules, written in Python. Cdist only has "types" which serve the purposes of both modules and roles and are mostly written in Bourne Shell. Cdist's approach might be preferable because Shell is familiar to many system administrators who have never used a configuration management system before, but Ansible's declarative language is arguably more readable and appropriate.

The remaining options all require agents, which is not ideal as I really wanted a low footprint on the managed nodes.

cfengine has a nice theoretical framework but also, not as popular as ansible or the other entries in this list. While written in C it uses a DSL for its configurations.

puppet is written in a mix of of Ruby, Clojure and C++ and uses a DSL for configuration. chef is written in a mix of Ruby and ERLAN and uses DSL for Configuration. Personally, I see the use of Ruby as a turn-off. So far several softwares I tried to use written in Ruby did not lead to good experiences for me.

saltstack is written in python.

Removing Python as a dependancy

I am mostly using Alpine Linux for servers. As such, adding python adds to a base image of 17.1MB, an additional 50MB. So it is a bit unreasonable. I found a project ansible-openwrt which removes the python dependancies but it has a lot of OpenWRT.

I manage remove the OpenWRT dependancies, and the result can be found HERE.

It makes use of the Ansible's var_plugin functionality to hook into the ActionBase._configure_module method.

Also adds a number of modules written in shell script that replace the built-in python modules. Specially important are:

  • setup: which is called automatically to gather facts at start.
  • ping: because, it is the first thing to test things.
  • stat: which is used by several modules specially copy.
  • command: which is used by command and shell modules.

Interestingly enough, there are other modules such as script that do not have a python dependency.