在我工作的公司,我们走的是不同的路线。
我们决定让 Consul 更新 Symfony 配置,而不是与 Symfony 对抗以接受运行时配置(例如 Spring Data Consul),在概念上相似,在实现上与 Frank 不同。
我们安装了 Consul 和 Consul Template。我们创建一个包含整个 parameters.yml 文件的 K/V 条目对。例子:
钥匙: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
脚本会:
#!/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 模板的指定键中更改值,它就会将文件转储到配置的目标并运行更新参数的命令。
它就像一个魅力。=)