Which Configuration Management Tool are you using?


I now have about 6 different storage nodes across multiple locations.
Besides docker and containers, I created some scripts to automate some things (including daily notification about the current estimate earnings).

It’s becoming difficult to keep everything at the same level of configuration.
That’s why I’m starting to see how to use some well-known software Configuration Management or Provisionning.
4 of them caught my attention: Puppet, Chef, Ansible, Terraform.

My question is: which one should I use?
My current storage nodes are either on VM or Raspberry Pis.
Since I deployed a set of scripts on all those nodes, I would like to find an easy way to keep them up to date.

So my questions:

  • If you have several nodes (especially spread across multiple locations), how do you manage them (deployment and configuration)?
  • Do you use one the tools I’ve mentioned above?
  • Which would you recommend in my case?

Thanks a lot for your help and discussions :slight_smile:

I’m not using any for storage nodes yet, as they’re very low-maintenance so far. But I know Ansible and I expect that it should be easy to do Ansible scripts for storage nodes given the docker support in Ansible.

However, personally I would probably instead package storage node for Debian (as opposed of using Docker) with systemd template services, so that installing new nodes would essentially be apt install + dropping a text file, with updates handled not by watchtower, but apt. You don’t really need configuration management for that then. If I’ll ever want to run storage node on more than few hosts (and while I used to have 2 computers running storage nodes, now I consolidated them to one), I’ll probably do so—again, I expect this to be pretty simple given its written in go.

1 Like

Ansible is probably the best fit for this use case, because you likely want changes to be immediate. Ansible has the disadvantage that the Ansible server needs to be able to ssh to each node, which requires one of:

  • The nodes must be on the same LAN as the server, or
  • The nodes must have unique public IPs, or
  • Suitable port forwarding configuration, or
  • A VPN between the server and all nodes.

We use Puppet for managing our servers (not storagenodes) and it uses a pull model where the agent checks for changes at a configurable interval (30 minutes by default). If you want to see changes applied quickly, you need to lower that interval but then the agent is hammering the server more often.

If you’re managing hundreds of servers/nodes and don’t need to see changes instantly applied (just “sometime soon”) then Puppet could work. Since the Puppet agent contacts the “puppet master” instead of the other way around, only the server needs to be accessible by the agents; the server doesn’t need to be able to connect to the agents.