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

171–180 of 186 posts

Re: Red Hat is buying Ansible

#171

Post by justingood »

Sphax wrote: post #145
justingood wrote: post #138

Earlier quoted context omitted.

I think one thing to keep in mind about Ansible is that it's an orchestration tool that also does configuration management. We've integrated Ansible into our workflows in such a way that it kicks off everything we need to do, even if that involves just coordinating some info between APIs. We don't mutate containers at all - merely get Ansible to make things happen around their deployment and communication.

How do you use ansible to deploy your containers, if I may ask ? We're looking into the docker module right now, but I don't know if it's good or what. Currently we're launching container via systemd and manage the unit files with ansible.

We're running all the containers on Mesos hosts, so really all Ansible needs to do for us is talk to Marathon. We realized early on down this path that to accommodate scale we'd need to have some sort of scheduler. Mesos happened to be the most robust.

We originally tried the docker module in Ansible but found it had a few problems. There's been a lot of work on it since, and I expect it will be in a much better state when Ansible 2.0 is released.

Re: Red Hat is buying Ansible

#172

Post by justingood »

swinglock wrote: post #153
justingood wrote: post #143

Earlier quoted context omitted.

Ansible 2.0 should have some new strategies to speed things up, depending on your requirements: https://docs.ansible.com/ansible/playbooks_strategies.html It will be interesting to see how performance is after it's released. We eventually settled on having Ansible build an AMI for us that can then be spun up by as part of a Cloudformation template (also initiated by Ansible). We've actually been moving further and fu…

What do you use for configuration management?

We've moved to using Hashicorp's Consul-Template (https://github.com/hashicorp/consul-template). Ansible populates Consul with any required configuration changes during the deployment of a new version, and Consul-Template knows about these changes and automatically writes them to disk. Applications running on the host are then reloaded to pick up the changes.

Re: Red Hat is buying Ansible

#173

Post by firstprimate »

Jweb_Guru wrote: post #152
zeveb wrote: post #132

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.

Can you elaborate on this?

Re: Red Hat is buying Ansible

#174

Post by TeMPOraL »

firstprimate wrote: post #173
Jweb_Guru wrote: post #152

Earlier quoted context omitted.

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.

Can you elaborate on this?

I think this is something along the lines of what a friend once told me: "Compare the grammar of Java and C++. C++ has a very complex definition, whereas Java is brain-dead simple. And that fact enables all the powerful transformations IDE can do."

Also there's this school of thought that attributes most security problems to people accidentally using Turing-complete languages where they meant to use something less powerful. Consider vulnerability to arbitrary code execution through user input injection, which could be interpreted by your program being a "parser" (so-called "shotgun parser" - it's implicitly distributed throughout your code base) for a Turing-complete superset of what was supposed to be a list of accepted inputs. There are pretty good talks about this line of thought and I personally find it pretty interesting.

But none of this affects the fact that in complicated enough programs, you need "configuration" to be more code than data, which leads people not knowing of Lisp to reinvent a subset of it in XML or JSON or something similar.

Re: Red Hat is buying Ansible

#175

Post by bovermyer »

jimi_c wrote: post #165
bovermyer wrote: post #113

Earlier quoted context omitted.

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…

I'd be interested in hearing how this stacks up against simply running the tasks via shell scripts, because the time to install packages/do other tasks is orders of magnitude higher than the connection overhead. Things will always be slow when doing `serial: 1`, so I'd definitely recommend a canary setup where you run a play with a small serial batch followed by a play with no serial limitation - that'll speed things…

I'll admit to not knowing what ControlPersist is. I have some reading to do, it would seem.

Re: Red Hat is buying Ansible

#176

Post by antod »

mbreese wrote: post #114
rjsamson wrote: post #107

Earlier quoted context omitted.

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.

In certain shops that may be true, but definitely not all. Python has had a large role in Red Hat's tools for a very long time so I bet you'll find more Python than Ruby in sysadmin-land overall. 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…

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

There is no Ruby installed by default in Ubuntu - or Debian last time I looked. Also (like Redhat) a significant chunk of the userspace distro code is written in Python.

Currently Vagrant is the only Ruby tool I use in sysadmin/devops land, and it's a workstation only installation rather than a server one.

Not having to deploy a whole new language runtime for your devops tooling is why I preferred Ansible and Salt over Chef and Puppet.

Re: Red Hat is buying Ansible

#177

Post by homulilly »

I like what I've seen of ansible but a lot of their modules are a complete mess. I've run into problems with both their AWS and Docker modules and ended up resorting to a series of tasks running shell commands because it was more reliable and didn't require me to install a specific version of some python library on every single machine.

Re: Red Hat is buying Ansible

#178

Post by firstprimate »

TeMPOraL wrote: post #174
firstprimate wrote: post #173

Earlier quoted context omitted.

Can you elaborate on this?

I think this is something along the lines of what a friend once told me: "Compare the grammar of Java and C++. C++ has a very complex definition, whereas Java is brain-dead simple. And that fact enables all the powerful transformations IDE can do." Also there's this school of thought that attributes most security problems to people accidentally using Turing-complete languages where they meant to use something less po…

Right. That addresses the point about mangling YAML into something that looks like a language. It was this that made be curious: "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."

Re: Red Hat is buying Ansible

#179

Post by dsmithatx »

Florin_Andrei wrote: post #163
dsmithatx wrote: post #105

Earlier quoted context omitted.

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'…

My thoughts exactly on all points except the last one. 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.

Well to be fair I use Codeship with Tower to do auto-deployments so, if I "git push" to dev I'm done.

Re: Red Hat is buying Ansible

#180

Post by icebraining »

wstrange wrote: post #158
icebraining wrote: post #141

Earlier quoted context omitted.

You could keep Postgres in an immutable image, with only /var/lib/postgres in a separate volume. Upgrading the PG config would just be a matter of unmounting it, replacing the image and re-mounting. (Docker automates this with its "data volumes", but you can do it manually too).

In theory yes - but that strategy doesn't always work. Sometimes the implementation of the data store changes between releases - requiring an upgrade or data migration. For large datasets that can take hours / days.

That may prevent the simple unmount/replace image/mount workflow, but it doesn't prevent the separation between the mutable and immutable parts of the DBMS.
Post reply on HN