linux – 编译和维护应用程序?
>您使用什么配置格式
编译,为什么? 示例(您不必回复示例,但请说明您的目录设置): <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个以上的答案,我会把它变成一个社区维基,直到那时我才会要求你把它变成一个 解决方法
我更倾向于使用主要脚本和源来标准化我的系统构建.其他人经常喜欢使用
configuration management tools并从源代码中为他们的发行版本地包管理器创建自己的包.如果您正确地标准化您的构建,这些方法在很大程度上提供了相同的结果,它们只是不同的处理方式.
我仍然使用系统包和本机系统构建实用程序.使用RHEL,Kickstart对于初始构建来说绝对必不可少.对于常见的用户态实用程序,我倾向于默认为包.我只从源代码编译主服务器角色.例如:数据库,Web服务器,代理服务器,负载平衡器等. A1:我希望尽可能遵循Filesystem Hierarchy Standard. A2:这是一个复杂的话题.如果升级需要升级库,则其他软件也可能需要这些库.构建角色的所有核心要求我倾向于按源编译.库我经常在构建之间共享并重新编译针对它们编译的任何软件,因为我很少静态编译.如果您的更改经过测试并正确分阶段进行生产,则可以将风险降至最低. A3:配置选项通常在构建中在所有服务器上应用时指定.在唯一配置的情况下,例如Web服务器集群上的特定VirtualHost,我将在Revision Control System中维护这些配置文件.在以编程方式构建服务器之后,将完成系统核对表以进行完整性检查并配置任何选项最好手动处理.您也可以使用配置管理系统来提供帮助,但是根据您的构建标准化的程度,它可能会过时. A4:是的.每晚备份所有唯一的配置文件. A5:升级系统主要是内置于初始脚本中的逻辑,其周围有一个包装脚本.这允许升级作为构建的一部分进行维护.有时,在bash和pipe中使用for循环的更简单的脚本集通过ssh进行更改.我们的想法是让所有变更都得到适当的标准化. A6:在升级到生产之前,所有更改都在测试环境中进行测试和验证.应验证所有预期的功能是否可操作. 老实说,我可以根据你的问题写一本关于这个主题的书.您实际上是在询问如何正确地构建,标准化和维护生产环境.我的答案并非详尽无遗,并且有适用于所有方法的基本标准.您可能会受益于Practice of Systems and Network Administration一书中建立的基础. 我还就这个问题写了其他答案.也可以看看: Managing an application across multiple servers,or PXE vs cfEngine/Chef/Puppet automate server setup with source builds (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |