7 ms·

Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote

Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. In many cases, Ansible is even easier than shell scripts. I wrote a post about this a few months ago: https://devopsu.com/blog/ansible-vs-shell-scripts/ https://devopsu.com/blog/ansible-vs-shell-scripts/ I completely understand where the sentiment is coming from though. I wrote a comparison book on Puppet, Chef, Salt, and Ansible a few months ago and am currently finishing the 2nd edition ( https://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html https://devopsu.com/books/taste-test-puppet-chef-salt-stack-... ). Even for an experienced sysadmin, using Puppet and Chef to do even a trivial project (replacing a ~10 line shell script) took a painful couple of days. Why? They're overly complex and have confusing broken documentation (that mostly haven't been corrected even 6 months after I gave them a full breakdown on the issues). Salt was pretty smooth, but Ansible was downright easy. Using a shell script to set up a server generally indicates that it will then be managed manually afterwards (sadness and despair!). A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. An idempotent command will verify that the system is how you defined it and will only make changes to bring the system back into alignment with what you defined. That means you can define your system in the language of the CM tool and use it not only for initial system setup, but also for monitoring, updating, and correcting a server's configuration over the life of the server. A CM tool can ultimately act like a self-healing test suite for your systems - neat! Your systems are the "app" that your app runs on. They're the foundation. Not using a CM tool is like not having any tests for your app. Sure, it might seem faster at first, but you'll pay for it in chaos, slowness, bugs, and misery later. Shell scripts are a great first step, but if you're serious about your systems, you need to be using a CM tool. Modern ones like Ansible are simple, easy, and have great docs so there's little excuse left for not using one now.

atweiden 13y ago
I use a Bash script to set up Arch with Btrfs on LUKS and optionally enable SSH [1]. Assuming you have a base machine running, config management tools are great and quickly start to make sense. If you're starting from scratch with a blank physical machine, I think the answer is still shell scripts and then add on CM afterwards. 1: https://github.com/atweiden/pacstrapit https://github.com/atweiden/pacstrapit
- enjo 13y ago
  "I think the answer is still shell scripts and then add on CM afterwards." I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.
  - joevandyk 13y ago
    you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.
    - kbenson 13y ago
      Isn't that what Redhat's kickstart (and it's equivalents in other distros) is for? Give you the minimum base you've decided your org wants systems installed with? It's trivial to add users, keys, initial firewall config, etc. If you deploy more than a few systems a year and don't have a PXE boot environment (or at least the equivalent of a network accessible kickstart config to be manually selected) or a golden image to deploy from, then I can see how CM tools may seem a pain, because you haven't tackled the initial manual pain point yet, the actual install. I haven't really used any CM tools, so maybe I'm getting the point where kickstart would traditionally leave off and ansible or chef would take over slightly wrong, but I can't see it being all that complex to automate configuring one after install.
    - e12e 13y ago
      No, you obviously have console access, all you need is the ansible scripts and ansible. If you want to push from a central repository, then yes, you'd have to have a way for ansible to reach the box. But we're taking as a given that there's a way to run commands on the box here (and get script files via the network). There's a difference if you want to run the scripts automatically on install (non-interactively).
    - mateuszf 13y ago
      Actually, to use Ansible you need only ssh access (with password or public key) to root user. Everything else can be done easily in a simple Ansible role.
_hyn3 13y ago
If using a cloud, another often overlooked option is to just tear down and replace the instance rather than try to update/correct its configuration. In that case, a shell script or Userdata script will be more than enough and represents a single source of truth for how a server will be built (never upgraded).
- mattjaynes 13y ago
  That's a great point. It's one reason Docker is so exciting - to be able to replace a running server in a sane and organized way is a killer feature. For many cloud environments, it'd be costly (in time and energy, not necessarily $) to replace all 1000 virtual servers for an update. With Docker, you can essentially do that in a trivial manner. I'm still learning Docker and my understanding is still a bit weak, but it's an exciting development in this regard.
rdtsc 13y ago
> Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. Well not blow your brains out difficult but "learn a new syntax, behavior, rules, depend on a new package" difficult if a few shell commands is all you want to do. I can see where they are coming from. I can go a long way just using shell script to configure (and yes, you can make them idempotent too). From your site: > You already have a religious passion for a particular CM tool Aren't you doing the same against Chef and Puppet then? It sounds like. Oh "comparison" -- yeah just use Ansible.
- mattjaynes 13y ago
  Good point: "if a few shell commands is all you want to do." Agree totally. If you're doing something tiny, then a few shell commands are what is needed, not a CM tool. I'm speaking mostly about serious systems that businesses run on. Ansible is not for everyone. Each tool has strengths and weaknesses. I generally push Ansible because it's the easiest to get started with, but can also scale to 10K+ nodes. If something simpler/easier comes along, I'll recommend that instead. I suspect some combo of Docker and Ansible to ultimately be the simplest set up (in the near-term), but I'm actively learning that and not confident enough in it to be able to suggest it to newbies.
  - gerhardlazu 13y ago
    I'm all Ansible & Docker on my personal projects / servers, what a blast! http://gerhard.lazu.co.uk/ansible-docker-the-path-to-continuous-delivery-1 http://gerhard.lazu.co.uk/ansible-docker-the-path-to-continu... More focus on the "why", less on the "how" http://thechangelog.com/ansible-docker/ http://thechangelog.com/ansible-docker/
- bashcoder 13y ago
  Well, I'm a Salt user and I was communicating with Matt during the writing of his book. During that time he certainly gave Salt a solid, fair evaluation. He also spent a lot of time hanging out in #salt IRC asking key questions, and answering some as well. So I would suggest that it's natural and OK for someone's evaluation process to yield a favorite (apparently in Matt's case, it's Ansible), without it becoming a "religious passion."
garyrichardson 13y ago
I used to work for a little company called The Internet Marketing Center. I'm not sure who taught you how to market this way, but I definitely giggled a little when I saw your site using IMC style long copy to sell tech ebooks. I may even buy a copy :)
- mattjaynes 13y ago
  Thanks Gary :) I got most of my inspiration from Kathy Sierra and Why the Lucky Stiff. They're waaaay better than me in this regard, but they taught me that most brains love a little whimsy. I try to add a little since systems engineering can slip into dryness pretty quickly if you're not careful. Little jokes like the borg cow can lighten things up: https://devopsu.com/newsletters/ansible-weekly-newsletter.html https://devopsu.com/newsletters/ansible-weekly-newsletter.ht... An added benefit is that whimsy helps filter out trolls. Adorable puppies, kittens, squirrels, cows, etc have a way of turning trolls away or at least softening them up a little :)
  - da02 13y ago
    I remember this genius edu. researcher (Alan Kay) talking about his dog: "...and my little dog, Watson..." I wondered why he would emphasize the diminutive nature of his adult dog. The closest guess I came to was: Even though this guy had no kids, his mind/body still is "programmed" to respond to baby-like features. That might explain why your cute pictures calm the trolls. Then again, I'm no neuro-socio-biologist.
