3 ms·

I've tried really hard with Ansible and I think the complexity is more trouble than its worth. Its kinda nice to have an engine to do a lot of servers at the sa

by rr808 5y ago

I've tried really hard with Ansible and I think the complexity is more trouble than its worth. Its kinda nice to have an engine to do a lot of servers at the same time but its easier just to run some bash scripts.

milanaleksic 5y ago
I agree: bash scripts should always be the first step what people should try. Usually, the build.sh finds its way into a project to structurally build the system on the pipeline, or a cron running shell to delete some temporary files and so on. But, it simply doesn't work if you have more than one server. Each one becomes a so called "snowflake", with diverging configuration, installed packages and so on. A book I really liked is "UNIX&Linux System Administration Handbook" which explains exactly this evolution in thinking that most people need to go through at some point if they want to automate things. Ansible is not the only approach: I can see a lot of other things popping up in recent years: - Nix is really cool - Salt is an alternative for Ansible (but I didn't get it, although one of my former employers moved from Puppet to Salt so it's probably a really good thing for complex setup) - Terraform/Packer (if everything is on VMs or in the cloud) - K8s (ubiquitous, omni-potent, but I had enough of it tbh: I need to learn each year new tools and good practices and frameworks are changing constantly, it's like "frontend frameworks of infra" ;))
- tkiolp4 5y ago
  In general I agree, first try bash scripts and then, if needed, something like Ansible. More often than not, though, the bash scripts I produce are buggy, non-idempotent, and really difficult to maintain. One could argue “know your tools!”, and while I agree with the sentiment, somehow for me at least, it’s way easier to write maintainable, less buggy, and idempotent Ansible plays than to do the same with bash.
  - phillu 5y ago
    You are not the only one. Anecdotal, but I have seen far more unmaintainable, half-assed, 1000-line build.sh scripts than Ansible scripts.
k8sToGo 5y ago
So all your scripts are idempotent?
- dijit 5y ago
  Mine are! I’ll make a guide sometime. I considered making some helper functions for people to just import at one point. But ingesting 1k+ lines of bash for a few functions feels wrong.
dfinninger 5y ago
What complexity are you hitting? Are you trying to go all-in on roles and a full setup or just doing some simple scripts? The latter is a much easier jumping-in point. Also, you can ignore the yaml files entirely and use Ansible as a parallel SSH tool.
- rr808 5y ago
  I think the issue is my requirements aren't that big. Download a tar file, unzip, switch some soft links, run some setup. A bash script does those things in a way people understand, with ansible it ends up being a few people (me) that do everything.
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 ago
  I 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 ago
    Yeah, 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...
AtlasBarfed 5y ago
It's sad that we go from bash ---> massive enterprisey system. There's nothing in between. I ran into this at my work. We have ansible and salt and terraform and nomad and spinnaker and kubernetes and docker, each in varying states of favor/disfavor. Bash scripts are awful: no standard library, no functional ide for debugging, pathetic language, whitespace sensitive. The only saving grace is the universality. Everything else? Heavyweight servers, daemons, opinions through the wazoo. What did I want? I want a way to get an inventory/list/cluster map of nodes, then be able to send CLI commands to them, and the parse the response and send more. I want to a decent language, good runtime, IDE/modern toolchain support. Can I just ssh into boxes? Yeah, uh, kinda? Or maybe I use aws-ssm to send/receive commands. Or kubectl or dockerrun. Or teleport. Or salt daemon. Each of them can do the job of "send command to a node". And I want to write meta-applications on top of that. So I settled on groovy: optional typing, if I want near-full JVM speed I can use CompileStatic, lots of scriptability, full JVM parallelism/threading power. The JVM sucks in some ways at running CLI commands locally, but once I figured that monstrosity out, got Jsch working for "pure" java SSH, caching kinda solved, thing.... So after about six rewrites, and a sufficient amount of configuration that makes a complicated ssh conf look like child's play, I can do cluster-level operations that make me happy: setup clusters, orchestrate/run/track load tests, fully scripted backups and restores, migrations/upgrades, red/black. Restore backups to analysis clusters. I'm not tied to a specific cloud. I'm not tied to a command delivery substrate. Is it useful to someone else? Dunno, I'll try to get it released and documented. Does anyone else know of something like this?

