Re: [PLUG] Ansible for updating in the field

[brent timothy saner <brent.saner@gmail.com>]

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!"

> 
>>> Background:
>>> I have SSH connectivity as a non-root user who does have `sudo` access.
>> https://docs.ansible.com/ansible/become.html
> 
> 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:
>> ansible.host != '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:
https://docs.ansible.com/ansible/playbooks_checkmode.html

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 `setup.sh` 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).

downsides:
-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
>> "localhost".
> 
> I could.  As below I was thinking
> http://docs.ansible.com/synchronize_module.html was a better fit though.

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

> 
>> there are more elegant ways, however:
>> https://www.stavros.io/posts/automated-large-scale-deployments-ansibles-pull-mo/
>>
> 
> 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
mindset":

https://docs.ansible.com/ansible/playbooks_best_practices.html

> (SNIP)

> Thanks again,
> JP

any time!


[0] https://www.kernel.org/doc/Documentation/SubmittingPatches

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug