36 ms·

Ansible Simply Kicks Ass

185 points by hunvreus 13y ago

vacri 13y ago
My run-in with Ansible was that it was incredibly slow. What took puppet 1 minute to do took Ansible 7 minutes. Not great for pushing changes. Sure, it could probably use some tuning, but then we're out of the realm of 'just works' and into 'chasing down -foo-'. It certainly looks like it has its use-cases though.
- hunvreus 13y ago
  We haven't experienced such kind of latencies. Quite the opposite actually.
- mpdehaan2 13y ago
  Interesting. I'd like to hear more if you stop by the list and I would have hoped you would have brought it up so we could have explored more. Still want to do that. Not a lot of data to go on in the above, but if you are specifying -c ssh, ControlPersist is good! Perhaps you were also trying to manage an AWS cloud from outside AWS. Better to install a control node inside the cloud in that case. Otherwise, I don't know, maybe a DNS issue? I'd need to know where your issues were to dig further. One thing ansible is pretty sharp at is grouping yum transactions, so if you had every package in a seperate line, with_items is a good thing to use too, that can make deployments extra zippy. Another thing you might be interested in is 'fireball mode' which uses SSH for key exchange and uses a more direct transport for making subsequent changes.
  - vacri 13y ago
    Unfortunately I wasn't the one that set it up, so i don't know the details. The coder who set it up left, and the other coders who picked up his project were complaining about the time it took to push changes to staging. After trying it in puppet, it turned out to be much faster, and we moved onto other things. I don't know any further details, sorry.
deleted 13y ago
[deleted]
piffey 13y ago
Another Ansible convert here. Our entire team uses it, we love it. We have a semi-unique situation where we have to do a lot of finagling to access some machines, don't always have control over what sits in front of them, and frequently have to comply with outside regulations. I won't go into too much detail, but Ansible is flexible enough and expandable enough to fit our needs. We were able to have Ansible reading from our custom inventory system in under a day, have expanded it to tie in with tons of internals, and all with very minimal effort. What would've taken weeks setting up with Puppet or Chef just falls into place. It's a beautiful thing. Highly recommend giving it a try, even if just to have a quick way of setting up your own dev machines.
- benjamincburns 13y ago
  > I won't go into too much detail Actually, can you? I don't mean can you give me an exact lay of the land, but what kinds of problems in this arena are you facing? I presently work in gov't contracting and so far you've defined my exact deployment scenario. That is, infrastructure architecture requirements (hardware/network config) are ever changing, and won't stabilize for some time. If you can't be more specific as to your problems, maybe you could at least let me know what about Ansible has made this easier to deal with?
bsaul 13y ago
anyone with both ansible and saltstack experience to compare ?
- nek4life 13y ago
  Very curious about the same thing.
- hunvreus 13y ago
  Haven't used it personally and hope my colleague can weight in on that one, but it was on the list of tools we evaluated end of last year while working with Chef. It use agents ("minions") and is architected very differently. Ultimately, we settled for Ansible because it uses lean and out-of-the-box tech, doesn't push dependencies on remote hosts and uses YAML extensively (close enough to JSON, actually I believe JSON is a subset of YAML).
- boothead 13y ago
  I started with salt a while ago (not serious production use) and recently picked up ansible. So far I'm coming down on the side of ansible. The config is a marginal improvement on salt (which is already pretty good) but I think the clinchers is the explicit push nature rather than the declarative state declarations in salt. I'm far from expert mind you and not using either in a serious production setting, so don't take my word on anything!
