3 ms·

I tried doing this once. It just wasn't worth the additional testing effort and increased complexity. Switching to Ansible was far more productive. Interesting

by josho 5y ago

I tried doing this once. It just wasn't worth the additional testing effort and increased complexity. Switching to Ansible was far more productive. Interestingly though starting in Bash was a good MVP approach. Fast to get started. But as things started to slow down the project switched to a better tool. I expect for many projects the number of bash scripts may never grow large enough to merit a switch. So, sure write scripts that are safe to run multiple times, but if that effort grows know that there are better tools.

nathancahill 5y ago
I might be misremembering, but I believe Ansible started this way too? And then switched from Bash to Python as the project grew?
- CraigJPerry 5y ago
  I only remember Python even from the very beginning. Also Cobbler (Michael Dehaan’s prior project) was in Python too. I could be wrong though, the only reason this stuff sticks in my mind is because i was working on a CFEngine deployment (scarred for life) at the time Ansible popped up.
- zufallsheld 5y ago
  Ansible started as a Python peoject according to the first commit: commit f31421576b00f0b167cdbe61217c31c21a41ac02 Author: Michael DeHaan <michael.dehaan@gmail.com> Date: Thu Feb 23 14:17:24 2012 -0500 Genesis. diff --git a/README.md b/README.md new file mode 100644 index 00000000000..60bbc9f8137 --- /dev/null +++ b/README.md @@ -0,0 +1,88 @@ +Ansible +======= + +Ansible is a extra-simple Python API for doing 'remote things' over SSH. +
pas 5y ago
Ansible - in my experience (mostly with openstack-ansible years ago) - was too slow, hard to configure, debug and hard to extend with new modules. :( Moving toward "declarative state with enforcing/monitoring (idempontent!?) control loops" is much, much better. (What k8s does well. Now all we need is one master bash script to setup k8s :D )
tryauuum 5y ago
Even better than Ansible is Saltstack or Puppet or Chef. In other words, something that sits on a controlled machine and already knows facts about said machine
- giobox 5y ago
  Not all idempotent automation operations need heavy weight centralized state management like a deployed Chef server... Ansible has a lot less boiler plate in many scenarios. Indeed this is exactly why Chef even have 'chef-solo'/local mode to let you avoid having a Chef Server at runtime: https://docs.chef.io/chef_solo/ https://docs.chef.io/chef_solo/ While its a matter of opinion and will depend on problem you are trying to solve, I've found teams get productive on Ansible a lot faster and Chef Cookbooks often end up requiring significant maintenance. I have similar complaints with Puppet too. My biggest complaint with Chef is that its DSL so closely resembles Ruby that developers often assume the code in the cookbook is executed as pure Ruby rather than a DSL conversion; the transcoding phase in Chef is pretty complex and can lead to lots of debug head scratching.
  - tryauuum 5y ago
    Yeah, my favorite solution of them all is SaltStack. You can literally put jinja2 in any part of state, not into just specific parts like in Ansible. And it's malleable like clay, you can turn SaltStack into a perfect fit for your case

by josho 5y ago

nathancahill 5y ago

I might be misremembering, but I believe Ansible started this way too? And then switched from Bash to Python as the project grew?

CraigJPerry 5y ago
I only remember Python even from the very beginning. Also Cobbler (Michael Dehaan’s prior project) was in Python too. I could be wrong though, the only reason this stuff sticks in my mind is because i was working on a CFEngine deployment (scarred for life) at the time Ansible popped up.
zufallsheld 5y ago
Ansible started as a Python peoject according to the first commit: commit f31421576b00f0b167cdbe61217c31c21a41ac02 Author: Michael DeHaan <michael.dehaan@gmail.com> Date: Thu Feb 23 14:17:24 2012 -0500 Genesis. diff --git a/README.md b/README.md new file mode 100644 index 00000000000..60bbc9f8137 --- /dev/null +++ b/README.md @@ -0,0 +1,88 @@ +Ansible +======= + +Ansible is a extra-simple Python API for doing 'remote things' over SSH. +

pas 5y ago

Ansible - in my experience (mostly with openstack-ansible years ago) - was too slow, hard to configure, debug and hard to extend with new modules. :( Moving toward "declarative state with enforcing/monitoring (idempontent!?) control loops" is much, much better. (What k8s does well. Now all we need is one master bash script to setup k8s :D )

tryauuum 5y ago

Even better than Ansible is Saltstack or Puppet or Chef. In other words, something that sits on a controlled machine and already knows facts about said machine

giobox 5y ago
Not all idempotent automation operations need heavy weight centralized state management like a deployed Chef server... Ansible has a lot less boiler plate in many scenarios. Indeed this is exactly why Chef even have 'chef-solo'/local mode to let you avoid having a Chef Server at runtime: https://docs.chef.io/chef_solo/ https://docs.chef.io/chef_solo/ While its a matter of opinion and will depend on problem you are trying to solve, I've found teams get productive on Ansible a lot faster and Chef Cookbooks often end up requiring significant maintenance. I have similar complaints with Puppet too. My biggest complaint with Chef is that its DSL so closely resembles Ruby that developers often assume the code in the cookbook is executed as pure Ruby rather than a DSL conversion; the transcoding phase in Chef is pretty complex and can lead to lots of debug head scratching.
- tryauuum 5y ago
  Yeah, my favorite solution of them all is SaltStack. You can literally put jinja2 in any part of state, not into just specific parts like in Ansible. And it's malleable like clay, you can turn SaltStack into a perfect fit for your case