为什么选择 CentOS 6 或 7

介绍

运行我们的应用程序、我们的业务的服务器都依赖于安装的操作系统(或操作系统)提供的稳定性和底层功能。 作为管理员,我们必须提前计划并考虑未来我们的用户将如何使用我们监管的机器,同时确保这些机器保持稳定和在线。 有多种操作系统可供选择; 然而,最流行、最稳定和高度支持的操作系统之一是 CentOS。 结合了出色的功能、坚如磐石的性能稳定性以及红帽和红帽等以企业为中心的机构的支持 Fedora 使 CentOS 成为管理员可以信赖的主流操作系统。

虽然在两次迭代中都非常稳定,但从 CentOS 6 到 CentOS 7 的变化带来了许多变化,这些变化使 CentOS 周围的社区两极分化,并使管理员不得不决定哪个最适合他们的项目和组织。 选择用于给定项目的版本取决于许多只有您知道的因素。 但是,有一些常见的问题/兴趣点可以帮助您更轻松地做出决定。

评估当前需求

首先要考虑的也是最终最重要的方面是您要满足什么需求? 了解问题实际上是什么将为确定最终的解决方案提供清晰的路径。 一些 example 我帮助客户尝试在 Liquid Web 协商需求的“需求”是:

  • 在支持传统应用程序的同时利用更新和更强大的硬件
  • 为待开发项目准备测试和登台环境
  • 将客户数据/系统应用程序从报废软件迁移到受支持的软件

以上所有都需要检查现有系统的要求,并考虑将涉及哪些困难以及如何克服这些困难。 需要考虑的几点:

  • 如果您有想要支持的旧系统,或者可能已经在使用 CentOS 6 的系统,而您正试图简单地迁移到较新的硬件,那么您将需要考虑在生产环境中迁移到 CentOS 7 之前运行 CentOS 7 的测试环境。 底层操作系统、命令语法甚至可用的软件包版本都有很多变化。 由于预期环境发生变化而在生产中遇到问题是一个很容易避免的问题。
  • 保持一致的环境可以显着降低支持开销。 此外:如果您的环境目前由基于 CentOS 6 的主机组成,您将不必担心培训您或您的员工了解 CentOS 6 与 7 之间的差异/细微差别的教育方面。如果您在此处拥有完全托管的服务器Liquid Web 您可以更轻松地休息,因为我们的支持人员由 RHEL 6 和 7 Red Hat 认证系统管理员组成(更多内容见下文)。
  • 如果您有机会使用 CentOS 6 或 7 开始一个项目,您将需要考虑该项目的生命周期。 如果这是一个短期项目,那么使用您熟悉的操作系统的好处可能比更新的操作系统更大。 如果项目将得到长期支持,您将需要考虑软件包的生命周期和为操作系统提供的支持。

如果这是一个新项目,强烈建议使用 CentOS 7,因为它将继续获得支持,这是我的下一个讨论主题:

支持时间表

CentOS 有一个独特的版本控制方案,他们已将其用于他们最新的操作系统。 重要的是要识别您使用的版本、您需要/想要的版本以及任何给定版本的好处。 如果您的项目时间表认为该项目持续了相当长的时间,您将需要考虑对您的操作系统进行更新/修补的需求。 权衡使用 CentOS 6 与 CentOS 7 的好处完全取决于您需要多长时间才能获得支持。

CentOS 维基 在分解 CentOS 7 版本号的含义方面做得很好(第 29 点); 但是,记住 CentOS 7 版本控制的基本方法是:“两位数年份两位数月份”。 因此如下: CentOS-7-1406 代表 2014 年 6 月以来的 CentOS 7 版本。更改的主要原因是提供一个 CentOS 7 版本发布时间的快速参考,并让您了解它是否会发布支持的。 唯一支持的图像是次要分支中的最新图像。 Liquid Web 会定期更新我们的完全托管服务器,以确保它们运行最新的次要分支,确保您收到保持受保护所需的更新/补丁。

