4 ms·

I worry when I can't tell if a comment like this is based on fact or just trying to be funny. Because I've seen my share of nasty "legacy" automation but, surp

• acveilleux 10y ago
  My take is that the shell script does not have any unspoken assumption or magic that is performed by the tool. It all has to be in the script building up strictly from well-understood and long stable basic bricks (and the few places where you don't it's even worse with devops tools.) Any issue, any question can be answered by reading the damn shell script and you're never dependent on a cookbook/recipe/playbook/component that you got off of some github repo that you need 5% of to do X.
• CaptSpify 10y ago
  An un-researched opinion from someone who replaced chef/ansible/puppet with his own shell-script config-management system: I don't have to rewrite my shell-scripts every 6 months when a new version comes out. New updates usually only happen when security issues arise. Shell-scripts tend to be simple. There's not a lot of magic hand-holding going on, which means not a lot of complexity to break things. It keeps you from getting too abstract. Your writing pretty close and specific to what you want it to do, not "how it should be". They are typically standalone. It's really easy to have 1 script that solves one problem, and another script that solves another. You don't need a giant code-infrastructure to keep things going. I think config-mgmt tools can be extremely useful if your running a widely-ranged environment. But, you probably shouldn't be running a widely-ranged environment. If you keep things simple, and run as homogeneous as possible, you probably don't need all the added complexity.
  • CrLf 10y ago
    > I think config-mgmt tools can be extremely useful if your running a widely-ranged environment. But, you probably shouldn't be running a widely-ranged environment. If you keep things simple, and run as homogeneous as possible, you probably don't need all the added complexity. This applies to small environments. If the environment is large the situation almost reverses. Deploying automation throughout a large homogenous environment is where config-management tools really shine. They make it easy to ensure homogeneity is maintained (even if that just means ensuring all machines have the same set of shell scripts) and allow grouping for staggered updates. If the environment is widely-ranged and large, the utopia starts to break down. Their configuration explodes in complexity and (if you're not careful) you end up with mostly the same amount of work as if they were managed as small independent environments. With the added risk that there is now a single place from where you can break everything at once. And this happens... Usually from wrong assumptions of what's common between all machines in the environment. In homogeneous environments almost everything is common, but in widely-ranged environments you sometimes add some configuration that wasn't there before and you think applies to the whole set and all hell breaks loose. If you're lucky this will happen suddenly, if you're not, breakage will spread slowly and you'll spend quite a lot of time scratching your head on why.
    • CaptSpify 10y ago
      Well, it depends ;) I don't think large/small is a good deciding factor. You can be large and homogeneous, or small and diverse. I think similar/dissimilar is a better decider for config-mgmt vs shell-scripts. I'd argue that config-mgmt usually does a better job if your setup is large and complex. No need to write a script that checks if it needs to install a .deb, .rpm, or whatever, if your config-mgmt tools have already done that work. Also, if you build your shell-scripts right, they can ensure that your system is kept the same.