Obsługa konfiguracji środowiska wykonawczego Symfony2 przy użyciu usługi Consul Service Discovery

Question

Nasz zespół analizuje obecnie koncepcję wykrywania usług dla aplikacji Symfony2 za pomocą programu Consul. Będąc na względnej granicy, na drodze dyskusji jest bardzo niewiele. Do tej pory odkryliśmy:

• Konfiguracja środowiska wykonawczego has previously been shot down.
• A bundle exists radzi sobie z takim przypadkiem użycia, ale ostatnio również nie widział zbyt wiele aktywności.
• Jednym z contributors of said bundle suggested, że External Parameters może być odpowiedź na problem.
• Sensio stworzył swój own Consul SDK. Jednak nie wydaje się być trochę w sposób dokumentacji/Dziennik artykuły blogi re: integracja Symfony2
• Consol provides watches, które mogą być uruchamiane na różnych zmianach

Aktualne myśli zbadać wykorzystując obserwatorów konsula ponownie wyzwolić kompilację pamięci podręcznej wraz z zewnętrznymi parametrami. To powiedziawszy, istnieje pewien niepokój w związku z taką operacją, jeśli usługi zmieniają się pół-często.

W oparciu o powyższe informacje i znajomość elementów wewnętrznych konsul/Symfony byłoby to wskazane? Jeśli nie, dlaczego i jakie alternatywy są dostępne?

Answer 1

Prosty obserwator KV, który umieszcza wartość w parametrze parameters.yml, uruchamia pamięć podręczną: clear jest najprostszą opcją według mnie, a także zapewnia korzyść z kompilacji, tak aby nie musiała iść do Consul za każdym razem do sprawdź, czy wartości są zaktualizowane. Tak jak powiedziałeś, niektóre z nich wydają się być w porządku, jeśli nie zmienisz parametrów co 5 minut.

Obecnie badamy tę opcję, ale jeśli zrobiłeś postępy w tej kwestii, aktualizacja byłaby doceniana.

[Aktualizacja 2016-02-23] Wdrożyliśmy pomysł, o którym wspomniałem powyżej i działa zgodnie z oczekiwaniami: dobrze. Pamiętajmy, że zmienimy nasze parametry tylko przy wdrażaniu nowej wersji (ponieważ używamy także wykrywania usług przez Consul, więc nie trzeba aktualizować list usług w parametrach). Zrobiliśmy to głównie dlatego, że zaoszczędziliśmy nam nudnej pracy polegającej na zmianie parametrów na kilku serwerach. Jak zwykle: to może nie działać, ale myślę, że byłbyś bezpieczny, jeśli, jak już powiedziałem, nie zmieniasz swoich parametrów co 5 minut :)

Answer 2

W firmie, w której pracuję, wzięliśmy inną trasę .

Zamiast walczyć z Symfony, aby zaakceptować konfigurację środowiska wykonawczego (coś, co powinno, na przykład Spring Data Consul, na przykład), zdecydowaliśmy się uczynić konfigurację Consul update Symfony, w podobnej koncepcji, różnej w implementacji niż Frank.

Zainstalowaliśmy szablon konsula i konsula. Tworzymy parę pozycji K/V, która zawiera cały plik parameters.yml.Przykład:

Klucz: eblock/config/parameters.yml

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

Następnie plik konfiguracyjny szablon konsul dodano w miejscu /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" 
} 

której zawartość pliku ctmpl są:

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

Wreszcie nasz skrypt: parameters_updated.sh:

#!/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 & 

Wiedząc, że obie usługi konsul i konsul szablonów to się tak szybko, jak wprowadzone zmiany wartości w określonym kluczu szablonu konsula, będzie to zrzucić plik do skonfigurowanego połączenia i uruchom polecenie dla parametrów aktualnych.

Działa jak urok. =)