Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat is buying Ansible

venturebeat.com

Post reply on HN
Print view View original

121–130 of 186 posts

Re: Red Hat is buying Ansible

#121

Post by caw »

superuser2 wrote: post #118
mattzito wrote: post #55

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?

Config file changes rather than code changes. Version of the software stays the same, so you just have to restart it.

Re: Red Hat is buying Ansible

#122

Post by kangman »

WestCoastJustin wrote: post #58

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

yeah really helpful. I paid for these lessons and Justin was kind enough to refund me the cost when he moved on to Docker.

Re: Red Hat is buying Ansible

#123

Post by mattzito »

superuser2 wrote: post #118
mattzito wrote: post #55

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?

Well, there's a couple of scenarios:

- Long-running processes where they don't want to destroy and redeploy every single time a fix or change gets deployed

- One is where they try to reduce the configuration sprawl by making configuration changes at runtime using something like ansible

- One is straight-up bigco stupidity (we must have a way to change the running configuration of a system because the audit team says so)

- separation of responsibilities - we have one team that builds "approved" docker images, and then dev teams can make changes based on that - it might be easier to deploy changes at launch time

Again, I'm not saying all of these make sense, but back when I was workign on docker strategy and interviewing really big companies, these are the types of concerns they had about implementing docker at scale.

Re: Red Hat is buying Ansible

#124

Post by techdragon »

superuser2 wrote: post #118
mattzito wrote: post #55

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?

Managing the container hosts.

Re: Red Hat is buying Ansible

#125

Post by unethical_ban »

superuser2 wrote: post #118
mattzito wrote: post #55

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?

Containers are useful as an alternative to full VMs. I use LXC on Ubuntu, and I edit software and packages on my containers as I would a normal VM.

Maybe that's not standard with Docker specifically.

Re: Red Hat is buying Ansible

#126

Post by mrits »

rjsamson wrote: post #107
nailer wrote: post #104

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.

Since most people don't know Ruby I don't know how you can say this.

Re: Red Hat is buying Ansible

#127

Post by deckerdoes »

rjsamson wrote: post #107
nailer wrote: post #104

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.

I do most DevOps from a Java perspective. Languages aren't even mentioned here:

https://en.wikipedia.org/wiki/DevOps

Re: Red Hat is buying Ansible

#128

Post by pilif »

devit wrote: post #91
jjnoakes wrote: post #81

Earlier quoted context omitted.

Take the time to learn a tool like Ansible. It is not about replaying a simple sequence of commands (imperative). It is more about declaring what you want your system to look like, and letting the tool decide which pieces need to run based on the current state of the system. It's like make vs a shell script. If you use scripts to build your programs, you either have to write your own checks to test whether every step…

Most shell commands are actually "declarative" in a sense. If you run "apt-get -y install foo" that means that you want "foo" to be installed. If it's already installed, it just does nothing. In Ansible, you'd use "apt: name=foo state=present" which does exactly the same thing as the apt-get command, but requires a web search to figure out how to write (assuming you know normal Linux system usage but haven't memorize…

> "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 could of course also mean: "the user didn't exist, but creating it failed".

Then you start to have a look at the exit code which may be different between the two cases.

But every command behaves differently, so you need to learn all of this.

With Ansible (or puppet), the syntax is always the same and the actually needed operations are abstracted away.

Re: Red Hat is buying Ansible

#129

Post by crdoconnor »

falcolas wrote: post #119
crdoconnor wrote: post #106

Earlier quoted context omitted.

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.

And if you add a new machine to the cluster, which hasn't gotten all tags run against it? Or of a machine was temporarily offline when a tag was run, or... There are many potential situations where not running a full inventory against a running machine results in a machine not being properly configured.

>And if you add a new machine to the cluster

Then you'll probably be running the whole playbook again, including those settings changes you made before.

>Or of a machine was temporarily offline when a tag was run

Then it'll fail and give you a warning. Shrug your shoulders and run it again?

Re: Red Hat is buying Ansible

#130

Post by cpitman »

caw wrote: post #121
superuser2 wrote: post #118

Earlier quoted context omitted.

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?

Config file changes rather than code changes. Version of the software stays the same, so you just have to restart it.

But one of the central points of Continuous Delivery is that there is no difference between "configuration" and "code", and that changes for either of them will result in a new release candidate. Every release candidate goes through the same automated quality checks before going to production.
Post reply on HN