Web 服务器配置文件的版本控制
在我和网络架构师之间，我们管理着一堆 Web 服务器（FreeBSD）。他负责所有服务器/网络相关的东西（IP、防火墙、用户/组等），我负责所有与 Web 相关的东西（Apache、PHP、MySQL）。有时职责会重叠。
有几次对配置文件进行了一些更改，这些更改或多或少地影响了服务器，我们无法弄清楚是我们中的哪些人进行了更改以及原因。
作为一名 Web 开发人员，我认为将文件置于版本控制之下是一个很好的做法（我们目前使用 Subversion），这样每当我们更改任何内容时，我们都必须提交更改的注释。它将解决所有想知道谁做了什么以及为什么做的问题。
我想到的特定配置文件是：
- 防火墙配置
- apache 配置（带附加功能）
- php 配置（php.ini）
- MySQL 配置（my.conf）
我已经知道，服务器配置文件的版本控制理念是基于 < a href="https://stackoverflow.com/questions/4243174/should-server-database-config-files-include-passwords-be-stored-in-source-con">提出的其他问题在这里。我唯一担心的是如何在 Web 服务器端正确执行此操作，因为文件位于不同的位置。将整个 /usr/local/etc 置于版本控制之下似乎毫无意义，因为它不仅仅包含配置文件。
我想知道是否不创建一个新文件夹，比如 /config ，它将受到版本控制，并包含我们需要的所有配置文件，然后用符号链接替换原始的 >/config 文件夹。例如：
/usr/local/etc/apache22/httpd.conf -> /config/apache22/httpd.conf
所以问题是：这是一个好主意吗？如果不是，更好的解决方案是什么？
Between me and a Network Architect we manage a bunch of Web Servers (FreeBSD). He's responsible for all server/network related stuff (IPs, Firewalls, users/groups, etc.) and I'm responsible for all web-related stuff (Apache, PHP, MySQL). Sometimes the responsibilities overlap.
It happend few times that some changes were made to the config files which more or less affected the server and we were not able to figure out which of us made the changes and why.
I - being a Web Developer - think it'd be a good practice to put the files under version control (we currently use Subversion), so that whenever we change anything we have to commit an comment the changes. It'll solve all the problems with wondering who did what and why.
The particular config files I was thinking of were:
- firewall config
- apache config (with extras)
- php config (php.ini)
- MySQL config (my.conf)
I already know, that the idea version control of server config files is sound based on other question asked here. My only worry is how to do it properly on the Web Server side since the files are in different locations. Putting the whole /usr/local/etc under version control seems pointless as it contains not just the config files.
I was wondering whether not to create a new folder, say /config which would be under version control and would contain all the config files we need and then replace the original ones with symlinks to ones in the /config folder. E.g.:
/usr/local/etc/apache22/httpd.conf -> /config/apache22/httpd.conf
So the question is: Is this a good idea and if not, what is a better solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用 GIT，那么将整个
/usr/local/etc置于版本控制之下根本没有意义。只需安装 git，然后转到
/usr/local/etc并写入git init。这将在您当前位置创建 .git 文件夹（基本上使该文件夹成为存储库）。然后添加您要跟踪的配置文件：
git addfirewall/firewall_config.conf apache2/httpd.conf等并提交：
git commit -m "Initial Configuration"您的配置文件现在正在被跟踪。
If you use GIT then puitting the whole
/usr/local/etcunder version control is not pointless at all.Just install git, then go to
/usr/local/etcand writegit init. This will create the .git folder in your current location (basically making this folder a repository).Then add the config files you want to track:
git add firewall/firewall_config.conf apache2/httpd.confetcand commit:
git commit -m "Initial Configuration"Your config files are now being tracked.
由于您正在对敏感配置文件进行版本控制，因此我建议您设置一个内部 git 服务器，例如 gitlab。为每个服务器或服务器模板/图像/等创建一个 git 存储库。转到 / 目录并“git init”。
您可以通过仅对要自定义的文件使用“git add /path/to/file”来选择将哪些内容置于版本控制之下。
然后，'git -m '提交评论' 和 'git Push -u origin master'。
Since you are versioning sensitive configuration files, I would recommend setting up an internal git server like gitlab. Create a git repository for each server, or server template/image/etc. Go to the / directory and 'git init'.
You can be selective about what you put under version control by only using 'git add /path/to/file for the files that you will be customizing.
Then, 'git -m 'commit comment' and 'git push -u origin master'.
您是否看过专门用于执行此类操作的管理工具？我推荐 Puppet 或 Chef，在之前的工作中使用过它们来完成此类事情。
Have you looked at any of the management tools made to do just this sort of thing? I recommend Puppet or Chef, having used them in previous jobs to do this sort of thing.