1. 18
  1.  

  2. 4

    This is an interesting read. I was looking at pyinfra after it was posted here recently.

    At $WORK we heavily use Salt and almost everyone is frustrated with it. We have a lot of “spaghetti Jinja” thrown all over YAML which makes most of the states very difficult to read.

    On the flipside Ansible is conservative about where you can use Jinja, but your YAML is still semi-templated so there are some weird gotchas.

    For my personal things I find Salt works okay as I can keep it fairly clean with a small setup, but I’m not all that keen on using the master-minion setup. (I don’t use it in minion-only mode because I don’t want to have to have the repo on every server. I haven’t tried salt-ssh recently.) I tried Ansible briefly but I felt like I was fighting it a lot or having to weird twisty things to run a task N times for different inputs.

    I sometimes wonder if I should try Puppet again as it’s been nearly 8 years since I last used it. Having a DSL was sort of nice, if a little frustrating to use at the time, but I’m not that keen on Ruby so extending Factor was unpleasant.

    1. 4

      If the main purpose is to setup VPS and remote servers, I would consider NixOS where you can automate everything including the OS in a declarative way.

      1. 2

        I want to look into it some day.

      2. 3

        Interesting, I was looking into Ansible, but I might try this as well for comparison.

        I have to ask: I look at some of these scripts and wonder if a simple bash script is not shorter and more efficient than running python to install packages and move files around?

        Edit: typo

        1. 1

          Some of these tools are (semi-)declarative. For instance, in Ansible, you usually define how you want the server to be like, and Ansible goes in to check whether that’s already true. If it is, Ansible does nothing (further). There are also shell commands that just run a shell script on the server, so those are obviously not declarative and get run on every run. But that’s sometimes useful as well.

          This makes incremental development of a server using Ansible nice, since you can continuously keep running your whole stack to the server and only the changes get applied. Personally, after getting used to this, I consider the declarative nature to be the most important feature of such a tool.

          I’ve sometimes thought that it might be interesting to try a migration model for server maintenance instead. Then you could just dumb down everything to running simple shell scripts, and the system simply keeps books on which server migrations have been run and which not. This obviously only would work if you can trivially start over, since doing reversal migrations all the time would be nasty. And you would need to make sure nobody does manual changes without this system. But you need to make such a restriction anyway in order to properly handle any larger number of systems.

          1. 2

            That’s an interesting point, the incremental nature of Ansible. I really need to get experienced with it