CentOS 6 不再接收更新的截止日期是 2020 年 11 月 30 日。在此时间点之后,CentOS 6 将被宣布为“生命终结”并且不再接收更新(补丁、安全等……)。 虽然这意味着 CentOS 6 最终会遇到尚未发现的问题或新硬件不支持的问题,但这并不意味着它仍然不能用于项目并且可以毫无问题地工作。 Liquid Web Support 还将继续为基于 CentOS 6 的服务器提供帮助,并指导您如何最好地升级到 CentOS 7(如果您选择的话)。 这也让您有时间开始测试 CentOS 7(也许使用可以轻松创建/拆除的虚拟服务器)并发现您需要进行哪些更改,以便您的应用程序可以在较新的操作系统上正常运行。

虽然您有时间决定是否可以使用 CentOS 6 或 7,但最好还是着眼于托管环境的未来。 CentOS 6 不再接收更新会带来潜在的安全风险,因为恶意个人将能够利用稍后发现的错误/弱点,而不必担心这些漏洞会被修补。 迁移基础架构需要时间,而那些希望利用这一事实的人将探查您的服务器和应用程序,以尝试找出那些无法纠正的弱点。 不过,迁移所需的时间取决于许多因素,包括 CentOS 6 / CentOS 7 之间的巨大变化和差异。下一节讨论许多人认为最大的变化:

系统D

毫无疑问,正是 SystemD 的引入引发了围绕 CentOS 7 发布的最大争议。尽管一段时间以来人们都知道它会从上游源(CentOS 使用 Red Hat 作为上游源,在转用 Fedora 作为上游资源的项目),对于习惯于 CentOS 6 的个人来说,这仍然是一个重大变化。 SystemD 的这种采用意味着必须检查和测试应用程序和软件,以确保它们在 CentOS 7 上正常工作,并且 SystemD 架构没有不会引起问题。 SystemD 的设计应该是向后兼容的; 这并不意味着每个更改都可以被忽略,因为它不会引起问题。 为您的项目选择 CentOS 7 时要考虑的事项:

  • 您是否需要完全控制您的系统和日志记录?
  • 您的应用程序是否需要定期与守护程序和其他服务交互?
  • 您是否希望能够使用您自己的软件包选择来覆盖操作系统默认值?

一旦这样 example 为什么 SystemD 会产生问题: SystemD 带来了“目标”,类似于 CentOS 6 的“初始化级别”。每个“目标”设置将要启动的服务,并围绕特定目的进行设计。 然而,这是一个素数 example 为什么测试以确保您的应用程序工作是关键:目标不是初始运行级别,您可能对给定运行级别进行的自定义可能不起作用。 如果您的环境不是为处理这些更改而设计的,那么默认行为的这种更改可能会产生意想不到的后果。 默认值的更改是 CentOS 7 中的一个流行主题,这让我想到了我的最后一个主题:

默认值已更改

最后要讨论的主题是您将在 CentOS 6 和 7 之间看到的默认更改。同样,这一切都与您设计应用程序要处理的内容有关。 以下是个人可能会注意到的从 CentOS 6 到 CentOS 7 的一些更改默认值:

  • 默认文件系统从 EXT4 更改为 XFS
  • 默认内核从 2.6 更改为 3.10
  • 默认防火墙从 Iptables 更改为 FirewallD
  • 默认数据库管理系统从 MySQL 更改为 MariaDB

这些选项是可以解决的,但是您冒着创建一个系统的风险,您不断地尝试“修复”和纠正,以便您可以处理引入的更改。 评估您是否甚至需要关注这些更改是确定 CentOS 6 或 7 是否会对您的项目产生影响的另一个组成部分。

结论

尽管 CentOS 7 已经发布了一段时间,并且 SystemD 已经在上游使用了更长时间,但仍有一些错误和问题正在解决。 CentOS 一直是托管世界的中流砥柱,因为它提供了坚如磐石的稳定性,其中大部分在 CentOS 7 中得到延续。它仍然经过彻底的测试,并且有一个围绕开发的大型社区。 未来在于 SystemD 和正在发生的变化,如果您需要支持或期望更新,您将被迫使用 CentOS 7。但是,只有您知道您的项目需要和依赖什么。 无论您是否熟悉 CentOS 7、SystemD 以及迁移数据的过程,Liquid Web 都可以为您提供帮助。

如果您有兴趣了解 CentOS 7 的一些更改,请查看知识库以获取讨论 CentOS 7 和常见操作/任务的文章。