Come gestire la configurazione di runtime di Symfony2 utilizzando Consul Service Discovery

Question

Il nostro team sta attualmente esplorando l'idea della scoperta dei servizi per un'applicazione Symfony2 usando Consul. Essendo nella relativa frontiera, c'è ben poco fuori nel modo di discutere. Finora abbiamo scoperto:

• Configurazione di runtime has previously been shot down.
• A bundle exists A gestire tale caso d'uso, ma non ha visto molte attività anche in ritardo.
• Uno dei che External Parameters potrebbe essere la risposta al problema.
• Sensio ha creato il suo own Consul SDK. Tuttavia, sembra che ci sia poco in termini di documentazione/articoli ufficiali del blog re: l'integrazione Symfony2
• Consol provides watches che può essere attivato in vari cambiamenti

pensieri attuali sono per esplorare utilizzando i osservatori Consul di ri- innescare una build di cache insieme a parametri esterni. Detto questo, c'è un po 'di preoccupazione per il sovraccarico di tale operazione se i servizi cambiano semi-frequentemente.

Sulla base di quanto sopra, e la conoscenza degli interni di Consul/Symfony, sarebbe un approccio consigliabile? In caso negativo, perché e quali alternative sono disponibili?

Answer 1

Un semplice watcher KV che inserisce il valore in parameters.yml, attiva una cache: clear è l'opzione più semplice a mio parere e offre anche il vantaggio della compilazione in modo che non debba andare a consultare ogni volta il Console per controlla se i valori sono aggiornati. Come hai detto tu, un po 'di overhead, ma sembra essere ok se non cambi i tuoi parametri ogni 5 minuti.

Stiamo esplorando questa opzione ora, ma se avete fatto qualche progresso su questo, un aggiornamento sarebbe apprezzato.

[Aggiornamento 2016-02-23] Abbiamo implementato l'idea che ho menzionato sopra e funziona come previsto: bene. Intendiamoci, cambiamo i nostri parametri solo sulla distribuzione di una nuova versione (perché usiamo anche la scoperta dei servizi da parte di Consul, quindi non è necessario aggiornare gli elenchi di servizi nei parametri). Lo abbiamo fatto principalmente perché ci risparmia il noioso compito di modificare i parametri su diversi server. Come al solito: potrebbe non funzionare per te, ma penso che tu saresti al sicuro se, come ho detto prima, non cambi i parametri ogni 5 minuti :)

Answer 2

In azienda io lavoro, abbiamo preso una strada diversa .

Invece di lottare contro Symfony per accettare la configurazione di runtime (qualcosa che dovrebbe, ad esempio, Spring Data Consul, per esempio), abbiamo deciso di fare in modo che Consul aggiorni la configurazione di Symfony, in un concetto simile, diverso da quello di Frank.

Abbiamo installato Consul e Consul Template. Creiamo una coppia di voci K/V che contiene l'intero file parameters.yml.Esempio:

chiave: eblock/config/parameters.yml

parameters: 
    router.request_context.host: dev.eblock.ca 
    router.request_context.scheme: http 
    router.request_context.base_url:/

Poi un file di configurazione del modello console è stato aggiunto alla locazione /opt/consul-template/config/eblock.cfg:

template { 
    source = "/opt/consul-template/templates/eblock-parameters.yml.ctmpl" 
    destination = "/var/www/eblock/app/config/parameters.yml" 
    command = "/opt/eblock/scripts/parameters_updated.sh" 
} 

Il contenuto del file ctmpl sono:

{{key "eblock/config/parameters.yml"}} 

Infine

, lo script parameters_updated.sh fa:

#!/bin/bash 

readonly PROGNAME=$(basename "$0") 
readonly LOCKFILE_DIR=/tmp 
readonly LOCK_FD=201 

lock() { 
    local prefix=$1 
    local fd=${2:-$LOCK_FD} 
    local lock_file=$LOCKFILE_DIR/$prefix.lock 

    # create lock file 
    eval "exec $fd>$lock_file" 

    # acquire the lock 
    flock -n $fd \ 
     && return 0 \ 
      || return 1 
} 

lock $PROGNAME || exit 0 

export HOME=/root 
logger "Starting composer install" && \ 
/usr/local/bin/composer install -d=/var/www/eblock/ --no-interaction && \ 
logger "Running composer dump-autoload" && \ 
/usr/local/bin/composer dump-autoload -d=/var/www/eblock/--optimize && \ 
logger "Running app/console c:c/c:w" && \ 
/usr/bin/php /var/www/eblock/app/console c:c -e=prod --no-warmup && \ 
/usr/bin/php /var/www/eblock/app/console c:w -e=prod && \ 
logger "Running doctrine commands" && \ 
/usr/bin/php /var/www/eblock/app/console doctrine:database:create --env=prod --if-not-exists && \ 
/usr/bin/php /var/www/eblock/app/console doctrine:migrations:migrate -n --env=prod && \ 
logger "Restarting php-fpm" && \ 
/bin/systemctl restart php-fpm & 

Sapendo che entrambi i servizi console e console-modello sono in su, non appena il valore cambia nella chiave specificata per il modello console, sarà il dump del file in destinazione configurata ed eseguire il comando per i parametri aggiornati.

Funziona come un fascino. =)