- maheart 13y ago
  I've used and continue to use, both. I like both tools, it's hard to choose one. Ansible advantages: +1 no client required. Python libraries may be required on the client machine to take advantage of certain modules (e.g. Python's postgresql library to use some parts of the postgresql module) +1 roles. A nice, best practice way to package up logical configurations (e.g. files, templates, tasks). +1 separate host files for prod/uat/dev/whatever you like. Keep all generic configuration tasks/roles host-agnostic. +1 very easy to write (and distribute) additional modules +1 uses SSH for all transport. I love that it uses something tried and true, secure, and robust like SSH. Based on comments on Salt's Github, Salt may be receiving something similar soon. A ZeroMQ mode (aka Fireball mode) is available in Ansible for speed. +1 sticks to Linux (Unix?) only. I like that Ansible is not targeting Windows (for now?); The Windows ecosystem is a very different community; with its own mindset and tools, and they'd prefer to use their own vs. something from Linux-land. This also allows Ansible to concentrate on getting really good on Linux/Unix. Salt stack advantages: +1 (+1 +1 +1) allows you to use Python (with Jinja2 templates) to express logic in configurations. Some people are against this (and tools like Puppet and Ansible try to hide programming from the user), but I feel this is a terrible idea. All that you end up doing is writing a configuration language that's Turing complete [joking!]). Some people will say: logic doesn't belong in configuration! But when you need to express conditions or loops, let me use a (standard, i.e. Python) programming language. I don't want to have to learn your DSL (which only your specific community knows about). So in summary, I'd love a tool, that has: - Ansible's "no client" setup - Ansible's logical way to package up configurations (roles) - Ansible's separate host file setup - Ansible's simplicity of writing (and distributing) modules - uses SSH (currently only Ansible, but might be available in Salt shortly) - Salt's templating being available in Salt states (Ansible's "playbooks"). This point alone puts Salt on even ground with Ansible. I cannot stress this point enough. This is the reason one of the main reasons I don't use Puppet and Chef.
dschep 13y ago
The main thing that irks me (last I tried it) is that the pkg repo functionality uses add-apt-repo. This makes it not work on Debian (6 was stable at the time) or with any repo that doesn't have a matching src repo. edit: docs indicate it's still a problem http://www.ansibleworks.com/docs/modules.html/#apt-repository http://www.ansibleworks.com/docs/modules.html/#apt-repositor...
- mpdehaan2 13y ago
  We've got a pull request to fix that one up, somewhat in progress - https://github.com/ansible/ansible/pull/3117 https://github.com/ansible/ansible/pull/3117.
  - dschep 13y ago
    Awesome! Might be switching from Salt soon. I _really_ like that I can just pip install it.
rurounijones 13y ago
> Doing this with Chef would probably mean chasing down a knife plugin for adding Linode support, and would simply require a full Chef stack (say hello to RabbitMQ, Solr, CouchDB and a gazillion smaller dependencies) It is throwaway lines line that where you really need to be careful since, no, you don't need to RabbitMQ, solr, couchdb etc. You can just use chef-solo which can also be installed with a one liner (albeit running a remote bash script) When comparing two products (especially in an obviously biased manner) you need to make sure you are 100% correct. Otherwise you weaken your case and comments like this one turn up.
- mpdehaan2 13y ago
  True, though chef-solo is a local-only solution. Ansible manages to manage remote machines without that kind of setup, and can start managing the remotes without installing anything on them.
  - rurounijones 13y ago
    Install chef-solo on server. scp locally dev'd (with vagrant ideally) cookbook to server Run cookbook 3 steps that can easily be wrapped in a little script (which I know a large company does because I saw their presentation about it on confreaks. Sorry I cannot remember the name of the company or presentation but it was a chef related one). Still not exactly killing it in terms of complexity. I would avoid comparing ansible to chef-solo in that respect and focus on bits where ansible has a clear (IMHO) win. Having said that I should say that I have not used ansible and am basing this on what I have read about it.
    - andyhmltn 13y ago
      You don't even need to do that. You can type `knife solo prepare root@my-server` and it will install chef-solo on that machine. Then type `knife solo cook root@my-server` and you're good to go.
      - rurounijones 13y ago
smoyer 13y ago
I agree ... Ansible is awesome. I'm using a single set of playbooks for my infrastructure with Jenkins to check out changes and push them to production machines. The same infrastructure definitions are used with Vagrant to give each developer an exact copy of the production system.
- herge 13y ago
  How do you let jenkins install packages and make changes to the machine? Passwordless sudo?
  - mpdehaan2 13y ago
    That's one way, you could also allow SSH key access as root too. Ansible also has a --ask-pass and --ask-sudo-pass if you want to provide a password.
    - herge 13y ago
      So you store a password that will give you root/sudo on your production machine in your deployment code, or just on your ci server?
      - mpdehaan2 13y ago
        I would suggest just using keys in this case.
  - smoyer 13y ago
    I turn off password access to production machines, so nobody accesses them without a known key anyway. Ansible has its own key installed on the servers and its account is allowed to sudo without a password.
    - herge 13y ago
      So if I can break into your ci machine (or just get jenkins to run random commands on your prod server, which is probably easier), I then have sudo access to your prod server? Using ansible from a local machine is fine, because you can make your devs type in passwords and etc, but I can't think of a secure way to do it with continuous integration.
StavrosK 13y ago
The only weak point Ansible has is that its documentation doesn't show enough real-life scenarios. Fortunately, it's really easy to grok and extend when you see a script, so I wrote this to help: http://www.stavros.io/posts/example-provisioning-and-deployment-ansible/ http://www.stavros.io/posts/example-provisioning-and-deploym...
- mpdehaan2 13y ago
  I agree, we need to fold more playbook examples into the docs for sure. Folks might be interested in checking out http://github.com/ansible/ansible-examples http://github.com/ansible/ansible-examples for some full-stack use cases showing playbooks that we do have.
  - StavrosK 13y ago
    Oh, thanks, that wasn't there when I started using Ansible. I'll take a look at those, they look very well structured, and very reusable.
  - georgebashi 13y ago
    I've just picked up ansible, and one thing I found lacking was an example ansible repository with a standard directory layout and config documented on the site or on github. For example, it's not obvious from the docs that a nice way to set things up is: site.yml ansible.cfg hosts host_vars/* group_vars/* roles/*/{files,templates,tasks,handlers,vars}
    - mpdehaan2 13y ago
      Have you seen http://www.ansibleworks.com/docs/bestpractices.html http://www.ansibleworks.com/docs/bestpractices.html ? Just noticed these don't mention "vars" in the roles directory, do need to fix that :)
      - georgebashi 13y ago
        I hadn't, doh! Thanks. Might be worth adding a link to that at start of the docs, because I found I was hesitant to start writing yamls without knowing the "right" structure for them.
mncolinlee 13y ago
Unfortunately, we were forced to toss out Ansible immediately in our tool selection process because it did not support Windows OS clients without Cygwin. Also, none of the "VM lifecycle management" tools we needed like Foreman or its commercial equivalents had any integrations with Ansible. These concerns left Ansible dead on arrival for us. It sounds like a decent tool if it matches your needs.
- mpdehaan2 13y ago
  (note: Ansible creator here) Yeah, there's no Windows now. If we do it, I'd want it to push powershell over native means. I'm still not 100% convinced it's something Windows admins want to do in a large enough number to focus on it, but input is always good and would be interested in hearing more about use cases folks want. As for lifecycle, Ansible has significantly less provisioning integration required than some of the other systems because all you need to do is get your SSH keys in there -- less bootstrapping. It also has a pluggable inventory system so you can get your list of hosts/variables from things like EC2 or OpenStack, so with things like cloud-init, that is usually what folks need. And there are some modules for spinning up new guests in various systems. (I'd like to see a vcenter inventory plugin too). I'm also the original author of Cobbler and there's integration with that on the provisioning side, and for something else similar, it's largely the case of writing an inventory plugin and making sure the key is installed.
  - jessaustin 13y ago
    I'm still not 100% convinced it's something Windows admins want to do in a large enough number to focus on it... I think this is much more common now that windows in the cloud is quite easy. (My company seems to have as many windows instances in EC2 as linux.) I do agree with your preference for powershell over cygwin.
  - mncolinlee 13y ago
    I'm glad to hear from the creator. That's one reason I love HN. Our Windows folks are big Powershell fans here. You wouldn't find too many complaints with it. The biggest problem going with Powershell would be bootstapping it into the environment if it's not already installed or if you depend upon a more recent version. Since we're actively evaluating lifecycle management tools right now, this is our main concern. Many of the integrations to provisioning tools flow downhill from frontends which manage the state of many systems. We find ourselves choosing the best-integrated stack rather than evaluating provisioning software. The plumbing is very important, but a well-written lifecycle tool should make the copper pipes less visible.
minsight 13y ago
I've been using Ansible in an EC2 environment and it's been fantastic. It's powerful enough, but its requirements are slight and you don't end up fussing with bootstrapping it into being. A server with Python (and a few little things that can be installed via Ansible/Python) will get you to a place where your instances are being populated.
3amOpsGuy 13y ago
This is definitely cool but the real hard problem isn't in these simple easily scripted cases. The real hard to solve problem is managing all the complexity of similar-but-different hosts. This article could just as easily have taken the complete opposite view of Ansible by saying things like "parallel ssh sessions don't scale, strong encryption costs too much CPU time; push can never work reliably therefore pull is the only viable model; etc. etc." I feel one of Ansible's strongest points to champion is the low barrier to entry. It takes minimal understanding to get going, compare that with at least 1 month hands on with cfengine or perhaps 2 weeks puppet before you would consider yourself proficient enough. With Ansible it's 20 mins or so.
- hunvreus 13y ago
  I keep on hearing these arguments of scale. I haven't ever experienced such issues. Now yes, if you're running Facebook infrastructure you may run into issues. Though honestly, who here manages more than a few hundreds hosts? I can't find the post that was making the point of encryption cost and parallel SSH sessions, but it'd be helpful to get actual hard numbers backing these claims, and how they compare to Puppet's or Chef's approach. I agree with the complexity of similar-but-different hosts, and that's actually something we're set to solve with devo.ps (we'll see if we pull if off).
  - 3amOpsGuy 13y ago
    To some extent i agree; most will never scale so why worry about it? X times out of Y you'll come out ahead by just ploughing on and not considering the future. Even if we are thinking up front, we can rationalise that it's just a gamble, often one worth taking! It definitely doesn't take Facebook sized infra to outgrow a technology though. What if the gamble doesn't pay off? What if you planned to scale the central NFS server dependency by just adding an extra NFS server but have now found there's no rack space left / no budget / a purchasing delay / insufficient network capacity / cooling capacity / power capacity / a.n. other unplanned problem. For the SSH question, i couldn't reliably get more than 250 concurrent connections outbound from one circa 2008 blade server. From memory that would have had a spec of dual core CPU, maybe around 2.4Ghz with 8Gb ram using PAE as it would have been a 32bit kernel (our spec, the cores will have been 64bit). They were multiply-connected at chassis level on myrinet fabric in one DC and infiniband in another and the resource being exhausted was CPU. These days all the blade servers are gone but we see an absolute explosion of virtual machines so it's a similar and still relevant problem in many ways.
lucaspiller 13y ago
> means minimal dependency on install (Python is shipped by default with Linux). I love how the Ansible "Getting Started" guide [0] first says you need to install Puppet 2.6, as 2.4 on CentOS / RHEL is not supported :) [0] http://ansibleworks.com/docs/gettingstarted.html http://ansibleworks.com/docs/gettingstarted.html
- IanCal 13y ago
  s/Puppet/Python There's a very big difference given the nature of this article. I thought that Ansible was dependent on Puppet and was quite confused.
  - mpdehaan2 13y ago
    Yeah the web page does not say that unless you have a really sneaky IRC proxy in the way :) Python 2.4 is all you need on remote nodes, but on the control machine you do need Python 2.6.
    - jessaustin 13y ago
      I have also needed a JSON lib installed on the target for python < 2.6. Is there some way around that?
      - mpdehaan2 13y ago
        Easiest is probably to use ansible's "raw" module to install it with yum, by feeding the http:// http:// URL to yum, unless you have EPEL already configured.
AaronBBrown 13y ago
I'm very curious about the breakdown of developers versus operations people who are in the middle of this love affair with Ansible.
- zhynn 13y ago
  I'm ops, but the cool thing about ansible is that it is easy to get devs to help. They know their software packages, I don't, but I can point them at a playbook and they can fairly easily fill out the basics, I can work on the orchestration after they have done the initial playbook design and testing. Chef (and formerly Puppet) had (for us) a much higher barrier to entry when it comes to getting an unfamiliar dev on board. We basically had to get reqs from the dev, and then we would build the recipes.
- mpdehaan2 13y ago
  From surveys we've done, I think the breakdown is about 60% on the ops side, 40% on the developer side. Obviously in a lot of startups, especially folks using cloud stuff, lines blur a lot. I wanted to make a language that was good for both, and easy to do ordered tasks, and a lot of app deployment requires ordered tasks and being able to do things on the result of other things. OTOH, sysadmins want a language that is easy to read and has the declarative state features, so it's kind of both at the same time.
serverascode 13y ago
I love ansible. Very straightforward to use--only problem is it's moving so fast I can't keep up. :) Good problem to have though. It's also the first open source project I've committed code to. Huge fan. I use it to run a small 8 node openstack system, as well as deploy Apache VCL.
njharman 13y ago
Used Chef before. In current gig, it's just me managing stuff. I picked Ansible over Chef and Puppet cause it's low(no) barrier to entry and simplicity. Also ability to ad-hoc commands means I didn't have to use another tool for that. In the 1year since, Ansible has exploded in capability. It isn't quite as low barrier anymore (more to config language) but still gobs lower than others. While adding much sophistication. I wouldn't even consider Puppet or Chef anymore. Salt or Ansible. Although, Python guy, so biased more than a little.
GowGuy47 13y ago
We use this over at useartisan.com and though I'm not one of the Dev ops oriented people here everyone who is using it seems to be really psyched on it. Glad people are contributing and it's gaining steam!
peterwwillis 13y ago
I'm sorry, but even as fairly smart tech guy this page was not helpful to me. It didn't tell me anything useful about Ansible. I was left wondering ".... how the hell does it work? how do I use it?" and basically had to investigate their homepage to figure out why I should care. If it was a sales pitch to get me interested, it worked, but what the hell are sales pitches doing on HN?
- mpdehaan2 13y ago
  If you want to find out more, perhaps you want to read http://ansibleworks.com/docs http://ansibleworks.com/docs instead?
  - peterwwillis 13y ago
    Well, that's my point... why have a page which basically just says "Ansible is cool! Go check it out!" I mean, that's cool that they like Ansible, but there wasn't any real content... it was just link bait, basically. I just find blatant advertisement or marketing to not be useful. I would rather they have posted a cool thing you can do with ansible, or really anything of any value other than a brief outline and a link.
