4 ms·
Having dabbled with Ansible and Saltstack -- and much preferring the latter -- it's very sad that Ansible has seemingly won most of the sentiment amongst the de
by Jedd 5y ago
Having dabbled with Ansible and Saltstack -- and much preferring the latter -- it's very sad that Ansible has seemingly won most of the sentiment amongst the demographic of people who didn't want Ruby / DSL, but preferred Python / YAML / Jinja. RH's ownership and marketing was probably the compelling feature for many shops.
Less so with Ansible, and more so with Saltstack, I found it easy to slowly migrate my stack of bash scripts into the platform. As with any config management system you can always just wrap some config boilerplate around your scripts, and try to cater for idempotent requirements / shortfalls -- a bit like how learning PHP is relatively easy, as you can start safely by inject tiny fragments into your HTML.
- mdaniel 5y agoI have seen saltstack references in the kubernetes repo, and that alone was enough to pique my interest to read into it, but I guess maybe the "chicken and egg" is causing salt to be just massively behind on what one can do with ansible For example, this[1] is all that seems to be available for "cloud" on AWS. Now, I am super, super cognizant that there is a camp of "TF all the cloud, then $something on the machine" but here salt seems to be dipping its toes into the AWS API, and yet treating that machine as a pet, not even offering ASG nor LaunchTemplate knobs that could bring the machine back to life if it falls over 1: https://docs.saltproject.io/en/3004/ref/clouds/all/salt.cloud.clouds.ec2.html#module-salt.cloud.clouds.ec2 https://docs.saltproject.io/en/3004/ref/clouds/all/salt.clou... I will say, it seems salt's documentation just absolutely spanks ansible's approach, so there's that
- Jedd 5y agoYeah, there's certainly some fuzzy borders that delineate the various domains of deployment, fleet orchestration , config management, BCP, etc. Similar to author of TFA, I use Consul & Nomad and config management (in my case Salt) to manage a fleet of 'home' systems, and a couple of IaaS boxes (DO rather than AWS, because Jeff). $dayjob uses Ansible & Tower, but nothing about that experience has inspired me to try to lift and shift to that side of the fence. In any case, I've not hit many functionality gaps with Salt, though my requirements are relatively modest. My favourite demonstration of one of the pain points with Ansible is: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#understanding-variable-precedence https://docs.ansible.com/ansible/latest/user_guide/playbooks...