Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

请管好服务器配置!

  以前我喜欢用 nodejs 来搭开发环境的 Web 服务,甚至有时候把开发机上的 80 端口都直接交给 nodejs 用。但是后来渐渐发现这么做的坑很大。因为对外的 Web 服务器并没有直接使用 nodejs,而是 nginx 之类的东西。如果用 nodejs 搭建开发环境就需要额外的维护成本。
  只有让本地开发环境的配置规则与生产环境同步才不容易出错。以前就遇到过开发环境加了一条后端路由规则后代码急着上线,忘了给生产环境加上,于是生产环境就呵呵掉了。而且开发环境的配置如果和生产不同,可能会出现开发环境的程序可以正常跑通,到生产环境就出现莫名其妙问题的情况。
  当然,开发环境和生产环境的配置很多时候都不会是完全相同的。就拿 nginx 配置为例,root 和 server_name 这两个配置项就是由环境决定的。在开发环境可能是 root 是一个 github 仓库的目录,server_name 是 dev.xxx 之类的东西。到生产环境后就变成了打包后的文件目录和对外的域名。这两个配置项只是典型,还有很多这样在各个环境不同的配置项。所以如果真需要保证配置的一致性应该由一套模板来管理,把 root、server_name 这种配置作为参数。
  一个项目所跑的环境通常不仅是开发环境和生产环境,还有测试环境等一堆奇奇怪怪的环境。如果没有这样一套配置模板来维护各个环境间的配置,那就无法保证各个环境之间的配置一致性。所以我推荐的做法是将 root、server_name 之类的属性保存在机器的环境变量中,用一套模板引擎来把这些环境变量嵌入到 nginx 配置文件模板中使用。
  还有一个值得注意的点是我们应该保持所有机器上的配置同步。如果机器上的配置不一致,开发人员可能很难调试并定位到问题所在,这会浪费大量时间,特别是在分布式的拓扑中尤其明显。所以这个模板文件应该统一管理并部署到每台机器上。而且这个过程不应该有人工来做,人工做的难免会有遗漏。应该有个专门的配置管理系统来做这件事,或者最差也应该有一个 shell 脚本来做这件事。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^