- ChuckMcM 13y ago
  "but what the hell are sales pitches doing on HN?" I assume this is a rhetorical question :-) A number of folks on HN are either in a full-time or part-time dev/ops role and so tools that are developed in this space are interesting. Unlike other sites there aren't specific subcategories of interest on HN so you get the devops stuff with the politics stuff with the new language stuff with the economics stuff with the funky physics stuff with the the i-did-a-thing stuff. Ansible is an example of what is part of the Web 3.0 stack, dynamic but durable provisioning of resources out of a third party infrastructure.
sbt 13y ago
I think you can think of these tools on a spectrum from pull-based to push-based. I say spectrum, because many of them are in reality hybrid. Tools running agents are naturally pull-based, where as with push you don't necessarily need an agent (consider sand blasting ssh commands). CFEngine is by far the most pull-based tool as it is underpinned by a theory mandating this behavior. Puppet is pull-based but with more push, Chef is even more push based, and Ansible and Salt are (I guess) mostly push. In the end it depends on what is more practical for your situation. If you have a few machines, then more push will be practical, but the more machines you have, pull-based solutions scale better.
- mpdehaan2 13y ago
  Slight correction, ansible has a pull based mode, called ansible-pull, which simply scales with git. It's there if you want it! ansible-pull can also be easily deployed with regular ansible as well, if you want to do that, there's an example playbook. If you want solid reporting with pull mode, we're going to have a product release in the next month that has a cool callback based feature, where you get centralized reporting and nodes can still phone in any time and request configuration of themselves. Easy to bootstrap, it will just require a one-line wget to invoke a configuration request. I would not characterize SS as being push based in the same way, one of the things Ansible is really good at doing is orchestrating things "like an orchestra", so if you want to talk to the woodwinds, brass, percussion, and then go BACK to the woodwinds, you can. It's not simply saying this-than-that, etc. This enables things like the rolling update feature, and doing some pretty intricate multi-tier work. One of the major inspirations for Ansible was when I was building Func at Red Hat and wanting to build a multi-tier architecture management system. I still strongly believe you need a push based system for that, because you don't want to wait 30 minutes + 30 minutes + 30 minutes for all of those changes to stack up. Some other tools try to solve this by glueing layers on top, with Ansible, at least the intent is to build that in. So yeah, I think there are definitely times when you need both.
  - sbt 13y ago
    Yes, I think you need both pull and push, the ratio depending on the situation at hand. A senior sysadmin once told me that he asked all incoming recruits about what this proportion generally should be. The answer: 1/6 (16.6%) push and 5/6 pull (83.3%). I found that answer slightly amusing as it seemed overly general. On the other hand, he felt very strongly about that point and was quite annoyed with juniors' natural inclination to use push by default when pull could practically be used.
