Ruby, Unicorn y variables de entorno

Question

Mientras jugaba con Heroku, encontré su enfoque de usar variables de entorno para la configuración local del servidor brillante. Ahora, al configurar un servidor de aplicaciones propio, me pregunto qué tan difícil sería replicar.

Estoy implementando una aplicación de sinatra, montando Unicorn y Nginx. Sé que a nginx no le gusta jugar con el medio ambiente, así que uno está fuera. Probablemente pueda poner los vars en algún lugar del archivo de configuración de unicornio, pero como está bajo el control de la versión con el resto de la aplicación, de alguna manera se frustra el propósito de tener la configuración en el entorno del servidor. No hay ninguna razón para no mantener mis archivos de configuración específicos de la aplicación junto con el resto de la aplicación, en lo que a mí respecta.

La tercera y última (que yo sepa) opción, es configurarlas en el shell de desove. Ahí es donde me perdí. Sé que las shells de inicio de sesión y de no inicio de sesión usan diferentes archivos rc, y no estoy seguro de si llamar a algo con sudo -u http stuff está generando o no un shell de inicio de sesión. Hice algunos deberes y pregunté a Google y a los demás, pero aún no estoy del todo seguro de cómo abordarlo. Tal vez estoy siendo tonto ... de cualquier manera, realmente agradecería que alguien pudiera arrojar algo de luz sobre el trato con el entorno de shell.

Answer 1

Creo que su tercera posibilidad está en el camino correcto. Lo que te estás perdiendo es la idea de un script de contenedor, cuya única función es configurar el entorno y luego llamar al programa principal con las opciones que sean necesarias.

Para hacer un script de contenedor que pueda funcionar como un script de control (si prodEnv usa DB = ProdDB, etc.), hay una pieza más que simplifica este problema. Bash/ksh admite una característica llamada archivos fuente. Esta es una operación que proporciona el shell para abrir un archivo y ejecutar lo que está en el archivo, como si estuviera alineado en el script principal. Me gusta #include en C y en otros idiomas.

ksh y bash automáticamente fuente /etc/profile, /var/etc/profile.local (a veces), $HOME/.profile. Hay otros nombres de archivo que también se recogerán, pero en este caso, deberá crear su propio archivo env y cargarlo explícitamente.

Como estamos hablando de wrapper-scripts, y desea administrar cómo se configura su entorno, querrá hacer el abastecimiento dentro del script de contenedor.

¿Cómo se obtiene un archivo de entorno?

envFile=/path/to/my/envFile 
. $envFile 

donde envFile se llenará con declaraciones como

dbServer=DevDBServer 
webServer=QAWebServer 
.... 

puede descubrir que necesita exportar estas variables para que sean visble

export dbServer webServer 

Una asignación/exportación alterna es compatible

export dbServer=DevDBServer 
export webServer=QAWebServer 

Dependiendo de cómo no idénticos sean sus diferentes entornos, puede hacer que su script de contenedor determine qué archivo de entorno cargar.

case $(/bin/hostame) in 
prodServerName) 
    envFile=/path/2/prod/envFile ;; 
QASeverName) 
    envFile=/path/2/qa/envFile ;; 
devSeverName) 
    envFile=/path/2/dev/envFile ;; 
esac 

. ${envFile} 

#NOW call your program 
myProgram -v -f inFile -o outFile ...... 

A medida que desarrolla más y más scripts en su entorno de procesamiento de datos, se puede todos los días source su envFile en la parte superior. Cuando finalmente cambias la ubicación física de un servidor (o su nombre), entonces solo tienes un lugar donde debes realizar el cambio.

IHTH

Answer 2

Para generar un shell interactivo (shell de entrada alias) es necesario invocar sudo así:

sudo -i -u <user> <command> 

También se puede utilizar -E para preservar el medio ambiente. Esto permitirá pasar algunas variables para su entorno actual al comando invocado con sudo.

Answer 3

También un par de gemas que tratan con esto. figaro que funciona con o sin heroku. Figaro usa un archivo yaml (en config y git ignorado) para hacer un seguimiento de las variables. Otra opción es dotenv que lee las variables de un archivo .env. Y también another article con todas las opciones.

Answer 4

Resolví un problema similar al decirle explícitamente a Unicorn que lea un archivo de variables como parte del inicio en su script init.d. Primero creé un archivo en un directorio sobre la raíz de la aplicación llamada variables. En este script, llamo al export en todas mis variables de entorno, p. export VAR=value. Luego definí una variable GET_VARS=source /path/to/variables en el archivo /etc/init.d/unicorn. Finalmente, modifiqué la opción de inicio para leer su - $USER -c "$GET_VARS && $CMD" donde $CMD es el comando de inicio y $USER es el usuario de la aplicación. Por lo tanto, las variables definidas en el archivo se exportan al shell del usuario de la aplicación Unicorn en el inicio. Tenga en cuenta que utilicé una secuencia de comandos init.d casi idéntica a la de this article.