161–170 of 186 posts
Ansible creator, founder and CTO Michael DeHaan previously worked at Red Hat where he helped build Cobbler.
FYI- A lot of Ansible employees have a Red Hat past. The lead developer James Cammarata has, and is also the current Cobbler maintainer.
Ansible is best of breed. But didn't Red Hat hear? Immutable infrastructure is the future! http://michaeldehaan.net/post/118717252307/immutable-infrast...
Yes it is, but the future is not evenly distributed, to paraphrase William Gibson. For many enterprises, even Ansible's current model is already way out there in the distant future. Also, I think Ansible's idempotent model actually works nicely with immutable infrastructure. Why? For development of your stack. While messing around with it, you probably don't want to rebuild the whole thing from scratch. Of course you…
Earlier quoted context omitted.
I think what makes a product like ansible catch on is its use of a simple scripting language like python. This makes project participation more accessible. Ordinary sysadmins can write their own ansible modules with ease. It's possible that cfengine has that now but ask sendmail about repairing an old reputation.
Actually I think it's more the YAML config files than the fact it's written in Python. I learned 80% of Ansible in probably 10 days of writing playbooks and going through the infrastructure at my new job. Also I used to work with Puppet in an 8000 server environment and Ansible and Salt both are so much more fun and easy to use than Puppet. I hear the same thing over Chef too. Last Ansible is the only one that doesn'…
It's definitely good to not be forced to use agents everywhere + a dedicated "mothership" instance, but sometimes I do wish I had Ansible agents on my instances, just so I could "git push" the whole thing and forget about it.
Looking forward to Red Hat following on their good old habits and open-sourcing Tower.
Every time I use some "configuration management" tool I wonder whether it's really better than just using shell. Basically you lose a lot of time searching the web for how to do things that you already know how to do in shell, but the benefits are not so clear.
My experience with Ansible has not been so pleasant. Especially performance is a jobstopper. In my environment it takes 20 min for 12 Servers to be setup with some Redis, Elasticsearch stuff. Quite some become_user directives, but 20 min for this kind of stuff is just not acceptable. After all, application settings needs to be tuned and iterated over, too. My idea was to develop the infrastructure with Ansible, e.g.…
This has been my experience as well. Even using a small subset of a playbook via tags can take a long time, especially if you're doing a run in serial. One of our deployments that only affects six servers takes fifteen minutes. This can be mitigated somewhat by putting Ansible on the target machine, downloading all the necessary files to that machine, and then running Ansible locally... but that seems awfully fragile…
Finally, when using ControlPersist with pipelining mode in Ansible, it's as fast if not faster than zeromq or our own accelerated mode (which we will be deprecating at some future point when older SSH installs are not as common).
Earlier quoted context omitted.
Ansible's Python as well, so will integrate well with the rest of RHEL, whereas Puppet was nearly the only Ruby tool in the Unix sysadmin community. Not saying that one is better than the other, just than there's more Python out there in sysadminland.
I don't think that's necessarily true - both Puppet and Chef are Ruby, and you'll often hear Ruby referred to as the "lingua franca" of DevOps.
Earlier quoted context omitted.
> Lisp is not and has never been the right tool for configuration management. Why not? Configurations are collections of items, and among the things Lisp excels at is…lists of atoms. Take a look at https://github.com/ansible/ansible-examples/tree/master/lamp... (a simple LAMP stack implemented in Ansible). It uses a .ini-style file to manage lists of hosts, e.g.: [webservers] localhost [dbservers] bensible sensible W…
Oh, I didn't mean to say that S-expressions can't be used for configuration. It's that in general you don't want a Turing-complete language to do configuration management, because you want to be able to reason about things like rollbacks, dependencies and diffs.
In a S-expression-based configuration language, one would either embed an S-expression-based programming language, or generate the S-expressions with a programming language which can manipulate S-expressions.
I don't think that it's that easy to get away from needing Turing-completeness in general. No reason you can't still support rollbacks, dependencies and diffs anyway.
Earlier quoted context omitted.
> "apt-get -y install foo" that means that you want "foo" to be installed. If it's already installed, it just does nothing. not really. If you do that it means that you want to update foo to the latest version the system knows about. And other commands fail if the thing they are supposed to to is already done. Like `adducer`. So you could still run it and assume a failure to mean "the user already exists" - but it co…
Again, my advice is to take some time and learn the tools before discussing their strengths and weaknesses. You missed more Ansible strengths, like detecting changes and restarting only affected services for example. Show me the idempotent shell script which does apt-get to install some dependency, updates some configuration file, and then starts or restarts a service depending on both the current state of the servic…
Earlier quoted context omitted.
That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.
Lisp is not and has never been the right tool for configuration management.