111–120 of 186 posts
Wondering if RH will let Tower become Open Source.
Red Hat has a history of buying closed source software and releasing it as Open Source (KVM, Gluster, Cloudforms etc) so I would expect Tower to be open sourced. Assuming Ansible have the rights to all the code of course and dont license it from someone else of course.
Earlier quoted context omitted.
Spot on. I'm constantly amazed at how many projects use _serialization formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.
That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.
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 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 to me.
I am much more interested in Salt's ZeroMQ path these days. It seems to scale better, at least on paper and in my few small tests.
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.
If you aren't using Rails for your web-stack, I suspect you might not be using any Ruby at all on a server. It isn't even part of the CentOS minimal install. Python is. I'm not sure about how Ruby is used in Ubuntu, maybe it's more common there.
However, language choice alone makes Ansible more "compatible" with the rest of the RHEL stack.
I always wonder why cf-engine is so unpopular on HN. It has some nice advantages like no dependency on ssh or a scripting language. It is not as simple to get started, though.
Is SSH really a dependency you have to worry about though? Basically every server out there runs SSH.
If you're new to Ansible. I've created about two hours of free screencasts on it. It's a very simple to use and understand configuration management tool. https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl... https://sysadmincasts.com/episodes/45-learning-ansible-with-... https://sysadmincasts.com/episodes/46-configuration-manageme... https://sysadmincasts.com/episodes/47-zero-downtime-deployme...
This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarative' and easy to read, yet piling on loops and conditional statements and an unintuitive inheritance tree of global and local variables.
Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious (compared to mako for example).
Still I find its agentless model, the idempotent model, being able to use it on machines where you don't have root access etc... gives it a place that nobody had fulfilled.
I think the price point here is about a couple of things: - Chef and Puppet are too expensive for most companies to acquire, and have too much operational cost for too little revenue - Ansible got a strong following in the SMB space, Red Hat probably thinks they can move that upmarket some - Ansible's agentless configuration management has potentially strong applicability in a container world (why do I need a chunky…
Earlier quoted context omitted.
You can just run portions of the playbooks, but then you lose the value of a descriptive infrastructure. What does X look like? Depends on when each tag was run.
It shouldn't unless you're very careless. A tag that just updates all of the settings files and restarts the services should have the same effect as the full playbook run.
There are many potential situations where not running a full inventory against a running machine results in a machine not being properly configured.
I think the price point here is about a couple of things: - Chef and Puppet are too expensive for most companies to acquire, and have too much operational cost for too little revenue - Ansible got a strong following in the SMB space, Red Hat probably thinks they can move that upmarket some - Ansible's agentless configuration management has potentially strong applicability in a container world (why do I need a chunky…
I really don't understand why an organization would want to use Docker (besides buzzword compliance) if they were planning on mutating running containers. What's the advantage?