mercurial 13y ago
> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to provision a second server with the same configuration and realize you're missing a runtime dependency. That's what I find fascinating about NixOS/NixOps: you can describe the entire state of the machine in a single configuration file (if you use the declarative style of package management). Of course, it won't help you if: - you already have a large number of non NixOS systems - you need many packages not present in NixOS - you'd like polished package management (the Nix package management still has a way to go before it reaches yum/apt ease of use)
- herokusaki 13y ago
  Are there VPS providers that offer NixOS by OOTB?
  - chongli 13y ago
    No need for that. The configuration management of NixOS is baked right into the installation procedure. This makes it super simple to install a fresh machine completely from the configuration.nix file that you've developed over time.
    - herokusaki 13y ago
      Well, with an OpenVZ VPS, the most common variety these days, you'd have to have it offered by the provider.
      - chongli 13y ago
        Ahh, I would never use a VPS that didn't let me use my own OS install image.
  - mercurial 13y ago
darklajid 13y ago
In my experience (playing with ansible, on and off, for quite a while) limitations or bugs in the tool often lead to your ansible scripts to become .. shell scripts. The more raw/command/shell modules you have to use, the uglier the whole approach seems to me - and maybe not worth the trouble in the first place. If it can't be done 100% 'right', should I bother? I put my efforts on hold so far. Ansible improved greatly (especially the documentation) lately, but .. it still feels cumbersome and hackish for my usecases.
- andrewvc 13y ago
  Writing ansible modules is really easy however. They're essentially just executables (usually python, but really any language), that take in JSON, and output JSON.
- bdunbar 13y ago
  > The more raw/command/shell modules you have to use Yeah, that's a problem. It's gotten a lot better with the 1.5 release. Example: we just made the light-speed jump from 1.1 to 1.5. While re-doing a role yesterday, I noticed we now have a module for ec2 snapshots. So _next_ week I'm replacing a 50-line bash script with a five-line playbook. Which will be run by Jenkins.
