6 ms·
It’s good to know which command line tools are idempotent, but I think once you start running automated scripts repeatedly you’re better off with something like
by mnutt 7y ago
It’s good to know which command line tools are idempotent, but I think once you start running automated scripts repeatedly you’re better off with something like Chef where you declaratively define the end state and let chef figure out how to converge upon that state. Taking the “create a directory” example, you would say “I want to end up in a state where this directory is created and has these permissions” and chef will determine if the directory already exists.
There are of some downsides to that approach which stem from the fact that you can’t possibly declare every possible thing. For instance, if you were to run the above declaration and then later remove the declaration, chef wouldn’t know to delete the directory; at that point chef wouldn’t know anything about the directory at all. So ideally you can build infrastructure from scratch each time (Docker, etc) rather than having to converge an existing machine.
- itchyouch 7y agoChef does have an action on their primitives, so it is possible in the directory example to set the action to :delete instead of only implying :create
- mnutt 7y agoYou’re right, it’s totally functional, the (minor) challenge I see with it is that it breaks the illusion that you’re describing the state of the system, and feels more like describing a set of changes you want to make.
- pas 7y agoChef isn't magic, it just uses a lot of cookbooks which are just running things to check what the state is. Usually those cookbooks will want to have things in a particular way, which might not be the way you want. Chef/Ansible/Puppet all have the problem of having many layers of overhead for the same thing. This makes them slow, hard to debug, hard to read and even write (in my opinion). Sure, bash is hell, but the go from bash to something like Rust, instead of Chef/Ansible. Sure, again, this might sound rather unconventional, but you get safety, speed and convenience of a full fledged programming language, single binary output, etc. And you need to test cookbooks/playbooks too, so why spend enormous effort on cobbling together scripts and high-level abstractions instead of writing just what you need with the assumptions you really have - instead of what a general cookbook/playbook has to have (which is a vast difference).
- empath75 7y agoWriting a shell script in rust would be obnoxiously difficult for no real benefit.
- dymk 7y agoYeah, and tools like Chef are 99% blocked on disk operations anyways, so I have no idea why GP thinks Rust would help
- heavenlyblue 7y agoRust would help due to the type system and lack of library dependencies (it does static linking AFAIK), I suppose.
- dymk 7y agoI feel like my comment went in one eyeball and out the other. Chef and friends are blocked on disk I/O. How does a typesystem and/or thinner abstraction layer to disk I/O speed up the underlying expensive operation: blocking disk I/O?
- heavenlyblue 7y agoI - on the other hand, feel like your comment somehow forgot that the op said “safety, speed and convenience”, so you attacked the least important point made in the first place. It’s much easier to see the failure conditions in a Rust program rather than in bash. Also rust seems like easier to maintain, too.
- dymk 7y agoHow does having a borrow checker and snazzy memory safety benefit you when nearly all the operations you're performing are disk I/O? How is a 100 lines of rust easier to maintain than 10 lines of shell script? It's exactly what the other commnet said: "Writing a shell script in rust would be obnoxiously difficult for no real benefit."
- xorcist 7y agoAbsolutely this. When the intent is to get the system into a desired state, reach for Puppet/Salt/Ansible. If you are doing sysop^Wdevops work it is the single most important thing you can learn, once you have a good grasp of your shell and your editor. The difference between a giant git archive of shell scripts that various people have modified over the years and state changes described in a configuation management language is the difference between fixing things in the small and reasoning about integrated systems. It's something that needs to be experienced to be appreciated. Reasoning about system state as an integrated whole is just as relevant when you are shipping applications as containers, if not more so. It's not uncommon to start using something like Kubernetes without first being able to describe global state and the result is just as messy as before, if not worse. Something like Helm is impossible to understand unless you have complete control over your configuration.
- cpitman 7y ago100% Agree. I originally got into Puppet after spending several months with a client that wanted me to write bash scripts to push out a major middleware deployment, switchover, and uninstall to 10,000+ stores. There was no standard for the hardware in the stores, and their configuration was all over the place because 100's of teams also used (non-idempotent) shell scripts to push changes. I learned a lot about catching all the different bad things that can happen, adding prerequisite checks, rolling back changes automatically, etc. In the end, a tool like Puppet/Chef/Ansible would have taken a fraction of the time to develop scripts for. Containers have definitely lessened the need for mutable configuration management, but they are still useful in the 90% of environments that are still working in a past decade.
- audience_mem 7y agoIs it not a bit of a large jump from "shell script" to "chef"? There is some inbetween. I understand a shell script is not suitable for orchestrating a datacenter, but sometimes it is suitable for installing a couple of things.
- pnutjam 7y agoAnsible is good for small or large installs.