2012-05-08 7 views
5

Ho alcune app nel mio cluster, ho bisogno di avviarne alcune a volte su host diversi.Erlang, come caricare le applicazioni con le loro dipendenze

La storia è che il cluster di Erlang è già in esecuzione, quindi anche se ho il mio file di risorse .app per applicazione che indica quali applicazioni devono essere avviate prima di mine, funziona solo per creare uno script di avvio, non per avviare un'app in un nodo già in esecuzione.

Al momento ho una routine personalizzata che utilizza l'applicazione: get_key (Applicazione, applicazioni) per estrarre le dipendenze e avviarle separatamente prima di avviare l'applicazione specificata.

Mi chiedevo se non c'è un modo migliore per farlo.

risposta

1

Quando si avvia l'app all'esterno dello script di avvio, è necessario avviare prima le dipendenze. È possibile creare l'intelligenza per farlo nell'app stessa, in modo che all'avvio dell'app inizi tutte le dipendenze necessarie prima che ne abbia bisogno.

Un posto in cui ho visto questo fatto è nelle app Mochiweb. L'impostazione predefinita app templates includere il codice per le dipendenze di caricamento all'avvio:

-module(some_app). 
-export([start/0, stop/0]). 

ensure_started(App) -> 
    case application:start(App) of 
     ok -> 
      ok; 
     {error, {already_started, App}} -> 
      ok 
    end. 

%% @spec start() -> ok 
%% @doc Start the some_app server. 
start() -> 
    some_app_deps:ensure(), 
    ensure_started(crypto), 
    application:start(some_app). 

%% @spec stop() -> ok 
%% @doc Stop the some_app server. 
stop() -> 
    application:stop(some_app). 
0

Se scrivete la vostra applicazione in "OTP Principi di progettazione", si dovrà fare file di yourappname.app, quale sezione applicazioni Volontà contiene `. Questa sezione definisce le altre applicazioni che vuoi avviare prima delle tue. Here si precisa:

applicazioni

Tutte le applicazioni che devono essere avviati prima di avviare questa applicazione . systools utilizza questo elenco per generare gli script di avvio corretti. Il valore predefinito è [], ma si noti che tutte le applicazioni hanno dipendenze da almeno a kernel e stdlib.

Quindi, se si utilizzano versioni, questa risoluzione delle dipendenze verrà risolta da systools.

+1

Penso che questo assicuri solo che l'app non sia avviata prima che tutte le dipendenze 'delle applicazioni 'siano avviate, ma in realtà non le avviano. – nietaki

6

Francamente, gli strumenti standard per farlo in Erlang sono inutilmente fastidiosi in questo momento. Io tendo a mettere le seguenti caldaia-piatto in mio modulo di callback applicazione:

-module(myapp_app). 
-export([start/0]). 

start() -> a_start(myapp, permanent). 

a_start(App, Type) -> 
    start_ok(App, Type, application:start(App, Type)). 

start_ok(_App, _Type, ok) -> ok; 
start_ok(_App, _Type, {error, {already_started, _App}}) -> ok; 
start_ok(App, Type, {error, {not_started, Dep}}) -> 
    ok = a_start(Dep, Type), 
    a_start(App, Type); 
start_ok(App, _Type, {error, Reason}) -> 
    erlang:error({app_start_failed, App, Reason}). 

È possibile aggiungere -s myapp_app alla riga di comando erlang e questo inizierà l'applicazione e tutte le sue dipendenze in modo ricorsivo. Perché questa funzione non è nel modulo applicativo non so :)


C'è un esempio di lavoro di questo custom erlang app startup code nel mio Erlang fabbrica 2012 SFBay esempio app.