3 ms·

I don't have a problem with third party tools or need to run a setup scrip on Cygwin or LXSS, but shell scripting just seems easier than a tool like ansible bec

by ykler 10y ago

I don't have a problem with third party tools or need to run a setup scrip on Cygwin or LXSS, but shell scripting just seems easier than a tool like ansible because you have a full programming language (albeit a terrible one), and you can use familiar command line utilities to do everything. (You can use them in ansible too, but it is frowned on -- you are supposed to relearn how to do everything using modules that are usually less powerful than the equivalent command line utilities.) I have never had to manage a huge fleet of servers, so maybe ansible has advantages in that setting, but for setting up a single box it just seems to make everything harder.

geerlingguy 10y ago
When you have three+ Macs to configure, it starts looking more like a fleet and less like a single computer :) The main advantage I see is at it's a lot easier to reason with Yaml configuration than shell scripts with a ton of conditionals, and it's also easier to use Ansible's modules to make sure you can reprovision whenever you want to get new things added or old things removed.
- StavrosK 10y ago
  That's exactly my use case as well, which I detailed in a writeup: https://www.stavros.io/posts/provisioning-your-computer-one-command-awesome/ https://www.stavros.io/posts/provisioning-your-computer-one-... It's a great way to synchronize state between computers, including installed packages, fonts, Vim plugins, etc. It goes much further than dotfiles.
gnosek 10y ago
I'm a fan of Ansible, so let me reply to a few of your points :) 1. Playbooks are not a complete programming language for a good reason. You just get a simple linear flow of tasks with limited loops and conditions, so they're hard to make unreadable, unlike full-blown programming languages, like Python in Fabric or Ruby in Chef. 2. Yes, using shell commands for things that can be done using modules is frowned upon, but nobody is going to physically frown at you, so don't worry about it too much :) I drop down to shell/command/script modules whenever I need to without giving it a single thought. 3. Yes, the modules are often less powerful than the underlying tools. The other side is that they return nicely parsed data and changed/not changed status, so you can analyze their results more easily than shell commands. 4. Yes, ansible has immense advantages over shell scripting whenever one or more applies (generally the "manage a fleet of servers" scenario, not the "set up a dev box" one): - you need to coordinate configuration between multiple machines (sshing back and forth is just clumsy in comparison) - the playbook is to be used more than once (e.g. evolving configuration) -- I can't imagine my life right now without diffs and check mode. This also makes developing/debugging playbooks much easier than scripts, e.g. I recently wrote a hairy migration tool as a playbook and could easily see all the changes it would do without applying them - some things are just easier in ansible (template and lineinfile come to the top of my head, plus everything is parsed for you into easily usable data structures) 5. I'd probably use ansible to set up my own machine if I ever got to automating the task, but you're right: learning ansible just for that makes little sense.

by ykler 10y ago

geerlingguy 10y ago

When you have three+ Macs to configure, it starts looking more like a fleet and less like a single computer :) The main advantage I see is at it's a lot easier to reason with Yaml configuration than shell scripts with a ton of conditionals, and it's also easier to use Ansible's modules to make sure you can reprovision whenever you want to get new things added or old things removed.

StavrosK 10y ago
That's exactly my use case as well, which I detailed in a writeup: https://www.stavros.io/posts/provisioning-your-computer-one-command-awesome/ https://www.stavros.io/posts/provisioning-your-computer-one-... It's a great way to synchronize state between computers, including installed packages, fonts, Vim plugins, etc. It goes much further than dotfiles.

gnosek 10y ago

I'm a fan of Ansible, so let me reply to a few of your points :) 1. Playbooks are not a complete programming language for a good reason. You just get a simple linear flow of tasks with limited loops and conditions, so they're hard to make unreadable, unlike full-blown programming languages, like Python in Fabric or Ruby in Chef. 2. Yes, using shell commands for things that can be done using modules is frowned upon, but nobody is going to physically frown at you, so don't worry about it too much :) I drop down to shell/command/script modules whenever I need to without giving it a single thought. 3. Yes, the modules are often less powerful than the underlying tools. The other side is that they return nicely parsed data and changed/not changed status, so you can analyze their results more easily than shell commands. 4. Yes, ansible has immense advantages over shell scripting whenever one or more applies (generally the "manage a fleet of servers" scenario, not the "set up a dev box" one): - you need to coordinate configuration between multiple machines (sshing back and forth is just clumsy in comparison) - the playbook is to be used more than once (e.g. evolving configuration) -- I can't imagine my life right now without diffs and check mode. This also makes developing/debugging playbooks much easier than scripts, e.g. I recently wrote a hairy migration tool as a playbook and could easily see all the changes it would do without applying them - some things are just easier in ansible (template and lineinfile come to the top of my head, plus everything is parsed for you into easily usable data structures) 5. I'd probably use ansible to set up my own machine if I ever got to automating the task, but you're right: learning ansible just for that makes little sense.