AnsibleWorks Raises $6M
techcrunch.com
techcrunch.com
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?
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. :)
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?
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!
Thanks!
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.
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?
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.
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.
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.
1. https://github.com/puppetlabs/puppetlabs-postgresql/issues/1... .
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.
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. ++
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.
Congrats for the fund!
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.
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.
Succes!
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.
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.
http://www.ansibleworks.com/docs/api.html
> 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.
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.
https://github.com/ansible-provisioning/ansible-provisioning
http://jpmens.net/2013/06/18/adapting-inventory-for-ansible/
Especially for ec2 there is many modules that allows you to do that too. You can easily specify an inventory file which you populates dynamically.
There is also a lot being done about this in v1.3.
HTH
https://github.com/ansible/ansible/tree/devel/plugins/invent...
Can anyone who's worked with Puppet/Chef and Ansible offer some insights?
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.
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]
[1] http://tickets.opscode.com/browse/CHEF-3204
[2] https://github.com/ansible/ansible/issues/3776#issuecomment-...
[3] https://groups.google.com/forum/#!searchin/ansible-project/g...
(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 :)
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.
(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.
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.
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.
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 understand the part about GPL libraries forcing it on linked applications. However, not sure why it matters regarding stand-alone apps.
p.s.: I know this post could sound like veiled contempt, but I really am just curious and a trifle perplexed.