6 ms·

Find yourself a configuration management server such as Puppet, Chef, CFEngine etc, and learn to automate system deployment and management with it. I use Puppet

Find yourself a configuration management server such as Puppet, Chef, CFEngine etc, and learn to automate system deployment and management with it. I use Puppet CE as my main automation tool. Use Python/Shell for tasks that are not well suited for a configuration management server. Usually, this is when procedural code makes more sense than the declarative style of Puppet manifests. Interactive "wizards" (i.e. add domain users accounts to a samba server, and create home directories for them) and database/file backups are my usual uses for these types of scripts. Fabric is a useful tool to use with python. It allows you to send SSH commands that you put into functions to groups of servers in bulk. I also use python for troubleshooting network issues. It has libraries to interact with all manner of network services/protocols, as well as crafting packets and creating raw sockets. Look into PowerShell if you work in a Windows environment. Everything from Microsoft is hooked into PowerShell in their newer versions.

tchaffee 9y ago
I evaluated Puppet, Chef, and Ansible and Ansible was by far the easiest for me to learn. My favorite thing I use it for is my personal laptop setup. I can go from clean Ubuntu install to having all the software I use along with system settings all perfect within an hour, without me being involved.
- 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.
- zwischenzug 9y ago
  I wrote a simpler ansible :) https://learnxinyminutes.com/docs/shutit/ https://learnxinyminutes.com/docs/shutit/ use it all the time, eg: https://zwischenzugs.wordpress.com/2017/03/04/a-complete-openshift-cluster-on-vagrant-step-by-step/ https://zwischenzugs.wordpress.com/2017/03/04/a-complete-ope...
- VLM 9y ago
  The real world tends to have a diversity of hosts and an automation system that only partially applies is in many ways worse than none at all. I ended up with Ansible because it seems to require nothing on the far side but python2 and ssh. Everything else needed a specific version of a specific client software. CFEngine was particularly awful in a diverse setup, fighting SSL to make puppet work was never fun. I haven't found anything Ansible won't talk to, or can't be made to talk to eventually. I used Puppet for a bit less than a decade before switching to Ansible maybe two years ago, and I don't miss fighting its SSL at all. I miss when the puppetmaster would randomly crash and I'd find out when a deployment failed or worse failed partially, or when the puppetmaster process would take 5 minutes to start because, well, I donno why, but it sure was annoying. One interesting anti-pattern I saw over the years was people using puppet (or ansible or otherwise) as the worlds weirdest version control system. You can git pull a release branch, or you can write 10K custom lines (no kidding) of automation software to replace one line of 'git pull'. Depends if you're paid by hour/LoC or not. The borderline between "this is managed with ansible/puppet/wtf" and "this is managed by living in a git repo" can be annoyingly fuzzy and going to either extreme doesn't turn out well...
  - btown 9y ago
    The funny thing is that with Docker builds, that anti-pattern is cool again. Why bother telling the remote to pull from Git when you can just push it an entire disk image that knows nothing about source control? Of course, those 10K lines are still there, they're just hidden by Docker abstractions :)

tchaffee 9y ago

I evaluated Puppet, Chef, and Ansible and Ansible was by far the easiest for me to learn. My favorite thing I use it for is my personal laptop setup. I can go from clean Ubuntu install to having all the software I use along with system settings all perfect within an hour, without me being involved.

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.
zwischenzug 9y ago
I wrote a simpler ansible :) https://learnxinyminutes.com/docs/shutit/ https://learnxinyminutes.com/docs/shutit/ use it all the time, eg: https://zwischenzugs.wordpress.com/2017/03/04/a-complete-openshift-cluster-on-vagrant-step-by-step/ https://zwischenzugs.wordpress.com/2017/03/04/a-complete-ope...
VLM 9y ago
The real world tends to have a diversity of hosts and an automation system that only partially applies is in many ways worse than none at all. I ended up with Ansible because it seems to require nothing on the far side but python2 and ssh. Everything else needed a specific version of a specific client software. CFEngine was particularly awful in a diverse setup, fighting SSL to make puppet work was never fun. I haven't found anything Ansible won't talk to, or can't be made to talk to eventually. I used Puppet for a bit less than a decade before switching to Ansible maybe two years ago, and I don't miss fighting its SSL at all. I miss when the puppetmaster would randomly crash and I'd find out when a deployment failed or worse failed partially, or when the puppetmaster process would take 5 minutes to start because, well, I donno why, but it sure was annoying. One interesting anti-pattern I saw over the years was people using puppet (or ansible or otherwise) as the worlds weirdest version control system. You can git pull a release branch, or you can write 10K custom lines (no kidding) of automation software to replace one line of 'git pull'. Depends if you're paid by hour/LoC or not. The borderline between "this is managed with ansible/puppet/wtf" and "this is managed by living in a git repo" can be annoyingly fuzzy and going to either extreme doesn't turn out well...
- btown 9y ago
  The funny thing is that with Docker builds, that anti-pattern is cool again. Why bother telling the remote to pull from Git when you can just push it an entire disk image that knows nothing about source control? Of course, those 10K lines are still there, they're just hidden by Docker abstractions :)