生产环境的配置不应该写在代码里

再加强一点，所有配置都不应该写在代码里

再加强一点，服务器软件的配置就不应该写在项目代码 /运行时环境的路径和子路径里，也不提倡写在运行服务器的帐户的家目录里，最好按照操作系统生态的惯例，写在全局配置的空间

脑海中瞬间弹出 FBI Warning

UUID 没毛病，但是在 MySQL 上用嘛……连原生支持都没有，就像上面有 v 友说的，你打算当 binary 还是 text ？

推荐发行版打包的 deb/rpm

一个高级玩具，想业余玩就业余玩，想专业玩就专业玩，什么意义不意义的

妥妥投诉到工信部，IPv6 可是部里的任务

如果服务器数量比较多，而且都是异质的（企业信息化环境里很常见，没有那么多像互联网环境那样一大堆同质节点做横向扩展的架构），那么一个带 GUI 的客户端对日常琐碎操作还是有点用的。至少，从 connection manager 里用眼睛看文字识读挑选目标服务器打开，比在命令行上输入 ip 或者别名要舒适很多。服务器多了，记不清 ip 或者名字很正常，但是看着列表挑选就容易很多。而且，既然是跑信息化业务的，还有很多名字是中文业务名，能挑选还是不输入了吧。

NetBSD 倒是很多年前就在内核放 Lua 了

这种打字机敲文稿时代形成的手指分工规则，对于 PC 键盘敲代码来说……还是不要奉为圭臬的好。

安全部门一般会要求至少保证 security 的及时更新。业务部门一般会抵制更新。屁股决定脑袋，都希望出问题了责任不在自己。

但是 esxi 是免费的，要上 vcsa 就得掏钱了。破解另说。

esxi 只是个 hypervisor ，要多机集群用得上 vcenter server appliance 做管理。用上 vcsa 之后你会发现世界完全不一样了。

只有等翟天临博士动嘴才能治得住这种无良商家😄

看这架势很快会有人实现类似 dnsmasq 的 ipset 分流功能……

这么执着 wine…有没有考虑过用 Windows…

方法四，加一个命令行参数，用于指定从哪里读取配置文件。默认是从项目内部路径，可以指定覆盖。服务器上部署时，就在 systemd unit 或者其它启动机制里指定。

我自己做的小项目或者要供应商做的大项目里主要用方法三和四。

只写过业务代码没在生产环境玩过服务器运维但是对这个问题又困惑并且愿意较真的小盆友们还是认真玩玩服务器。比如用 Linux 的，至少了解文件系统的各部分，知道发行版打包好的基础软件是怎么使用文件系统里不同目录结构的，File-system Hierarchy Standard 是什么。虽然发行版打包好的基础软件的惯例通常不太适合 100%照搬到业务系统上，但有很大的借鉴价值，会让你们的系统部署跟运维老司机的对接更流畅。

只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。