2015-02-28 18 views
9

L'esecuzione dell'applicazione Ubuntu 14.04 LTS a 64 bit Rails e l'impossibilità di accedere alle variabili dell'ambiente dell'app.Le variabili di ambiente OpsWorks di AWS non funzionano

Nel pannello OpsWorks App, ho impostato il mio variabili d'ambiente, dicono:

MYKEY: 1234 

Poi li risparmio e distribuire di nuovo la mia app per rendere questi visibile.

Nella mia applicazione Rails, o la console rotaie ottengo nulla:

$ bundle exec rails c production 
>ENV["MYKEY"] 
=> nil 

Ho provato a riavviare il server. Non sono sicuro di cosa mi stia perdendo, ho utilizzato variabili di ambiente in altri servizi.

Come posso rintracciare dove dovrebbero essere impostati?

+0

Se eseguo ssh ed eseguo 'sudo opsworks-agent-cli get_json', vedo che MYKEY è lì' {"deploy": {"server": {"ambiente": {"MYKEY": "1234"} .. ' – peterept

+0

Hai trovato una soluzione per questo? – loganathan

+0

La cosa strana è che funziona nelle istanze di produzione Passenger, ma non funziona quando ho $ bundle exec rails c production' come utente di distribuzione (che è lo stesso utente in cui Passenger è in esecuzione). Apache è in esecuzione su www-data, ma se accedo come www-data o deploy non vedo alcun set di vv env. Quindi sto correndo, ma non ho idea di cosa stia succedendo sotto il cofano. – peterept

risposta

4

OpsWorks memorizza le variabili ambientali in luoghi diversi a seconda del tipo di app che si sta distribuendo. Su Rails/Passenger dovrebbero essere salvati nel file di configurazione Apache #{your_app_name}.conf. (Source)

Ciò significa che non sono disponibili nell'ambiente di shell normale.

So che le ricette di Node.js hanno memorizzato tutto in un file /srv/www/#{app_name}/shared/app.env ... che viene quindi estratto dall'ambiente per eseguire il server Node. Questo dettaglio di implementazione ha anche significato la possibilità di scrivere script di shell che hanno fornito il file app.env, quindi chiamato qualche script di nodo o altro.

Ovviamente, Rails non è un nodo. Non ho idea se le variabili ambientali siano memorizzate altrove o altrove: una rapida occhiata alle ricette di Rails nei libri di cucina OpsWorks non ha trovato nulla di ovvio, ma forse mi sono perso qualcosa.

A seconda della quantità di modifiche che avete in corso nel vostro OpsWorks libro di cucina, è possibile creare una ricetta implementare che fa qualcosa di simile:

application_environment_file do user deploy[:user] group deploy[:group] path ::File.join(deploy[:deploy_to], "shared") environment_variables deploy[:environment_variables] end

(forse la regolazione del percorso)

Quindi per eseguire la tua console, quando sei SSHed nel server, fai qualcosa come

sudo source /srv/www/my_app_name/shared/app.env; bundle exec rails console -e production o qualsiasi altra cosa.

+0

Grazie mille, questa è l'informazione giusta! Se visualizzo '/ etc/apache2/sites-enabled/myapp.conf', vedo lì' SetEnv "PKTEST" "testing" 'così chiaramente è dove OpsWorks sta effettivamente scrivendo, e perché non può essere visto console di rotaie in esecuzione. – peterept

+0

Ho risposto con maggiori dettagli e con una guida completa. Si prega di controllare quello e pensare a contrassegnarlo come la risposta giusta. Grazie. –

1

I (con qualche aiuto da Bruno al AWS PopUp Loft a New York) ha aggiunto un certo codice Chef personalizzato all'interno del gancio after_restart.rb Deploy, è sufficiente aggiungere la cartella "distribuire" nella directory di applicazioni di root e dentro aggiungere "after_restart. eb." In esso ....

Chef::Log.info("Running deploy/after_restart.rb") 

contents = [] 

node[:deploy].each do |application, deploy| 
    deploy[:environment_variables].each do |key, value| 
    contents << "export #{key}=\"'#{value}'\"" 
    end 
end 


Chef::Log.info("Adding the environment variables to /etc/profile.d/startup_env_config.sh") 

bash "create_startup_env_config.sh" do 
    user "root" 
    cwd "/etc/profile.d" 
    code <<-EOH 
    echo \''#{contents.join(" ")}\'' > startup_env_config.sh 
    source startup_env_config.sh 
    cd #{release_path} 

    EOH 
    end 

E questo è tutto. Se aggiorni le variabili di ambiente all'interno del pannello OpsWorks, ricorda di riavviare le tue istanze.

+0

Ho provato questa ricetta ma non ha funzionato! Ho aggiunto la mia risposta qui sotto con una guida dettagliata completa how-to-do –

+0

Ehi Diego - cosa è andato storto? Quali sono stati gli errori? – dsieczko

+0

Ho apportato una leggera modifica – dsieczko

3

La console OpsWorks di AWS consente di dichiarare le variabili di ambiente ma per renderle disponibili per la nostra app Rails, è necessario utilizzare una ricetta del ricettario dello Chef e alcune precauzioni.

In poche parole si utilizza l'opzione/secrets.yml file di configurazione combinato con config/dell'applicazione.yml file, Figaro gem e Ricetta cuoco di cucina. La ricetta del ricettario dello chef legge le variabili definite nella console OpsWorks e le lascia disponibili all'app Rails scrivendo il file config/application.yml.

Ho pubblicato una guida dettagliata per spiegare come farlo esattamente. Link here.

Questi sono i punti fondamentali che ho coperto: i file

  1. Usa config/secrets.yml (aggiunto da Rails 4.1)
  2. Usa Figaro gemma per caricare le variabili nell'ambiente
  3. variabili d'ambiente Declare all'interno AWS OpsWorks Console
  4. usa una ricetta Chef personalizzato per creare un config/application.yml file Figaro userà per far variabili disponibili
Problemi correlati