ruby on rails - Capistrano y variables de entorno

ruby-on-rails environment-variables

Question

He cambiado a usar variables de entorno para la configuración y funciona muy bien, excepto cuando tengo que implementar o ejecutar tareas con capistrano.

Capistrano 3 parece ejecutar cada comando con el prefijo /usr/bin/env que borra cualquier variable de entorno que haya establecido a través de .bashrc .

EDITAR - al hacer algunas búsquedas adicionales, este podría no ser el problema, el problema podría ser porque capistrano se ejecuta como un shell que no inicia sesión, no es interactivo y no carga .bashrc o .bash_profile . Todavía estancado, sin embargo.

¿Cuál sería la mejor manera de asegurarse de que los vars de entorno estén configurados cuando capistrano ejecuta sus tareas?

Answer 1

Aunque esto ha sido respondido, voy a dejar esto aquí en caso de que alguien más esté en la misma situación que yo.

Capistrano carga .bashrc . Pero si nota en la parte superior del archivo, hay esto:

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

La solución fue simplemente poner cualquier configuración por encima de esto y Capistrano funciona como yo quiero.

Esta solución también se observó en este número de GitHub .

Answer 2

Debe establecer las variables de entorno en el /etc/environment para que estén disponibles para todos los usuarios y procese dentro de un sistema. Las variables de entorno en los archivos .bashrc o .bash_profile solo están disponibles dentro de una sesión de shell y no para procesos y servicios generados automáticamente.

capistrano-env_config una biblioteca de Capistrano ( capistrano-env_config ) hace algún tiempo para administrar y sincronizar variables de entorno en un clúster que funciona exactamente modificando el /etc/environment . Es fácil de usar y es similar a cómo puede establecer variables de entorno con Heroku toolbelt. Aquí hay unos ejemplos:

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

Answer 3

La solución que establecí fue:

1. Habilite la opción PermitUserEnvironment en / etc / ssh / sshd_config de todos los servidores en los que necesito implementar.
2. Agregue un archivo ~ / .ssh / environment para el directorio inicial de cada usuario con el que despliego con formato de pares KEY = VALUE (despliego cada aplicación y servicio a través de su propio usuario al directorio de origen de ese usuario).

Referencia: http://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fenvironment

En realidad es peor que eso. Yo uso Upstart para administrar Puma / Rails, y necesito los archivos adjuntos establecidos allí también. Entonces, después de días de experimentación, terminé con la siguiente solución completa pero horrible:

1. Establezca mis archivos en el archivo .bashrc del usuario usando "export KEY = VALUE". (Entonces existen cuando yo SSH en forma interactiva)
2. Establezca mis archivos en el archivo .ssh / environment del usuario usando "KEY = VALUE". (Así que existen cuando Capistrano SSH en.)
3. Establezca mis archivos en la sección "script" de /etc/init/puma.conf. (Entonces existen cuando comienza Puma / Rails.)

Es un dolor de cabeza mantener la misma lista de archivos en múltiples archivos / plantillas y en múltiples formatos (con exportación, sin exportación ...). Por suerte, se hace un poco más fácil / más confiable usando Puppet para administrar la configuración del nodo antes de que Capistrano se utilice para implementarlo ...

Realmente odio el dominio completo de las shells de linux, la inicialización y los archivos dotfiles. Es hora de un reinicio completo.

Answer 4

Para depurar el problema actualice config/deploy.rb con una tarea simple:

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

ahora ejecute la cap staging debug:env . Debería poder ver la configuración efectiva de las variables ENV .

El orden y los nombres de los archivos dependen de su distribución; por ejemplo, en Ubuntu, la secuencia de origen es la siguiente:

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

Cuando ~/.bashrc contiene primeras líneas como esta, cualquier código posterior no se originará:

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

Para comprender cómo capistrano carga variables ENV, este cuadro ( source ) puede ser útil.

Lo más probable es que el archivo ~/.bash* no esté cargado debido a una sesión no interactiva.

Answer 5

Tal vez sea mejor que mire la diferencia entre ENVIRONMENT VARIABLES y SHELL VARIABLES

Cuando activa SSH, su aplicación cargará las variables SHELL que están definidas en su archivo .bashrc . Estos solo existen durante la vida del caparazón, y por lo tanto, no los usamos tanto como los valores de ENV

Puede que sea mejor poner los genes ENV en:

/etc/environment

Me gusta esto:

export ENVIRONMENT_VAR=value

Esto hará que las variables estén disponibles en todo el sistema, no solo en diferentes sesiones de shell

Actualizar

Has probado

Capistrano: ¿Puedo establecer una variable de entorno para toda la sesión de tope?

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