ansible rant

Posted Oct 17, 2015 22:34 UTC (Sat) by yodermk (subscriber, #3803)
Parent article: Red Hat acquires Ansible

So our esteemed editor had a few qualms about how Ansible works; I now do too. My team mostly uses Puppet, but we're starting to use Ansible for orchestration tasks. I'm now really trying to get into it and learn it. But it seems that every time I do anything, some weird error comes up that forces me to Google how to do it right, and even then an obvious answer isn't always forthcoming.

I really wanted to love Ansible (not much of a Puppet fan) but I can't say I'm impressed at the moment. [The Puppet "language" isn't bad, but I *hate* writing tests and facts in Ruby... Python is one reason why I want to love Ansible.]

It just seems to me that while trying to make things "easy", they've come up with a weird language that seems very backwards to my brain. Am I alone in thinking this?

That said, I'm 100% in favor of the *idea* of this kind of thing. It really is needed. Hard to believe LWN (or I) got along so long without it.

Haven't looked much at SaltStack yet, but maybe it would be my cure (won't help at work though, we're tied to Puppet and Ansible).

ansible rant

Posted Oct 18, 2015 20:18 UTC (Sun) by picca (subscriber, #90087) [Link] (6 responses)

Maybe it is time for you to try something else

https://propellor.branchable.com/

ansible rant

Posted Oct 19, 2015 23:17 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (5 responses)

That looks…interesting. I'll have to look at getting a static propellor build to distribute to containers (or run it externally) since there's actual mention of systemd-nspawn (which I'll probably end up using for my infrastructure if I can get the requisite images built).

ansible rant

Posted Oct 20, 2015 18:42 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

After a closer look, it seems propellor runs on the *host* of the containers, not the containers themselves.

ansible rant

Posted Oct 21, 2015 8:45 UTC (Wed) by picca (subscriber, #90087) [Link] (3 responses)

I think that you are wrong.
In fact propellor is also run in the container, in order to setup all the properties you defined for it.

This is the nice part of propellor,
container or host you define the properties the same way :).

ansible rant

Posted Oct 21, 2015 12:48 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

Well, it's a problem when you're using buildroot to make 2.4M images (750K when compressed) and need to get a propellor binary in there :) . I'll have to get something based one this[1] though. I'd rather just remake the image and redeploy (potentially based on a committed root image) than have a cron job running anyways.

[1]https://propellor.branchable.com/todo/spin_without_remote...

ansible rant

Posted Oct 22, 2015 4:10 UTC (Thu) by joey (guest, #328) [Link] (1 responses)

Propellor can run inside a chroot or container without being actually contained within it. This is done by bind mounting a directory from the host with the propellor binary and the necessary libraries (and linker) to run it.

So, you could run propellor inside a chroot/container of the buildroot images without increasing their size.

ansible rant

Posted Oct 24, 2015 18:19 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

OK, that also sounds sufficient for my use case.

Basically my goal is to have a repo for *building* images using Buildroot and adds the generated images to the git repository as refs/images/$name/base (explicit refs used so that old images aren't cloned by default and don't take up disk space past the reflog history length). Propellor would then grab these tarballs from git and configure them. It'd be nice to tar the configured images up and put them in as refs/images/$name/latest which is then also created as refs/images/$name/deployed when deployed as well.

First is getting all of the services I use available in buildroot…but I can at least play around with those which are already available.

ansible rant

Posted Oct 19, 2015 14:20 UTC (Mon) by aaron (guest, #282) [Link]

I'd strongly recommend you check out SaltStack. In addition to config-management, my group has been using the heck out of SaltStack's orchestration and remote-management capabilities. Most of our release/deploy stuff is self-serve now via TeamCity (but any pretty web interface would do in its stead.)
We were *very* happy to go from Chef + Fab to an all-Python stack.

This is speaking as a grumpy sysadmin who's inflicted various combos of CFengine, Puppet, Chef, ClusterSSH and BASH-asshattery on my poor hosts. :)

I have some fiendish ideas for using some of the new reactive features, but I want to test them before commenting further.