Re: [PLUG] Ansible for updating in the field

[JP Vossen <jp@jpsdomain.org>]

More good ideas, esp.:
https://docs.ansible.com/ansible/playbooks_checkmode.html.
https://docs.ansible.com/ansible/playbooks_best_practices.html

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

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