3 ms·
System automation is very “scripty” so the traditional tools have always been in scripting languages (chef, ansible, puppet, salt) and you can have lots of othe
by johntdaly 5y ago
System automation is very “scripty” so the traditional tools have always been in scripting languages (chef, ansible, puppet, salt) and you can have lots of other peoples “code” running instead of doing it all yourself. That is sort of the appeal, enough other people use it so that you don’t have to do everything yourself if you don’t want to.
There are solutions in go, one that looked interesting to me was mgmt [1]. You can look into that if it is to your liking. There is a list of videos and blog posts to mgmt that you can take a look at.
Thing is, if you move away from the mainstream you will find less help and less pre-made solutions. Don’t overestimate the skill of the “average” programmer. For every brilliant programer there is somebody out there that just googles code snippets and haphazardly bashes them together to try to solve a problem. It is easy to reach you limits, if not in skill then in time and that is where a tool with a larger community can save your ass.
[1]: https://github.com/purpleidea/mgmt https://github.com/purpleidea/mgmt
- viraptor 5y agoThere's also the issue of ansible being very easily extensible. That would either have to go through some new compatibility later with golang or it would be lost. The plugin building story is not trivial at the moment.
- astaunton 5y agoI would agree with this, Ansible (and Salt) allow you to extend the functionality by 1) Create a python script for your functionality 2) Drop it in a predefined folder on the master server 3) sync all agents (if using agents) In my experience Chef / Puppet are not so easily extendable, and anything using Golang or Rust would require a step to generate the binary code for your new functionality, taking for granted the proposed tool would allow extensions to be picked up dynamically by adding them to a specified folder.