v5out 13y ago
We really wanted to use Ansible but couldn't get it to work with virtualenvwrapper. Has anyone done this (easily)?
- mpdehaan2 13y ago
  Not sure about virtualenvwrapper, as the setup process does want to install some modules for you, but Ansible runs pretty easily from a straight checkout. Source ./hacking/env-setup from a checkout and you are running live from there. So you may wish to just install the python package and then set up your library directory.
- mmgutz 13y ago
  Wierd, I haven't had any issues in my virtualenv. All I did was `pip install ansible`. The only hiccup was I had to `apt-get install python-dev` on Debian.
  - e12e 13y ago
    For those new to python/Debian this is an important point -- with python-dev and python-virtualenv installed (and also look out for "gcc" and/or "build-essential") -- generally a virtualenv made with "--no-site-packages" should have a fully working "pip" for installing most things. Gcc is sometimes needed to build (often optional) c extensions.
boothead 13y ago
One unanswered question for me is how to manager packages on different systems. Apache for example has a different name on RPM vs apt based systems, or you might have a different command to go the install (arch vs ubuntu for example). Can ansible do this? Can I easily migrate a playbook from using say apt-get to pacman?
- elbac 13y ago
  Typically your playbooks are more specific then 'do something vague' for example, install apache. You would say specifically, using 'apt' install the package 'httpd'. To see the package managers Ansible supports OOTB look at: http://www.ansibleworks.com/docs/modules.html#packaging http://www.ansibleworks.com/docs/modules.html#packaging For examples on how this can be abstracted to handle multiple platforms see: http://www.ansibleworks.com/docs/bestpractices.html/#operating-system-and-distribution-variance http://www.ansibleworks.com/docs/bestpractices.html/#operati...
voltagex_ 13y ago
I found Ansible quite tricky to use. I was trying to set up https://github.com/pas256/ansible-ec2 https://github.com/pas256/ansible-ec2 to manage some EC2 instances and it seems like I needed to replace a static config file with a script? Wouldn't that prevent me doing anything that wasn't EC2 with that instance of Ansible? Debian also moved the inventory files around in their package so that made things confusing.
airtonix 13y ago
Not ruby therefore instant awesome. Man! I really don't like ruby.
quicksilver03 13y ago
Is there any automated or semi-automated way to create an /etc/ansible/hosts file from a ssh config file? Not fully supporting the ssh config file is a real drag for me, I currently have several dozen hosts configured and I just don't want to retype everything for ansible to work.

