AnsibleWorks Raises $6M

http://techcrunch.com/2013/08/12/ansibleworks-raises-6m-for-popular-open-source-and-easy-to-use-it-automation-framework/

by tomaac • 13 years ago

121 58 13 years ago

techcrunch.com

giulianob4• 13 years ago

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.

lyra-• 13 years ago

They deserve this so much ! For their amazing work and amazing support across irc/github/mailinglist <3

grey-area3• 13 years ago

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?

INTPenis• 13 years ago

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. :)

grey-area3• 13 years ago

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?

mpdehaan28• 13 years ago

Note: author of Ansible here.

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!

adient2• 13 years ago

Puppet supports a push model using mcollective. You can also just use ssh the same as ansible and use any CF tool to "push" changes.

digisign• 13 years ago

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?

jamie_ca2• 13 years ago

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.

grey-area3• 13 years ago

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.

knowshan• 13 years ago

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.

1. https://github.com/puppetlabs/puppetlabs-postgresql/issues/1... .

giulianob4• 13 years ago

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.

rektide• 13 years ago

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. ++

taude• 13 years ago

I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet...

Can anyone who's worked with Puppet/Chef and Ansible offer some insights?

donjigweed• 13 years ago

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.

andyl• 13 years ago

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.

tszming2• 13 years ago

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]

[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...

iffycan• 13 years ago

aye... opinionated he is :)

mpdehaan28• 13 years ago

So, to address some questions.

(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 :)

dschep• 13 years ago

I really want to use ansible (currently using salt), but I'm still waiting for the apt_repository pr[0] to get merged.

[0] https://github.com/ansible/ansible/pull/3783

borplk• 13 years ago

can you elaborate on why you are moving away form salt?

BozeWolf• 13 years ago

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.

liyanage• 13 years ago

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.

mpdehaan28• 13 years ago

Looks like this got merged an hour ago :) (Thanks James!)

bostonvaulter2• 13 years ago

That was only opened 6 days ago. Seems premature to be complaining about it.

purephase4• 13 years ago

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.

giulianob4• 13 years ago

The folks at the google group or IRC channel are super helpful. Ask there and you will usually get an answer fairly quick.

bhangm• 13 years ago

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)

purephase4• 13 years ago

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!

bryanlarsen• 13 years ago

If server manifest is executable, it executes the script rather than reading it.

purephase4• 13 years ago

Seems silly in hindsight to not consider that. ;)

susi22• 13 years ago

Don't call it "server manifest". It'll confuse people. You mean "inventory". You can dynamically populate "facts" and "inventory". See:

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

purephase4• 13 years ago

Excellent! Thanks for letting me know. I'll have to dive back in and check it out.

mpdehaan28• 13 years ago

Yeah check out the API chapter of the docs, there's information about all kinds of dynamic inventory scripts.

https://github.com/ansible/ansible/tree/devel/plugins/invent...

davis_m• 13 years ago

This is exactly the info I needed for some work I am doing. Thanks!

topfunky• 13 years ago

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.

zhynn• 13 years ago

Email sent! I would love to do this.

gosub• 13 years ago

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.

bryogenic• 13 years ago

If you really want to do that way you can, they explicitly call out that kind of functionality on their APIs and Integration's page.

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.

adient2• 13 years ago

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.

pessimizer• 13 years ago

You don't push to ansible, you push from ansible to a server that has never heard of ansible.

njharman• 13 years ago

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.

SEJeff• 13 years ago

Props to Michael and team. More options for python deployment and config management is a good thing.

txutxu2• 13 years ago

Hello, one question:

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!

mpdehaan28• 13 years ago

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.

txutxu2• 13 years ago

I'm glad to read this.

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!

giulianob4• 13 years ago

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.

andrewflnr• 13 years ago

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.

josephlord• 13 years ago

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.

3am• 13 years ago

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.

akurilin• 13 years ago

Big fan of Ansible, it's great that they'll have more resources to keep making the product even better.

AnsibleWorks Raises $6M

Related Stories