4 ms·

Have spent the past few months heavily working with Ansible and would totally recommend it for anyone wanting simple configuration management and orchestration.

Have spent the past few months heavily working with Ansible and would totally recommend it for anyone wanting simple configuration management and orchestration. The barrier to entry is extremely low, because it uses ssh and there are no remote agents, so you can get going pretty quickly. I have an introductory screencast on in @ https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...

erichmond 12y ago
The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.
- chimeracoder 12y ago
  > The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started. Having used Chef, Puppet, and Ansible, this is exactly why I prefer Ansible for all my projects now. If you can write a shell script, you can write an Ansible playbook. It won't be a great playbook, and you get benefits from using their modules instead of shell commands (like idempotency). But you don't have to worry about learning a new DSL just to do write a basic playbook or tweak an existing one. As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0]. [0] At least in 2015 - perhaps things will change as we move toward better containerization models
  - makmanalp 12y ago
    And it's also not that it's just a /new/ DSL - every so often I find the DSLs annoyingly limited compared to having a full fledged programming language.
  - cies 12y ago
    > Having used Chef, Puppet, and Ansible The only comparable system that I believe is a match for Ansible is SaltStack. > As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0]. Have you looked into Nix/NixOS/NixOps? I think they have a really good approach to "functional configuration mgmt". > perhaps things will change as we move toward better containerization models I agree. When using scrappable VMs/containers (deploy to a new one, then scrap the old one) that are build from a description, it is in some ways quite close to approach in the Nix-camp.
luca_barbieri 12y ago
I'm using Ansible as well, but I'm not really sure that it's better than just using shell scripts. The problem of something like Ansible is that you have to do a web search to figure out how to do anything, rather than just writing the shell command you already know to do it. The only major advantage is that it can tell you whether a configuration step changed the machine or not in a standardized format, which is something that shell cannot do without manually writing the code to do so. Ansible in particular is also much slower than shell, since it seems to do a network roundtrip for each command. This is pretty surprising, since the #1 performance concern in writing such a tool is of course precisely not doing that.

erichmond 12y ago

The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.

chimeracoder 12y ago
> The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started. Having used Chef, Puppet, and Ansible, this is exactly why I prefer Ansible for all my projects now. If you can write a shell script, you can write an Ansible playbook. It won't be a great playbook, and you get benefits from using their modules instead of shell commands (like idempotency). But you don't have to worry about learning a new DSL just to do write a basic playbook or tweak an existing one. As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0]. [0] At least in 2015 - perhaps things will change as we move toward better containerization models
- makmanalp 12y ago
  And it's also not that it's just a /new/ DSL - every so often I find the DSLs annoyingly limited compared to having a full fledged programming language.
- cies 12y ago
  > Having used Chef, Puppet, and Ansible The only comparable system that I believe is a match for Ansible is SaltStack. > As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0]. Have you looked into Nix/NixOS/NixOps? I think they have a really good approach to "functional configuration mgmt". > perhaps things will change as we move toward better containerization models I agree. When using scrappable VMs/containers (deploy to a new one, then scrap the old one) that are build from a description, it is in some ways quite close to approach in the Nix-camp.

luca_barbieri 12y ago

I'm using Ansible as well, but I'm not really sure that it's better than just using shell scripts. The problem of something like Ansible is that you have to do a web search to figure out how to do anything, rather than just writing the shell command you already know to do it. The only major advantage is that it can tell you whether a configuration step changed the machine or not in a standardized format, which is something that shell cannot do without manually writing the code to do so. Ansible in particular is also much slower than shell, since it seems to do a network roundtrip for each command. This is pretty surprising, since the #1 performance concern in writing such a tool is of course precisely not doing that.