3 ms·
Is there a config manager based on shell scripts?
So, I stumbled upon "fucking shell scripts" from a couple of years ago: https://news.ycombinator.com/item?id=7401952
From the major config managers, I'm only familiar with Ansible.
There, I feel like I'm fighting its syntax and quirky errors more than it really helps me.
Maybe that would change if I had more than 100 servers to change but I don't.
As it is, the idea behind "fucking shell scripts" looks pretty good to me.
However, the project requires ruby (on my local machine only, I believe) and it is has been marked unmaintained.
I'm wondering if there's an alternative with a similar approach?
Has anyone tried using Ansible exclusively with the shell module?
That might do exactly what I'm looking for, no?
- mattbillenstein 9y agoShell scripts are just so brittle is the problem -- I think maybe you're looking for something closer to fabric: http://www.fabfile.org/ http://www.fabfile.org/ It's kinda fallen out of favor I think with things like Ansible and Saltstack, but I think it might still be a good fit for some things.
- mkauer 9y agoNow that you mention it, I've used fabric before as well. I didn't feel as much of a disconnect between local and remote commands as I do in Ansible somehow. Nevertheless, it is once again, its own syntax somehow. You say that scripts are brittle and I am not sure where to stand on that issue. What are the biggest problems you have run into with shell scripts for configuration?
- mattbillenstein 9y agoThey're just hard to compose, mix in configuration state, make idempotent, etc. I mean, probably fine for one box, but once you have two, not ideal.
- brudgers 9y agoRandom remarks from the internet: The only reason I will mention containers this is because you are looking for a new solution and a new solution will result in having to learn a new workflow anyway. The advantage of putting multi-component configuration into a single container is that their deployment is atomic. The state of the remote machine is either: Container not deployed Container deployed There are zero in between states of Partial-Deployment/Build that need to be either rolled back or rolled forward. The issues created by the dependency of one container on another bubble up to the level of container orchestration but boil down to: When container X.123 is deployed, container Y.456 must be running. If container Y.456 is not running, deploy Y.456, then X.123. Nothing gets built on the remote machine. No dependency gets pulled from another network. The container orchestration has the same logical problem of dependency management but far fewer practical issues with interrupted execution.