gangster_dave 13y ago
I agree. If someone claims Ansible is hard, they should go RTFM. Then if that doesn't work, they should go back to grade school. Ansible is easier than shell scripts by virtue of not having to write shell code. Then once Ansible Galaxy is out, config management will be trivial.
blueskin_ 13y ago
Ansible is easy compared to Puppet/Chef specifically because it doesn't use Ruby. That doesn't make it good.

atweiden 13y ago

I use a Bash script to set up Arch with Btrfs on LUKS and optionally enable SSH [1]. Assuming you have a base machine running, config management tools are great and quickly start to make sense. If you're starting from scratch with a blank physical machine, I think the answer is still shell scripts and then add on CM afterwards. 1: https://github.com/atweiden/pacstrapit https://github.com/atweiden/pacstrapit

enjo 13y ago
"I think the answer is still shell scripts and then add on CM afterwards." I'm genuinely curious. Why? Ansible, in particular, provides the same value (easy) but has existing modules to do a bunch of the things you'd have to script.
- joevandyk 13y ago
  you gotta setup the ssh user, modify/install ssh keys, install python if it's not there, possibly adjust firewalls, setup the hostnames, possibly tell the machine where to find the private dns servers, etc.
  - kbenson 13y ago
    Isn't that what Redhat's kickstart (and it's equivalents in other distros) is for? Give you the minimum base you've decided your org wants systems installed with? It's trivial to add users, keys, initial firewall config, etc. If you deploy more than a few systems a year and don't have a PXE boot environment (or at least the equivalent of a network accessible kickstart config to be manually selected) or a golden image to deploy from, then I can see how CM tools may seem a pain, because you haven't tackled the initial manual pain point yet, the actual install. I haven't really used any CM tools, so maybe I'm getting the point where kickstart would traditionally leave off and ansible or chef would take over slightly wrong, but I can't see it being all that complex to automate configuring one after install.
  - e12e 13y ago
    No, you obviously have console access, all you need is the ansible scripts and ansible. If you want to push from a central repository, then yes, you'd have to have a way for ansible to reach the box. But we're taking as a given that there's a way to run commands on the box here (and get script files via the network). There's a difference if you want to run the scripts automatically on install (non-interactively).
  - mateuszf 13y ago
    Actually, to use Ansible you need only ssh access (with password or public key) to root user. Everything else can be done easily in a simple Ansible role.

_hyn3 13y ago

If using a cloud, another often overlooked option is to just tear down and replace the instance rather than try to update/correct its configuration. In that case, a shell script or Userdata script will be more than enough and represents a single source of truth for how a server will be built (never upgraded).

mattjaynes 13y ago
That's a great point. It's one reason Docker is so exciting - to be able to replace a running server in a sane and organized way is a killer feature. For many cloud environments, it'd be costly (in time and energy, not necessarily $) to replace all 1000 virtual servers for an update. With Docker, you can essentially do that in a trivial manner. I'm still learning Docker and my understanding is still a bit weak, but it's an exciting development in this regard.

rdtsc 13y ago

> Have to say I'm a bit puzzled by the claim of Ansible being "blow your brains out" difficult. Well not blow your brains out difficult but "learn a new syntax, behavior, rules, depend on a new package" difficult if a few shell commands is all you want to do. I can see where they are coming from. I can go a long way just using shell script to configure (and yes, you can make them idempotent too). From your site: > You already have a religious passion for a particular CM tool Aren't you doing the same against Chef and Puppet then? It sounds like. Oh "comparison" -- yeah just use Ansible.

mattjaynes 13y ago
Good point: "if a few shell commands is all you want to do." Agree totally. If you're doing something tiny, then a few shell commands are what is needed, not a CM tool. I'm speaking mostly about serious systems that businesses run on. Ansible is not for everyone. Each tool has strengths and weaknesses. I generally push Ansible because it's the easiest to get started with, but can also scale to 10K+ nodes. If something simpler/easier comes along, I'll recommend that instead. I suspect some combo of Docker and Ansible to ultimately be the simplest set up (in the near-term), but I'm actively learning that and not confident enough in it to be able to suggest it to newbies.
- gerhardlazu 13y ago
  I'm all Ansible & Docker on my personal projects / servers, what a blast! http://gerhard.lazu.co.uk/ansible-docker-the-path-to-continuous-delivery-1 http://gerhard.lazu.co.uk/ansible-docker-the-path-to-continu... More focus on the "why", less on the "how" http://thechangelog.com/ansible-docker/ http://thechangelog.com/ansible-docker/
bashcoder 13y ago
Well, I'm a Salt user and I was communicating with Matt during the writing of his book. During that time he certainly gave Salt a solid, fair evaluation. He also spent a lot of time hanging out in #salt IRC asking key questions, and answering some as well. So I would suggest that it's natural and OK for someone's evaluation process to yield a favorite (apparently in Matt's case, it's Ansible), without it becoming a "religious passion."

garyrichardson 13y ago

I used to work for a little company called The Internet Marketing Center. I'm not sure who taught you how to market this way, but I definitely giggled a little when I saw your site using IMC style long copy to sell tech ebooks. I may even buy a copy :)

mattjaynes 13y ago
Thanks Gary :) I got most of my inspiration from Kathy Sierra and Why the Lucky Stiff. They're waaaay better than me in this regard, but they taught me that most brains love a little whimsy. I try to add a little since systems engineering can slip into dryness pretty quickly if you're not careful. Little jokes like the borg cow can lighten things up: https://devopsu.com/newsletters/ansible-weekly-newsletter.html https://devopsu.com/newsletters/ansible-weekly-newsletter.ht... An added benefit is that whimsy helps filter out trolls. Adorable puppies, kittens, squirrels, cows, etc have a way of turning trolls away or at least softening them up a little :)
- da02 13y ago
  I remember this genius edu. researcher (Alan Kay) talking about his dog: "...and my little dog, Watson..." I wondered why he would emphasize the diminutive nature of his adult dog. The closest guess I came to was: Even though this guy had no kids, his mind/body still is "programmed" to respond to baby-like features. That might explain why your cute pictures calm the trolls. Then again, I'm no neuro-socio-biologist.