by rr808 5y ago

milanaleksic 5y ago

I agree: bash scripts should always be the first step what people should try. Usually, the build.sh finds its way into a project to structurally build the system on the pipeline, or a cron running shell to delete some temporary files and so on. But, it simply doesn't work if you have more than one server. Each one becomes a so called "snowflake", with diverging configuration, installed packages and so on. A book I really liked is "UNIX&Linux System Administration Handbook" which explains exactly this evolution in thinking that most people need to go through at some point if they want to automate things. Ansible is not the only approach: I can see a lot of other things popping up in recent years: - Nix is really cool - Salt is an alternative for Ansible (but I didn't get it, although one of my former employers moved from Puppet to Salt so it's probably a really good thing for complex setup) - Terraform/Packer (if everything is on VMs or in the cloud) - K8s (ubiquitous, omni-potent, but I had enough of it tbh: I need to learn each year new tools and good practices and frameworks are changing constantly, it's like "frontend frameworks of infra" ;))

tkiolp4 5y ago
In general I agree, first try bash scripts and then, if needed, something like Ansible. More often than not, though, the bash scripts I produce are buggy, non-idempotent, and really difficult to maintain. One could argue “know your tools!”, and while I agree with the sentiment, somehow for me at least, it’s way easier to write maintainable, less buggy, and idempotent Ansible plays than to do the same with bash.
- phillu 5y ago
  You are not the only one. Anecdotal, but I have seen far more unmaintainable, half-assed, 1000-line build.sh scripts than Ansible scripts.

k8sToGo 5y ago

So all your scripts are idempotent?

dijit 5y ago
Mine are! I’ll make a guide sometime. I considered making some helper functions for people to just import at one point. But ingesting 1k+ lines of bash for a few functions feels wrong.

dfinninger 5y ago

What complexity are you hitting? Are you trying to go all-in on roles and a full setup or just doing some simple scripts? The latter is a much easier jumping-in point. Also, you can ignore the yaml files entirely and use Ansible as a parallel SSH tool.

rr808 5y ago
I think the issue is my requirements aren't that big. Download a tar file, unzip, switch some soft links, run some setup. A bash script does those things in a way people understand, with ansible it ends up being a few people (me) that do everything.

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 ago
I 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 ago
  Yeah, 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...

AtlasBarfed 5y ago

It's sad that we go from bash ---> massive enterprisey system. There's nothing in between. I ran into this at my work. We have ansible and salt and terraform and nomad and spinnaker and kubernetes and docker, each in varying states of favor/disfavor. Bash scripts are awful: no standard library, no functional ide for debugging, pathetic language, whitespace sensitive. The only saving grace is the universality. Everything else? Heavyweight servers, daemons, opinions through the wazoo. What did I want? I want a way to get an inventory/list/cluster map of nodes, then be able to send CLI commands to them, and the parse the response and send more. I want to a decent language, good runtime, IDE/modern toolchain support. Can I just ssh into boxes? Yeah, uh, kinda? Or maybe I use aws-ssm to send/receive commands. Or kubectl or dockerrun. Or teleport. Or salt daemon. Each of them can do the job of "send command to a node". And I want to write meta-applications on top of that. So I settled on groovy: optional typing, if I want near-full JVM speed I can use CompileStatic, lots of scriptability, full JVM parallelism/threading power. The JVM sucks in some ways at running CLI commands locally, but once I figured that monstrosity out, got Jsch working for "pure" java SSH, caching kinda solved, thing.... So after about six rewrites, and a sufficient amount of configuration that makes a complicated ssh conf look like child's play, I can do cluster-level operations that make me happy: setup clusters, orchestrate/run/track load tests, fully scripted backups and restores, migrations/upgrades, red/black. Restore backups to analysis clusters. I'm not tied to a specific cloud. I'm not tied to a command delivery substrate. Is it useful to someone else? Dunno, I'll try to get it released and documented. Does anyone else know of something like this?