" So... the problem with putting these variables into my playbook instead of
> directly into $PATH is that we do our deployments using Capistrano (I've
> used it for 5 years and couldn't be happier and have no desire to use a
> provisioning tool for something as simple as deployments). In turn this
> means that any environment variables set in Ansible playbooks won't be
> accessible to my deployment environments"
vars:
base_path: {{ lookup('env','SOME_ENV_VAR' }}
or use -e on the command line to pass in a base path.
On Wed, Nov 20, 2013 at 4:57 AM, Nick Groenen <n...@travelbird.nl> wrote:
> On Tue, Nov 19, 2013 at 3:28 PM, Steven Haddox <ste...@haddox.us> wrote:
>
> > Thanks very much for your reply and thoughts. This has helped
> tremendously
> > (and will help as I write the rest of these playbooks)
>
> Awesome, glad I could help!
>
> > So... the problem with putting these variables into my playbook instead
> of
> > directly into $PATH is that we do our deployments using Capistrano (I've
> > used it for 5 years and couldn't be happier and have no desire to use a
> > provisioning tool for something as simple as deployments). In turn this
> > means that any environment variables set in Ansible playbooks won't be
> > accessible to my deployment environments. It also means that I'd either
> have
> > to rewrite everything to deploy with Ansible (which isn't the community
> best
> > practice in Ruby world, even to use Chef or Puppet wouldn't be ideal for
> the
> > vast majority of teams) or it means I'll have to duplicate variables in
> my
> > playbook environment variables and then again somewhere in my tasks to
> setup
> > those variables for the user when they login.
>
> In cases like these, I usually recommend to decouple variables from
> the deployment/configuration tool itself. Have the tools you use all
> pull their configuration data from some source using, in Ansible's
> case, inventory scripts for example, as these can also set variables
> for hosts. If the shared set of variables is small, another option may
> be to include them as vars files in Ansible, and have an adapter of
> some kind for Capistrano that can read the same YAML files to get the
> data there.
>
> This is more work, so admittedly it's a trade off whether or not it's
> worth it, but it does bring other advantages with it as well.
>
> > So that leads to yet another question... Is there a best practice to be
> able
> > to get Ansible tasks to load my .bashrc if I'm sure it'll be there before
> > running the shell module or am I likely to have to always do the
> following?
> >
> > shell: source {{HOME.stdout}}/.bashrc; <cmd>
>
> Like Michael said, environment is your friend. That said, I don't see
> a reason why you couldn't do this if you need to rely on an
> environment that is set up by bashrc. It's hacky and can be
> unpredictable, but if you're aware of the associated risks, I say go
> for it. Sometimes doing the hacky thing that just works is preferable
> over an ideal-world solution that takes a lot of effort to develop. :)
>
> > The next question is, is there an alternative approach to storing
> > environment variables / modified $PATH without having to use the .bashrc
> but
> > that would still be accessible for a user actually logged into the box
> from
> > a remote terminal? I've been playing with server setup / maintenance as a
> > side-duty of all my jobs for about a decade and haven't come across any,
> but
> > it's also not my full-time $dayjob and I'm not an expert by any means.
> I'd
> > love to hear suggestions or tips from others as to a better approach than
> > putting $STOW and $PATH modifications / exports in the .bashrc of the
> > sysadmin user.
>
> I'm not aware of any universal way to do so, either.
>
> --
> Nick Groenen | zoni | @NickGroenen
> https://zoni.nl | GnuPG/GPG key ID: 0xAB5382F6
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-project+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Michael DeHaan <mich...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
