3 ms·

It's like choosing programming language by selecting the one that's easiest for you to learn. You haven't learned anything beside new punctuation and keywords.

by dozzie 9y ago

It's like choosing programming language by selecting the one that's easiest for you to learn. You haven't learned anything beside new punctuation and keywords. Ansible is basically a glorified shell script executed semi-interactively through SSH. It doesn't exhibit a new paradigm in server management by any stretch. CFEngine, on the other hand, shows a whole another way to approach managing systems, and thus it's quite hard to learn (akin to learning Prolog or Coq after writing in Java). Puppet stems from that, but then slaps on top of that many weird and possibly unnecessary concepts, without much of an apparent plan or strategy, so it ended up a mess. Chef is a Ruby framework and some tooling around it, so no wonder it's more difficult to deploy than shell scripts through SSH.

tchaffee 9y ago
> It's like choosing programming language by selecting the one that's easiest for you to learn. It is. Is there anything wrong with that if the most important feature to you based on your requirements is that it be the quickest to learn? I needed something that was very quick to learn and I had most of my setup automated in Ansible before I had even finished trying to learn the other options. Ansible won hands down on the "easy to learn" factor. So far it meets all my needs, and thanks to Ansible Galaxy, I've had to do very little config myself. 95% of the time someone has already written what I need. > thus it's quite hard to learn Then it's definitely the wrong product based on my requirements at the time.
- dozzie 9y ago
  >> It's like choosing programming language by selecting the one that's easiest for you to learn. > It is. Is there anything wrong with that if the most important feature to you based on your requirements is that it be the quickest to learn? On its own it's not a wrong thing, but as I said, you didn't learn anything substantially different, so you're stuck with the approach that doesn't scale. You only added shell script SSH executor to your toolbelt, while you still haven't seen a proper configuration management system.
  - tchaffee 9y ago
    If I had spent the time to learn a "proper" configuration management system, it would have been a loss. I had a very limited amount of time to make it worth automating what amounts to a few hours of manual work. > you didn't learn anything substantially different So what? Learning something substantially different wasn't one of my requirements. My goal was to automate a few simple deployments, including my personal laptop setup, which previously took at least a day. Ansible got the job done and I haven't looked back. > You only added shell script SSH executor to your toolbelt You've said this enough that I'll push back. That's definitely wrong. I can write shell scripts. I would have never attempted this in a shell script. Ansible was far easier than writing a shell script, and it does a lot more than just executing scripts via SSH. For one, it checks the current state of the system it is configuring to determine whether or not software needs to be installed. > you're stuck with the approach that doesn't scale. That wasn't one of my requirements either. Although I'm not even sure your claim is true considering that there are some pretty big companies using Ansible, and it was recommended to me by someone who is one of the better programmers I have met in my long career. The whole point of my original post was that I actually tried products instead of reading about pros and cons. Based on my needs, Ansible was far superior to the other products I tried. Because my requirements aren't your requirements. I'm not so sure why it seems that it's so important to convince me and / or others that Ansible isn't a real tool. People should spend some time trying a few of the most popular tools and decide for themselves which tool best meets their needs. Which may include constraints like how much time they can budget towards learning a tool. "Proper" tool or not.
    - dozzie 9y ago
      >> You only added shell script SSH executor to your toolbelt > You've said this enough that I'll push back. That's definitely wrong. [...] For one, [Ansible] checks the current state of the system it is configuring to determine whether or not software needs to be installed. So you claim that Ansible learns the state of the system through some magic that is not possible to be called from shell? Because I could do pretty much the same in a shell script just fine. I've seen a different paradigm for managing servers, I thought about it for a long time figuring out the differences from a shell script, and this is not where they are. > I'm not even sure your claim [the approach doesn't scale] is true considering that there are some pretty big companies using Ansible There are many big companies that throw money at dumb processes only to make them running, so this argument is pretty weak. > [Ansible] was recommended to me by someone who is one of the better programmers I have met in my long career. You see, precisely this is the issue here. It was recommended to you by a programmer. You should have asked a sysadmin, because this is where these tools come from and whose tasks they do. For some strange reason, programmers tend to avoid tools available to sysadmins, which is a quite big blind spot (even more so, since it's usually unrealized blind spot).
vacri 9y ago
I started with Puppet and moved to Ansible. Ansible is much easier to debug, because everything happens in sequence and it doesn't freak out and break if you have the same identical command in two modules. Puppet builds this rats-nest dependency graph before it runs, and that's a pain in the arse to debug. Ansible's limitation is 'ssh bandwidth' - something like Puppet seems to me better for more heavyweight environments where you have three figures or more of servercount.
TeMPOraL 9y ago
There are many kinds of "difficult" - sometimes the difficulties may be just conceptual, other times it's because the tool is not good for the job you have in mind. For instance, I once took a serious look at Angular and then decided it's too difficult. I'm sure there is time and place for Enterprise JavaScript, but none of the things I'm doing right now would benefit from it (and frankly, neither do most of the smaller sites I've seen using it).

by dozzie 9y ago

tchaffee 9y ago

> It's like choosing programming language by selecting the one that's easiest for you to learn. It is. Is there anything wrong with that if the most important feature to you based on your requirements is that it be the quickest to learn? I needed something that was very quick to learn and I had most of my setup automated in Ansible before I had even finished trying to learn the other options. Ansible won hands down on the "easy to learn" factor. So far it meets all my needs, and thanks to Ansible Galaxy, I've had to do very little config myself. 95% of the time someone has already written what I need. > thus it's quite hard to learn Then it's definitely the wrong product based on my requirements at the time.

dozzie 9y ago
>> It's like choosing programming language by selecting the one that's easiest for you to learn. > It is. Is there anything wrong with that if the most important feature to you based on your requirements is that it be the quickest to learn? On its own it's not a wrong thing, but as I said, you didn't learn anything substantially different, so you're stuck with the approach that doesn't scale. You only added shell script SSH executor to your toolbelt, while you still haven't seen a proper configuration management system.
- tchaffee 9y ago
  If I had spent the time to learn a "proper" configuration management system, it would have been a loss. I had a very limited amount of time to make it worth automating what amounts to a few hours of manual work. > you didn't learn anything substantially different So what? Learning something substantially different wasn't one of my requirements. My goal was to automate a few simple deployments, including my personal laptop setup, which previously took at least a day. Ansible got the job done and I haven't looked back. > You only added shell script SSH executor to your toolbelt You've said this enough that I'll push back. That's definitely wrong. I can write shell scripts. I would have never attempted this in a shell script. Ansible was far easier than writing a shell script, and it does a lot more than just executing scripts via SSH. For one, it checks the current state of the system it is configuring to determine whether or not software needs to be installed. > you're stuck with the approach that doesn't scale. That wasn't one of my requirements either. Although I'm not even sure your claim is true considering that there are some pretty big companies using Ansible, and it was recommended to me by someone who is one of the better programmers I have met in my long career. The whole point of my original post was that I actually tried products instead of reading about pros and cons. Based on my needs, Ansible was far superior to the other products I tried. Because my requirements aren't your requirements. I'm not so sure why it seems that it's so important to convince me and / or others that Ansible isn't a real tool. People should spend some time trying a few of the most popular tools and decide for themselves which tool best meets their needs. Which may include constraints like how much time they can budget towards learning a tool. "Proper" tool or not.
  - dozzie 9y ago
    >> You only added shell script SSH executor to your toolbelt > You've said this enough that I'll push back. That's definitely wrong. [...] For one, [Ansible] checks the current state of the system it is configuring to determine whether or not software needs to be installed. So you claim that Ansible learns the state of the system through some magic that is not possible to be called from shell? Because I could do pretty much the same in a shell script just fine. I've seen a different paradigm for managing servers, I thought about it for a long time figuring out the differences from a shell script, and this is not where they are. > I'm not even sure your claim [the approach doesn't scale] is true considering that there are some pretty big companies using Ansible There are many big companies that throw money at dumb processes only to make them running, so this argument is pretty weak. > [Ansible] was recommended to me by someone who is one of the better programmers I have met in my long career. You see, precisely this is the issue here. It was recommended to you by a programmer. You should have asked a sysadmin, because this is where these tools come from and whose tasks they do. For some strange reason, programmers tend to avoid tools available to sysadmins, which is a quite big blind spot (even more so, since it's usually unrealized blind spot).

vacri 9y ago

I started with Puppet and moved to Ansible. Ansible is much easier to debug, because everything happens in sequence and it doesn't freak out and break if you have the same identical command in two modules. Puppet builds this rats-nest dependency graph before it runs, and that's a pain in the arse to debug. Ansible's limitation is 'ssh bandwidth' - something like Puppet seems to me better for more heavyweight environments where you have three figures or more of servercount.

TeMPOraL 9y ago

There are many kinds of "difficult" - sometimes the difficulties may be just conceptual, other times it's because the tool is not good for the job you have in mind. For instance, I once took a serious look at Angular and then decided it's too difficult. I'm sure there is time and place for Enterprise JavaScript, but none of the things I'm doing right now would benefit from it (and frankly, neither do most of the smaller sites I've seen using it).