JP Vossen on 27 Jun 2016 14:32:55 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Ansible for updating in the field

More good ideas, esp.:

I know I read the latter one but now might be a good time for a review. --check, "--check --diff", --syntax-check, --list-hosts, and --list-tasks are all really handy. I'd still love a "--transcript" that would give me what it *would* do; like "--list-tasks" but more detailed, with all variables shown *interpolated*, and all branch logic followed. I realize that's a lot easier said than done, but imagine the uses! Among other things, Ansible is readable enough that it's literally step-by-step instructions for hard-copy DR docs.

I certainly can't do github. Internal Gitlab might work, but it's supposed to be SVN internally and there is...tension...on those kinds of issues. (Sigh.) But I doubt pull requests would work, you can barely get some of them to do tickets...

On 06/27/2016 04:45 PM, brent timothy saner wrote:
On 06/27/2016 04:15 PM, JP Vossen wrote:
Thanks Brent!  It sounds like I'm not missing anything obvious, and I
like your path forward.

thanks! i did it with a large number (can't say how many exactly because
NDA, but i will say "100*n") of servers recently, so this is coming from
what i learned.

"LUGs: where others make mistakes so you can learn from them!"

I have SSH connectivity as a non-root user who does have `sudo` access.

Yup, I do that all the time, that's why I (unclearly) mentioned I'm good
to go there.

ah! sorry, i think i missed that.

By my design, all my 120+ files can be arbitrarily overwritten, any
special snowflakes are handled via *.local files that are per-device and
only ever touched manually.  (The nodes are mostly cattle, not pets, but
there are some "special" ones.)

this can be handled by ansible logic. there's a couple different ways to
do this- via jinja2, host_variables, or the least-elegant "when: != 'somehostname'".

Yes, but that also requires that the tier1/tier2 guy who did the work
tells me about it, so I don't accidentally nuke it later.  That will not
happen, so the policy is "only ever touch one-offs manually, on the
device."  Yes , that sucks, but there it is.

I might have another project that might help that later, but that's
months out at least, so for now...

This could probably serve you well in at the least detecting it:

With some perl or python (and the --diff flag), you could probably even
write out some "patching" to your templates or host_vars or what have
you to keep it consistent down the line.

I already have a `` that can install missing RPMs, create
symlinks, fix permissions/owner, etc.  It is idempotent and designed to
be run any time just for the hell of it to make sure stuff is correct.
There were Good Reasons to start that way instead of Ansible from
scratch, but now I'm torn.  The tier1/tier2 folks working on these
devices will not have Ansible access, nor do they have strong Linux
skills, so having a local "just make it right" script is very handy.
OTOH, it duplicates the hell out of Ansible's domain.

who says you can't have both? granted, it means any updated
checks/tasks/etc. have to be now added to two places instead of one, etc.

That's why, double-entry is BAD.

an alternate idea here might be to set up a git project (via gitolite
or.. (sigh) github or gitlab) where the tasks/playbooks/etc. could be
kept with ACL. give T1 and T2 seperate branches and have them submit
pull requests (REAL[0] ones, preferably ;) ), and merge them into *your*
branch (which the ansible master can then do a cron'd pull from).

-requires extra steps from T1/T2
-...requires T1/T2 to read/write YAML.
-requires review before adding it to production deployment

it's a bit overcomplicated, but i'm an engineer. we can't help it.

alternatively you could just use the copy module to copy over the
relevant task/playbook/what have you, have ansible installed on the
local machine, and run it via local_action or ansible host as

I could.  As below I was thinking was a better fit though.

i didn't even know this was a thing. thanks!

there are more elegant ways, however:

Oh that's awesome!  I used to with with Stavros at $WORK-- and I've
talked about Ansible with him a little, but never about pull that I
recall.  I do follow his blog.

I really want a push though, my question is just about the best way to
organize it in Ansible idiom.

due to how every infra's different and there's so many ways to skin a
cat(1) in *nix, this is i'd say largely up to you and your organization.
however, this gives a good starting point in getting into that "ansible


Thanks again,

any time!


--  -------------------------------------------------------------------
JP Vossen, CISSP | |
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --