|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.: https://docs.ansible.com/ansible/playbooks_checkmode.html. https://docs.ansible.com/ansible/playbooks_best_practices.htmlI 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!"Background: I have SSH connectivity as a non-root user who does have `sudo` access.https://docs.ansible.com/ansible/become.htmlYup, 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 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, JPany time!  https://www.kernel.org/doc/Documentation/SubmittingPatches
Thanks, JP -- ------------------------------------------------------------------- JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/ ___________________________________________________________________________ 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