web-dev-qa-db-fra.com

Capistrano et variables d'environnement

Je suis passé à l'utilisation de variables d'environnement pour la configuration et cela fonctionne très bien - sauf lorsque je dois déployer ou exécuter des tâches avec capistrano.

Capistrano 3 semble exécuter chaque commande préfixée par /usr/bin/env qui efface toutes les variables d'environnement que j'ai définies via .bashrc.

[~ # ~] modifier [~ # ~] - en effectuant des recherches supplémentaires, ce n'est peut-être pas le problème, le problème peut être dû au fait que capistrano s'exécute en tant que shell sans connexion et non interactif et ne charge pas .bashrc ou .bash_profile. Toujours coincé.

Quelle serait la meilleure façon de s'assurer que les variables d'environnement sont définies lorsque capistrano exécute ses tâches?

ruby-on-railsenvironment-variablescapistranocapistrano3
42
Rahul Sekhar

Il vaut peut-être mieux regarder la différence entre ENVIRONMENT VARIABLES et Shell VARIABLES

Lorsque vous lancez SSH, votre application charge les variables Shell définies dans votre .bashrc fichier. Celles-ci n'existent que pour la durée de vie du Shell, et par conséquent, nous ne les utilisons pas autant que ENV vars

Il vaut peut-être mieux placer les variables ENV dans:

/etc/environment

Comme ça:

export ENVIRONMENT_VAR=value

Cela rendra les variables disponibles dans tout le système, pas seulement dans différentes sessions Shell

Mise à jour

As-tu essayé

Capistrano: Puis-je définir une variable d'environnement pour toute la session de plafonnement?

set :default_env, { 
  'env_var1' => 'value1',
  'env_var2' => 'value2'
}
48
Richard Peck

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

Capistrano charge .bashrc. Mais si vous remarquez 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 le souhaite.

Cette solution a également été notée sur ce problème GitHub .

48
Delameko

Afin de déboguer la mise à jour du problème 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

exécutez maintenant cap staging debug:env. Vous devriez pouvoir voir la configuration efficace des variables ENV.

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

  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 ne sera ensuite fourni:

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

Pour comprendre comment capistrano charge les variables ENV, ce graphique ( source ) peut être utile.

Très probablement, le ~/.bash* le fichier n'est pas chargé en raison d'une session non interactive.

capistrano env variables loading

15
Tombart

Vous devez définir des variables d'environnement dans le fichier /etc/environment Pour les rendre disponibles à tous les utilisateurs et les traiter dans 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 créé une bibliothèque Capistrano ( capistrano-env_config ) il y a quelque temps pour gérer et synchroniser les variables d'environnement à travers un cluster qui fonctionne exactement en modifiant le fichier /etc/environment. Il est facile à utiliser et ressemble à la façon dont vous pouvez définir des 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
1
Itay Grudev

La solution sur laquelle j'ai opté était:

  1. Activez l'option PermitUserEnvironment dans/etc/ssh/sshd_config de tous les serveurs sur lesquels je dois déployer.
  2. Ajoutez un fichier ~/.ssh/environnement pour le répertoire personnel de chaque utilisateur vers lequel je déploie avec des vars env sous la forme de paires KEY = VALUE (je déploie chaque application et service via son propre utilisateur dans le répertoire personnel de cet utilisateur).

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

C'est en fait pire que ça. J'utilise Upstart pour gérer Puma/Rails, et j'ai également besoin des vars env. Donc, après des jours d'expérimentation, je me suis retrouvé sur la solution complète mais horrible suivante:

  1. Définissez mes vars env dans le .bashrc de l'utilisateur en utilisant "export KEY = VALUE". (Donc, ils existent lorsque je SSH en interactif.)
  2. Définissez mes vars env dans le fichier .ssh/environnement de l'utilisateur à l'aide de "KEY = VALUE". (Ils existent donc lorsque les SSH Capistrano sont entrés.)
  3. Définissez mes vars env dans la section "script" de /etc/init/puma.conf. (Ils existent donc lorsque Puma/Rails démarre.)

C'est une douleur dans le cul de maintenir la même liste de vars env dans plusieurs fichiers/modèles et dans plusieurs formats (avec exportation, sans exportation ...). Heureusement, cela est rendu un peu plus facile/plus fiable en utilisant Puppet pour gérer la configuration du nœud avant que Capistrano ne soit utilisé pour y déployer ...

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

0
odigity