如何使用Consul服务发现处理Symfony2的运行时配置

Question

我们的团队目前正在探索使用Consul为Symfony2应用程序进行服务发现的想法。由于这是相对较新的领域，关于此方面的讨论非常有限。到目前为止，我们已经发现：

• 运行时配置以前被关闭。
• 存在一个捆绑包来处理这种情况，但是最近也没有看到太多活动。
• 其中一位捆绑包的贡献者建议，外部参数可能是解决问题的答案。
• Sensio创建了自己的Consul SDK。 然而，关于Symfony2集成方面似乎很少有官方博客文章/文档。
• Consol 提供手表可以在各种更改上触发。

目前的想法是探索利用Consul watchers来重新触发缓存构建，并带有外部参数。但是，如果服务的更改频率较高，这种操作的开销可能会引起一些担忧。

基于上述情况和对Consul/Symfony内部的了解，这是否是一个可行的方法？如果不是，为什么？还有哪些替代方案可用？

- ReservedDeveloper

Answer 1

在我工作的公司中，我们采取了不同的方法。与其像Spring Data Consul那样与Symfony抗争接受运行时配置（它本应该这样做），我们决定让Consul更新Symfony配置，这与Frank的概念类似，但实现方式不同。

我们安装了Consul和Consul Template。我们创建了一个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 添加了一个Consul模板配置文件：

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"
}

< p > 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 模板的指定键中更改值后，它将将文件转储到配置的目标并运行更新参数的命令。

它工作得非常好。 =)

- Guilherme Blanco

Answer 2

在我看来，将简单的KV监视器将值放入parameters.yml中，触发cache:clear是最简单的选择，而且还提供了编译的好处，这样它就不必每次都去Consul检查值是否更新。像你说的，会有一些开销，但如果您不每5分钟更改参数，则似乎可以接受。

我们正在探索这个选项，但如果您对此有任何进展，我们将不胜感激。

[更新2016-02-23] 我们已经实现了我上面提到的想法，并且它按预期工作得很好。请注意，我们仅在部署新版本时更改参数（因为我们还使用Consul的服务发现，因此无需在parameters中更新服务列表）。我们主要这样做是因为它节省了我们在多台服务器上更改参数的繁琐工作。像往常一样：这可能对您不起作用，但是如果您像我之前说的那样不每5分钟更改参数，则应该是安全的 :)

- Frank

---

如果您有新的问题，请点击提问按钮进行提问。如果您拥有足够的声望，您可以投票支持该问题。或者，将其标记为收藏夹中的“星标”，您将收到任何新答案的通知。 - Tunaki

我可能误解了，但对我来说这是与该主题相关的问题。我正在请求有关他自己的问题的更新，而不是让其他人回答它（尽管那会很好）。 - Frank

所以这是一条注释，注释不能作为StackOverflow上的答案发布。用户通过提问、回答和编辑活动来获得评论特权。 - Tunaki

请阅读我之前评论中的链接。它解释了为什么。 - Tunaki

@Frank 这有点像鸡生蛋、蛋生鸡的情况，评论方面。我自己也遇到了一些挑战。针对你的问题，我们还没有继续探索这个问题。它被搁置了，因为我们的 Consul 值目前仍然保持着相当稳定。如果你最终采取你建议的路线并更新这个答案，我认为它可以证明是一个更符合 Tunaki 提到的回答。我认为，删除初始段落并将第二段清理成更多的陈述而不是问题可以解决大部分问题。 - ReservedDeveloper