您使用什么配置格式进行编译以及为什么?
示例(您不必按照示例回复,但请说明您的目录设置):
<Layout MyPersonalizedLayout> prefix: /usr exec_prefix: ${prefix} bindir: ${prefix}/bin sbindir: ${prefix}/sbin libdir: ${prefix}/lib/application_name libexecdir: ${prefix}/lib/application_name/modules installbuilddir: ${prefix}/lib/application_name/build mandir: ${prefix}/man sysconfdir: /etc/application_name includedir: ${prefix}/include/application_name localstatedir: /var runtimedir: ${localstatedir}/run/application_name logfiledir: ${localstatedir}/log/application_name </Layout>
在重新编译或升级应用程序之前,您会考虑哪些步骤以及采取哪些措施?
如何跟踪上次用于编译应用程序的所有配置选项?
您是否定期备份配置文件?多久一次?
您是否有一个特殊/不同的升级系统,以便您可以维护上一个可运行的应用程序直到新的应用程序准备就绪?
在将编译内容应用到生产服务器之前,您通常会对其进行测试吗?在这样做之前您考虑了哪些因素?
我不太喜欢使用 yum、apt-get 等安装管理器,尽管我相信它们对于某些东西非常有用,但我更喜欢在需要管理的应用程序中拥有自己的控制权和可能性,因此我想知道大家对此有何看法。
如果这个问题得到超过 3 个答案,我会把它变成一个社区维基,在此之前,我要求你不要把它变成一个
答案1
我倾向于使用脚本和源代码来标准化我的系统构建。其他人通常喜欢使用配置管理工具以及从源代码为他们的发行版原生包管理器创建自己的包。如果您正确地标准化构建,这些方法在很大程度上会提供相同的结果,它们只是做事的不同方式。
我仍然使用系统软件包和本机系统构建实用程序。对于 RHEL,Kickstart 对于初始构建绝对必不可少。对于常见的用户空间实用程序,我倾向于默认使用软件包。我仅从源代码编译主要服务器角色。例如:数据库、Web 服务器、代理服务器、负载平衡器等。
A1:我更喜欢遵循文件系统层次标准只要有可能。
A2:这是一个复杂的话题。如果升级需要升级库,其他软件可能也需要这些库。我倾向于通过源代码编译构建角色的所有核心要求。我经常在构建之间共享库,并重新编译针对它们编译的任何软件,因为我很少进行静态编译。如果您的更改经过测试并正确准备投入生产,则可以最大程度地降低风险。
A3:配置选项通常在构建中指定,当它们适用于所有服务器时。对于独特的配置,例如 Web 服务器集群上的特定 VirtualHost,我将在版本控制系统。在以编程方式构建服务器后,将完成系统检查表以进行健全性检查并配置最好手动处理的任何选项。您也可以使用配置管理系统来提供帮助,但根据您的构建标准化程度,它可能会被淘汰。
A4:是的。每晚备份所有唯一的配置文件。
A5:升级系统主要是内置于初始脚本中的逻辑,并带有包装脚本。这样可以将升级作为构建的一部分进行维护。有时,一组更简单的脚本使用for
循环bash
并通过 ssh 进行管道更改。我们的想法是首先让所有更改都得到适当的标准化。
A6:所有变更在投入生产之前都会在测试环境中进行测试和验证。所有预期功能都应经过验证以确保可操作。
老实说,我可以根据您的问题写一本关于这个主题的书。您本质上是在问如何正确构建、标准化和维护生产环境。我的答案并不详尽,并且应该在所有方法中应用基本标准。您可能会从本书中建立的基础中受益系统与网络管理实践。
我还就此主题写过其他答案。另请参阅:
答案2
如何跟踪上次用于编译应用程序的所有配置选项?
这取决于我如何构建应用程序。如果我正在构建 Debian 包,我会将 debian/ 文件夹的内容存储在 SVN 中。
如果我在没有包管理器的情况下进行安装,我将构建一个脚本或 makefile 并将其存储在 SVN 中。
您是否定期备份配置文件?
SVN 存储库每日备份。
在将编译结果应用到生产服务器之前,您通常会对其进行测试吗?在这样做之前您考虑了哪些因素?
我几乎总是进行测试,但具体测试方法取决于应用程序及其用途。
答案3
我为我使用的软件构建 SRPM,然后备份它们。这样,我就有了一个无限可重复的方法来干净地构建我在任何系统上使用的任何代码。