Variables de Capistrano et d'environnement

bien que ceci ait été répondu, je vais laisser ceci ici au cas où quelqu'un d'autre serait dans la même situation que moi.

Capistrano ne charge .bashrc . Mais si vous remarquerez en haut du fichier, il y a ceci:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

la solution était simplement de mettre n'importe quelle configuration au-dessus de cela et Capistrano fonctionne comme je veux.

Cette solution a également été notée à cette question GitHub .

afin de déboguer la mise à jour de la question config/deploy.rb avec une tâche simple:

namespace :debug do
  desc 'Print ENV variables'
  task :env do
    on roles(:app), in: :sequence, wait: 5 do
      execute :printenv
    end
  end
end

maintenant, Lancez cap staging debug:env . Vous devriez être en mesure de voir la configuration effective des variables ENV .

l'ordre et les noms des fichiers dépendent de votre distribution, par exemple sur Ubuntu la séquence de sourcing est la suivante:

1. /etc/environment
2. /etc/default/locale
3. /etc/bash.bashrc
4. ~/.bashrc

quand ~/.bashrc contient les premières lignes comme celle-ci, aucun code après ne sera fourni:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

pour comprendre comment capistrano charge variables ENV Ce graphique ( source ) pourrait être utile.

très probablement le fichier ~/.bash* n'est pas chargé en raison de session non interactive.

vous devez définir des variables d'environnement dans le fichier /etc/environment pour les rendre disponibles à tous les utilisateurs et traiter au sein d'un système. Les variables d'environnement dans les fichiers .bashrc ou .bash_profile ne sont disponibles que dans une session shell et non pour les processus et services générés automatiquement.

j'ai fait une bibliothèque Capistrano( capistrano-env_config ) Il ya quelque temps pour la gestion et la synchronisation des variables d'environnement à travers un cluster qui fonctionne exactement en modifiant le fichier /etc/environment . Il est facile à utiliser et est similaire à la façon dont vous pouvez définir les variables d'environnement avec la ceinture D'outils Heroku. Voici quelques exemples:

cap env:list
cap env:get[VARIABLE_NAME, VARIABLE_NAME, ...] 
cap env:unset[VARIABLE_NAME, VARIABLE_NAME, ...] 
cap env:set[VARIABLE_NAME=VALUE, VARIABLE_NAME=VALUE, ...] 
cap env:sync

la solution que j'ai choisie était:

1. activer L'option Permituserenvironnement dans le fichier /etc/sshd_config de tous les serveurs sur lesquels je dois me déployer.
2. Ajouter un ~/.fichier SSH / environnement pour le dir à domicile de chaque utilisateur auquel je me déploie avec env vars sous la forme de combinaisons clé=valeur (je déploie chaque application et service via son propre utilisateur vers le dir à domicile de cet utilisateur).

référence: http://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fenvironment

c'est pire que ça. J'utilise Upstart pour gérer Puma/Rails, et j'ai besoin des Vars env installés là aussi. Ainsi, après des jours d'expérimentation, je me suis retrouvé sur la solution complète mais horrible suivante:

1. mettre mon envvars dans celui de l'utilisateur .bashrc à l'aide de "l'exportation de la CLÉ=VALEUR". (Donc ils existent quand je suis en interactivement.)
2. mettre mon envvars dans celui de l'utilisateur .fichier SSH / environment utilisant "KEY=VALUE". (Ils existent donc quand Capistrano S'installe.)
3. configurer mon env vars dans /etc/init/puma.conf "script". (Donc ils existent quand Puma / Rails commence.)

c'est pénible de maintenir la même Liste d'envvars dans plusieurs fichiers/gabarits et dans plusieurs formats (avec exportation, sans exportation...). Heureusement, il est rendu légèrement plus facile/plus fiable en utilisant Puppet pour gérer la configuration du noeud avant que Capistrano ne soit utilisé pour le déployer...

je déteste vraiment tout le domaine des shells linux, l'initialisation et les dotfiles. Il est temps de redémarrer complètement.