mercurial 13y ago

> A huge advantage of using a configuration management (CM) tool is that they're "idempotent". Idempotency basically means that you can run the directives over and over again safely. They're idempotent only as long as the configuration stays the same. If you removed this "apt: package=XXX state=present" line, XXX is not going to be magically uninstalled, but you may have a nasty surprise the next time you attempt to provision a second server with the same configuration and realize you're missing a runtime dependency. That's what I find fascinating about NixOS/NixOps: you can describe the entire state of the machine in a single configuration file (if you use the declarative style of package management). Of course, it won't help you if: - you already have a large number of non NixOS systems - you need many packages not present in NixOS - you'd like polished package management (the Nix package management still has a way to go before it reaches yum/apt ease of use)

herokusaki 13y ago
Are there VPS providers that offer NixOS by OOTB?
- chongli 13y ago
  No need for that. The configuration management of NixOS is baked right into the installation procedure. This makes it super simple to install a fresh machine completely from the configuration.nix file that you've developed over time.
  - herokusaki 13y ago
    Well, with an OpenVZ VPS, the most common variety these days, you'd have to have it offered by the provider.
    - chongli 13y ago
      Ahh, I would never use a VPS that didn't let me use my own OS install image.
- mercurial 13y ago

darklajid 13y ago

In my experience (playing with ansible, on and off, for quite a while) limitations or bugs in the tool often lead to your ansible scripts to become .. shell scripts. The more raw/command/shell modules you have to use, the uglier the whole approach seems to me - and maybe not worth the trouble in the first place. If it can't be done 100% 'right', should I bother? I put my efforts on hold so far. Ansible improved greatly (especially the documentation) lately, but .. it still feels cumbersome and hackish for my usecases.

andrewvc 13y ago
Writing ansible modules is really easy however. They're essentially just executables (usually python, but really any language), that take in JSON, and output JSON.
bdunbar 13y ago
> The more raw/command/shell modules you have to use Yeah, that's a problem. It's gotten a lot better with the 1.5 release. Example: we just made the light-speed jump from 1.1 to 1.5. While re-doing a role yesterday, I noticed we now have a module for ec2 snapshots. So _next_ week I'm replacing a 50-line bash script with a five-line playbook. Which will be run by Jenkins.

gangster_dave 13y ago

I agree. If someone claims Ansible is hard, they should go RTFM. Then if that doesn't work, they should go back to grade school. Ansible is easier than shell scripts by virtue of not having to write shell code. Then once Ansible Galaxy is out, config management will be trivial.

blueskin_ 13y ago

Ansible is easy compared to Puppet/Chef specifically because it doesn't use Ruby. That doesn't make it good.