11–20 of 71 posts
Could you explain what this line of code does? ssh -t user@example.com "$(
ssh -t user@example.com "$(cat ./my-setup-script.sh)"
I came from setup shell scripts (especially running in the postinstall step of debian-installer) to Ansible, and I think the big win with Ansible is at least the ideal of idempotency. That's a lot harder to achieve with plain shell scripts, unless you're pretty disciplined about only performing mutations to your system that are themselves idempotent (like a package install).
Could you explain what this line of code does? ssh -t user@example.com "$(
Looks like a fancier version of ssh -t user@example.com "$(cat ./my-setup-script.sh)" I'll have to file this away myself!
[bash] https://www.gnu.org/software/bash/manual/html_node/Command-S...
[posix] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
Could you explain what this line of code does? ssh -t user@example.com "$(
Could you explain what this line of code does? ssh -t user@example.com "$(
I came from setup shell scripts (especially running in the postinstall step of debian-installer) to Ansible, and I think the big win with Ansible is at least the ideal of idempotency. That's a lot harder to achieve with plain shell scripts, unless you're pretty disciplined about only performing mutations to your system that are themselves idempotent (like a package install).
Stupid question, but why are Ansible playbooks supposed to be "more idempotent" than plain shell scripts? Due to taking over a project I had to deep dive into it pretty quickly and to me it feels like shell in yaml syntax.
I came from setup shell scripts (especially running in the postinstall step of debian-installer) to Ansible, and I think the big win with Ansible is at least the ideal of idempotency. That's a lot harder to achieve with plain shell scripts, unless you're pretty disciplined about only performing mutations to your system that are themselves idempotent (like a package install).
Stupid question, but why are Ansible playbooks supposed to be "more idempotent" than plain shell scripts? Due to taking over a project I had to deep dive into it pretty quickly and to me it feels like shell in yaml syntax.
https://ryaneschinger.com/blog/ensuring-command-module-task-...
But as long as you're careful about coupling operations like lineinfile with checks for the line already being there and so on, you can achieve it (and Ansible certainly makes this much easier than shells scripts do).
I came from setup shell scripts (especially running in the postinstall step of debian-installer) to Ansible, and I think the big win with Ansible is at least the ideal of idempotency. That's a lot harder to achieve with plain shell scripts, unless you're pretty disciplined about only performing mutations to your system that are themselves idempotent (like a package install).
Stupid question, but why are Ansible playbooks supposed to be "more idempotent" than plain shell scripts? Due to taking over a project I had to deep dive into it pretty quickly and to me it feels like shell in yaml syntax.
There are a few tricks that Ansible uses that are non-obvious uses of shell - For example, files should be replaced by copying the new version to the target directory, then unlinking the original file and linking in the new version in it's place, finally unlinking the temporary file. This functionality has been implemented in the 'install' utility in gnu and bsd coreutils since the 80s (though it's not in POSIX, so it's not exactly guaranteed; You'd be hard-pressed to find a machine outside of busybox docker images that does not support it)
I came from setup shell scripts (especially running in the postinstall step of debian-installer) to Ansible, and I think the big win with Ansible is at least the ideal of idempotency. That's a lot harder to achieve with plain shell scripts, unless you're pretty disciplined about only performing mutations to your system that are themselves idempotent (like a package install).
I think this is much less of an advantage if you follow the pattern of "immutable servers", where, instead of mutating and updating servers directly, you just blow them away and provision new ones. The biggest benefit to systems like Ansible and Salt with that use case is the templating/config systems, which are much more flexible and powerful than what you can get with shell scripts (and which Welder, incidentally,…
It's not realistic to perform a multi-minute deploy (or have to be resetting VMs to snapshots) just to try out tweaks in your non-idempotent setup script.