4 ms·

Shell scripts are pretty nice and it's unfortunate that the new crop of configuration management tools puts them on the sidelines instead of treating them as fi

Shell scripts are pretty nice and it's unfortunate that the new crop of configuration management tools puts them on the sidelines instead of treating them as first class citizens in the configuration pipeline. Now the much harder problem of orchestration is still an unsolved problem and I think that is what the author was referring to.

zwischenzug 12y ago
I agree, which is why I wrote this :) http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/
- contingencies 12y ago
  This is docker-specific, obviously. Also, AFAICT it's not really 'deterministic builds' despite claims to the contrary since the network is allowed as input.
  - zwischenzug 12y ago
    The first point is technically untrue - it works over ssh or plain bash also. The second point is correct; it's deterministic in the sense that the ordering is always the same, and as much as Dockerfile are (they're also regularly described as deterministic). I should probably clarify that somewhere.
peterwwillis 12y ago
IMHO you can't make an orchestration product that a devops person will like. The only people i've met who appreciate pre-built, non-customized orchestration tools are people who can't program. For the devops crowd, I think fail-closed or fail-safe shell scripts work really well for orchestration. Too many times i've seen a really complex chain of operations make it much harder to debug and fix a problem because the tool was trying to be smarter than it needed to be, or ignored failures. You get faster development time, simplicity, portability, extensibility, interoperability, etc for free. And really i'm sick of re-writing the same tool only to later fix it with a shell script because tackling the tool would be too complex or time-consuming.
- dkarapetyan 12y ago
  Maybe you're right. I've fallen into the trap of re-inventing orchestration but the layer on top of shell scripts as always been tiny (200 or so lines of Ruby or Python). At some point you want some kind of self-healing and monitoring infrastructure and managing all that with shell scripts I'm sure is possible but I wouldn't want to be the one to do it.
- contingencies 12y ago
  fail-closed or fail-safe shell scripts I nearly choked. Perhaps in the 1980s when you could hire people with shell minutiae memorized, this was a good strategy. These days, I would be wrapping the executable for the job (purposefully in an unspecified language to facilitate broader use and survivability of the design) in a layer that makes its environment temporary and OS-level sandboxed (to stave off security challenges), and completely explicit (to nip the clasically vast number of undocumented dependencies in the bud). Ideally, versioning of such environments and their builds would be supported. That's exactly cims.
andrewchilds 12y ago
This is one of several reasons why I wrote Overcast[1]. I don't want to learn a DSL, I'd rather simplify the process of running shell scripts on multiple machines. [1] http://andrewchilds.github.io/overcast/ http://andrewchilds.github.io/overcast/
- 23david 12y ago
  Cool project. Are you continuing to develop it?
  - andrewchilds 12y ago
    Thanks, yes it's still in development, mostly just adding more providers and recipes at this point. I'd love to add Docker as a provider but I had questions around implementation (https://github.com/andrewchilds/overcast/issues/18 https://github.com/andrewchilds/overcast/issues/18), so maybe Docker Machine will be a better alternative, or something I can require as a dependency.

zwischenzug 12y ago

I agree, which is why I wrote this :) http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/

contingencies 12y ago
This is docker-specific, obviously. Also, AFAICT it's not really 'deterministic builds' despite claims to the contrary since the network is allowed as input.
- zwischenzug 12y ago
  The first point is technically untrue - it works over ssh or plain bash also. The second point is correct; it's deterministic in the sense that the ordering is always the same, and as much as Dockerfile are (they're also regularly described as deterministic). I should probably clarify that somewhere.

peterwwillis 12y ago

IMHO you can't make an orchestration product that a devops person will like. The only people i've met who appreciate pre-built, non-customized orchestration tools are people who can't program. For the devops crowd, I think fail-closed or fail-safe shell scripts work really well for orchestration. Too many times i've seen a really complex chain of operations make it much harder to debug and fix a problem because the tool was trying to be smarter than it needed to be, or ignored failures. You get faster development time, simplicity, portability, extensibility, interoperability, etc for free. And really i'm sick of re-writing the same tool only to later fix it with a shell script because tackling the tool would be too complex or time-consuming.

dkarapetyan 12y ago
Maybe you're right. I've fallen into the trap of re-inventing orchestration but the layer on top of shell scripts as always been tiny (200 or so lines of Ruby or Python). At some point you want some kind of self-healing and monitoring infrastructure and managing all that with shell scripts I'm sure is possible but I wouldn't want to be the one to do it.
contingencies 12y ago
fail-closed or fail-safe shell scripts I nearly choked. Perhaps in the 1980s when you could hire people with shell minutiae memorized, this was a good strategy. These days, I would be wrapping the executable for the job (purposefully in an unspecified language to facilitate broader use and survivability of the design) in a layer that makes its environment temporary and OS-level sandboxed (to stave off security challenges), and completely explicit (to nip the clasically vast number of undocumented dependencies in the bud). Ideally, versioning of such environments and their builds would be supported. That's exactly cims.

andrewchilds 12y ago

This is one of several reasons why I wrote Overcast[1]. I don't want to learn a DSL, I'd rather simplify the process of running shell scripts on multiple machines. [1] http://andrewchilds.github.io/overcast/ http://andrewchilds.github.io/overcast/

23david 12y ago
Cool project. Are you continuing to develop it?
- andrewchilds 12y ago
  Thanks, yes it's still in development, mostly just adding more providers and recipes at this point. I'd love to add Docker as a provider but I had questions around implementation (https://github.com/andrewchilds/overcast/issues/18 https://github.com/andrewchilds/overcast/issues/18), so maybe Docker Machine will be a better alternative, or something I can require as a dependency.