185 points by hunvreus 13y ago

vacri 13y ago

My run-in with Ansible was that it was incredibly slow. What took puppet 1 minute to do took Ansible 7 minutes. Not great for pushing changes. Sure, it could probably use some tuning, but then we're out of the realm of 'just works' and into 'chasing down -foo-'. It certainly looks like it has its use-cases though.

hunvreus 13y ago
We haven't experienced such kind of latencies. Quite the opposite actually.
mpdehaan2 13y ago
Interesting. I'd like to hear more if you stop by the list and I would have hoped you would have brought it up so we could have explored more. Still want to do that. Not a lot of data to go on in the above, but if you are specifying -c ssh, ControlPersist is good! Perhaps you were also trying to manage an AWS cloud from outside AWS. Better to install a control node inside the cloud in that case. Otherwise, I don't know, maybe a DNS issue? I'd need to know where your issues were to dig further. One thing ansible is pretty sharp at is grouping yum transactions, so if you had every package in a seperate line, with_items is a good thing to use too, that can make deployments extra zippy. Another thing you might be interested in is 'fireball mode' which uses SSH for key exchange and uses a more direct transport for making subsequent changes.
- vacri 13y ago
  Unfortunately I wasn't the one that set it up, so i don't know the details. The coder who set it up left, and the other coders who picked up his project were complaining about the time it took to push changes to staging. After trying it in puppet, it turned out to be much faster, and we moved onto other things. I don't know any further details, sorry.

deleted 13y ago

[deleted]

piffey 13y ago

Another Ansible convert here. Our entire team uses it, we love it. We have a semi-unique situation where we have to do a lot of finagling to access some machines, don't always have control over what sits in front of them, and frequently have to comply with outside regulations. I won't go into too much detail, but Ansible is flexible enough and expandable enough to fit our needs. We were able to have Ansible reading from our custom inventory system in under a day, have expanded it to tie in with tons of internals, and all with very minimal effort. What would've taken weeks setting up with Puppet or Chef just falls into place. It's a beautiful thing. Highly recommend giving it a try, even if just to have a quick way of setting up your own dev machines.

benjamincburns 13y ago
> I won't go into too much detail Actually, can you? I don't mean can you give me an exact lay of the land, but what kinds of problems in this arena are you facing? I presently work in gov't contracting and so far you've defined my exact deployment scenario. That is, infrastructure architecture requirements (hardware/network config) are ever changing, and won't stabilize for some time. If you can't be more specific as to your problems, maybe you could at least let me know what about Ansible has made this easier to deal with?

bsaul 13y ago

anyone with both ansible and saltstack experience to compare ?

