app.yaml lattina impostare variabili di ambiente per il resto dell'applicazione, ma non ha alcun modo di controllo loro e fare cose diverse a seconda delle loro valori in ingresso. Pertanto, è necessario presentare diversi file app.yaml in qualsiasi procedura di distribuzione che si sta utilizzando.
Per quanto riguarda il modo migliore per preparare il codice corretto app.yaml come passaggio preliminare alla distribuzione GAE, si tratta di un problema di devops più sottile. I rami nel tuo git o hg o qualsiasi altra cosa, come dici tu, funzionerebbero, ma personalmente (forse solo sfortuna? -) Ho spesso trovato che più semplice è la mia struttura, meglio e rami destinati ad essere longevi (come opposto alla deviazione temporanea destinata a essere presto fusa nel tronco) mi hanno dato i grattacapi peggiori.
Quindi, se fosse per me, avrei un modello preapp.yaml (forse Jinja2, a prescindere) con la necessaria se/logica altro, e preparo il diritto app.yaml da esso, come il primo passo di qualsiasi schieramento, con un semplice script Python.
Praticamente il tipo di architettura utilizzata (per tutti i tipi di file di configurazione, e quindi con le complicanze più inevitabili) per il momento-beta gcloud preview deployment-manager, vedere https://cloud.google.com/deployment-manager/, così naturalmente ho potuto essere prevenuto verso l'approccio (ma come ho menzionato il mio pregiudizio deriva essenzialmente da precedenti esperienze negative di distribuzione :-).
fonte
2015-02-02 17:39:36
Forse è meglio avere file diversi, ad es. dev.yaml staging.yaml e così via. Quindi è possibile eseguire il server dev con quei file in modo esplicito e quando si distribuirà userà sempre app.yaml. –
@PaulCollingwood c'è un comando da eseguire con un file di configurazione specifico? Non l'ho visto nella documentazione. – jwarzech
puoi dire dev_appserver somefile.yaml e lo userà. molto maneggevole. ma solo localmente, non prod afaik. –