Как обрабатывать временную конфигурацию Symfony2 с помощью службы Consul Service Discovery

Ответ 1

В компании, в которой я работаю, мы выбрали другой маршрут.

Вместо того, чтобы бороться с Symfony, чтобы принять конфигурацию во время выполнения (что-то, что должно быть, например, Spring Data Consul, например), мы решили сделать конфигурацию Symphony от Consul по аналогии по-разному в реализации, чем Фрэнк.

Мы установили шаблон Consul и Consul. Мы создаем входную пару K/V, содержащую весь файл parameters.yml. Пример:

Ключ: eblock/config/parameters.yml

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

Затем в месте /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"
}

Содержимое файла ctmpl:

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

Наконец, наш parameters_updated.sh script делает:

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

Зная, что как службы consul, так и consul-template будут готовы, как только ваше значение изменится в указанном ключе для шаблона consul, он выгрузит файл в сконфигурированный пункт назначения и запустит команду для обновленных параметров.

Это работает как шарм. =)

Ответ 2

Простой наблюдатель KV, который помещает значение в parameters.yml, запускает кеш: clear - самый простой вариант, на мой взгляд, и также дает преимущество компиляции, так что ему не нужно каждый раз обращаться к Консулу, чтобы проверить если значения обновляются. Как вы сказали, некоторые накладные расходы, но, похоже, все в порядке, если вы не меняете свои параметры каждые 5 минут.

Мы изучаем этот вариант сейчас, но если вы достигли какого-либо прогресса в этом, будет оценено обновление.

[Обновление 2016-02-23] Мы реализовали идею, о которой я упоминал выше, и она работает так, как ожидалось: хорошо. Имейте в виду, мы меняем наши параметры только при развертывании новой версии (потому что мы также используем сервисное обнаружение Консулом, поэтому нет необходимости обновлять списки услуг в параметрах). В основном мы это делали, потому что это избавляет нас от скучной работы по изменению параметров на нескольких серверах. Как обычно: это может не сработать для вас, но я думаю, что вы будете в безопасности, если, как я уже говорил, вы не меняете свои параметры каждые 5 минут:)