nek4life 13y ago
Very curious about the same thing.
hunvreus 13y ago
Haven't used it personally and hope my colleague can weight in on that one, but it was on the list of tools we evaluated end of last year while working with Chef. It use agents ("minions") and is architected very differently. Ultimately, we settled for Ansible because it uses lean and out-of-the-box tech, doesn't push dependencies on remote hosts and uses YAML extensively (close enough to JSON, actually I believe JSON is a subset of YAML).
boothead 13y ago
I started with salt a while ago (not serious production use) and recently picked up ansible. So far I'm coming down on the side of ansible. The config is a marginal improvement on salt (which is already pretty good) but I think the clinchers is the explicit push nature rather than the declarative state declarations in salt. I'm far from expert mind you and not using either in a serious production setting, so don't take my word on anything!
maheart 13y ago
I've used and continue to use, both. I like both tools, it's hard to choose one. Ansible advantages: +1 no client required. Python libraries may be required on the client machine to take advantage of certain modules (e.g. Python's postgresql library to use some parts of the postgresql module) +1 roles. A nice, best practice way to package up logical configurations (e.g. files, templates, tasks). +1 separate host files for prod/uat/dev/whatever you like. Keep all generic configuration tasks/roles host-agnostic. +1 very easy to write (and distribute) additional modules +1 uses SSH for all transport. I love that it uses something tried and true, secure, and robust like SSH. Based on comments on Salt's Github, Salt may be receiving something similar soon. A ZeroMQ mode (aka Fireball mode) is available in Ansible for speed. +1 sticks to Linux (Unix?) only. I like that Ansible is not targeting Windows (for now?); The Windows ecosystem is a very different community; with its own mindset and tools, and they'd prefer to use their own vs. something from Linux-land. This also allows Ansible to concentrate on getting really good on Linux/Unix. Salt stack advantages: +1 (+1 +1 +1) allows you to use Python (with Jinja2 templates) to express logic in configurations. Some people are against this (and tools like Puppet and Ansible try to hide programming from the user), but I feel this is a terrible idea. All that you end up doing is writing a configuration language that's Turing complete [joking!]). Some people will say: logic doesn't belong in configuration! But when you need to express conditions or loops, let me use a (standard, i.e. Python) programming language. I don't want to have to learn your DSL (which only your specific community knows about). So in summary, I'd love a tool, that has: - Ansible's "no client" setup - Ansible's logical way to package up configurations (roles) - Ansible's separate host file setup - Ansible's simplicity of writing (and distributing) modules - uses SSH (currently only Ansible, but might be available in Salt shortly) - Salt's templating being available in Salt states (Ansible's "playbooks"). This point alone puts Salt on even ground with Ansible. I cannot stress this point enough. This is the reason one of the main reasons I don't use Puppet and Chef.

dschep 13y ago

The main thing that irks me (last I tried it) is that the pkg repo functionality uses add-apt-repo. This makes it not work on Debian (6 was stable at the time) or with any repo that doesn't have a matching src repo. edit: docs indicate it's still a problem http://www.ansibleworks.com/docs/modules.html/#apt-repository http://www.ansibleworks.com/docs/modules.html/#apt-repositor...

mpdehaan2 13y ago
We've got a pull request to fix that one up, somewhat in progress - https://github.com/ansible/ansible/pull/3117 https://github.com/ansible/ansible/pull/3117.
- dschep 13y ago
  Awesome! Might be switching from Salt soon. I _really_ like that I can just pip install it.

rurounijones 13y ago

> Doing this with Chef would probably mean chasing down a knife plugin for adding Linode support, and would simply require a full Chef stack (say hello to RabbitMQ, Solr, CouchDB and a gazillion smaller dependencies) It is throwaway lines line that where you really need to be careful since, no, you don't need to RabbitMQ, solr, couchdb etc. You can just use chef-solo which can also be installed with a one liner (albeit running a remote bash script) When comparing two products (especially in an obviously biased manner) you need to make sure you are 100% correct. Otherwise you weaken your case and comments like this one turn up.

mpdehaan2 13y ago
True, though chef-solo is a local-only solution. Ansible manages to manage remote machines without that kind of setup, and can start managing the remotes without installing anything on them.
- rurounijones 13y ago
  Install chef-solo on server. scp locally dev'd (with vagrant ideally) cookbook to server Run cookbook 3 steps that can easily be wrapped in a little script (which I know a large company does because I saw their presentation about it on confreaks. Sorry I cannot remember the name of the company or presentation but it was a chef related one). Still not exactly killing it in terms of complexity. I would avoid comparing ansible to chef-solo in that respect and focus on bits where ansible has a clear (IMHO) win. Having said that I should say that I have not used ansible and am basing this on what I have read about it.
  - andyhmltn 13y ago
    You don't even need to do that. You can type `knife solo prepare root@my-server` and it will install chef-solo on that machine. Then type `knife solo cook root@my-server` and you're good to go.
    - rurounijones 13y ago

smoyer 13y ago

I agree ... Ansible is awesome. I'm using a single set of playbooks for my infrastructure with Jenkins to check out changes and push them to production machines. The same infrastructure definitions are used with Vagrant to give each developer an exact copy of the production system.

herge 13y ago
How do you let jenkins install packages and make changes to the machine? Passwordless sudo?
- mpdehaan2 13y ago
  That's one way, you could also allow SSH key access as root too. Ansible also has a --ask-pass and --ask-sudo-pass if you want to provide a password.
  - herge 13y ago
    So you store a password that will give you root/sudo on your production machine in your deployment code, or just on your ci server?
    - mpdehaan2 13y ago
      I would suggest just using keys in this case.
- smoyer 13y ago
  I turn off password access to production machines, so nobody accesses them without a known key anyway. Ansible has its own key installed on the servers and its account is allowed to sudo without a password.
  - herge 13y ago
    So if I can break into your ci machine (or just get jenkins to run random commands on your prod server, which is probably easier), I then have sudo access to your prod server? Using ansible from a local machine is fine, because you can make your devs type in passwords and etc, but I can't think of a secure way to do it with continuous integration.

StavrosK 13y ago

The only weak point Ansible has is that its documentation doesn't show enough real-life scenarios. Fortunately, it's really easy to grok and extend when you see a script, so I wrote this to help: http://www.stavros.io/posts/example-provisioning-and-deployment-ansible/ http://www.stavros.io/posts/example-provisioning-and-deploym...

mpdehaan2 13y ago
I agree, we need to fold more playbook examples into the docs for sure. Folks might be interested in checking out http://github.com/ansible/ansible-examples http://github.com/ansible/ansible-examples for some full-stack use cases showing playbooks that we do have.
- StavrosK 13y ago
  Oh, thanks, that wasn't there when I started using Ansible. I'll take a look at those, they look very well structured, and very reusable.
- georgebashi 13y ago
  I've just picked up ansible, and one thing I found lacking was an example ansible repository with a standard directory layout and config documented on the site or on github. For example, it's not obvious from the docs that a nice way to set things up is: site.yml ansible.cfg hosts host_vars/* group_vars/* roles/*/{files,templates,tasks,handlers,vars}
  - mpdehaan2 13y ago
    Have you seen http://www.ansibleworks.com/docs/bestpractices.html http://www.ansibleworks.com/docs/bestpractices.html ? Just noticed these don't mention "vars" in the roles directory, do need to fix that :)
    - georgebashi 13y ago
      I hadn't, doh! Thanks. Might be worth adding a link to that at start of the docs, because I found I was hesitant to start writing yamls without knowing the "right" structure for them.

mncolinlee 13y ago

Unfortunately, we were forced to toss out Ansible immediately in our tool selection process because it did not support Windows OS clients without Cygwin. Also, none of the "VM lifecycle management" tools we needed like Foreman or its commercial equivalents had any integrations with Ansible. These concerns left Ansible dead on arrival for us. It sounds like a decent tool if it matches your needs.

mpdehaan2 13y ago
(note: Ansible creator here) Yeah, there's no Windows now. If we do it, I'd want it to push powershell over native means. I'm still not 100% convinced it's something Windows admins want to do in a large enough number to focus on it, but input is always good and would be interested in hearing more about use cases folks want. As for lifecycle, Ansible has significantly less provisioning integration required than some of the other systems because all you need to do is get your SSH keys in there -- less bootstrapping. It also has a pluggable inventory system so you can get your list of hosts/variables from things like EC2 or OpenStack, so with things like cloud-init, that is usually what folks need. And there are some modules for spinning up new guests in various systems. (I'd like to see a vcenter inventory plugin too). I'm also the original author of Cobbler and there's integration with that on the provisioning side, and for something else similar, it's largely the case of writing an inventory plugin and making sure the key is installed.
- jessaustin 13y ago
  I'm still not 100% convinced it's something Windows admins want to do in a large enough number to focus on it... I think this is much more common now that windows in the cloud is quite easy. (My company seems to have as many windows instances in EC2 as linux.) I do agree with your preference for powershell over cygwin.
- mncolinlee 13y ago
  I'm glad to hear from the creator. That's one reason I love HN. Our Windows folks are big Powershell fans here. You wouldn't find too many complaints with it. The biggest problem going with Powershell would be bootstapping it into the environment if it's not already installed or if you depend upon a more recent version. Since we're actively evaluating lifecycle management tools right now, this is our main concern. Many of the integrations to provisioning tools flow downhill from frontends which manage the state of many systems. We find ourselves choosing the best-integrated stack rather than evaluating provisioning software. The plumbing is very important, but a well-written lifecycle tool should make the copper pipes less visible.

minsight 13y ago

I've been using Ansible in an EC2 environment and it's been fantastic. It's powerful enough, but its requirements are slight and you don't end up fussing with bootstrapping it into being. A server with Python (and a few little things that can be installed via Ansible/Python) will get you to a place where your instances are being populated.

3amOpsGuy 13y ago

This is definitely cool but the real hard problem isn't in these simple easily scripted cases. The real hard to solve problem is managing all the complexity of similar-but-different hosts. This article could just as easily have taken the complete opposite view of Ansible by saying things like "parallel ssh sessions don't scale, strong encryption costs too much CPU time; push can never work reliably therefore pull is the only viable model; etc. etc." I feel one of Ansible's strongest points to champion is the low barrier to entry. It takes minimal understanding to get going, compare that with at least 1 month hands on with cfengine or perhaps 2 weeks puppet before you would consider yourself proficient enough. With Ansible it's 20 mins or so.

hunvreus 13y ago
I keep on hearing these arguments of scale. I haven't ever experienced such issues. Now yes, if you're running Facebook infrastructure you may run into issues. Though honestly, who here manages more than a few hundreds hosts? I can't find the post that was making the point of encryption cost and parallel SSH sessions, but it'd be helpful to get actual hard numbers backing these claims, and how they compare to Puppet's or Chef's approach. I agree with the complexity of similar-but-different hosts, and that's actually something we're set to solve with devo.ps (we'll see if we pull if off).
- 3amOpsGuy 13y ago
  To some extent i agree; most will never scale so why worry about it? X times out of Y you'll come out ahead by just ploughing on and not considering the future. Even if we are thinking up front, we can rationalise that it's just a gamble, often one worth taking! It definitely doesn't take Facebook sized infra to outgrow a technology though. What if the gamble doesn't pay off? What if you planned to scale the central NFS server dependency by just adding an extra NFS server but have now found there's no rack space left / no budget / a purchasing delay / insufficient network capacity / cooling capacity / power capacity / a.n. other unplanned problem. For the SSH question, i couldn't reliably get more than 250 concurrent connections outbound from one circa 2008 blade server. From memory that would have had a spec of dual core CPU, maybe around 2.4Ghz with 8Gb ram using PAE as it would have been a 32bit kernel (our spec, the cores will have been 64bit). They were multiply-connected at chassis level on myrinet fabric in one DC and infiniband in another and the resource being exhausted was CPU. These days all the blade servers are gone but we see an absolute explosion of virtual machines so it's a similar and still relevant problem in many ways.

lucaspiller 13y ago

> means minimal dependency on install (Python is shipped by default with Linux). I love how the Ansible "Getting Started" guide [0] first says you need to install Puppet 2.6, as 2.4 on CentOS / RHEL is not supported :) [0] http://ansibleworks.com/docs/gettingstarted.html http://ansibleworks.com/docs/gettingstarted.html

IanCal 13y ago
s/Puppet/Python There's a very big difference given the nature of this article. I thought that Ansible was dependent on Puppet and was quite confused.
- mpdehaan2 13y ago
  Yeah the web page does not say that unless you have a really sneaky IRC proxy in the way :) Python 2.4 is all you need on remote nodes, but on the control machine you do need Python 2.6.
  - jessaustin 13y ago
    I have also needed a JSON lib installed on the target for python < 2.6. Is there some way around that?
    - mpdehaan2 13y ago
      Easiest is probably to use ansible's "raw" module to install it with yum, by feeding the http:// http:// URL to yum, unless you have EPEL already configured.

AaronBBrown 13y ago

I'm very curious about the breakdown of developers versus operations people who are in the middle of this love affair with Ansible.

zhynn 13y ago
I'm ops, but the cool thing about ansible is that it is easy to get devs to help. They know their software packages, I don't, but I can point them at a playbook and they can fairly easily fill out the basics, I can work on the orchestration after they have done the initial playbook design and testing. Chef (and formerly Puppet) had (for us) a much higher barrier to entry when it comes to getting an unfamiliar dev on board. We basically had to get reqs from the dev, and then we would build the recipes.
mpdehaan2 13y ago
From surveys we've done, I think the breakdown is about 60% on the ops side, 40% on the developer side. Obviously in a lot of startups, especially folks using cloud stuff, lines blur a lot. I wanted to make a language that was good for both, and easy to do ordered tasks, and a lot of app deployment requires ordered tasks and being able to do things on the result of other things. OTOH, sysadmins want a language that is easy to read and has the declarative state features, so it's kind of both at the same time.

serverascode 13y ago

I love ansible. Very straightforward to use--only problem is it's moving so fast I can't keep up. :) Good problem to have though. It's also the first open source project I've committed code to. Huge fan. I use it to run a small 8 node openstack system, as well as deploy Apache VCL.

