用 Consul 管理 Laravel 项目配置

在预生产环境跑了一年多,在此记录和分享一下。

file

问题 & 其他方案

当我们需要在多台服务器部署多个不同的项目时,我们需要一个集中的配置信息管理和同步的工具。考虑过的方案有:

  1. 用rsync同步.env文件:多个项目的配置略繁琐,要ssh到服务器修改再同步
  2. 用Docker:集群部署比较方便,可以用图形界面修改环境变量,但是更新环境变量要重启容器,大部分项目没迁移到Docker

下面看一下Consul + Consul Template的方案。

安装

ConsulConsul Template都提供了预编译的可执行文件,下载解压即可。

启动Consul:

consul agent -server -bootstrap -ui -bind <ip>

其他服务节点可以通过consul agent -join <ip>加入到集群。

启动之后通过consul命令、RESTful API、Web UI管理Consul。

Consul KV

Consul提供了一个分布式的键值对存储,可以用来存储应用的动态配置信息,基本操作:

# put 设置一个KV对
consul kv put APP_DEBUG false

# get 获取
consul kv get APP_DEBUG

# exprot 导出JSON
consul kv export > data.json

# import 导入JSON
consul kv import @data.json

# delete 删除
consul kv delete APP_DEBUG

Consul KV支持目录,可以通过/分隔key实现,例如我们使用configs/<app_name>/这样的目录来存放一个项目的所有配置。

Consul Template

配置集中管理了,怎样传给Laravel呢?一个方法是在Laravel里用Consul的API获取配置信息,第二个发放是在外部监听KV变化然后写入到.env文件,Consul Template就是这样的一个外部工具。

我们用的配置模板(.env.tpl):

{{ range ls "configs/crm" }}
{{ .Key }}={{ .Value }}{{ end }}

意思是遍历config/crm这个KV目录,生成key=value格式。

运行:

## 格式: 模板文件:目标文件:更新后执行的命令
consul-template --template \
    /path/to/.env.tpl:/path/to/.env:'php /path/to/artisan config:cache'

就可以生成.env文件,并且持续监听变化,一个consul-template实例可以有多个--template多个参数,可以为一台服务器上多个项目生成配置文件。

本帖由系统于 10个月前 自动加精
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 10

你们都用到分布式键值储存了,业务有多大

10个月前

@xuanjiang1985 我们业务不大,主要是项目多、配置多。Consul的键值对存储主要是配置信息,大容量、高并发的键值对还是要Redis、Memcache这些。

10个月前
medz

@Oraoto 说个实话哈,docker 上容器云的话,配置你们貌似用错了~这个配置其实完全不需要进行同步,除非做了自定义的其他配置文件挂载事件进来覆盖配置才需要!
程序进行容器化后,应该在编排的时候进行变量配置。即可~

10个月前

@medz docker的问题不是同步,而是要重启、重新编排才能改环境变量,而我们有比较多的动态配置(例如特性开关)是通过环境变量设置的,所以不太合适。如果只是静态配置,用docker的环境变量是很合适的。

10个月前
不忘初心

@Oraoto 觉得配置文件还是跟项目文件在一起比较好, 不然的话每次配置的修改和查询都要走网络而且还是静态数据很不值得.所以觉得不建议把配置文件这种静态数据存到Redis、Memcache中 在读取. 还是跟着项目代码落到文件中好一些.

10个月前

@不忘初心 这个方案里是直接生成.env然后缓存,运行时Laravel应用里查询配置是不走网络的。代码管理方面,我们还是会把去敏的.env.example放到仓库里,可以用在本地开发或者用脚本导入到conusl。

10个月前
MrJing

感谢楼主分享!
业务多了,配置中心的优势就出来了。比如多个项目有一些公共的配置(MySQL、OSS、Redis)修改后,那就得都修改一遍。而且如果是每个项目还部署了多台机器,就更加糟心了。一开始我的想法是为配置文件建立一个git repo,修改配置后用 deployer 部署配置,项目目录里面配置文件其实都是通过软连接指向配置项目的目录和文件。但是由于不同项目之间除开公共配置之外,还有大量不同的配置项,这个方案也并不是很方便。

10个月前
motecshine

ConsulRedis 最大的区别是 Consul 实现了 Raft算法,从而保证了分布式k-v集群数据强一致性。不知道看你们的 业务 是不是 微服务化了,如果 Consul不是Cluster,那我觉得用redis还是 更简单点

9个月前

@Noober Phper 我们的consul是集群部署的,consul的理念就是每台服务器一个client agent,应用只和本机的agent交互。我们的应用之间有依赖,但是没彻底微服化。

9个月前
eiomi

谢谢分享

7个月前

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!