I tried Ansible just last week for automating server config and setup as it happens and was really impressed.
I was using shell scripts previously but like the idea I can just spin up a server and from the base OS, run a deploy which will install everything I need from a local recipe, including configuring and restarting services, and have the server ready to use in a few minutes. It took a few hours to learn the ins and outs of their concept of playbooks (just simple recipes for deployment), but I liked the way you can nest these so once you have a setup for say Postgresql that you like it is usable in any other recipes combined with other components.
The best bit is that it can be run multiple times when new configs are added - this means any config changes to say nginx can be done on the playbook and then replayed to send them to the server(s), over and over till the recipe is right. This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.
It'd be great if VPS providers had a library of Ansible playbooks - perhaps AnsibleWorks should consider having a library of playbooks which they manage on their website for common OS/setups and are downloadable from there? Their examples don't really cover all the bases as yet (I wanted Nginx/Postgresql for example), and it'd be nice if whatever setup you want there's already a playbook ready for.
I'm sure similar things are possible in other comparable tools like Chef and Puppet, but I liked that Ansible requires nothing on the server, doesn't require git etc. and has a simple declarative language rather than a dsl to learn - the configuration language is very simple - you can start just by executing commands and installing packages and build up from there.
Would anyone care to compare to Chef/Puppet for those who haven't used them?
I've used Puppet in a network of a few hundred hosts, mixed Linux and FreeBSD, and I can't complain.
However, I also started using ansible shortly after it came out and I much prefer their push model.
One sad note about the fast open source development we all love so much though, I setup ansible when it was still in 0.x, everything worked fine.
Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Everything had changed and I couldn't even get it to work. Not even after purging all the installed files of ansible. So now I have some studying to do. :)
I'd be interested in feedback as to what that was specifically, can you stop by our mailing list perhaps? If it was the 0.X conditional support getting that in line was a very major priority, to streamline it so we all have something we like going forward.
In general, we take a pretty hard line on backwards compatibility -- though some things with regard to "only_if" were pretty legacy and I think you'll like the newness a lot more. Anyway, please do stop by the list!
Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy.
Thanks for the heads up, I'll be sure to test before updating ansible in future. I suppose going from 0.x to 1.x you can expect some breakage, but hopefully after 1.0 formats will be pretty stable?
Well, it's a message bus, and requires initial setup, so you don't get the zero-boostrapping capability, and require the agent to stay running and have an open port continuously open to the server.
Yes, you can initiate local runs on other CM tools, but with ansible the multi-tier orchestration and rolling updates can be accomplished from the central server without it -- just set it up and run from a laptop.
Props to the ansible folks. After trying the more established tools I quickly appreciated not having to install their various runtimes and servers.
Also I came across an new alternative the other day which I find even simpler (maybe too simple) called pave:
https://bitbucket.org/mixmastamyk/pave ... anyone else heard of it?
Ansible has done a great job by including out of the box modules for most commonly used resources like PostgreSQL, ec2, NTP etc. It provides users standard code base which can be evolved/forked by community members. Of course, one can create a completely independent module code base, but it's nice to have a standard/curated code base.
Puppet: It's really difficult to find quality modules on the Puppet forge. Sometimes modules can give a false configuration impression. For example, when I had tested PostgreSQL module, the database owner wasn't being set properly [1]. I agree this can happen with Ansible modules as well. Also, badly written community modules can cause dependency issues (e.g. user1-http module uses user1-iptables module, but you are already using user2-firewall module etc..). It can be difficult to find good Puppet modules.
Chef: I haven't explored it much, but found it too complicated compared with Puppet and Ansible.
Chef/Puppet have a much higher learning curve and typically require you to set up a master. You can do things masterless but most of the docs I've read assume you have a master set up. Chef's documentation is incredibly awful and the only way to learn it seems to be by suffering through it. I would recommend Puppet over Chef but Ansible is just easier. If you have the time to learn Chef/Puppet then I guess go for it and you may find things you like more but if you're trying to get stuff done and want new folks to also be able to come up to speed fast then use Ansible.
The only problem with Ansible is that it is less mature so sometimes there may be features it doesn't support but the project is moving at an incredible pace and it is very extensible.
The amount of time I spent in Puppet writing modules to install things to a master was ridiculous. I could have not automated and done it manually, but I preferred bootstrapping Puppet with Puppet.
And that time you spend setting up a master? It's hopefully limited. But the joy doesn't end. Once your master is set up, then you get to install Puppet on every client too, and configure the client to point to your puppetmaster.
Ansible is really a data (or as they say, model) driven massively parallel shell scripting system with advanced templating, tailored for configuration management. It does a lot more, and it's design footprint is at the same time far less. ++
I was running into the same problem. So I wrote a playbook that deploys puppet agent using Ansible. https://github.com/rothgar/ansible-playbooks/tree/master/pla...
After writing that, and a few other playbooks, I really like Ansible and could see eventually replacing Puppet or at least using both in my environment.
> This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.
If you're not careful, you can do just that with Ansible pretty easily. Put a dotfile or something under ansible management, change your mind, and unless you do a complete run where you explicitly tell ansible to delete the file it will hang around and potentially cause issues.
Not that that's unique to Ansible or anything, but it's totally possible to have servers under configuration management for their whole lifetime, and have a subtly corrupt "master" config that's unable to be applied to a fresh OS install.
If you changed the file to state=delete it should store the fact that file should not exist though - that would avoid this problem wouldn't it?
Granted you're trading in a bit of convenience for having state controlled in this way -everything would have to go through your config tool (ansible in this case) - I found commenting out tasks after I was happy they were complete in order to experiment with the next part of the config was a good way to make config changes like this painless and quick though.
I'm with you on just commenting out or deleting things as you experiment up a new system config, but once you're using that config in production it's not as safe.
How it's going to affect, this raising, to the ansible project?
I mean, I like what I've used until now of ansible. I currently do not need the GUI. Is the ansible project going to continue it's development and licensing model? is there any possibility on ansible (without GUI) going "fremium" or any other functionality limitation with the time?
I just ask because I know that funds does not use to come for free and there use to be directives and guidelines which may affect a project...
I wish ansible is unaffected by the funders thoughts, even if I wish all the best for the ansibleWorks products too.
We're following exactly the same track record as before, and this was important in finding the right people to work with in the VC community.
We have already announced AWX, which is commercial software, and you can read about it at http://www.ansibleworks.com/ansibleworks-awx/ -- it's downloadable now and you can use it for up to 10 nodes free.
Basically the cutoff is ansible and ansible-playbook should be completely usable for all kinds of teams, but if you find the GUI useful, or want the REST API, or role based access control -- typically things enterprise companies do want, you have a product you can buy that adds a lot of value add on top.
We're going to continue merging in all kinds of great pull requests and features, and continue to expand the language where we need to, and modules.
One example of this is we recently were able to hire James Cammarata, who has been maintaining Cobbler, to work full time on just the OSS bits!
Another example of this is all of our support guys are also helping out on things like IRC, and helping with producing new example content and modules. All the recent modules for OpenStack are an example of one of these things.
Nothing is going to change in terms of licensing or the community at all, if anything, it allows us to have a lot more resources, help promote Ansible more, and move faster.
But yes, we're going to have a really awesome product as well, and I think lots of Ansible users are going to be quite interested in taking a look at it.
I love Ansible but I have a little bit of a complaint with the new website. The website used to be very focused on the product and how to get going fast. Now it seems more enterprisey with all of the major links on the frontpage linking to the solutions page which have way too much content for someone who isn't attached to the product yet. It seems almost more geared towards the business folks rather than the devops people like before. What I like about Ansible is that it gets you up running fast. Now, I have to spend a lot more time digging through the website to figure out what Ansible actually is. Even under Products, Ansible isn't there there. Instead, it lists Ansible AWX which makes very little sense w/o knowing Ansible first.
The documentation is still great and gets you going fast. I think the focus on the website with the Technology vs Solutions vs Products categories is uninviting to your core audience. Perhaps the reason for all of this is because Ansible != AnsibleWorks which makes sense. If that's the case though, I would recommend splitting up the two websites like 10gen did with Mongo ( http://www.10gen.com/ vs http://www.mongodb.org/ ). If you look at Mongo's site, it's very much straight to the point. However, 10gen's site is more focused on the business side of things.
Anyways, you guys are doing a great job with the actual project. See you around.
Seems as a sincere and clear explanation to me. Which is a big plus.
I'll look forward to the progress of ansibleWorks and I think the free until 10 servers model, is great to let the product be tested and even used in little projects.
The two things that makes me prefer ansible over chef/puppet/cfengine are:
1) being push based
2) working via shell over ssh.
There is a definite vantage, with a small install base, in not having to setup a server on either side and being able to control the process from the "admin" machine.
What would make ansible perfect for me would be ditching yaml and use python directly. It would be easier to extend and control programmatically, without the awkward variables and looping constructs it uses in yaml.
> Advanced programmers may also wish to read the source to ansible itself, for it uses the Runner() API (with all available options) to implement the command line tools ansible and ansible-playbook.
You can use any CF tool over ssh, this is not unique to ansible. In doing so, you can also "push" to any CF tool. You can also push by using more integrated tools, such as mcollective with puppet.
Given enough effort, you can do any 'X' with any 'Y'. The point is the design, future design, etc. all support that way and make it easy and robust out of the box.
Good for them! Ansible is amazing and everyone I've shown it to so far love it because it's just so much simpler to use than the alternatives. As soon as I found out about the project (before AnsibleWorks was even founded) I knew these guys were gonna be well off.
I love the concept, but I couldn't figure out how to make the server inventory dynamic. I tag a lot of instances and want to use the AWS API to grab a list of tagged instances to automatically build the server inventory on execution.
Since the instances are so variable (auto-scaling etc.) I see that as a killer feature. Maybe I have to dig deeper, but I spent some time evaluating it against Chef/Puppet etc. and I couldn't find anything.
not sure how long ago you tried it out, but ansible has an ec2 inventory script bundled along with it, that you can use instead of maintaining static manifests. This script plugs into the AWS API to get you a list of instances and metadata. Along with that, comes all the goodness of tags and pattern matching, so you can do stuff like tag_Name_DB*:&tag_type_slave to select all database slaves (if you had tags called "Name" and "type" for example)
That's awesome. I just spent some time going through the getting started section for each project so in my haste I missed all the best parts. Back to it!
I have been using chef (solo/server) for 2 yrs and started playing with ansible two weeks ago, so far, my comments:
Pros:
- ansible's creator is very active and helpful in github/mailing list in answering issues/questions; for chef, reproducible bugs can't even get an acknowledgement from opscode [1], free users are not their priority IMO
- simple in design, able to deploy multiple targets without a centralized monster like chef-server, you just need SSH
- batteries included, e.g. aws, linode, mysql, postgresql tasks
Cons:
- ansible is more buggy and still under heavy development
- documentation is confusing, e.g. current ansible latest is 1.2.2 but documentation showing features only appear in 1.3
- no playbook dependency handling
- build in modules are helpful but not really extensible [2]
- the creator is helpful but sometimes opinionated [3]
(A) Definitely file tickets on bugs. If there are things we don't know about we can't fix them :)
(B) Role dependencies I think are what you may mean. They are on deck for inclusion in 1.3 which is out this month.
(C) I would agree that core modules aren't subclassable by design though this is largely an artifact of how we are engineered to not have any dependencies for getting things going on remote nodes (zero bootstrapping). For the most part it works well and I'm fine with moving get_url into module common.
(D) Yay variable scope thread! No doubt, I do have opinions and we want to fight to keep things minimal. There was a recent proposal to inject role variables into the local namespace that fixes most of this, this is also something we are going to do in 1.3. I think that will eliminate most of the "prefix" ideas when you have variables defined in multiple places. I still think group_vars/ is a great place for defaults :)
Hi Michael, congratulation first and thanks for your prompt reply. It is amazing how you can be so attentive to the community.
For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line!
For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.
While I see your point on (C), there are characteristics of ansible that have led to that point, such as zero-boostrapping and keeping things very efficient. So yes, I agree that's true, but it hasn't been much of a problem so far.
(D) We're pretty big about backwards compat, so I'm definitely not going to be reverting any priorities. I think a lot of people DO like the way things are set up now. I'm open to including a 'defaults/' type directory in roles though and that's something we are exploring for those that want to ship defaults and don't want to edit their group_vars for whatever reason.
Same basic concept as the others. Ansible has Playbooks to Chef's Recipes. Ansible has Vars to Chef's data bags, and template files just like Chef or Puppet. For some reason, Ansible just ends up being much simpler to get going with. Probably because you write playbooks in a very straightforward yaml syntax, and the topology is not client-server - you just run Ansible right from your local terminal, like running knife I guess, with chef-solo. Just look at the documentation on their site, there's basically 3 or 4 pages you need to read before you're writing playbooks. I've worked with all three, Ansible is far and away the only sane one if you ask me.
I started with Chef, then switched to Puppet, then to Ansible. They all do similar things, but for me, Ansible was simplest and most productive.
Things I like best: Ansible relies on SSH and not a custom messaging system. Ansible requires no software to install/monitor on the remote systems. Ansible configs generally smaller and simpler, based on YAML and not a custom config file format.
Also I found it to be simple to extend Ansible with custom modules written in Ruby and Bash.
Would like to hear that as well. In my current project, vagrant is being provisioned with ansible. We chose ansible because it's easy to extend and its written in python. This project runs on freelancers, so its important the next django developer understands the provisioning system and custom modules as well.
For some reason I tend to prefer the idea of being more "abstract" like Salt is. So my private project (server+vagrant) is being provisioned with Salt. Like borplk i'm interested in opinions of people which have experience with both.
I'd be interested in hearing what you mean about being more abstract, but I think you'll like the simplicity angle.
In general, we build things with the goal of readability by diverse levels of skill and busy-ness -- to make things readable like a book and easy so you don't forget something in Ansible 6 months after you wrote it, and so you can dive in, get something done, and dive out.
We've got some IT managers saying they can tell employees to do X, Y, and Z, and not knowing Ansible, can still read the playbook. So, it should be fine for your freelancer case I'm sure. This is also why there is no graph dependency system, just handlers and notifies, so you can read things top to bottom.
Same here, I'd be interested to hear why you're moving in that direction.
I heard great things about Ansible and would love to try it, but in some of the environments I work in, using GPL software (especially v3) is not possible (in other environments it is perfectly fine).
Because I'd like to use the same system in all environments I work in, and because I strongly prefer a Python-based system, I'll probably go with Salt.
If there were a different licensing option than GPL, I'd look into Ansible first, based on all the comments I read about it so far.
I'm the open source curriculum coordinator at Pluralsight. We would love to commission a video to help devops people learn and use Ansible. Email geoffrey@pluralsight.com if you're interested.
I like Ansible, but I have to ask: Is $6M a lot for this sort of thing? It sounds like a lot to me for a GUI tool and "REST endpoint", whatever that means in this context. Is there enough of a market to return $6M x10 or whatever it takes to make the investment worthwhile?
p.s.: I know this post could sound like veiled contempt, but I really am just curious and a trifle perplexed.
I have no connection to Ansible or the deal but I think that you are probably forgetting the team that got them to the current state, their future potential and what they can do with 6M.
It doesn't seem to be a overly large round of funding. Look at comparable rounds at Puppet Labs & Opscode (so you'd probably want to look at Bs since the market is more validated now). Similar business models, and they should be valued similarly, too.
I was using shell scripts previously but like the idea I can just spin up a server and from the base OS, run a deploy which will install everything I need from a local recipe, including configuring and restarting services, and have the server ready to use in a few minutes. It took a few hours to learn the ins and outs of their concept of playbooks (just simple recipes for deployment), but I liked the way you can nest these so once you have a setup for say Postgresql that you like it is usable in any other recipes combined with other components.
The best bit is that it can be run multiple times when new configs are added - this means any config changes to say nginx can be done on the playbook and then replayed to send them to the server(s), over and over till the recipe is right. This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.
It'd be great if VPS providers had a library of Ansible playbooks - perhaps AnsibleWorks should consider having a library of playbooks which they manage on their website for common OS/setups and are downloadable from there? Their examples don't really cover all the bases as yet (I wanted Nginx/Postgresql for example), and it'd be nice if whatever setup you want there's already a playbook ready for.
I'm sure similar things are possible in other comparable tools like Chef and Puppet, but I liked that Ansible requires nothing on the server, doesn't require git etc. and has a simple declarative language rather than a dsl to learn - the configuration language is very simple - you can start just by executing commands and installing packages and build up from there.
Would anyone care to compare to Chef/Puppet for those who haven't used them?