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

В настоящее время наша команда изучает идею открытия службы для приложения Symfony2 с использованием Consul. Находясь в относительной границе, там очень мало обсуждений. До сих пор мы обнаружили:

Конфигурация времени выполнения ранее была сбита.
A существует для обработки такого прецедента, но с недавнего времени также не видел много активности.
Один из участников упомянутого пакета предположил, что Внешние параметры могут быть ответом на проблему.
Sensio создал свой собственный Консул SDK. Тем не менее, похоже, что на пути к документации/официальным статьям в блогах не так много: интеграция Symfony2
Consol предоставляет часы, которые могут запускаться при различных изменениях.

Текущие мысли состоят в том, чтобы исследовать использование наблюдателей Consul для повторного запуска построения кеша вместе с внешними параметрами. Тем не менее, существует некоторая озабоченность по поводу накладных расходов на такую операцию, если услуги часто меняются.

Основываясь на вышесказанном и знании внутренних дел Consul/Symfony, это было бы целесообразным подходом? Если нет, то почему и какие альтернативы доступны?

Ответ 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 минут:)