njharman 13y ago

Used Chef before. In current gig, it's just me managing stuff. I picked Ansible over Chef and Puppet cause it's low(no) barrier to entry and simplicity. Also ability to ad-hoc commands means I didn't have to use another tool for that. In the 1year since, Ansible has exploded in capability. It isn't quite as low barrier anymore (more to config language) but still gobs lower than others. While adding much sophistication. I wouldn't even consider Puppet or Chef anymore. Salt or Ansible. Although, Python guy, so biased more than a little.

GowGuy47 13y ago

We use this over at useartisan.com and though I'm not one of the Dev ops oriented people here everyone who is using it seems to be really psyched on it. Glad people are contributing and it's gaining steam!

peterwwillis 13y ago

I'm sorry, but even as fairly smart tech guy this page was not helpful to me. It didn't tell me anything useful about Ansible. I was left wondering ".... how the hell does it work? how do I use it?" and basically had to investigate their homepage to figure out why I should care. If it was a sales pitch to get me interested, it worked, but what the hell are sales pitches doing on HN?

mpdehaan2 13y ago
If you want to find out more, perhaps you want to read http://ansibleworks.com/docs http://ansibleworks.com/docs instead?
- peterwwillis 13y ago
  Well, that's my point... why have a page which basically just says "Ansible is cool! Go check it out!" I mean, that's cool that they like Ansible, but there wasn't any real content... it was just link bait, basically. I just find blatant advertisement or marketing to not be useful. I would rather they have posted a cool thing you can do with ansible, or really anything of any value other than a brief outline and a link.
ChuckMcM 13y ago
"but what the hell are sales pitches doing on HN?" I assume this is a rhetorical question :-) A number of folks on HN are either in a full-time or part-time dev/ops role and so tools that are developed in this space are interesting. Unlike other sites there aren't specific subcategories of interest on HN so you get the devops stuff with the politics stuff with the new language stuff with the economics stuff with the funky physics stuff with the the i-did-a-thing stuff. Ansible is an example of what is part of the Web 3.0 stack, dynamic but durable provisioning of resources out of a third party infrastructure.

sbt 13y ago

I think you can think of these tools on a spectrum from pull-based to push-based. I say spectrum, because many of them are in reality hybrid. Tools running agents are naturally pull-based, where as with push you don't necessarily need an agent (consider sand blasting ssh commands). CFEngine is by far the most pull-based tool as it is underpinned by a theory mandating this behavior. Puppet is pull-based but with more push, Chef is even more push based, and Ansible and Salt are (I guess) mostly push. In the end it depends on what is more practical for your situation. If you have a few machines, then more push will be practical, but the more machines you have, pull-based solutions scale better.

mpdehaan2 13y ago
Slight correction, ansible has a pull based mode, called ansible-pull, which simply scales with git. It's there if you want it! ansible-pull can also be easily deployed with regular ansible as well, if you want to do that, there's an example playbook. If you want solid reporting with pull mode, we're going to have a product release in the next month that has a cool callback based feature, where you get centralized reporting and nodes can still phone in any time and request configuration of themselves. Easy to bootstrap, it will just require a one-line wget to invoke a configuration request. I would not characterize SS as being push based in the same way, one of the things Ansible is really good at doing is orchestrating things "like an orchestra", so if you want to talk to the woodwinds, brass, percussion, and then go BACK to the woodwinds, you can. It's not simply saying this-than-that, etc. This enables things like the rolling update feature, and doing some pretty intricate multi-tier work. One of the major inspirations for Ansible was when I was building Func at Red Hat and wanting to build a multi-tier architecture management system. I still strongly believe you need a push based system for that, because you don't want to wait 30 minutes + 30 minutes + 30 minutes for all of those changes to stack up. Some other tools try to solve this by glueing layers on top, with Ansible, at least the intent is to build that in. So yeah, I think there are definitely times when you need both.
- sbt 13y ago
  Yes, I think you need both pull and push, the ratio depending on the situation at hand. A senior sysadmin once told me that he asked all incoming recruits about what this proportion generally should be. The answer: 1/6 (16.6%) push and 5/6 pull (83.3%). I found that answer slightly amusing as it seemed overly general. On the other hand, he felt very strongly about that point and was quite annoyed with juniors' natural inclination to use push by default when pull could practically be used.

v5out 13y ago

We really wanted to use Ansible but couldn't get it to work with virtualenvwrapper. Has anyone done this (easily)?

mpdehaan2 13y ago
Not sure about virtualenvwrapper, as the setup process does want to install some modules for you, but Ansible runs pretty easily from a straight checkout. Source ./hacking/env-setup from a checkout and you are running live from there. So you may wish to just install the python package and then set up your library directory.
mmgutz 13y ago
Wierd, I haven't had any issues in my virtualenv. All I did was `pip install ansible`. The only hiccup was I had to `apt-get install python-dev` on Debian.
- e12e 13y ago
  For those new to python/Debian this is an important point -- with python-dev and python-virtualenv installed (and also look out for "gcc" and/or "build-essential") -- generally a virtualenv made with "--no-site-packages" should have a fully working "pip" for installing most things. Gcc is sometimes needed to build (often optional) c extensions.

boothead 13y ago

One unanswered question for me is how to manager packages on different systems. Apache for example has a different name on RPM vs apt based systems, or you might have a different command to go the install (arch vs ubuntu for example). Can ansible do this? Can I easily migrate a playbook from using say apt-get to pacman?

elbac 13y ago
Typically your playbooks are more specific then 'do something vague' for example, install apache. You would say specifically, using 'apt' install the package 'httpd'. To see the package managers Ansible supports OOTB look at: http://www.ansibleworks.com/docs/modules.html#packaging http://www.ansibleworks.com/docs/modules.html#packaging For examples on how this can be abstracted to handle multiple platforms see: http://www.ansibleworks.com/docs/bestpractices.html/#operating-system-and-distribution-variance http://www.ansibleworks.com/docs/bestpractices.html/#operati...

voltagex_ 13y ago

I found Ansible quite tricky to use. I was trying to set up https://github.com/pas256/ansible-ec2 https://github.com/pas256/ansible-ec2 to manage some EC2 instances and it seems like I needed to replace a static config file with a script? Wouldn't that prevent me doing anything that wasn't EC2 with that instance of Ansible? Debian also moved the inventory files around in their package so that made things confusing.

airtonix 13y ago

Not ruby therefore instant awesome. Man! I really don't like ruby.

quicksilver03 13y ago

Is there any automated or semi-automated way to create an /etc/ansible/hosts file from a ssh config file? Not fully supporting the ssh config file is a real drag for me, I currently have several dozen hosts configured and I just don't want to retype everything for ansible to work.