2020s-的系统管理学习手册-全-

2020s 的系统管理学习手册（全）

原文：Linux System Administration for the 2020s

协议：CC BY-NC-SA 4.0

一、Linux 概览

Linux 从何而来？Linux 何去何从？为什么你不应该害怕使用 Linux？

对于任何不熟悉 Linux 的人，或者任何希望更多地了解这个神奇的操作系统的人来说，这些都是重要的问题。Linux 已经并将继续改变世界；Linux 已经带来的机会是惊人的，但是它仍然提供真正让我兴奋的东西。与开放源码社区一起，Linux 将继续发展、成长，并鼓励全球数百万开发者创造新项目的创新。有了开源世界的开放协作本质，我们将无所不能。任何问题都不会太大。

在第一章中，我们看一下社区和企业 Linux 发行版之间的区别。我们将讨论为什么有些人喜欢 enterprise Linux，而有些人喜欢社区发行版。我们将看看一些发行版在如何管理操作系统方面采用的不同方法，并理解为什么会产生发行版的变体。最后，我希望帮助您理解为什么有人会使用社区或企业 Linux 发行版的可能原因。

简述 Unix 到 Linux 的历史

早在人们想到 Linux 之前，世界上就有了 Unix。Unix 与 Linux 非常相似，都是出于需要而创建的。

由几个组织，即通用电气、麻省理工学院、美国电话电报公司和贝尔建立的分时操作系统 Multics，并没有取得所有人希望的成功。肯·汤普森、丹尼斯·里奇和他的同事们退出了 Multics 项目，开始研究我们今天所知的 Unix 操作系统。在 20 世纪 70 年代，进行了各种各样的改变和改进，最终使得 Unix 得到了更多的重视。像 C 这样的新编译器被加入进来，顺便成为用它编写新版本 Unix 的催化剂。

早期 Unix 的一大症结在于法律限制。不幸的是，贝尔实验室没能把 Unix 作为一种产品来销售。然而，这并没有阻止 Unix 源代码奇迹般地公开。有传言说，对操作系统代码有许多要求的 Ken Thompson 最终放弃了，并把带有 Unix 代码的媒体发送给任何要求它的人，通常还附有一张纸条“爱你的 Ken”这种“开放”的方法当然会在以后的几年流行起来，但更多的是在一点。

正如任何新项目的新软件开发一样，总会有不同的开发人员对如何完成工作有不同的想法。Unix 开发也不例外，所以自然不存在标准。各种 Unix 平台中不同的开发思想和方向在 20 世纪 80 年代 Unix 的三个主要变体出现时最为流行。它们是 System V、BSD 和 Xenix。到了 20 世纪 90 年代，常识终于占了上风，COSE(Common Open Software Environment，通用开放软件环境)成立，为 Unix 操作系统设定了标准。有了这些新标准，Unix 操作系统越来越强大。Unix 已经成为一项全球性的工作，不再由个人来完成。

Linux 的开始和 Unix 没有太大区别。不像 Unix 是 Multics 的一个分支，Linux 是从底层重新发明的 Unix。

20 世纪 90 年代初，赫尔辛基大学的一名芬兰学生 Linus Torvalds 厌倦了现有的操作系统选择。Linus 想使用 Unix，但不幸或幸运的是，取决于你如何看待它，Unix 对一个学生来说太贵了。只剩下一个选择，Linus 开始从头开始构建他的内核“只是为了好玩” 1 。

大约在莱纳斯编写 Linux 内核的同时，一位名叫理查德·斯托尔曼的美国软件开发人员和 FSF 2 一起开发了他们自己的操作系统 GNU。莱纳斯和理查德·斯托尔曼以及 FSF 最终都朝着同一个目标努力，尽管出发点不同。Linus 构建内核，FSF 的 Richard 构建实用程序。这些实用程序和内核的结合导致了第一个 Linux 操作系统“GNU/Linux”的诞生

开放源码

开源并不意味着“免费”。软件没有成本并不意味着软件没有价值；这意味着源代码是开放的，而不是被锁在某个专有的金库里。

如果软件没有成本，那还有什么意义，对吗？怎么会有人从中赚钱？

这是像 SUSE、Canonical 和 Red Hat 这样的公司赚钱的地方。他们出售订阅来支持他们的发行版，但实际上并不出售软件。例如，您可以使用 Red Hat Enterprise Linux，而无需订阅，并且您可以毫无问题地从社区存储库更新操作系统。然而，你不能要求红帽支持你。为此，你需要付出代价。

Linux 无处不在

我们今天使用的几乎所有东西，从智能手机到笔记本电脑，或者我们在电影院买电影票的自助终端，都有一个共同点:它们都使用 Linux。嗯，几乎所有的事情。当我走过伦敦地铁时，我仍然能看到奇怪的“BSOD”窗户。我的观点是，我们几乎每天都在不知不觉中使用或看到 Linux。Linux 经常被用在火车站和机场的广告牌上，但是你有没有意识到你的航班上使用的娱乐系统也是 Linux 驱动的？如果你坐了八个小时的飞机却没有娱乐，这可能不是最好的例子。

像这样的 Linux 系统更容易开发和改进，而且由于维护它们的社区不断地致力于错误修复或新项目，这种开发模式推动了创新，并不断地鼓励来自更大组织的投资来开发新的想法。

硬件供应商也开始理解为什么开源更好，并不断寻找利用开源工具的方法。在移动或手机市场，这一点怎么强调都不为过。

2013 年，安卓市场有 75%的市场份额；今天，这个数字仍然在 72%左右。这在全球智能手机市场中仍占非常大的比例。超过 50 亿人使用智能手机。也就是说，全球约三分之二的人口使用移动设备。其中 72%的设备使用安卓系统。这意味着现在世界上几乎有一半的人口在使用 Linux。

智能电视、平板电脑、家庭自动化设备和物联网设备也不排除在外。开源软件使得这些平台和小工具变得越来越流行。像谷歌、亚马逊和飞利浦这样的公司已经为简单的家庭自动化发布了非常好的产品。如今，技术含量最低的人也有能力配置自己的家，让灯光按照时间表或动作开启。

当我看到一个水壶可以在早上起床前烧开水时，这似乎仍然像是科幻电影中的东西。如果你对此不感兴趣，想象一下一个智能设备，它有一个由虚拟厨师控制的机器人手臂，可以根据菜单命令烹饪你的晚餐。

令人印象深刻的不仅仅是我们家中的创新，让我兴奋的是将改变世界的自动化。我最近看到了管理菜园的新自动化工具。使用的软件可以检测和命令机器人系统清除杂草，给蔬菜浇水，喷洒农药。

这些创新的设备和想法深深植根于开源和 Linux。成百上千的开发人员和爱好者的存在表明，协作远远胜过任何专有软件公司的开发工作。

我提到的这些例子现在是小规模的，但是想象一下全规模的；想象一下，数百英亩的农田正在被自动化种植食物，或者自动化餐馆有机器人厨师，可以烹饪你从菜单上选择的任何东西。是的，总是有人的因素会面临这种创新的冲击，对此也有一个答案。通过自动化和创新，我们摆脱了工作，我们正在建立让我们吃饱穿暖的系统和平台。正如我们的技术在不断发展，我们也必须如此。农民在田地里辛苦劳作，现在他们可以花时间增强推动自动化的机器学习。农民现在可以花更多的时间和家人在一起，或者创新更好的耕作技术。

通过遵循开源实践和回馈社区，农民可以扩大和养活更多的人。建设社区项目和与地球共享只会增加消除饥饿的能力。正是这些创新让未来变得光明，打开了新的大门。这些想法让我们能够解决世界难题，做我们作为智慧生物应该做的事情。改善我们生活的世界，而不是摧毁它。

社区 Linux 发行版

顾名思义，社区 Linux 发行版，或者更广为人知的“发行版”，是由社区为社区开发和支持的。

这很好，但是“社区”这个词实际上是什么意思呢？

社区

“社区”是一个名字，通常指不为单一组织开发产品的一群人。嗯，我想那不完全是真的。一些组织，如 Red Hat，赞助社区开发和开发社区产品，作为它们的上游变体。这些社区更喜欢关注术语“项目”而不是“产品”

向上游

开源世界中的另一个词是“上游”。“上游”是一个用来描述企业产品基于什么的术语。这也不意味着企业产品是上游产品的直接拷贝。上游更多地被认为是“前沿”或创新温床，通常用于在推向企业产品之前证明和测试新产品功能。

如果一个产品赞助商，比如 Red Hat，喜欢某个上游特性，他们就从社区中获取代码，然后把新的特性加入到企业中。然后，在向客户发布新版本之前，对这些功能进行测试和修改，以确保它们是企业级的。

值得一提的是，企业产品的名称通常与“上游”产品不同。以 Fedora Linux 为例。Fedora 被认为是红帽企业 Linux 或 RHEL 的上游。

社区贡献者

为了一个社区的存在或提供一个产品，社区需要贡献者。社区贡献者通常是软件开发人员、业余爱好者或喜欢在业余时间构建和开发项目的人。这些贡献者将他们的业余时间奉献给任何人使用。对他们来说，这就是让尽可能多的人分享他们的作品。

Note

还有一点需要注意的是，回馈社区不仅仅意味着写代码。成为社区的一员可以是任何事情，只要你能以有意义的方式为项目或社区做出贡献。这可能是一笔捐款，也可能是放弃你的一些时间来举办一次聚会。任何有助于项目发展的东西都是有价值的。

常见分布

在撰写本文时，大约有 600 个 Linux 发行版可用，误差不大。很多是比较知名的发行版的叉，也有一些是叉的叉的叉。

正如已经提到过几次的，开源就是开放，让任何人都可以使用代码。这就是为什么任何人都可以创建一个新的发行版；事实上，有一些发行版可以帮助你创建发行版。

所有发行版都有一个共同点，那就是 Linux 内核。所以最终还是要看 Linus 发布了什么。欢迎您尝试创建自己的内核；我相信很多人都尝试过，但有时最好不要尝试重新发明轮子，尤其是如果它仍然工作得足够好的话。也许有一天内核需要被重新设计，但是在那之前我们会信任 Linus。

内核是少数几个在大多数(如果不是所有的话)Linux 发行版中都相同的东西之一。Linux 发行版之间确实存在着包管理系统的差异。像 Red Hat Enterprise Linux、Fedora 和 CentOS/Rocky 这样的 Linux 发行版使用基于 RPM 的包管理系统。像 Debian 和 Ubuntu 这样的发行版使用他们基于 deb 的包管理系统。

另一个不太为人所知的包装系统似乎得到了一点牵引力是吃豆人。Pacman 目前正被游戏发行版 SteamOS 和 Manjaro 使用。

有了所有可用的发行版，了解每个发行版的来源以及该发行版的用途是很重要的。如前所述，Fedora 被视为 Red Hat Enterprise Linux 的“上游”,但这并不是它最初的初衷。Fedora 最初是由 Warren Togami 在 2002 年作为一个本科生项目发布的。该项目的目标是让 Fedora 充当在非 Red Hat 平台上开发和测试的第三方产品的存储库。

其他发行版纯粹是为了安全而构建的，比如为渗透测试而构建和配置的 Kali Linux。像 Puppy Linux 这样的发行版是一个精简的发行版，允许用户在较旧较慢的硬件上运行“较轻”的 Linux。

作为对所有可用 Linux 发行版思维导图的小小尝试，下面是基于 RPM 的发行版家族树的一小部分。这个表没有考虑到从这些发生的分叉中的分叉。

|

RHEL/CentOS

|

一种男式软呢帽

|

大蜥蜴

|

曼德拉草

|
| --- | --- | --- | --- |
| 亚洲人克利罗斯停止 linux lts 奇迹 LinuxOracle Linux 红色 Linux 标志岩石群分布 Rocky Linux 科学 LinuxAmazon Linux 2 | Berry LinuxBLAG Linux 启动 Secure Linux 富顿图汉萨娜科罗拉 linpus linuxLinux XP 米戈俄罗斯 Fedora 混音信任黄狗 Linux | SUSE Linux 企业桌面企业服务器 SuSE studio(SuSE studio)壁虎 | 发送 LinuxMageia 粉红色 LinuxOpenMandrivaUnity Linux |

哪个发行版最适合你

有了这么多可用的发行版，对于任何新用户来说，选择哪一个发行版都是一项艰巨的任务，最终可能会吓跑潜在的新用户。

那么你如何着手选择适合你的发行版呢？

为了决定哪个发行版最适合你，你需要问自己正确的问题。

以下是我在选择发行版时喜欢考虑的几个问题。我相信还有很多更好的，但我认为这些是一个好的开始:

  1. 这是用来扩展我的知识面，还是仅仅替换我现有的操作系统？

  2. 我需要使用任何 Windows 产品吗？

  3. 我会在平台上玩游戏吗？

  4. 我想从平台获得多少控制权？

  5. 我希望预装和配置多少？

提交前

对于任何迁移到 Linux 的新用户来说，最好的方法是采用分阶段的方法，他们可能不熟悉 Linux 或开源工具。从在当前操作系统上使用开源工具开始。改用火狐浏览器或使用雷鸟收发电子邮件。找到您当前使用的产品的开源替代产品，并熟悉它们。一旦熟悉了新的工具，那么切换到 Linux 将会减少文化冲击。

Tip

列出你使用的所有工具，并在互联网上搜索开源替代工具，然后逐一切换。如果有些产品不适合您，请尝试不同的产品，或者使用您认为适合您的发行版启动虚拟机，并在那里测试您的替代工具。

三个 Linux 发行版类别

在我个人看来，有三类 Linux 发行版可以使用:

  • 更简单的“开箱即用”发行版，从第一天起一切正常

  • “几乎开箱即用”的选项，几乎拥有您需要的一切，但需要一些调整

  • “接受挑战”发行版，从安装到配置都需要时间、耐心、学习和经验

选项一:开箱即用的发行版

容易理解

对于 Linux 的新用户，您会希望看到一些安装简单、易于理解的东西，一些“开箱即用”的东西像 Ubuntu、Zorin OS 和 Elementary OS 这样的发行版使用起来很简单。所有这些在某些方面都与 Windows 有相似之处，这使得以 Windows 为主要背景的用户切换起来更容易一些。

安装不需要学位

为初次使用 Linux 的用户寻找最佳发行版的另一个重要方面是发行版需要易于安装且不复杂。销售预装 Linux 的笔记本电脑或台式机的硬件供应商并不多，所以重要的是用户可以安装发行版而不会感到沮丧。安装应该像从 DVD 或 USB 启动并点击安装一样简单。当不可避免地需要重新安装时，简单的安装会有所帮助。没有一个新用户会想要安装过于复杂的东西，包括深入的配置步骤。一个简单的，下一个，下一个，完成安装就可以了。

试试 Ubuntu

例如，Ubuntu 对于刚接触 Linux 的人来说是一个很好的选择。安装很简单，创建安装介质的方法并不过分复杂，并且有足够的一分钟 google 搜索来找到如何创建可引导介质的答案。安装本身不需要太多考虑；默认工作得很好，会给用户留下一个合适的安装。

对于新用户来说，Ubuntu 的配置可能会有一个小的学习曲线。然而 Ubuntu 有一个很好的“应用商店”,几乎可以找到任何东西。

像 Wine 和 Lutris 这样的应用在 Ubuntu 上运行得非常好，这意味着游戏可能会更容易。Lutris 本身是一个非常有用的工具，因为它很好地包装了游戏在 Linux 上运行所需的配置。这些脚本很容易在 Lutris 中找到，并且可以相对容易地添加。

跑步前先走

我对任何新用户的建议是从 Ubuntu 或类似的东西开始。熟悉 Linux 的一般工作方式。了解 systemd，了解防火墙是如何配置的。

熟悉为内核之外的硬件安装驱动程序，比如显卡。花时间在讨论板上学习如何自己解决问题。

作为一个有趣的入门项目，督促自己学习如何将 Linux 发行版配置为 web 服务器或 plex 服务器。

选项二:几乎开箱即用的发行版

选择一个需要更多理解的发行版是让你的 Linux 知识更上一层楼的好方法。这些发行版推荐给已经使用 Linux 一段时间的用户，他们可能希望开始尝试更复杂的配置，可能尝试合并工作元素并理解企业产品的新特性，甚至可能将您的工作环境迁移到 Linux。

试试 Fedora、openSUSE 或 Debian

如果电脑游戏不重要，不需要使用 Windows 产品，你可以考虑 Fedora、openSUSE 或 Debian。这些都是值得考虑的好选择。它们都需要“调整”才能适合你，但是如果你不太介意，你可以照原样使用它们。

我个人比较喜欢用 Fedora。它是 RHEL 的“上游”，对我的日常工作有帮助，也是我过去十年一直使用的。至于默认桌面，我真的不喜欢 Gnome 或 KDE，所以我安装了 Cinnamon。

然而，Fedora 并不适合玩游戏或安装 Windows 产品。显卡驱动程序并不出色，有时安装起来会很困难。并非不可能，但似乎比 Ubuntu 要多一点工作，例如。

安装第三方工具也需要安装新的存储库，有时需要“调整”才能工作。在线说明并不总是很清楚，这意味着你需要多考虑一下问题是什么。在大多数情况下，这相当简单，只要有足够的耐心就能解决。

选项三:“接受挑战”发行版

如果你更喜欢挑战，那么更“困难”的发行版可能是你要考虑的。使用这些更具挑战性的发行版将涉及如何配置平台的经验和理解，通常在线资源的帮助有限。

当你在网上寻求帮助时，使用这些发行版可能会让你求助于可怕的 RTFM 3 。这并不是说这些发行版的社区会很难，它们主要是由超级聪明的人组成的，他们没有太多的时间来帮助那些不想帮助自己的人。

Note

在后面的章节中，我将讨论如何提出技术问题。这是所有技术人员都需要学习的，以避免在问技术问题时激怒他人。

以巨大的力量…

这些“接受挑战”的发行版为用户提供了更多的“能力”(并不是说其他发行版没有这种能力)。它们为用户提供了更多的选择和机会，无需过多思考就能打破平台。这些发行版在运行命令或配置更改时需要小心。在不知道后果的情况下运行命令很可能会导致系统重建。

试试 Arch Linux 或 Gentoo

如果你仍然对这个挑战感兴趣，那么像 Arch Linux 和 Gentoo 这样的发行版是可以考虑的。众所周知，它们更难安装，而且有一个陡峭的学习曲线。

这些发行版应该在你自己解决问题的时候使用，并且不需要太多的指导。您应该精通于查找有意义的错误，并了解在需要时增加冗长的地方。

从代码中编译并重建内核模块也不应该是你以前没有做过的事情。在某些情况下，让应用程序或驱动程序工作将涉及这些类型的任务。像 Arch Linux 和 Gentoo 这样的发行版应该留给那些希望给自己设定一个挑战的铁杆粉丝，所以如果你有挫败感，不要轻视它们。

企业 Linux 发行版

Red Hat、SUSE 和 Canonical (Ubuntu)围绕付费订阅模式建立了自己的公司。由于软件和代码是开源的，这些公司不能卖给你软件。相反，他们向您销售支持和企业级产品更新。作为用户，你可以随意使用产品，只要你不违反许可协议，也就是说，声称代码是你的，并把它变成专有代码。

Note

如果您不确定，请阅读许可协议以确保您没有违反任何规则。

企业产品真正值得投资的地方是这些公司提供的产品更新。这些更新对于银行等需要企业支持的公司来说至关重要。银行需要高度的安全性。他们依靠像 Red Hat 这样的公司在漏洞公开时提供最新的安全更新。如果银行不使用企业产品，而选择使用基于社区的产品，他们将需要等待社区修复报告的漏洞。这有时可能需要几个小时或几天，如果不是几个星期。

如果这个漏洞是一个特别严重的漏洞，它给银行带来的损失可能比任何软件订阅都要大。如果一些组织因为等待社区修复的漏洞而被攻破，这甚至可能意味着它们的终结。

企业 Linux 公司可以从他们支持的软件中赚钱，但是不要认为他们没有帮助社区开发他们的产品。企业 Linux 公司对于社区来说已经变得非常重要，他们从社区中获得大部分“上游”产品。例如，Red Hat 不仅使用像 Fedora for RHEL 这样的“上游”项目，而且还支持许多其他“上游”项目。正是这种支持推动了产品的发展，并促进了整个行业的采用。

红帽子

Red Hat 拥有大量的企业产品组合，从 Red Hat Enterprise Linux 一直到他们用作混合云解决方案的 OpenShift 容器平台。

自 1993 年成立以来，Red Hat 一直在开发解决方案，并且从未停止尝试发布下一款最佳企业产品。红帽在企业开源解决方案中不断引领潮流；如果说红帽没有积极开发新产品，那么他们一直在收购有新产品的公司。最近收购 StackRox 就是一个例子。

Red Hat 围绕推动其业务和客户采用的三个主要产品类别开展业务。

红帽企业版 Linux

RHEL 是 Red Hat 在将客户工作负载迁移到 Linux 的汹涌大海中开始旅程的那艘船。这使公司在竞争中保持领先，并继续使 Red Hat 成为 Linux 世界中的大牌之一。多年来，Red Hat 已经不仅仅是一个 Linux 提供商，现在拥有从基础设施产品到云解决方案的大量产品组合。红帽公司从为 RHEL 销售 CD 开始，已经走过了漫长的道路。

自动化

随着 2015 年 10 月收购 Ansible，Red Hat 通过迄今为止最好的自动化产品之一加强了他们向市场提供的产品。Red Hat 不仅开发了 Ansible 企业级平台，还采用了以前专有的 Ansible 平台(Ansible Tower)并对其进行了开源。Ansible 平台的社区版本叫做 AWX。

Ansible 越来越受欢迎，并继续成为社区中开发最活跃的自动化产品之一。几乎每天都在不断开发新的模块来改进产品。

混合云

云是我们现在都知道的东西。这不是什么新鲜事；大多数组织都在积极考虑云选项，如果他们还没有迁移或者正在为未来的路线图计划迁移的话。红帽也不例外。

这些年来，红帽已经变得非常善于寻找下一个大事件。2010 年收购 Makara 就是这种情况。Makara 之所以如此特别，是因为他们正在开发 PaaS(平台即服务)解决方案。2011 年 5 月，OpenShift 从此次收购中宣布成立，2012 年 OpenShift 开源。

OpenShift 是 Red Hat 首要的混合云解决方案；OpenShift 为容器提供了一个编排层，允许客户将工作负载从内部迁移到云，反之亦然。Red Hat 正在对 OpenShift 进行大量投资，open shift 正在不断发展，并且已经成为大多数组织在选择容器编排工具时的首选。

OpenShift 是 IBM 收购 Red Hat 时针对其开放式混合云解决方案的关键产品之一。

权威的

Canonical 于 2004 年由马克·舒托沃尔斯在英国创立。Canonical 更出名的是他们的社区 Linux 发行版 Ubuntu。非常像 Red Hat，Canonical 为他们的产品提供付费支持订阅。然而 Ubuntu 不像红帽企业版 Linux 和 Fedora。只有社区版 Ubuntu 产品。Canonical 在可能的地方提供支持和中断/修复，但实际上并不像 Red Hat 那样有自己的发行版。

Canonical 像 Red Hat 一样有一个不仅仅包含 Linux 支持的产品组合。Canonical 提供以下类别的产品。

Linux 支持

Canonical 业务的第一个也是最明显的部分是围绕着他们对 Ubuntu 的支持。如前所述，Ubuntu 只由社区开发，由 Canonical 付费支持。

云

Canonical 提供了对 Kubernetes 的支持，这是一个类似于 OpenShift 的容器编排产品。对于他们的私有云解决方案，Canonical 支持并帮助安装 OpenStack。这两款产品都为 Canonical 提供了云功能。

物联网

Canonical 与 Red Hat 和 SUSE 的一个不同之处在于它们对物联网设备和嵌入式 Ubuntu 的支持。越来越多的公司正在为他们的“智能”设备和设备寻找 Linux 发行版。Canonical 在这个市场上有优势，因为它是唯一提供这种级别支持的企业 Linux 公司之一。

注意

SUSE 是第三家企业 Linux 公司，但绝不是最后一家，它目前的产品组合比 Canonical 稍微多一点，但还不及其最接近的竞争对手 Red Hat。SUSE 和 Red Hat 一样，有自己的 enterprise Linux 发行版。SUSE Enterprise Linux 的社区版本称为 openSUSE。SUSE 的企业版支持从 SUSE Linux Enterprise Desktop 到 SUSE Enterprise Linux for IBM Power 的订阅。

如前所述，SUSE 拥有比 Canonical 稍宽的投资组合。目前，SUSE 有两个产品类别推动他们的业务，这可能是对他们产品的不公平的过度简化。

服务器和台式机

第一个产品类别是 SUSE 建立业务的基础:他们的企业 Linux 发行版。SUSE 有许多 Linux 版本，从桌面到 IBM Power 版本。所有这些都有不同的订阅可以购买，而且大多数(如果不是全部的话)都是由“上游”openSUSE 产品驱动的。

在服务器操作系统市场上，SUSE 仍然是 Red Hat Enterprise Linux 的有力竞争对手。苏斯和 RHEL 的数据中心并不少见。

云、存储和管理

除了他们的 enterprise Linux 产品，SUSE 还有一些他们出售订阅的其他产品。SUSE 有自己的基于 Ceph 的企业存储解决方案；这与 Red Hat 为其企业存储解决方案所做的是一样的。Ceph 也用于 OpenStack 和 OpenShift，这意味着客户可以有效地拥有一个 SUSE Ceph 集群，并将其与 Red Hat 解决方案相结合。

对于云平台，特别是围绕混合云和容器编排，最近收购的 Rancher(2020 年 12 月收购)为 Red Hat 的 OpenShift 提供了竞争。

SUSE、Red Hat 和 Canonical 都为私有云功能提供了 OpenStack。所有公司都支持该平台，并提供部署和配置 OpenStack 的专业服务。

为了管理 SUSE Enterprise Linux，SUSE 支持一个名为 SUSE Manager 的产品。SUSE Manager 基于 Spacewalk 和 SaltStack，非常类似于第一个基于 Spacewalk 和 Puppet 的 Red Hat 卫星产品。

社区与企业

使用社区产品与受支持产品的理由是什么？当您可以免费获得相同或相似的解决方案时，为什么要使用付费解决方案呢？

如果你理解了企业和社区之间的区别，前面的问题已经有了答案。对我个人来说，使用例子总是能把事情弄清楚，所以让我们以一家银行为例，特别是一家处理信用卡/借记卡交易的银行。这些类型的银行很有可能受到 PCI DSS 类型合规性和监管要求的管理，通常需要围绕安全和平台漏洞进行严格的控制，尤其是在存储卡数据的系统上。一个非常重要的 PCI DSS 合规性要求是，客户平台使用的软件已经过全面测试并通过了严格的安全审查，最好是由声誉良好的公司进行，这些公司已经过各种合规性审计员的批准，并且其安全性已经得到认可。由于这个非常重要的原因，你会发现银行总是使用企业产品而不是社区产品。

银行是 enterprise Linux 的一个很好的用例，但是对于不需要法规遵从性的人呢？另一个例子是慈善机构。大多数慈善机构不处理信用卡/借记卡数据。慈善机构的 IT 足迹也往往很小，因为它们大多在云平台上工作，或者内部拥有有限的物理硬件。所有这些都使慈善成为社区产品的理想前景。慈善机构需要知道如何找到答案和解决足够简单的问题的员工。比如说，可能有人在读这本书。由于社区产品没有支持电话号码或支持台来提出案例，这些慈善机构需要他们的员工来做艰苦的工作。请记住，这仅适用于不可预见的问题，并且相对罕见。经过测试和验证的适当测试、预开发和生产平台应能降低风险并确保足够的稳定性。

社区产品的另一个用例是像我们这样的技术人员。并非所有人都足够幸运，能够获得无限订阅的公司账户，并需要为自己的个人项目提供替代方案。构建我们的家庭实验室或个人网络服务器可能是社区产品的理想选择。我们非常乐意解决问题，如果情况变得更糟，我们可以从备份中重建和恢复。好了，别笑了。我们中的一些人实际上备份了我们的家庭实验室(我没有)。

在选择社区产品而不是企业产品时，要记住的最重要的一点是，要知道你必须解决不可避免的漏洞。像红帽、Canonical、SUSE 这样的公司对安全漏洞早有准备。他们有专门的人员发现零日漏洞，并在漏洞公开之前修复它们。社区往往是被动的，在发布安全补丁时总是落后于形势。像银行这样的大型组织不愿意拥有的东西。你和我，如果我们担心安全问题，我们可以关掉实验室。银行没有这种特权。

知识检查

为了更好地使用这本书，你应该了解 Linux 系统管理的基础知识。这将包括以下内容

  • 基本 Linux 系统命令

  • 基本 Linux 系统配置，包括如何管理存储设备以及如何添加新用户

  • 基本的 Linux 安全概念

如果你不熟悉这些东西，在继续阅读这本书之前，最好做一些进一步的阅读。

然而，这本书的写作方式很有希望让你从它的内容中受益，但是如果你有一个坚实的 Linux 基础，它会更好地为你服务。

摘要

本章介绍了以下主题:

  • Unix 和 Linux 的简史

  • Linux 如何无处不在，在你的智能手机、电视和飞行娱乐系统中

  • 什么是社区 Linux 发行版，谁开发了它们

  • 如何决定哪个发行版最适合你

  • 有哪些企业 Linux 选项可用，哪些公司提供这些选项

  • 社区 Linux 和企业 Linux 的主要区别

二、改善管理体验的新工具

现在基础知识已经在第一章中介绍过了，我们可以开始寻找新的方法来改进你目前正在做的事情。这一章将重点介绍作为 Linux 系统管理员应该如何工作，应该考虑使用什么工具，以及这些工具如何提高效率。

本章将首先介绍任务管理，如何创建后台任务，以及如何在您需要离开一天时让任务保持运行。然后，我们将开始学习 Ansible 的基础知识。对于 Ansible，我们将只讨论最基本的内容来帮助您入门。在本书的后面，我们将深入探讨自动化。对于本章来说，如果您以前从未使用过 Ansible，那么让您快速了解它是非常重要的。然后，为了结束这一章，我们将看看哪些控制台可以用来简化 Linux 配置。

到本章结束时，你不仅会知道如何更好地管理任务，还会有一些开始自动化的基础知识。您还将看到除了传统的命令行选项之外的其他配置 Linux 的方法。

任务管理

Linux 操作系统本质上是一系列文件和进程，它们协同工作来帮助用户完成计算请求。这些过程需要偶尔进行管理。作为 Linux 用户，建议理解如何启动、停止进程，以及在需要时如何终止进程，有时是强制终止进程。

开始一个过程

可以通过多种方式启动一个进程；最常用的方法是启动一个服务。例如，启动 apache web 服务通常需要启动 httpd 服务。根据您的配置，该服务会产生一些 httpd 进程。然而，服务实际上只不过是一个脚本或一组命令，调用二进制文件，后跟参数。当查看您的流程时，参数通常会列在它的后面。

如上所述，启动 apache web 服务器需要一个服务命令。对于大多数 Linux 发行版，这将是一个 systemctl 命令:

# systemctl start httpd

要检查服务是否已经启动，可以用 status 参数替换 start 参数，或者可以检查正在运行哪些与名称 httpd:

# ps -ef | grep httpd

输出应该类似于

root      150274       1  0 22:48 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    150275  150274  0 22:48 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    150277  150274  0 22:48 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    150278  150274  0 22:48 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    150279  150274  0 22:48 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
root      150506  108621  0 22:48 pts/2    00:00:00 grep --color=auto httpd

任务可视化工具

查看正在运行的进程对于了解您的系统正在做什么，或者是什么导致您的系统出问题非常重要。查看过程可以通过几种方式完成。您可以使用默认安装的实用程序，也可以使用 ps 命令并搜索您的进程。在 Fedora 上，我在安装下面提到的包时没有遇到任何问题。

顶端

我用过的几乎所有 Linux 发行版都默认安装了 Top。执行命令“top”应该会产生类似于以下内容的输出:

# top
top - 21:51:30 up 35 days, 22:34,  1 user,  load average: 4.80, 5.38, 3.13
Tasks: 423 total,   1 running, 421 sleeping,   0 stopped,   1 zombie
%Cpu(s):  8.8 us,  6.9 sy,  0.0 ni, 81.9 id,  0.0 wa,  1.8 hi,  0.6 si,  0.0 st
MiB Mem :  23679.7 total,   1453.4 free,  11263.9 used,  10962.5 buff/cache
MiB Swap:   8192.0 total,   8190.8 free,      1.2 used.  10835.9 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   3219 ken       20   0   17.3g 237396 144936 S  16.9   1.0 106:56.90 chrome
   1033 root     -51   0       0      0      0 D  10.6   0.0  21:58.24 irq/136-rmi4_sm
 129564 ken       20   0   20.6g 323744 123548 S   9.9   1.3  14:31.80 chrome
  29109 ken       20   0 4450712 196656 105148 S   9.3   0.8  34:17.92 cinnamon
   2021 ken       20   0 1051020 103268  62488 S   8.6   0.4  37:08.53 Xorg
 108567 ken       20   0  754204  42076  30860 S   3.3   0.2   0:08.86 gnome-terminal-
   3171 ken       20   0   16.9g 489020 192036 S   1.7   2.0  66:08.40 chrome
   3220 ken       20   0   16.5g 131584  92976 S   1.0   0.5  28:09.36 chrome
 151128 root      20   0  236260   5568   4376 R   1.0   0.0   0:00.15 top
 150042 root      20   0       0      0      0 I   0.7   0.0   0:08.40 kworker/1:2-events
     14 root      20   0       0      0      0 I   0.3   0.0   1:09.19 rcu_sched
   1140 dbus      20   0   13396   9064   2644 S   0.3   0.0   0:20.92 dbus-broker
   3177 ken       20   0    7768   4120   3304 S   0.3   0.0   2:19.38 cgroupify
   3532 ken       20   0   20.7g 404148 123592 S   0.3   1.7  12:04.38 chrome
  49421 systemd+  20   0   17712   8712   7832 S   0.3   0.0   1:25.22 systemd-oomd
  83705 ken       20   0   20.6g 119640  79348 S   0.3   0.5   0:11.45 chrome
  97202 ken       20   0   20.6g 147012  97388 S   0.3   0.6   0:13.16 chrome

顶级产品的替代品

如果你想尝试不同的东西，除了“top”还有几个选择(表 2-1 )。就个人而言，我已经尝试并使用了一些，但总是默认为 top，主要是因为我工作的系统不是我自己的。如果你以前没有尝试过表格 2-1 中的替代方案，我建议你安装并亲自看看它们是否能给你的工作方式带来任何好处。

表 2-1

顶级产品的替代品

|

首选方案

|

描述

|
| --- | --- |
| atop | 交互式工具，显示系统的负载和其他有用信息 |
| htop | 非常类似于顶部，除了您可以使用鼠标垂直或水平滚动 |
| glances | 一种监控工具，用于在一个屏幕上显示尽可能多的信息。如果您想查看有关传感器的信息，这很有用 |
| bpytop | 非常好的自定义工具，有一个基于文本的界面。该实用程序将要求您下载源代码并编译 |

工具

nmon 是帮助诊断系统问题的另一个非常有用的工具。默认情况下，它通常不会安装，但可以安装在大多数平台上。nmon 有一个非常清晰的方法来显示 CPU、内存、磁盘和内核等等。这绝对是我推荐使用的工具。

杀戮过程

偶尔，可能需要杀死一个进程；这可能是从挂起的线程到内存泄漏的进程的任何情况。在您终止这个进程之前，请始终自问终止这个进程是否是终止您的进程的最佳方式。我确实明白，有时候没有别的选择，任务必须杀。但是，千万不要强行终止一个进程。总是从尝试使用 systemctl 或类似的服务命令开始。一些应用程序或实用程序有自己的定制工具，也可以使用。阅读官方文档或手册页，看看是否有推荐的方法。

我在过去经历过，一些系统管理员并不总是理解终止一个进程的含义。我曾经和一位系统管理员一起工作，他认为强行终止 PostgreSQL 数据库进程是一个好主意，这是他停止数据库服务的主要方法。这不仅吓了我一跳，还让我看到系统管理员真的不知道如果他坚持这种行为，会给自己带来什么后果。作为当时和他一起工作的顾问，我向他解释了为什么这是一个可怕的想法，然后带他走了正确的程序。

如果您不得不终止一个进程，请务必遵循以下步骤:

  1. 使用“top”或“ps”等进程查看工具获取进程 ID

  2. 尝试使用不带参数的 kill 命令礼貌地终止进程。这将默认使用“TERM”信号，这有效地告诉进程它将被终止，如果它有任何处理程序，它们将在终止之前尝试运行清理任务。

  3. 如果“好”的方法不起作用，你可以应用大锤方法。这将强制终止该进程，并且无法捕获终止事件，这意味着该进程将无法运行任何清理作业。

kill <process id>


kill -9 <process id>

kill 命令还有许多其他信号选项，每种选项用于不同的情况。“kill -l”命令将给出可使用的所有信号的列表。

僵尸进程

我们先来了解一下什么是僵尸进程。僵尸进程是指一个进程已经被杀死，并且它的内存描述符 EXIT_ZOMBIE 还没有被它的父进程清除。这通常是在父进程执行 wait()系统调用来读取死进程的退出状态和任何其他信息时完成的。wait()完成后，EXIT_ZOMBIE 内存描述符被清除。如果没有做到这一点，通常是因为父进程行为不当或编码不当。

我曾经听到过一个非常简单的杀死僵尸进程的解释。

“你不能杀死已经死去的东西。”

如果你考虑一下僵尸进程实际上是什么，这就很有意义了。它只不过是一个没有被清除的内存描述符。再多的 kill 命令也无法清除它。你需要找到内存中的内存描述符并自己清除它，我们都知道，没有人会费心去做。不幸的是，清除僵尸进程需要重启。

要找到僵尸进程的根本原因，需要查看进程死亡的应用程序。代码写得很差吗？父进程先死了吗？根据我的经验，这通常是由于另一个进程或应用程序破坏了进程，导致系统不稳定。

像“top”这样的实用程序有一个专门的区域来显示僵尸进程。如果您看到僵尸进程出现，那么您的系统有一个更大的问题需要解决。第十一章，我们将讨论如何诊断问题并找到解决方案。

后台任务

服务在启动时会创建后台运行任务，这主要是因为没有系统管理员希望活动会话一直运行，而且这样做实在是太傻了。

后台任务可以通过查看 top 之类的工具或者运行 ps 命令来查看，但是要发送一个任务到后台需要做什么呢？当您启动一个长时间运行的流程并需要执行其他任务时，会发生什么情况？您可以打开一个新窗口或控制台，并在那里运行任务。但是，更好的方法是将当前任务发送到后台。以下是将当前正在运行的任务发送到后台的基本步骤:

  1. 按下“CTRL + Z”键。

    • 这告诉 Linux 操作系统暂停当前任务，并将用户返回到 shell。

  2. 一旦回到 Shell，执行命令“bg”。

    • 该命令将当前暂停的任务发送到后台并继续运行。

如果您想将后台任务带回到前台，只需执行“fg”命令。

运行耗时的任务

作为系统管理员，您经常需要运行需要很长时间才能执行的脚本或任务。有时候，如果你在笔记本电脑上运行这些长时间的任务，并且你想离开一天，那么运行这些任务会非常令人沮丧。幸运的是，如果使用正确的工具，您不必等到任务完成。

有几个工具可以帮助你完成耗时的任务，让你重新享受工作之外的生活。

屏幕

许多人使用的一个非常流行的多任务工具是“screen”大多数 Linux 系统管理员都使用过或者至少知道"screen"，并且很可能已经知道了基本知识，但是对于那些不熟悉 Linux 的人来说，" screen "是一个允许用户创建作为后台进程运行的会话的工具。用户可以根据自己的意愿断开并重新连接到会话，这意味着当用户断开连接并回家时，长时间运行的脚本或进程可以在屏幕会话中保持运行。在过去，任务或流程会被绑定到用户的会话，一旦用户断开连接，任务就会被终止。

Screen 可以在大多数发行版中找到，并且可以通过尝试安装一个名为“screen”的包来非常简单地进行安装。

要以非常基本的方式使用屏幕，您需要知道的只是表 2-2 中列出的命令。

表 2-2

如何使用“屏幕”

|

命令

|

描述

|
| --- | --- |
| screen | 开始新的屏幕会话 |
| ctrl + a followed by d | 断开您与正在运行的屏幕会话的连接，但保持会话运行 |
| screen -list | 列出所有屏幕会话 |
| screen -r <session name> | 重新连接到正在运行的屏幕会话 |

Note

应该注意的是，一些发行版已经在他们的一些新版本中停止发布“screen ”,但是该包仍然可以在社区库中获得。

Tmux 的

随着“screen”的可用性降低，正在使用的新工具是“tmux”“??”和“屏幕”一样，允许用户断开连接并重新连接到会话，只是“tmux”有非常丰富的功能。我个人现在在我所有的 Linux 平台上都使用“tmux”。这些命令已经变成了肌肉记忆，当我在一个没有tmux的系统上工作时，我经常感到失落这听起来很奇怪，但是作为一名 Linux 系统管理员，我们经常被要求解决问题，这涉及到多任务处理的能力。我们可能需要一个窗口运行观察命令，另一个窗口跟踪日志。当你有大量的应用程序在运行时，在这些窗口之间切换会很混乱。所以为了避免这种情况，使用“tmux”允许我在 tmux 中创建一个分屏和新窗口。我能够在会话之间切换，最棒的是，我不必离开舒适的命令行。

与“screen”非常相似，“在开始使用“tmux”时，您需要知道一些基本命令。”在那里，您可以通过阅读手册页或帮助来扩展您的理解。

表 2-3 列出了您在日常活动中会用到的一些常用命令。

表 2-3

如何使用“tmux”

|

命令

|

描述

|
| --- | --- |
| tmux | 启动新的 tmux 会话 |
| ctrl + b + d | 从正在运行的会话中断开连接 |
| tmux list-sessions | 列出所有 tmux 会话 |
| ctrl + b + % | 垂直拆分屏幕 |
| ctrl + b + " | 水平分割屏幕 |
| ctrl + b + w | 在 tmux 中显示一个窗口，其中包含所有 tmux 会话供您切换到 |
| ctrl + b + arrow keys | 允许您调整窗口大小 |

可译简介

在过去的十年中，Linux 系统管理员的角色已经演变成自动化工程师的角色。越来越多的系统管理员正在编写自动化代码。传统的 Linux 系统管理角色正慢慢变得不如以前重要。你可能正在读这本书，因为要么你正在努力学习你应该做些什么来在快速发展的 Linux 世界中保持相关性，要么你是 Linux 新手并且想要学习如何开始。

这两个问题的答案都是自动化，尤其是 Ansible。如今，系统修补或系统配置等标准任务都是自动化的，需要的手动干预更少。Linux 系统管理员不仅仍然需要了解如何配置 Linux，而且现在还需要知道如何自动化这些配置。Ansible 是当今最受欢迎的自动化工具之一，如果你开始熟悉它，它将对你的职业发展大有裨益。在本书的后面有一个专门的章节是关于自动化的，在那里我们将会更深入地研究自动化的实践。在这一节中，我们只是简单地看一下 Ansible 的基础知识。

安装 Ansible

幸运的是，与其他一些自动化工具相比，安装 Ansible 并不太复杂。这确实很有意义，因为使用 Ansible 的驱动因素之一是使用它更容易的学习曲线。

Ansible 有两种安装方式。

包装管理

安装 Ansible 的第一个也是最简单的方法是通过你的发行版包管理系统，比如 dnf 或 apt。

简单地尝试安装 Ansible 包就可以在大多数社区发行版上运行，因为它们的标准库中通常都有 Ansible。然而，像 Red Hat Enterprise Linux 这样的企业发行版需要单独的订阅和对不同存储库的访问。对于这些发行版，请确保遵循它们的官方文档，了解如何启用所需的库。

Note

通过包管理系统安装 Ansible 是推荐的方法，因为这不仅安装了 Ansible 二进制文件，还为您的 Linux 系统准备了所有其他支持 Ansible 的配置文件，允许您在最佳配置下工作。

点

安装 Ansible 的另一种方法是通过 Python 首选安装程序，或通常称为 pip。除了安装 pip 本身之外，不需要订阅或不同的存储库。一旦安装了 pip，就可以通过 pip 安装命令安装 Ansible。

Note

当通过 pip 安装时，一定要检查 pip 将要安装到的 Python 版本。

配置 Ansible

Ansible 的核心是您编写的执行任务的 YAML。为此，您几乎不需要配置什么。如果你是通过一个包管理系统安装 Ansible 的，比如 dnf 或者 apt，你会得到为你创建的配置文件。如果您通过 pip 安装或下载二进制文件，您将需要自己创建配置文件。

Ansible 配置文件称为 ansible.cfg，可用于在其限制范围内自定义 ansible。例如，如果您希望配置非标准环境，可以配置存储插件或清单文件的位置。

然而，配置文件确实需要存储在特定的位置，以便 Ansible 能够在没有被告知的情况下读取它们。Ansible 还将遵循一个层次结构，在这个层次结构中，Ansible 将首先读取文件。

您可以在以下位置创建 Ansible 配置文件。Ansible 也是按照这个顺序读取配置文件的。如果它没有找到第一个，它将继续下一个。如果 Ansible 没有找到配置文件，它将采用默认值。

  • ansible.cfg 文件放在您正在工作的当前目录中。

  • 用户主目录中的. ansible.cfg。

  • 创建/etc/ansible/ansible.cfg。

还可以通过设置 ANSIBLE_CONFIG 环境变量来告诉 Ansible 在哪里可以找到配置文件。

Note

在用户的主目录中创建 Ansible 配置文件时，务必将该文件命名为“. ansible.cfg”而不是“ansible.cfg”。如果文件不以“.”开头，它将被忽略。

易变库存

在使用 Ansible 之前，您需要知道如何定位 Ansible 将在其上执行命令或任务的系统。在 Ansible 中，我们在库存文件的帮助下完成这项工作。如果 Ansible 是从软件包管理系统安装的，则创建的缺省清单文件是/etc/ansible/hosts。这个文件可以按原样使用，或者您可以编辑 ansible.cfg 来告诉 ansible 库存文件的位置。指定 Ansible 在哪里可以找到库存文件的另一种常见方法是在执行带有“-i”参数的“ansible”或“ansible-playbook”命令时完成的，后跟库存文件的路径。

可回应清单文件的基本布局由方括号中的组名组成，后跟属于该组的系统列表。在以下示例中，两台服务器属于“webserver”组，一台属于“database”组:

[webserver]
servera
serverb

[database]
serverc

运行 Ansible

Ansible 命令行工具由几个二进制文件组成。两个常用的是“ansible”和“ansible-playbook”“ansible”命令可用于直接对主机执行单个特别命令，而“ansible-playbook”命令可用于执行包含许多 ansible 任务的剧本。用于 ping 清单文件中所有主机的专用 Ansible 命令示例如下:

ansible all -m ping

要运行行动手册，您可以使用类似下面的内容:

ansible-playbook -i /path/to/inventory /path/to/playbook.yaml

Ansible 运行起来相对简单，使用它不需要任何配置。要熟悉 Ansible，首先运行一些特定的 Ansible 命令，然后继续创建您自己的剧本。

剧本

一旦您完成了运行 Ansible 即席命令，您将希望继续创建行动手册。简单地说，剧本是一种一个接一个地运行多个可完成的任务的方式。Ansible 剧本需要从指定任务将在其上执行的主机或组开始。还可以添加一个变量文件或变量列表，但是对于一个非常简单的剧本来说，这并不是必须的。以下是行动手册的基本示例:

---
- name: "Install webserver"
  host: webserver
  tasks:
    - name: "Install httpd"
      yum:
        name: "httpd"
        state: present

角色

行动手册可能会变得非常复杂，并且经常会有您想要重用代码的时候。这就是可变角色变得有用的地方。Ansible 角色是使用 Ansible 完成特定工作的一种方式。这可能像安装一个包一样简单，也可能像部署整个云平台一样复杂。通常，一个写得很好的 Ansible 角色应该开箱即用，执行起来没有问题。应该配置一个默认变量，这样，如果用户不做任何设置，角色仍然会运行。一个好的可回答角色还应该包括一个 README.md 文件，其中包含如何使用该角色的说明。该角色还应该包括 Ansible Galaxy 可以使用的元数据。

角色目录结构

角色目录结构应该类似于以下内容，但也可以简化为至少只有任务目录。完整的结构包括并不总是需要的附加目录，如 vars 目录或 templates 目录:

[Role name]
 ->  [tasks]
   --> main.yaml
 ->  [defaults]
   --> main.yaml
 ->  [handlers]
   --> main.yaml
 ->  [meta]
   --> main.yaml
 ->  [vars]
   --> main.yaml

Note

Ansible 角色名通常应该以“ansible-role-”开头，然后是您希望对角色的称呼。

生成可变角色

作为 Ansible 的一部分安装的另一个二进制文件是“ansible-galaxy”二进制文件。这个二进制文件可以用来管理角色和集合。这包括生成一个可回答的角色框架的能力。要创建一个基本的角色结构来开始您的角色开发之旅，请运行以下命令:

# ansible-galaxy init <your role name>

模块

Ansible 模块是 Ansible 的另一个重要方面，但没有多少人理解。如果一个可转换的角色可以被看作是一个工具箱，那么可转换的模块可以被看作是螺母和螺栓。

在几页前的“行动手册”部分，有一个行动手册示例。在示例中，我使用了“yum”模块来安装“httpd”包。这个“yum”模块是标准 Ansible 集合的一部分，不需要任何额外的安装。本例中的“yum”模块告诉正在执行该剧的系统(“webservers”)使用“yum”二进制文件来安装“httpd”包。

有些模块比“yum”模块复杂得多，使用起来也更复杂。幸运的是，Ansible 文档相当不错，它很好地解释了一个模块通常具有的所有参数和选项。要查看文档，您可以进行快速的互联网搜索或使用 Ansible 的命令行帮助。例如，查看 yum 模块的帮助:

# ansible-doc yum

Ansible 模块通常是用 Python 编写的。从技术上讲，它们可以用任何开发语言来开发，只要所用的语言能够输出 JSON。模块应该执行单个任务，并且必须返回任务的结果。将模块写成幂等的也是非常重要的。

分享你的答案

共享 Ansible 的知识和代码使得 Ansible 可能成为当今最好的自动化工具。社区在开发 Ansible 模块方面的努力令人惊讶，来自各个角落的供应商贡献代码来促进 Ansible 的采用。不仅仅是供应商，像我们这样的系统用户也在为你能想到的几乎任何东西创建可转换的模块。

Note

一旦你对 Ansible 更熟悉了，考虑把你的代码还给 Ansible Galaxy 之类的地方。

不稳定星系

Ansible Galaxy 是与世界分享你的答案的绝佳方式。这不仅能让你的名字被其他人认出来，还能增加每个人都可以使用的不断增长的 Ansible 库。

当需要编写一个新的 Ansible 角色或模块时，总是从搜索 Ansible Galaxy 开始，寻找任何你可以使用的东西，或者至少从它开始。

Web 控制台

Linux 系统管理传统上包括通过 ssh 登录系统，并运行各种命令行命令来根据需要配置平台。这在今天仍然可以实现，但是随着 Linux 的发展。系统配置总是会发展到包括更易于使用的方法，以适应新用户学习 Linux。

战场

任何构建和配置过 Linux 服务器的人都会非常清楚，桌面往往不会在服务器平台上被大量使用。大多数时候，所需要的只是 ssh 和服务器执行其功能所需的任何软件。由于这个原因，需要有一个桌面的替代品来实现更快更简单的图形用户界面配置。

这就是驾驶舱变得有用的地方。Cockpit 允许 web 控制台访问 Linux 服务器。在 web 控制台中，用户能够配置存储、网络和各种其他配置。用户还可以打开系统的终端会话并运行命令行命令。

Cockpit 通常只在服务器平台上使用，但是可以安装在任何支持使用 cockpit 的平台上。

装置

与 Linux 上的大多数软件安装非常相似，建议使用您的软件包管理系统安装“cockpit”。在 Red Hat Enterprise Linux 上，这将是 yum 或 dnf，而在 Ubuntu 上，您将使用 apt。以下是 RHEL 或 Fedora 的安装:

# yum install cockpit -y

配置

安装后，确保“驾驶舱”服务已启用并启动:

# systemctl enable cockpit && systemctl start cockpit

检查“驾驶舱”正在运行:

# systemctl status cockpit
# netstat -nap | grep LIST

最后，如果您的防火墙正在运行，请确保端口 9090 已经为 tcp 流量开放:

# firewall-cmd --list-all

使用驾驶舱

安装和配置完成后，您应该能够打开 web 浏览器，并使用端口 9090 输入您的 Linux 系统的主机名或 IP 地址:

https:// :9090

web 控制台现在应该会打开并要求提供凭据。用户名和密码可以是任何本地用户，如果您知道 root 密码，也可以使用它。

在“驾驶舱”，您可以配置您的网络接口，通过 NFS 或 iSCSI 添加存储，并查看日志。有几个不错的功能，比如从 web 控制台加入域，并查看系统上安装了什么应用程序。大多数配置都是不言自明的，足够简单易懂。

限制

cockpit 的一个主要限制是，它是正在运行的 Linux 服务器的 web 控制台，这简单地意味着服务器必须正在运行，并且“Cockpit”服务需要工作。您不能使用“驾驶舱”来解决引导问题，也不能使用“驾驶舱”来安装任何虚拟机。

驾驶舱的替代方案

在开源世界中有一个项目的地方，肯定会有更多类似的项目。这与 Linux web 控制台管理完全相同。虽然驾驶舱是常用的选项，并提供了相当不错的功能，但值得一提的是一些可以使用的替代方案。

Note

由于 Linux 是开源的，我的建议和选择将是非专有软件和一般的开源产品。即使有很好的专有选择，它们也会让你去寻找和阅读。

Webmin(网站管理员)

与 Cockpit 非常相似，您可以配置各种配置选项，如添加新用户或启动和停止服务。Webmin 的缺点是产品更新发布周期较慢。Cockpit 的目标是每两周发布一次版本，Webmin 可以长时间不更新。然而，这也可以被视为一件好事。最好的建议是自己比较这些产品，看看什么最适合你。

艾恩特

另一个替代驾驶舱的非常好的网络控制台是 Ajenti。与 Webmin 和 Cockpit 非常相似，Ajenti 提供了一个简洁易用的 web 控制台，允许用户配置它所安装的 Linux 平台。所有这些 web 控制台都存在相同的限制，并且只为安装它的系统提供配置。

文本控制台

如果 web 控制台不适合你，那么文本 UI 工具可能更适合你。当用户不熟悉所有命令行参数时，文本控制台或“tui”工具为用户提供了快速配置选项。一个很好的例子是过去在 RHEL 上配置身份验证。在 RHEL 配置的早期，您需要挖掘帮助，并计算出使您的命令成功所需的各种参数。现在，运行文本用户界面进行身份验证可以让您选择或取消选择所有选项。除了连接细节之外，您不需要记住任何参数。配置更快更简单，出错空间更小。在压力下我会给你一些建议。

安装

对于所有的 tui 控制台，不只是安装一个软件包。如果没有安装标准的“tui”包，每个应用程序都需要提供自己的“tui”。

使用 Linux 系统的软件包管理系统，尝试通过在软件包名称的末尾添加“-tui”来安装“tui”。例如，尝试使用网络管理器文本用户界面。如果软件包未安装，请尝试安装以下软件:

# yum install nm-tui -y

使用

文本控制台使用起来非常简单，并且通常不言自明。了解它们的最好方法是开始使用它们。我个人一直在使用 network manager“tui”来配置网络配置，主要是因为它更快，我需要记住的东西更少。

摘要

在本章中，向您介绍了以下内容:

  • 如何在 Linux 系统上管理任务，以及如何处理后台任务。

  • Ansible 基础知识，以及如何在几个小时内熟练掌握 Ansible。

  • web 控制台带来的管理 Linux 平台的能力。

  • 不是所有的事情都要用一个长命令和一百万个参数来完成。文本控制台可以节省时间和精力。

三、财产管理

上一章讨论了新的工具或工作方式，这一章也将继续讨论。然而，它将着眼于你的财产的更大图景:你应该做什么，你应该避免什么。

在这一章中，我们不仅会看到过去人们是如何管理 Linux 财产 的，以及如何对其进行改进，我们还会深入研究系统构建、系统补丁以及您应该使用或应该考虑使用的工具。说到这里，我们将简单讨论一下现在可以使用的管理软件。这一章的主要思想是向你介绍如何改变你的工作方式，使你在管理这些大型财产时生活更轻松。

我们不仅将讨论 Linux 资产管理的技术方面，还将研究如何进行适当的规划，以及如何避免那些需要工程师加班加点的可怕的午夜修补周期。本章将探讨简化传统 Linux 系统管理所需的大量手工工作的想法。我们将讨论如何在您的组织内开始文化变革，以及如何开始推动对话以促进创新并减少救火时间。

在本章的末尾，我们将讨论 Linux 系统管理员有时会做的一些常见的坏习惯。然后，我们将以一些推荐的好的实践来结束这一章，Linux 系统管理员应该开始这样做，如果还没有这样做的话。

过时的工作方式

在我过去十年作为 Linux 顾问的经历中，我遇到了许多了不起的人。有些教会我新的有趣的东西，有些教会我新的做事方法。在天平的另一端，我遇到过一些人，他们因缺乏进步或前瞻性思维而令我沮丧。这并不是说他们没有任何好处；事实上，大多数人都是非常聪明的人，他们只是被困在他们工作的组织没有给他们提供成长、学习或尝试新事物的机会的情况下。我的挫折感不仅仅止于个人，还延伸到违规的组织。由于没有促进增长和新的创新工作方式，与我一起工作的 Linux 系统管理员变得停滞不前和厌倦，经常以他们离开组织而告终。

因此，考虑到这一点，这里有几个例子来说明我所说的“过时的工作方式”是什么意思

过时的技能

我经常遇到不经常更新技能的 Linux 系统管理员。有些人只能怪自己，有些人不幸得不到他们工作的组织的支持。这方面的例子包括不熟悉他们管理的产品的新版本中的新变化和已知问题，这通常是由于缺乏培训。其他的例子包括没有跟上市场的变化和用于平台管理的新趋势。其他问题包括组织不希望 Linux 系统管理员在其环境中引入新技术。这通常意味着 Linux 系统管理员需要在家庭实验室或沙盒环境中进行实验，有些人可能无法进入这些环境。不管出于什么原因，Linux 系统管理员的技能变得过时了，让他们在拒绝支持他们的组织中束手无策。

保守秘密

这是最坏的最坏的。我遇到过一些人，他们在工作中与别人保持一定距离。其意图似乎是不要向任何人展示他们在做什么，这样他们就可以多一点时间保住他们的工作。这些人倾向于不愿意让任何人与他们合作任何项目，并且倾向于过度工程化他们所做的一切。在当今的工作环境中，我不建议这样做。分享的越多，学到的越多；通常，关于过时技能的前一点和这一点是密切相关的。如果你为此感到内疚，我的建议是开始尽可能多地学习新兴技术，并开始与他人合作。这不仅会改善你正在做的事情，还会为你开辟新的道路，甚至有可能去一个不同的组织，有可能获得更高的薪水。

过度工程化

这让我想到了我认为我们都曾犯过的错误:让一个简单的需求变得过于复杂。如果我每次看到简单任务中完全过度设计的东西都能得到一分钱，我会成为一个富人。后退一步，问问你自己，我真的需要把所有这些复杂性加入到这个剧本或者这个作品中吗？如果答案是否定的，那么削减多余的，保持任务简单。如果你过去有过工程过度的罪恶感，就用“KISS”这个缩写。“保持简单愚蠢。”

Shell 脚本

我们都编写过 shell 脚本，是的，有时候这是不可避免的，对于这种情况，你只能苦笑着忍受。然而，如果可能的话，尝试使用更新的自动化工具来管理您的系统或执行您想要做的任务。还可以利用管理软件来管理系统，而无需使用 shell 脚本。改变您的方法，使用 shell 脚本的替代方案，将开始您从一个中心位置向更大的资产管理的转变。更不用说，对旧的 shell 脚本进行更少的维护。

组织的新成员也不需要麻烦你去理解你的脚本是做什么的；你可以直接让他们阅读你正在使用的管理工具的官方文档。

如今，除了快速包装器脚本或快速脚本来测试某些东西之外，编写 shell 脚本的理由越来越少。脚本不应该用于任何永久的东西，更不应该用于生产中的任何东西。

雪花

落到地球上的每一片雪花都是独一无二的；至少这是我被告知和读到的。这有时就是 Linux 资产如何发展的。Linux 系统管理员构建了这样的系统，其中每个系统都变成了自己独特的雪花。资产中的每个 Linux 系统都因其独特的配置而变得如此不同，更不用说过于复杂，以至于组织中没有人知道该系统做什么或如何重建它。这些系统比什么都让我害怕。当需要重建平台时，他们需要花费大量精力来确定需要什么，如果需要将平台故障转移到灾难恢复站点，他们就会成为负担。

Tip

改善遗产管理和减少救火的第一步是尽可能多地清除雪花。

重新发明轮子

最后，编写一个脚本或一个软件来做一些已经存在于操作系统中的事情是一种不可原谅的行为。除非有非常好的理由，否则应该避免这样做。即使在编写 Ansible 时，也要注意是否有不存在的东西。它可以节省时间和公司的资金。就是不做。

构建流程

Linux 构建过程通常是您在构建或管理中型到大型资产时需要考虑或花费相当多时间去做的事情。对于家庭爱好者或个人用户来说，你不会太在意这个过程，而倾向于手工构建你的系统。在较大的财产中，出于不同的原因被要求建立十个或一百个系统是很常见的。随着行业的发展，手动构建这些系统不再是一个好的选择。

构建不可替代的系统的时代已经过去了。系统现在被视为更像云实例。如果它坏了，丢弃它并重新部署。这个过程是有意义的，因为它节省时间和精力。没有必要尝试当场解决问题，甚至当场解决根本原因。只需删除系统并重新部署。大多数系统将日志发送到外部，因此故障排除和根本原因分析可以在生产启动并运行后继续进行。

20 年前，这种思维方式会让你看起来很有趣，如果管理层听说了，会让你被扫地出门。幸运的是，时代变了，今天这种思维方式受到鼓励。

要了解如何改进，我们需要了解我们做错了什么。为此，让我们讨论部署 Linux 系统的不同方法，什么使它们值得做，以及什么使它们成为应该避免的事情。

手动安装方法

要讨论的第一种方法是传统的手工部署。这对于你想测试或玩的奇怪的随机系统来说可能是好的，但是如果你有一百个系统要构建，这绝对不是你想做的事情。如果你花一周的时间去做一些本应该在 20-30 分钟内完成的事情，你肯定不会得到雇主的青睐。

有了所有可以构建系统的方法，包括可以用来构建系统的许多不同的工具或管理系统，手工构建系统不应该是其中之一。然而，在我们学习应该避免什么的时候，让我们从头开始，很好地理解这个手动过程应该如何完成，并查看已经用于安装 Linux 的手动构建方法。在本章的后面，我们将讨论如何简化这些过程。

启动媒体安装

最简单的方法是使用引导介质进行部署。这可能是 DVD 或 USB 设备。系统通常从您的安装介质启动，一旦您的系统引导到您的 Linux 安装程序，您通常会运行手动步骤。可以选择默认值作为最简单的选项，但是如果您正在构建除测试系统之外的任何东西，则不推荐使用默认值。像磁盘分区和包安装这样重要的事情可以为任何重要的系统定制。如果您正在构建一个将被用作模板的系统，那么在这个安装过程中应该非常小心。您真的不希望模板配置不正确，尤其是如果它将在以后用于部署整个资产。

网络安装

通过 NFS 服务器启动网络是手动部署 Linux 系统的另一种方法。这仍然需要引导介质，您需要将安装重定向到网络位置。这种安装方法要求运行 NFS 系统，并导出安装介质以供使用。您仍然需要手动运行安装，并且如果您正在构建一个生产系统，您仍然需要确保您不只是选择缺省值。如果你有一个 kickstart 文件，这可以简化，但需要进一步了解 kickstart 文件是如何编写的。幸运的是，我们生活在一个信息可以在互联网上自由获取的世界。有许多 kickstart 文件的例子和许多论坛问题和答案来帮助您开始。

模板

尽管有一些方法可以对物理机器进行成像，但你不会经常这么做。然而，虚拟机是另一回事。当您作为 Linux 系统管理员阅读本文时，我假设您已经理解了从模板创建虚拟机的过程，并且很可能在过去做过一些克隆。如果没有，这个过程非常简单。Linux 系统通常是在虚拟化平台上手动创建和安装的。完成构建和配置后，虚拟机将被转换为虚拟机映像或设备，具体取决于您使用的虚拟化平台。该图像可以被锁定或转换成模板，以避免不必要的编辑或配置漂移。通过该模板，可以创建安装了操作系统的新虚拟机，并为定制做好准备。

虚拟机映像

如果您不想构建自己的 Linux 映像，另一种方法是从您选择用于您的企业 Linux 资产的供应商那里下载一个映像。像 Red Hat 这样的公司已经为他们发布的每个版本的操作系统提供了预构建的映像供下载。这些图像可以导入并转换成模板；从那里，你能够建立系统。整个过程可以自动化，以进一步简化流程。

Tip

使用网络安装是开始自动化部署的好方法。如果您仍然手动部署，这肯定会改进您的构建过程。Foreman 是一个社区产品，所以如果你不能使用 Red Hat Satellite 或 SUSE Manager，它绝对是一个值得考虑的选项。

自动化 Linux 安装

既然已经介绍了手动安装，我们需要开始讨论如何简化这个过程。构建新系统时，减少浪费时间的第一步是尽可能自动化。这应该包括尽可能多的自动化，以使您的系统“生产”就绪。有两种方法可以使用。

方法 1:网络安装

自动化 Linux 构建的第一种方法是使用网络安装选项。为此，需要准备一些东西。

PXE 服务器

对于从网络构建的 Linux 系统，您需要一个监听构建请求的系统。这就是所谓的 PXE 启动服务器。该系统有效地允许“全新”系统从其网络适配器启动，并提示用户选择他们希望部署的内容，也就是说，如果您使用多个构建。还可以为系统配置默认选项，以便在没有用户干预的情况下自动构建。

通常，网络引导服务器类似于 Red Hat 卫星服务器或 Foreman 服务器。如果您选择使用自己的 DHCP 服务器，一旦分配了网络地址，这些系统就需要 DHCP 系统将“下一个服务器”选项重定向到这些系统。个人建议使用 Satellite 或 Foreman 自带的 DHCP 服务器。这使得管理工作变得更加容易，并且避免了必须配置中央 DHCP 系统。如果流量需要跨越防火墙，它还可以降低防火墙配置的复杂性。Satellite 和 Foreman 也可以配置为侦听不同的网络接口，如果您担心 DHCP 或 DNS 对您的网络造成不必要的影响，则允许 DHCP 和 DNS 隔离。

Tip

红帽卫星和福尔曼将在下一章更深入地讨论。

安装

一旦系统启动到网络安装，就需要配置 PXE 服务器来传送安装指令。这就是所谓的 kickstart 文件。Kickstart 文件基本上是 Linux 安装程序的应答文件。这些文件可用于网络安装和 ISO 或 USB 设备安装。

应该配置一个好的 kickstart 文件来部署您正在使用的 Linux 发行版的基本安装。由于主要关注的是磁盘布局和基本软件包安装，保持 kickstart 文件的简单性将允许您对各种不同的系统类型使用相同的 kickstart 文件。

方法 2:虚拟机模板

这种方法主要用于构建虚拟机。然而，使用类似于 PlateSpin 的技术从映像构建物理机器是可能的。为此，在继续本文之前，您需要弄清楚这个过程。

出于本节的目的，我们将仅提及虚拟机构建。

虚拟机管理程序 API

使用先前安装方法中的网络安装选项，您需要使用 PXE 引导系统。然而，从模板部署 Linux 系统不需要安装 Linux 操作系统，因为模板中已经安装了 Linux 操作系统。您需要的是一种与当前托管您的部署模板的虚拟机管理程序对话的方法。

要与虚拟机管理程序进行系统配置，有几个选项可供选择:

  • 可变模块

  • 木偶或类似的

  • 自定义 Shell 脚本

  • 管理系统，如卫星，领班，或 SUSE 经理

使用上述方法之一，您可以自动执行虚拟机管理程序的配置过程，以便从模板创建虚拟机。如果您想进一步简化，还可以自动创建模板，从互联网上下载图片。

可行的例子

对于前面的过程，我个人推荐使用 Ansible。Ansible 提供了一个更容易的学习曲线，是当前自动化的市场趋势。Ansible 已经提供了 Ansible 模块，可以通过安装所需的 Ansible 集合来添加其他模块。除了这些模块，网上还有足够多的例子向你展示如何自动化你能想到的任何东西。事实上，如果这是你想做的事情，可以看看我的 GitHub 仓库中关于 Ansible 的一些基本例子。在过去的几年里，我参与开发的一个特殊的可负责角色叫做“可负责角色基石”这个角色可以帮助用户在 VMware 和 Libvirt 中构建虚拟机，还允许用户在 AWS 和 Azure 中提供云实例。

https://github.com/kenhitchcock

使用图像

如果您希望采用模板部署模型，那么有必要了解哪种方法是最好的:使用黄金映像还是使用映像目录。

黄金图像

“黄金映像”模型包含一个映像或模板，作为所有系统的基础起点。这个图像将是真理的中心来源，一切都可以用它来建造。让我们来看看使用这种方法和不使用这种方法的一些理由。

使用它

  • 管理和维护一个映像。

  • 没有图像蔓延造成混乱的机会。

  • 真相的一个来源。你知道里面有什么。

不要用它

  • 如果您的映像不是 100%正确的，那么您可能最终会得到一批需要重建的 Linux 系统。

  • 不能用于快速启动开箱即用的系统。仍然需要配置。

  • 使用基本图像节省的时间最少。

Note

我不再推荐这种方法，主要是因为现在有更好的自动化系统构建的方法。这种方法多用于 Linux estate 构建的早期。

图像目录

该目录可以是虚拟机模板、映像或 kickstart 文件。都有相似的优点和缺点。

如果您决定使用图像目录或 kickstart 文件，建议您跟踪图像的用途以及如何将它们用于变体。下面是一个基本的例子:

  • linux 操作系统映像基础]

    • [Web 服务器图像]

      • [负载平衡器图像]

      • [反向代理图像]

    • [数据库服务器映像]

      • [Mysql 图像]

      • [Postgresql 图像]

这种管理构建过程的方法表面上看起来确实是个好主意，但是理解它可能带来的额外工作是很重要的。我们把这个分解成一些优缺点来比较一下。

优势

  • 可用于快速构建系统的预构建映像或 kickstart 文件的目录。允许每次重复构建。

  • 部署后，系统几乎可以 100%配置使用。

  • 可以密封模板，以确保不会发生配置漂移。

不足之处

  • 如果您使用模板进行虚拟机克隆，模板将需要修补，并且可能会被遗忘。

  • 图像蔓延可能会发生，你可能会得到一大堆没人知道它们是干什么用的模板。

  • 多个映像需要有人进行修补和维护。

构建流程流

为了改进任何组织中的构建过程，我们需要理解流程。一旦我们对流程进行了很好的细分，我们就可以看到哪些地方可以自动化，哪些地方可以改进。

基本构建过程

Linux 系统构建的基本流程通常如图 3-1 所示。在请求完成之前添加批准过程，并考虑对可用资源的检查，这样就有了构建新 Linux 系统的基本流程。

图 3-1

Linux 系统构建

这种解决方案至今仍被许多组织使用，在过去的十年中，除了所安装的操作系统版本之外，并没有太大的变化。

有哪些可以改进的地方

有了这个基本构建过程的例子，我们有很多改进和自动化的空间。让我们了解一下可以做些什么来改进这个过程。

自动，自动，自动

不言而喻，在构建过程中自动化你所做的每一件可能的手工操作。这包括安装或部署之外的任务。当尝试自动化完整的端到端系统时，网络寻址的分配和 dns 配置至关重要。你通常手动做的所有事情都必须自动化。

引入用户请求门户

通过使用某种类型的用户请求门户，您不再需要为您的工程师分配基本的构建工作。正如前面提到的，不仅系统构建应该是自动化的，请求系统的过程也应该是流线型的。

与其他平台的集成

用户门户应该能够与诸如变更管理平台之类的系统集成，在这些系统中，构建请求可以被自动发送以供批准。一旦一个任务被批准，门户应该能够与自动化平台对话以启动构建任务。一旦作业完成，应该通知用户。

简化资源需求

在用户门户中使用“t 恤尺寸”进行系统构建将降低最终用户的复杂性。仍然需要确定用户构建所需的资源需求，但这可以在用户请求过程中通过文档或注释来完成。

使用自动化平台

当尝试自动化完整的资产构建时，强烈推荐使用自动化平台。所提供的特性通常有助于简化这一过程，并在过程中提供指导和提示。

像 Red Hat Automation Platform 这样的一些自动化平台也可以被用户用作请求门户来启动批准的构建。将需要一些定制和用户访问控制，但在一定程度上是可能的。可以使用红帽自动化平台的社区版本，但是记住会有区别。缺乏目录服务集成就是一个例子。

替代的想法和系统可以包括从 Jenkins 管道到客户脚本或应用程序的任何东西。也有更高端的付费产品可以使用，但这将取决于您对企业产品的偏好。

引入截止日期

对于仅用于小型工作或测试的非生产或开发平台，引入自动淘汰它们的方法。如果需要，为用户提供一个扩展选项，但要确保未使用的系统过期并被删除。这并不总是可能的，但是当您允许用户请求新系统时，应该考虑这一点。如果没有这样的东西，你很快就会达到硬件的极限，或者更糟糕的是，如果你使用云平台，你可能会产生巨大的成本。

自动化构建流程流

如果所有的建议和更多的建议都被采纳，那么您的新构建流程不仅会减少日常的构建工作。它还将允许完整的财产重建和改善灾后恢复。由于可以在几分钟或一小时内重新配置和使用失效的系统，因此减少了对失效系统进行灭火的需求。通过适当的灾难恢复和故障转移，应该很少甚至没有停机时间。图 3-2 考虑了一些场景，但应该包括更多关于测试和系统定制的内容。

图 3-2

可以改进标准构建过程，以消除手动配置

通过改进您的构建过程，更多的时间可以花在更令人兴奋的工作上，并且它可以促进创新。

系统修补

系统补丁是系统管理员应该做的最重要的工作之一。如果系统没有定期修补，大多数需要认证的公司或组织可能会被罚款甚至更糟。因此，大多数组织都会定期计划和执行补丁程序。这通常意味着修补或更新需要在工作时间之外和特定的维护窗口内完成，对于分配了这项工作的可怜的系统管理员来说，这是一项痛苦的任务，尤其是当工作在凌晨 1 点结束时。

让我们首先了解不同的更新类型，然后了解如何以简化的方式管理修补和更新，以潜在地减少非工作时间的工作。

更新类型

企业发行版的 Linux 更新可供付费订阅的客户使用。之前，我们已经讨论过了，但要重申的是，这些订阅是企业与社区的区别。Red Hat 和 SUSE 等企业级 Linux 公司将不断发布更新。这些更新有两种形式:包更新和勘误表。

包更新

软件包更新占据了大多数系统修补周期的大部分。更新往往是已安装软件包的新功能或新版本。通常，在更新周期中，软件包管理器或软件包安装文件会备份任何可能受影响的配置文件。但是，千万不要想当然地认为这件事一定会做成。我曾经遇到过一个问题，一个产品被更新，覆盖了配置文件中的定制。我的建议是，在运行任何更新周期之前，一定要确保有备份。

正误表

Linux 更新中常见的另一种更新类型是勘误表更新。勘误表是错误修复和安全更新。这些可能是你需要安装的最重要的更新类型。正是在这些勘误表中，当在包或文件中发现漏洞时，您将收到重要的安全修复。这些勘误表必须尽快应用于任何生产环境。

Note

作为您的 Linux 资产的系统管理员，确保您收到所有带有勘误表版本的警告电子邮件。当新的勘误表发布时被告知将有助于您计划修补周期，尤其是当勘误表包含安全修复时。

脚手架

在对您组织的系统应用补丁程序和勘误表时，了解新的更新不会对任何正在运行的系统造成任何负面影响是至关重要的。为了降低这种风险，分阶段更新是有意义的。我的意思是，您的修补应该从优先级最低的系统流向优先级最高的系统。您可以从修补优先级最低的系统开始，比如沙盒环境。运行自动化测试，或者让测试团队签署平台，以确认在最近的补丁周期中没有发生任何问题。一旦您确信没有任何东西受到新补丁版本的影响，您就可以继续您的下一个环境(图 3-3 )。

图 3-3

典型修补流程

示例流程图仅考虑沙箱环境之后的测试，而不考虑不同平台中不同的包。对于这种设置，在生产前的环境中一直进行自动化测试是非常有益的。由于生产前应该是生产的一面镜子，所以您最好在生产前打好补丁后，了解打好补丁后生产中是否会出现任何问题。

补丁管理系统

使用像 Spacewalk 或 Red Hat Satellite 这样的补丁管理平台将有助于管理补丁管理周期。这些系统的构建功能允许系统管理员隔离补丁或勘误表，使其永远无法进入环境。

例如，Satellite 6 能够对下载的软件包和勘误表进行分组。然后，这些软件包和勘误表组会受到版本控制，并被推送到特定的环境中。然后，这些更新组可以在各种环境之间迁移，这就允许您(系统管理员)决定什么环境获取什么更新。如果你有“触发快乐”的用户不断尝试在他们使用的系统上运行“yum update ”,这是非常有用的。希望永远不会出现这种情况，但有时可能会发生错误，通过一开始就没有更新来避免不必要的停机是很有用的。

表 3-1 列出了一些目前常用的补丁管理系统。

表 3-1

补丁管理系统

|

系统名称

|

它是用来做什么的？

|
| --- | --- |
| Red Hat Satellite | 用于 RHEL 6 及更高版本的系统。可用于修补和系统配置等。 |
| SUSE Manager | 用于 SUSE 系统，可用于修补和系统配置。 |

Note

在下一章，我将更详细地讨论卫星服务器。如果你想知道更多，我推荐你阅读一些官方文档来获得更多信息。

规划

补丁计划听起来像是你在睡觉时做的事情，而且由于大多数组织在工作时间之外做补丁，这可能是系统更新时发生的事情。

拥有一个系统修补的可靠计划几乎和修补本身一样重要。这一计划将允许所有系统及时得到修补，并避免系统不能及时获得更新和暴露于它们本应避免的漏洞的风险。

一个好的修补计划应该包括如何应用修补程序、修补程序来自哪里(修补程序管理系统)、如何检查修补程序是否已安装，以及最重要的是，如何在出现系统问题时取消修补程序。如果计划是万无一失的，那么实现可以由经验较少的系统管理员来完成，这样可以分散工作量。

反转

当一个系统补丁造成的损害超过它所修复的损害时(这种情况很少见)，您需要知道如何将系统回滚到工作状态。这可以通过几种方式来实现。

从备份恢复系统

在对系统进行任何更改之前，最好备份系统。这将包括备份对您的系统最重要的文件系统文件和目录。从这些备份中恢复将使您恢复到更新前的状态，但必须理解，此过程可能非常耗时，如果在工作时间之外打补丁，您可能没有时间。

恢复快照

虚拟机可以拍摄快照，通常这是一个快速的过程。如果快照已运行了较长时间，从快照恢复有时会花费较长时间，但此过程通常需要几秒钟。

程序包管理回滚

另一种相对快速的回滚方法是使用包管理系统进行回滚。对于 Red Hat Enterprise Linux 或任何使用 yum 的发行版，您可以使用“yum history undo <id>”命令回滚。其他发行版如 Ubuntu 和 SUSE 稍微复杂一些。

软件包的重新安装

更令人恼火的方法是移除并重新安装有缺陷的软件包。这种方法的问题是，如果您要修补大量的软件包和系统，那么查找有问题的软件包的发现过程将花费您大部分的时间。虽然这可以解决问题，但您将花费在修补窗口中可能没有的时间。

系统的重新部署

大锤方法将是摧毁系统并重新部署。这可以在 sandpit 等优先级较低的系统中完成，但肯定不是大多数组织在生产中会做的事情。

备份和恢复

如果您构建的系统不容易重新部署，备份您的 Linux 系统是您通常会做的事情。如今，从代码中重新部署系统的想法比从备份中恢复更吸引组织。但是，在发生灾难时，有些系统可能无法轻松重新部署。对于这些系统，您需要知道哪些目录和文件需要备份。您需要了解如何从这些备份中恢复，以及更快恢复的最佳选择是什么。

重要的目录和文件

如果您需要在文件系统级别进行备份，有一些标准目录非常重要。这些目录应包括但不限于以下内容:

/etc
/home
/root
/usr
/opt
/svr
/var (be sure to exclude logs or anything large not required)

应该使用您选择的工具压缩上述目录。然后，可以将该归档推到备份位置。这可以是您希望的任何存储类型；请记住，网络上的一些备份位置可能比其他位置需要更长时间。如果您需要在特定窗口内完成备份，请明智地选择。

虚拟机备份

大多数虚拟机提供商都有能力拍摄虚拟机快照。然而，快照不是备份。当您在系统上工作时，快照可用于快速恢复。快照可能会变得非常大，因为它们跟踪系统更改的所有内容；如果这些更改没有得到控制，当您以后需要重新合并这些更改时，它们会给您带来一些问题。

备份虚拟机的方法有几种，但大多数基本上都是复制虚拟机的磁盘映像。一些第三方软件可以为您管理这一点，因此您可以备份实时虚拟机，但它们价格昂贵。标准虚拟机备份要求首先关闭虚拟机，但这并不总是可能的。

虚拟化平台经理应该准备好解决方案，但是如果没有备份，请确保在执行潜在的破坏性工作时至少拍摄快照。

灾难恢复

作为一个组织，生产平台尽可能保持运行至关重要。这可能涉及许多不同的解决方案，并且应该涉及所有级别的冗余。当这些计划在完全没有准备的情况下失败时，需要一个从灾难中恢复的计划。灾难恢复的目标不是确保覆盖所有单点故障，而是如何恢复生产。

基于恢复时间的最佳策略

让我们探索几个灾难恢复选项，并讨论哪些选项适合您的组织。

复制数据中心

尽管运行多个数据中心是个好主意，但有时也不足以避免灾难。如果两个数据中心互为镜像，则多个数据中心可以工作并实现真正的灾难恢复。数据需要不断复制，系统需要在两端完全相同，或者至少尽可能接近。这种解决方案实际上意味着所有成本加倍，并且需要两个数据中心之间的高质量连接。

伸展集群

从技术上讲，这不是一个灾难恢复解决方案，但确实允许数据中心之间的故障转移，从而减少停机时间，并在需要维护时切换数据中心。

然而，这种解决方案确实需要可以是集群的基础设施。从存储到网络设备的一切都需要以一种能够进行故障转移的方式进行配置。

基础设施作为代码

由于大多数组织已经开始拥抱自动化的世界，这种灾难恢复方法应该不会显得完全陌生。

如果在您的资产中部署和配置的所有东西都是自动化的，那么需要恢复以继续运行的所有东西就是执行自动化的代码。如果跨数据中心或云平台进行备份和恢复，则可以运行自动化来重建您的组织所需的所有系统。这种方法需要高度的组织，并且涉及严格的构建过程，该过程只允许从代码构建系统。

在发生灾难时，需要恢复实际数据，这本身就需要一本关于该主题的完整书籍，以解决创建完美解决方案所涉及的所有复杂问题。

云

就像拥有另一个数据中心一样，使用像 AWS 或 Azure 这样的云平台可以为灾难恢复提供一个优秀的平台。让整个云平台自动构建我们内部系统的副本可以提供理想的快速故障转移。理想情况下，该平台如果不用于生产，可以关闭以节省成本。然后，在发生灾难时，云环境可以启动并重定向流量，同时解决内部问题。这种解决方案需要您进行大量投资，以确保从本地系统复制配置，并且您还需要研究如何复制数据，以确保没有数据丢失。在所有灾难恢复选项中，这可能是最便宜的选项之一，因为一旦平台构建完成，它就可以关闭。仅考虑数据成本和保留 IP 地址的成本，云平台可能会一直处于休眠状态，直到需要时才会出现。

常见的不良做法

在看一些财产管理的良好做法之前，让我们看一些不太好的做法的例子。

虚拟机模板

之前，我们谈到了使用虚拟机模板来构建 Linux 系统。这本身并不是一个坏的实践，但是忽略了对模板的维护可能是个坏的实践。使用单个模板而不修补它或解决漏洞，可能会使您的资产面临部署无法通过合规性扫描的系统的风险。

如果您使用虚拟机模板作为您的 Linux 构建过程，请确保您保持模板有序。在您的工作计划中建立一个定期计划作业，该作业不能被某人跳过以检查模板的状态并确保它们保持最新。

修补或缺少修补

有时，系统修补会滞后，在极少数情况下会被遗忘。如果可以从外部访问系统，让系统保持最新是非常重要的。不言而喻，如果您的系统上没有已知漏洞的补丁，您就有可能让自己和您的组织面临灾难。即使是无法从外界访问的平台也应该定期打补丁和更新。这些系统看起来很安全，但是如果入侵者甚至能够访问您的网络，让您的所有系统尽可能安全至少会使任何进一步的破坏变得更加困难。

防火墙已禁用

当运行数千个系统时，维护和配置本地 Linux 防火墙可能是一件痛苦的事情，但是它们的重要性怎么强调都不为过。就像在安全网络中修补系统会降低入侵者设法破坏您的网络时造成进一步损害的风险一样，本地 Linux 防火墙可能会给潜在的入侵者带来另一个不便。

在构建和使用配置管理平台时自动化防火墙配置，以减轻管理这些防火墙的痛苦。总有一天他们会有所作为。

SELinux 已禁用或许可

通常，当我拜访新客户时，我发现他们禁用了 SELinux 或者没有在他们的系统上将 SELinux 设置为强制模式，有时是因为他们不知道如何配置 SELinux 或者不了解其好处。

拥有尽可能多的选项来确保系统保持安全对任何组织来说都是一种优势。将 SELinux 设置为强制模式通常是合规性扫描的一项要求。现在习惯于使用 SELinux 将会使以后被迫启用它时的生活变得更好。

使用社区存储库

使用像 Red Hat Enterprise Linux 这样的企业 Linux 发行版并不仅限于使用 Red Hat 存储库。如果你愿意，可以启用和使用像 EPEL 这样的社区知识库。有时，这是出于一个很好的理由，例如需要一个在 Red Hat 存储库中不可用的包，有时它可以被启用，因为一个组织希望使用先进的包，当你和你的组织完全支持时，这是很好的。但是，如果您依赖企业支持，这是不行的。这个问题可能会污染系统，直到它变得不受支持，直到您删除非分段的软件包和更新。当您在生产中遇到问题时，这可能会在提出支持案例时带来很大的麻烦。

脚本、脚本和更多脚本

使用 bash 或 shell 脚本来管理您的平台似乎是一个好主意，但是很容易失控。新的开始者和离开者都创建他们自己的脚本，很快在你知道之前，没有人知道什么是用来做什么的。更糟糕的是，这些脚本中的一些不尽如人意，在某些情况下甚至非常危险。

应该尽可能多地使用管理平台，并且所有脚本都应该是从自动化平台执行的自动化形式。

以 Root 用户身份运行

在生产环境中，任何人都不应该以 root 用户身份登录系统。生产也不总是意味着面向客户的系统。开发人员积极工作的开发环境也可以被视为生产环境。以 root 用户身份直接登录会删除任何审计线索，并为意外导致问题的人提供完全权限。始终使用您自己的凭据登录，并在需要时使用 su 登录到 root。这种做法需要每个人都遵守，而不仅仅是标准用户。

良好做法

以下是我个人对良好屋管理的一些看法。

构建一次性系统

您构建的任何系统都应该能够删除和重新部署。是的，一些系统需要时间来重新部署，但是如果是以标准的可重复的方式从一个可信的来源构建的，您应该有信心扔掉任何系统并重新部署。将你个人和组织的文化转变为面向云的工作模式将有助于推动创新。消防和故障排除应该减少，让你腾出更多时间做你更感兴趣的事情。

尽可能自动化

这一条是不言自明的，但是只要有可能，就尝试自动化您所做的事情。今天手动做任何事情的想法看起来很奇怪，因为你可能需要在某个地方重复这项工作。自动化的实现简化了一切，也为任何新手提供了一个很好的文档来源。此外，编写自动化代码远比点击下一步更令人兴奋和有趣。

创建前搜索

在开始写一个新的可承担的角色或任何类型的剧本之前，一定要做好你的尽职调查，看看是否有人已经为你做过了。很有可能你会找到你正在寻找的东西，节省你的时间和精力。重新发明轮子只是浪费时间，而且在大多数情况下，你找到的内容已经花了相当多的努力和思考。

分享知识和协作

与你的同事分享你所学到的东西，并尝试让尽可能多的人参与工作项目。举办研讨会，培养对自己工作的兴趣。这将为你的经理打开大门，让你有更多的时间去创新，向你的组织展示你的价值。请不要觉得你所学的应该只留给你自己；你永远不知道是否有人能提供一个有趣的观点来让事情变得更好。记住，开源不仅仅是可用的代码。这是合作和开放。

源代码管理

您开发的任何管理资产的东西都应该存储在一个像 Git 这样的源代码控制平台中。代码应该进行代码审查，在严格的测试完成之前，绝对不应该在产品中执行。当我们写代码时，我们都有最好的意图，但经常会被我们犯的错误所蒙蔽。第二双眼睛有时会有很大的不同。

重新评估系统要求

运行大型虚拟机资产时，所需的资源可能并不总是反映原始构建所需的资源。使用资产监控工具将有助于您控制那些实际上并不需要分配给它们的资源的系统。这可以让您为其他系统释放未使用的资源。如果您的虚拟化平台被配置为自动回收未使用的资源，这当然不会有太大影响。

摘要

本章向您介绍了以下主题和讨论要点:

  • 多年来采用的一些过时的工作方式。要避免的事情

  • Linux 构建过程以及如何改进它。可能会遇到哪些问题，可以做些什么来改进流程

  • Linux 系统补丁所涉及的过程以及保持更新的重要性

  • 备份和恢复选项，包括关于灾难恢复的想法

  • 管理 Linux 资产时，常见的不良实践和不应该做的事情

  • 好的实践和开始做事情的建议

四、财产管理工具

如果处理不当，管理较大的 Linux 资产可能会很有挑战性。试图按照 20 年前的技术和工具来管理数千个 Linux 系统会给你带来一大堆麻烦，尤其是当合规性扫描显示你的环境中存在漏洞时。您不仅会发现大量可能让任何安全人员心悸的安全漏洞，还会留给您大量令人沮丧的补救工作。

为了避免这些问题，强烈建议使用管理软件。即使只需要管理少量的 Linux 系统，管理平台也只会让生活变得更加轻松。日常任务可以自动化，构建流程可以简化，可怕的安全补救措施可以卸载到管理平台上为您处理。

有些工具是有成本的，因此，了解有哪些社区选项是很重要的。与我们在前面章节中讨论的非常相似，我们将做一个类似的比较。本章的目的是让您熟悉管理平台，它们的用途，以及它们如何让您的 Linux 系统管理员生活变得更轻松。

管理系统

在这一章中，我们将讨论两种管理系统:Linux 平台管理系统和自动化平台。对于每种类型的管理系统，我将解释系统做什么和工具的基本概念。首先要明确的是，这本书并不是关于如何使用这些平台的官方指南。我所要做的就是让你熟悉这些工具的作用，以及它们如何让你受益。

Linux 平台工具

如果您还没有使用管理工具，那么您应该使用的第一个也是最重要的管理工具是 Linux 平台管理工具。这个工具是您资产的中心，控制着 Linux 系统管理员应该做的大部分事情。该工具应具有以下部分(如果不是全部)功能:

  • 从外部存储库同步包

  • 能够按环境隔离包

  • Linux 构建和 kickstart 功能

  • 合规性扫描和报告

  • 配置漂移控制

  • 平台监控和日志记录

  • 集成到虚拟化或云平台中

  • 在离线环境中工作的能力

  • 必须可扩展且可靠

显然，您并不总是需要所有前述的功能，但是如果您开始改进您的工作方式，拥有这些功能确实会有所帮助。例如，您的组织决定开始使用更多的云设施。拥有一个具有云供应能力的工具将使您不必使用另一个平台或编写自己的平台。

可用的 Linux 平台工具

表 4-1 提供了一些更常用的 Linux 平台工具的列表，您可以使用这些工具来管理从小型到大型的 Linux 资产。

表 4-1

Linux 平台管理选项

|

产品

|

描述

|
| --- | --- |
| Red Hat Satellite | Red Hat 的首要企业 Linux 资产管理工具。用于管理 RHEL 6 及以上的地产。在撰写本文时，该产品已经问世近 20 年了 |
| Foreman | 用于管理 Linux 系统构建过程的社区产品。福尔曼是红帽卫星 6 号的上游 |
| Katello | 为 Foreman 提供内容管理的社区产品。卡特罗是红帽卫星 6 号使用的另一种产品，作为其上游对等产品 |
| Pulp | 一个管理 Linux 系统软件包仓库的社区产品。像 Foreman 和 Katello 这样的纸浆是 Red Hat Satellite 6 的另一个上游产品 |
| SUSE Manager | 管理 SUSE 平台的 SUSE 企业产品。SUSE Manager 基于社区产品 Uyuni，它本身是太空行走项目的一个分支 |
| Spacewalk | 太空行走在过去被用作红帽卫星 5 号的上游。今天，它仍然是一个社区 Linux 平台管理工具，已经被它的开发者抛弃了 |
| Uyuni | 一个社区平台管理系统，提供系统配置和补丁管理功能。配置管理由 SaltStack 管理，具有运行合规性扫描的功能。Uyuni 是集成了 SaltStack 的太空行走产品的一个分支。乌尤尼也是苏塞的上游经理 |
| EuroLinux | 另一个社区 Linux 资产管理工具，似乎也是从 Spacewalk 与 SaltStack 集成而来 |

Note

太空行走分叉平台除了包含盐堆之外，大部分都是一样的。如果您决定使用其中一个，则需要根据产品修复频率做出决定，以确保您有可用的错误修复和漏洞修补程序。

选择您的 Linux 平台工具

开源世界中的大多数东西都有企业产品和社区产品。根据组织的要求和预算限制，您的选择可能会受到限制。为了了解如何正确决定应该使用哪种工具，让我们看看您需要问自己的问题:

  • 支持:如果我遇到问题，我是否需要企业供应商的支持，或者我是否乐意与社区和他们的论坛合作来获得我的答案？

  • Linux 发行版:我在管理哪些 Linux 发行版？他们是否有需要管理的企业订阅？

  • 特色:有哪些特色是我离不开的？我是否乐于使用多个平台来提供我想要的所有特性，或者我是否需要一个在一个地方拥有一切的工具？

决定

您使用的产品将根据您组织的需求而定。通常，法规遵从性将决定您是使用企业产品还是社区产品。产品应该具有的特性，往往是由您上面的决策者决定的，他们不了解作为 Linux 系统管理员的您是做什么的，或者产品是做什么的，这可能会使您的产品成为障碍而不是帮助。

我以上的建议是为你认为不仅对你而且对你的组织都是正确的产品建立一个案例。为此，你需要果断地做出决定，并给出一个或多个明确的理由，说明为什么你更喜欢使用的产品最适合这项工作。如果产品是企业产品，你还需要证明成本，并证明它比竞争对手更好。根据你公司的工作方式，介绍优缺点应该是一个有用的练习，可以比较不同产品的特点。

为了支持您的决策和建立您的案例，您必须确信该产品是适合您的产品。要做到这一点，你必须熟悉它，了解它的局限性。这可以通过执行以下操作来实现:

  • 让供应商演示产品:如果产品是付费产品，请供应商来拜访您。要求向您和您公司的决策者展示产品演示。这将增加你得到你想要的产品的机会，如果它在你的组织中有更多的可见度。决策者将掌握所有信息，以便做出明智的决策。

  • 概念验证:理解平台工具如何工作的另一个有用的方法是构建一个概念验证系统来测试。如果您想要测试企业产品，请与供应商联系并申请演示订阅或许可证。社区产品通常不需要订阅，但有些可能需要或请求捐赠。

Tip

建议您测试一个稍旧版本的社区产品来进行 PoC 测试。这应该会减少一些尖端技术带来的痛苦。当你还在学习的时候，坚持稳定的分支。

卫星服务器

第一个也可能是大多数人都知道的是红帽旗舰管理系统:红帽卫星服务器。Satellite 最初发布于 2002 年，基于上游太空行走社区项目，直到 2014 年发布 Satellite 6.x。从那时起，Satellite 6 就已经基于一些上游产品全部组合在一起，提供最新的红帽平台管理系统。

卫星 5 号

Red Hat Satellite 5.x 作为一个完整的 Linux 资产管理系统工作得非常好。Satellite 提供补丁管理、系统部署、合规性扫描、配置管理和一般资产管理功能。

一些有趣的点，我总是花更多的时间在系统部署和配置管理上。两者在使用上都存在这样或那样的问题。

结构管理

在其生命周期中，Satellite 5.x 版本不断改进，但有一个主要问题:其配置管理系统。这种配置管理的尝试太糟糕了。配置管理使用存储配置文件的概念，这些文件将被推送到客户端系统。不幸的是，随着越来越多的配置文件被存储，这种情况已经变得混乱不堪。配置可以被版本化，但是管理起来非常痛苦，并且经常以一团糟告终。

系统部署

早期卫星使用的系统部署使用了 Cobbler 和 PXE 引导机制。让部署系统工作有时被证明是相当具有挑战性的。我花了很多时间调整配置来部署系统，但后来发现我没有设置正确的权限或者我丢失了一个包。后来的版本进行了改进，变得更容易安装。可能是我获得经验和文档改进的结合。

卫星 6 号

卫星服务器的当前主要版本是版本 6.x。卫星 6.x 基于以下产品组合:

  • 男工头

  • 卡特洛

  • 纸浆

  • 锤子

  • 烛光晚餐

内容管理

对我来说，Satellite 6 引入的最好的功能是对内容管理系统的全面检查。以前在卫星 5 号和太空行走系统中，内容被分成“频道”这些“通道”需要从一个克隆到另一个，以便为您创建一个将内容从开发、测试应用到生产的阶段流。如果这没有意义，不要担心；过去我试图展示给他们看的时候，它已经让足够多的人感到困惑。稍后，我将在“太空行走”部分对其进行更详细的分析，并进行更多的解释。

内容视图

幸运的是，Satellite 6.x 在 Katello 的帮助下提供了更好的解决方案。新系统不再使用“频道”，而是使用一个叫做“内容视图”的新概念“内容视图”是卫星可以提供给系统内容的集合。该内容可以包含 puppet 模块、Ansible 角色或标准 yum 存储库。“内容视图”真正的亮点在于它的版本控制能力。这意味着，当新的包被下载到卫星上或者新的 puppet 模块被添加时，先前版本化的“内容视图”不受影响。这意味着分配给这些“内容视图”的任何系统将看不到新内容。完美，如果你想通过你的生命周期阶段的内容。

Tip

随着内容视图的增长，发布它们可能需要更长的时间。保持内容视图较小有助于解决这个问题，或者您可以启用按需下载。

生命周期

内容视图对内容分组很有用，但是它们确实需要被系统使用。为此，已注册的系统被添加到不同的生命周期中。这些生命周期可以随便你怎么称呼，但一般来说，它们都被赋予了如下乏味的名称:

库(默认)➤开发➤测试 UAT ➤生产前➤生产

内容视图与生命周期相关联，而生命周期又与系统相关联。

内容管理流程

图 4-1 显示了更新内容并应用于生命周期环境的基本示例。

图 4-1

典型的生命周期环境

图 4-1 中的基本流程显示了如何更新、发布内容视图并将其推入不同的生命周期环境，从而允许将包更新或勘误表等内容从测试环境迁移到生产环境。

Tip

内容视图可以嵌套。它们被称为复合内容视图。

系统供应

随着使用 Foreman 代替 Cobbler 的引入，Linux 部署过程在某种程度上得到了简化，但在另一方面却变得复杂了。复杂性主要是围绕确保组织和位置已针对供应过程的所有组件进行了配置而引入的。像“操作系统”和“网络子网”都需要添加到正确的“组织”和“位置”中一旦您理解了分组问题，剩下的配置就变得比之前的补鞋匠配置简单多了。

关于系统供应过程需要注意的一个主要问题是，当您部署卫星时，您需要确保添加系统部署的功能。官方的 Red Hat 文档非常清楚地解释了这个过程，并提供了您需要的所有参数。如果您不想使用文档，您也可以查看“satellite-installer --help”命令以获得更多参数。它们是不言自明的，当你看到它们时应该是有意义的。我的建议是，当你第一次安装卫星时，坚持使用官方文档。一旦你做了一个，帮助命令是有用的，提醒你需要什么。

系统修补

注册到卫星的修补系统与以前的卫星版本没有什么不同。系统仍然需要运行“yum update”来获得最新的内容。远程执行也可以像过去在 Satellite 5.x 中那样用于整个地产的大规模执行。就我个人而言，我建议使用你的自动化平台来做这件事，但这取决于你希望如何管理你的遗产。

与以前的卫星版本相比，最大的变化仍然是“内容视图”版本。当新内容可用，并且您希望在您的资产中部署时，请记住遵循本章中的内容管理流程图。一旦您的“内容视图”被提升到系统的生命周期环境中，您将能够执行系统更新。

结构管理

从卫星 5 到卫星 6，配置管理得到了极大的改进。Satellite 6.x 的早期版本只使用“Puppet”进行配置管理和 SOE(标准操作环境)。puppet 的一个缺点是 Puppet 需要在客户机系统上运行 Puppet 代理。这些代理通常需要被配置为登记到卫星傀儡主服务器，以确保它们与预期的配置保持一致。

木偶内容将被存储在与注册到卫星服务器的客户机系统相关联的“内容视图”中。然后，傀儡客户机将向卫星傀儡主人登记，然后运行可用的内容，检查是否有任何新的内容需要应用或纠正。如果在客户机系统上停止了傀儡代理，则不会应用配置。

Satellite 6 的后续版本引入了 Ansible 作为配置管理的另一个选项，这与 Puppet 配置非常相似，需要一个“内容视图”来包含您希望系统配置的所有 Ansible 角色和配置。

Puppet 或 Ansible 配置也将通过“内容视图”进行版本控制，并且还需要发布和宣传更新的内容，以供注册到卫星的系统使用。

使用卫星的理由

  • 能够使用更易于使用的资源调配平台调配 RHEL 系统

  • 能够跨环境进行修补和更新

  • 具有持续支持和功能增强的企业产品

  • 集成的合规性扫描和补救

  • 使用 Puppet 或 Ansible 进行配置管理

不使用卫星的理由

  • 所涉及的成本可能超出小型组织的承受范围。

  • 不推荐用于少于 30 个系统左右的小型庄园。

  • 不适合非红帽系统。

SUSE 经理

SUSE Manager 4.x 是最新的 SUSE Linux 平台管理工具。SUSE Manager 4.x 基于社区产品 Uyuni (ya - uni)。

哇哦

乌尤尼最初是从太空行走项目中分出来的，但开始从最初的太空行走项目中分走了这么多，以至于它开始成为自己的工具，这令人耳目一新，因为太空行走已经存在了很长时间，并有其公平的问题。

在 Spacewalk 因其糟糕的配置管理而失败的地方，Uyuni 通过废弃旧的配置管理工具并用 SaltStack 取代它而表现出色。这个决定是天才之举，也可能是乌尤尼成为 SUSE 上游项目经理的一个好决定。

支持

我敢肯定，Uyuni 和 SUSE Manager 有他们自己的挑战，那些对这个工具有更多经验的人可能对它们了如指掌。SUSE 管理器的配置与 Red Hat Satellite 没有太大的不同，并且是不言自明的。这两种产品都有优秀的文档，并提供企业支持。

SUSE 管理器配置

使用 SUSE Manager 首先要做的事情之一是注册您的帐户，这样就可以为您的 SUSE 环境同步软件包，非常像 Red Hat Satellite。下载的内容然后被分类到“频道”中，这与太空行走中使用的概念相同。引入了生命周期的新概念，它改进了如何管理添加的内容，以提供跨环境的更新。这种新方法简化了这一过程，而不是像太空行走那样必须进行“频道”同步。

如果您是一个 SUSE 组织，SUSE Manager 4 是您应该考虑在您的环境中使用的工具。阅读官方文档，构建一个概念验证系统，并将其功能与其他可用的功能进行比较。

使用 SUSE 管理器的原因

  • 您可以使用中央预配平台预配 SUSE 系统。

  • 能够跨环境进行修补和更新。

  • 具有持续支持和功能增强的企业产品。

  • 使用 SaltStack 进行配置管理。

不使用 SUSE 管理器的原因

  • 当成本超过效用时

  • 使用需要管理的非 SUSE 发行版

  • 管理不到 30 个系统的小型企业

男工头

Foreman 是 Red Hat Satellite 6.x 的主要上游项目之一，Foreman 的主要功能是协助提供 Linux 系统；然而，Foreman 确实有能力通过添加插件来扩展其功能。

调配虚拟机管理程序

Foreman 的一个很好的特性是，它不仅能够供应 Linux 平台，还能够供应虚拟化管理程序。如果你想将你的财产自动化到“第 n”级，这是一个非常方便的能力。

插件

然而，Foreman 本身并不像 Satellite 6.x 那样有助于内容管理或配置管理。为此，您需要将 Foreman 与额外的插件结合起来。插件范围从 Katello 的内容管理一直到 Chef 的配置管理和自动化。由于 Foreman 是一个社区项目，新的插件一直都在推出，功能也在不断增加。

开源也需要钱

Foreman 是一个不需要订阅或许可的社区产品。如果你喜欢他们正在做的事情，这个项目接受捐赠。如果你准备好了，你可以为这个项目做贡献，尽你所能提供一些有价值的资源。

太空行走

作为启动 Linux 平台管理的管理工具，Spacewalk 值得一提，尽管只是简单地提一下。

被抛弃的

不幸的是，Spacewalk 已经被它的开发者放弃了，并被留给其他人来分叉和发展这个项目。Uyuni 就是这样一个项目，它继承了太空行走的成果，目前正在开发一个非常漂亮的工具。Ubuntu 发行版公司 Canonical 是另一个使用太空行走变体进行平台管理的公司。

为什么它很好

使 Spacewalk 在当时成为如此伟大的产品的是它管理 Linux 系统的能力。系统可以分组，远程执行可以一次发送到所有系统，当您有数百个系统需要修补或安装包时，这是一个非常有用的功能。这是在 Ansible 甚至傀儡时代之前。正如几次提到的，太空行走配置管理使用起来很糟糕，但是如果你不运行傀儡环境，它确实提供了保持配置一致的功能。由于 Puppet 稍微难以掌握和理解，所以 Spacewalk 中的配置管理是一个不错的工具，即使它不是最好的。

网络供应

Spacewalk 还向更多人介绍了 Cobbler 和 kickstart 部署，将 Linux 系统构建带入了一个新的部署时代。能够从网络启动系统并选择使用 kickstart 文件确实减轻了使用物理介质的痛苦。kickstart 文件将自动安装的事实使生活变得更加容易，那些准备迎接挑战的人可以创建自己的代码片段来配置新构建的系统。

环境暂存

带通道的环境管理意味着包克隆可以确保环境不会得到更新，除非 Linux 系统管理员认为是这样。勘误表和错误修复也是如此。

谢谢你的服务

太空行走在很长一段时间内都很好地服务于它的目的，但随着 Foreman 和其他类似产品的引入，太空行走已经到了退休的时候了。像乌尤尼这样的新版本已经把太空行走变成了新的令人兴奋的东西。

供应工具

另一种类型的管理系统，可以用来管理您的财产是一个专门的供应工具。从技术上来说，Foreman 和 Satellite 都是供应工具，但专用的供应工具将充当您投资组合各个方面的单一界面。如果您在云中进行内部部署，拥有一个配置工具意味着所有操作都可以从一个位置执行。

云形式

Red Hat Cloudforms 是基于 ManageIQ 上游项目的企业供应工具。Red Hat 在 2012 年 12 月收购了 ManageIQ，并在接下来的十年里继续推动 Cloudforms 的采用。

单层玻璃

Cloudforms 一直被描述为您的资产的单一窗口。Cloudforms 能够集成到 VMware、RHV 和各种云提供商(如 AWS 和 Azure)中进行资源调配，还可以集成到 Red Hat Satellite 和 Ansible Tower 中，让您能够更好地控制自己的资产。

状态机

有了可用的集成选项，就可以用所谓的“状态机”创建虚拟机和云实例。“状态机”是用 Ruby on rails 代码编写的，提供构建和配置虚拟机或云实例所需的自动化步骤。在 Cloudforms 的新版本中，可以使用 Ansible 代替 Ruby on rails。

状态机开发的一个相当大的缺点是需要复杂的设置来让它工作。这不是开箱即用的东西，通常需要有经验的人来帮助它工作。即使在那时，这个过程仍然很复杂。

用户请求门户

Cloudforms 或 ManageIQ 能够用作供应请求门户，如果进行配置，可以限制非技术用户使用和请求平台，而无需了解所需的底层配置。可以配置自定义表单和屏幕，以允许非技术用户填写和请求系统。在这些简单的屏幕后面是被配置来执行任务的状态机和自动化。

赔偿要求

另一个非常好的功能是能够控制在财产中构建的任何系统的计费。可以配置成本中心或类似机构来管理资产成本，并可以向不同的团队或部门收费。

请求批准

当用户请求新的系统或平台时，可以配置需要在执行任何自动化之前通过的批准。还可以配置多层批准，允许变更控制团队批准构建。如果你想控制构建的东西，这是非常有用的。

优势

  • 安装非常简单，因为 Cloudforms 是从模板设备部署的。

  • Cloudforms 是一个功能丰富的工具，有许多可能性。

  • 能够与许多系统交互，并提供单一管理工具来管理所有系统。

  • 一旦部署了设备，就可以配置完整的数据中心。

  • 自定义用户门户可用于用户请求系统。

  • 与 ServiceNow 等平台的集成。

不足之处

  • Cloudforms 有一个陡峭的技术学习曲线。

  • 配置不是最容易理解的，需要时间去习惯，但是一旦用户熟悉了，可能性是无穷的。

  • 近年来，功能开发也一直在放缓，这可能表明该产品的末日即将到来。

仿地成形

如果您希望为不同的平台提供服务，Terraform 是另一个有趣的产品。Terraform 由 HashiCorp 提供，是一个开源的基础设施代码解决方案，能够跨多个环境(如 AWS 或 Azure)进行配置。

可用产品

HashiCorp 提供了一些在企业支持之外使用 Terraform 的选项。

社区 CLI

有一个标准的社区 CLI 选项，可供任何希望学习和使用它的人使用。从第一天开始，您就可以使用大多数(如果不是全部)Terraform 功能。

Terraform 云平台

免费使用 Terraform 的另一种方式是通过 Terraform 云解决方案的“免费”层。这是一个 HashiCorp 托管服务，它在免费层提供一些基本功能，但也为一些付费服务提供扩展功能。

API 和提取有用的信息

如今有了这么多可用的管理工具，对不同的工作使用不同的工具会变得相当麻烦。为了解决这个问题，我看到一些组织构建了他们自己的“抽象”层。这一层通常是使用 Python 或类似的开发语言编写的自定义应用程序，它通过 API 与其他管理平台进行通信。

不要多此一举

已经有一些工具可以通过它们的 API 连接到其他系统。Cloudforms 和 ManageIQ 是现成的工具，可以用来将大量 API 集成到其他平台。这些工具唯一的缺点是它们更多的是围绕系统的部署来构建的。自动化和修补类型的任务可能需要一点调整才能开始。

为什么不编写自己的工具

编写您自己的定制工具，通过它们的 API 利用不同的工具，确实有一些主要的优势，但是它伴随着内部开发的沉重代价。这种耗费时间和精力的行为通常会断送任何潜在的创造机会。即使一个组织确实授权了时间和精力，另一个主要障碍可能是内部缺乏开发该产品的技能。这意味着需要进一步的培训或时间来提高技能。

最好使用的工具

用于 API 访问的最佳工具应该是能够连接到平台并以开箱即用的方式显示功能的工具。这个工具存在吗？不幸的是没有。这就是为什么人们传统上编写自己的 API 调用工具，并将 API 请求映射到应用程序功能。如果您正在寻找一个工具来减少您的开发工作，您可以使用下面的一些。

管道工具

Jenkins 或 Tekton 可能是连接到管理系统 API 以自动化部署或系统修补的有用方式。API 调用可以被触发，事件可以被捕获；由此，可以使用不同的逻辑来确定接下来的动作。这可能是在您的房产中引入自我修复功能的一种有趣方式。

自动化平台

使用 Ansible 或类似的方法联系管理系统 API 是一种更干净、更好的方法。例如，Ansible 有大量的模块已经可以通过它们的 API 与不同的管理工具对话。这方面的一个例子是新的卫星模块，现在可供用户自动配置卫星。当您可以自动升级和发布内容视图时，这对于管理您的修补周期非常有用。

Shell 脚本

这不是最好的解决方案，但如果你只想自动化一些基本任务，这是你可以使用的。就我个人而言，我不会采取这种方法；我宁愿写一些答案来替我做这项工作。

摘要

在本章中，向您介绍了以下内容:

  • Linux 资产管理平台简化了 Linux 构建流程、补丁安装和配置管理

  • 目前可用的不同财产管理工具，以及为什么使用或不使用它们

  • 云配置工具，如 Cloudforms、ManageIQ 和 Terraform

  • 使用管理工具 API 来简化它们的使用，并将它们的功能构建到您的日常自动化中

五、自动化

这是第一章，我们将针对一个特定的学科，自动化。

在这一章中，我们将成百上千地钻研操纵系统的黑暗艺术。我们将讨论什么是最好的工具，以及为什么应该使用或避免使用它们。我们将了解这些工具之间的不同之处，以便您能够做出明智的决定，选择最适合您的工具。然后，我们将了解这些产品的市场趋势，以及为什么有些人更喜欢其中一种工具。

本章从总体上讨论自动化，并不关注某个特定的产品。这个想法是为了理解自动化的概念，以及如何以最好的方式应用它们。我们将讨论诸如“什么时候应该自动化，什么时候不应该自动化”之类的话题我们将探索使用自动化技术，以及何时应该这样做。

最后，我们将结束讨论最佳实践和使用 shell 脚本的章节，其中我们将讨论可以使用的不同 shell 脚本语言。

理论上的自动化

对于大多数阅读本文的人来说，自动化应该不是什么新鲜事。在我们过去所做的事情中，总是存在某种形式的自动化，无论是定制的 shell 脚本还是一些计划开始一项工作的管理工具。

随着新的工具和自动化平台的开发，自动化在过去十年中有了很大的发展。使用从 cron 作业中执行的定制脚本的日子即将结束，如果不是已经结束的话。复杂的自动化解决方案现在管理着从系统构建到自我修复系统的一切。

自动化也不仅仅是技术性的。大多数组织现在都在寻找自动化业务流程及其技术资产管理的解决方案。建立自动化来创建变更请求或提高支持票越来越成为一种需求，而不是一种奢侈。节省的时间和精力让更多的组织意识到，没有全栈自动化意味着与竞争对手保持同步的灾难。

幂等码

所有自动化应该坚持的第一件事是确保编写的代码是等幂的。这实际上意味着，只有当状态与自动化平台要求的状态不匹配时，代码才会做出更改。

这方面的一个例子是更新系统包。如果系统安装了已经是最新版本的软件包，那么除了确认软件包是所请求的版本之外，您不会希望自动化任务做任何事情。除了确认包的状态之外，不做任何事情，系统保持不变。如果软件包需要重新启动服务，软件包的重新安装或更新可能会导致轻微的中断。这可能是一个糟糕的例子，因为句柄也可以用来确保没有中断。

在编写自动化代码时，请始终记住:

"我的代码是幂等的吗？"

知道何时以及何时不要自动化

编写自动化代码时，一半的战斗是知道什么应该自动化，什么不应该自动化。我的一般经验是在某个时候自动完成我要重复的任何事情，这在我的工作中是常有的事。

只为可重复的任务编写自动化似乎是显而易见的，但是编写自动化来构建只需要一次的东西呢？如果没有想清楚你为什么这么做，这可能是一件坏事，但也可能是完全有意义的。

“在花了那么多时间让您的自动化工作起来之后，您本可以自己手动安装系统，从而节省大量时间。”

这可能是你的经理在发现你为一个只会构建一次的东西编写代码时会对你说的典型的话。

您应该跟进的论点是，为什么自动化只会使用一次的东西是因为您正在从代码中构建资产，并且您正在为灾难事件中可能的重建做准备。

根据 Gartner 的调查，不进行自动化的组织的客户保持率可能会下降 25%。自动化正在各地迅速发展，如果您或您的组织落后了，您就有被竞争对手超越的风险。

为了充分理解什么时候自动化，什么时候不自动化，让我们看看支持和反对自动化的一些理由。

自动化的理由

今天，自动化应该是默认的；不过，如果你需要理由，这里有几个值得一提:

  • 可重复和可预测的构建

  • 基础设施作为代码

  • 代码作为文档

  • 节省时间和成本

  • 组织文化变革

  • 降低风险

  • 鼓励创新

不自动化的原因

今天很难想出不自动化任何东西的理由，但有时有理由，即使不是很好的理由:

  • 一个永远不会重复的任务。即便如此，也有理由实现自动化。

  • 组织尚未成熟到接受自动化。

  • 没有可用的技能或培训时间。

以上这些都不是很好的理由，只是我个人认为更多的借口。财产管理和财产建设的世界正在迅速变化，不应该选择自动化。作为 Linux 系统管理员，不管我们喜欢与否，我们的工作已经发生了变化。我们不再是 Linux 系统管理员，我们现在是自动化工程师。

状态管理

了解不同自动化平台的另一个非常重要的事情是它们管理系统状态的能力。一些平台仅在为特定任务执行代码时检查状态，而其他平台不断检查它们管理的系统的当前状态，以查看是否有任何改变。当检测到状态改变时，配置被更新以匹配自动化平台的期望状态。

Tip

使用基于期望状态不断检查系统状态的平台将确保您运行一个保持标准的环境。当不同的人可能会对系统进行可能导致系统中断的更改时，这非常有用。这种方法也将减少配置漂移的机会。

自动化工具

我们都同意自动化不会很快消失，为了不落后，了解您应该使用什么工具是很重要的。采用自动化实践将需要一套您需要学习的工具和开发语言；使用哪一种将需要您做出明智的决定。

在接下来的几页中，我们将讨论目前可供您使用的不同选项，并讨论它们的优缺点。

自动化脚本语言

在我们开始研究不同的工具之前，有必要了解可用于编写自动化代码的不同类型的自动化脚本语言:YAML、Ruby、Python 和 shell 脚本。

亚姆

“YAML 不是标记语言”是 Ansible 和 SaltStack 等自动化平台使用的主要语言。YAML 是最容易学习的脚本语言之一，因为大部分语法都很容易理解和记忆。

这些不是你要找的空间

YAML 因抱怨格式化而臭名昭著，当人们第一次学习用 YAML 编码时，格式化是一个令人烦恼的领域。缩进需要 100%正确，否则你的代码不会运行。

YAML 不喜欢使用制表符，只接受缩进的标准空格字符。大多数编辑器中的制表符被替换为相应数量的空格，以使这个过程看起来像使用了制表符值。

YAML 在行动

下面两个例子使用了流行的自动化平台 Ansible 和 SaltStack。两个示例提供了相同的结果，即安装“httpd”包。

安塞波
---
- name: "Build Linux Web server"
  hosts: webservers
  become: true

  tasks:
  - name: "Install latest apache httpd package"
    ansible.builtin.yum:
      name: httpd
      state: latest
盐堆
websetup:
   pkg:
      - installed
      - pkgs:
         - apache2

这些示例使用相似的格式，并且缩进方式非常相似。从这些例子中，逻辑很容易理解，也很容易操作来安装其他包。这些例子使用了提供的一个基本的包模块，但是还可以使用许多其他模块来做更多的事情。快速的谷歌搜索通常会让你找到最新的文档。

红宝石

Ruby 是一种高级通用编程语言，被设计成真正的面向对象语言。Ruby 在处理实例变量的方式上与 Perl 和 Python 类似。Ruby 将这些变量保持为类私有，只通过像“attr_writer”或“attr_reader”这样的访问器方法来公开它们

下面是 Ruby 代码的一个基本例子。除非你需要写一个新的函数或者类似的东西，否则你很少会为自动化任务写 Ruby 代码:

#!/usr/bin/ruby
def build(opt1 = "Linux", opt2 = "Windows")
   puts "The system that will be built is #{opt1}"
   puts "The system that will be built is  #{opt2}"
end
build

下面是一个木偶模块代码的例子。Puppet 包括两个用于编写定制函数的 Ruby APIs。puppet 模块的内容远不止以下这些，但为了让您对代码有一个基本的了解，我认为值得看一个示例:

class helloworld (
  $file_path = undef
){
  notify { "Hello world!": message => "I am in the ${environment} environment"}
  unless $file_path == undef {
    file{ $file_path :
      ensure    => file,
      content  => "I am in the ${environment} environment",
    }
  }
}

计算机编程语言

Python 以几种方式用于自动化任务。您可以使用 Python 编写自己的脚本，就像编写 Ruby 或任何其他脚本语言一样。然而，Python 倾向于主要用于 Ansible 和 SaltStack 之类的模块或函数。下面是一些基本 Python 代码的片段。

# Python Module example
def add(x, y):
   """This application returns the result of x + y"""

   result = x + y
   return result

print("The value of my python function is", add(3,4))

Shell 脚本

Shell 脚本可以用于自动化，但不推荐使用，主要是因为其他自动化语言和工具有如此丰富的模块，可以通过它们的 API 连接到大多数平台。

默认情况下，Shell 脚本作为一种幂等脚本语言并不能很好地工作。实现幂等性意味着相当多的额外编码。

Note

如今，通常编写的大多数自动化代码都是针对 Ansible 和 SaltStack 等平台的 YAML。其他变体是 Ruby 类型的木偶和厨师代码。埋头写 Ruby 或 Python 模块并不常见。

自动化平台

有了自动化脚本语言的基本概念后，现在有必要讨论一下您可以使用的一些自动化工具，这些工具利用了前面讨论过的脚本语言。

财产管理工具的自动化

在第四章中，我们谈到了 Linux 平台管理工具，我提到了一些内置的自动化工具。过去，在大多数情况下，自动化设施未能提供足够的功能，因此不能被视为完全的自动化平台。现在有例外，更新的管理工具，如 Uyuni，包括使用 SaltStack。SaltStack 的多少功能还有待测试。

然而，要解决像 Red Hat Satellite 这样的遗产管理工具可能缺少自动化功能的问题，建议您考虑使用一个自动化平台，专门管理您所有的遗产自动化需求。这些平台应该包括所有的功能，让你完全自动化你的遗产。

使用理由

  • 已经到位

  • 没有其他工具的预算

  • 技能已经到位

  • 节省时间

  • 有一个很好的集成自动化工具，有足够的特性可以开始使用

不使用的理由

  • 有限的功能

  • 增加了复杂性

  • 要求与 RBAC 分离

Ansible 自动化平台

Ansible 毫无疑问是市场领先的自动化工具的有力证明，至少在我写这本书的时候是这样。Ansible 在过去几年的发展令人印象深刻，每天都受到越来越多的用户和组织的欢迎。社区的发展和供应商们为 Ansible 创建模块的广泛采用继续证明了为什么许多人选择 Ansible 作为自动化工具的选择。

不去预测未来，我坚信 Ansible 还会存在一段时间。我这样说的原因有几个:

  1. 2015 年 10 月收购 Ansible 的红帽完全支持 Ansible 及其开发。每时每刻都在不断改进，显然他们对未来有着宏伟的计划。

  2. Ansible 的学习曲线比同一领域的其他产品要宽容得多。人们只是更喜欢用一些不需要硕士学位就能理解的东西。

  3. 随着越来越多的供应商不断提供新的模块，社区的采用几乎与日俱增。

无代理

Ansible 不需要任何代理来管理其客户端系统。在基于 Linux 或 Unix 的系统上，通过 ssh 与客户端系统建立连接；如果连接到 Windows 系统，则通过 WinRM 建立连接。可以通过在执行 Ansible 时输入系统密码或使用 ssh 密钥来进行身份验证。大多数 Linux 系统管理员倾向于使用 ssh 选项，主要是因为到 Linux 或 Unix 系统的连接是无缝的，不会提示输入密码。如果您在一百个系统上运行剧本，这可能是一个大麻烦。

如果 ssh 密钥不可行，那么可以使用其他选项，但是这需要所有系统在一个中心位置进行身份验证。否则你将不得不为不同的系统输入不同的密码。

潜在的安全漏洞

如果 ssh 密钥没有得到正确的管理，那么 Ansible 环境中的资产可能会存在一个很大的安全漏洞。例如，如果一个 Linux sysadmin 在他们的系统上有 ssh 密钥，可以访问资产中的任何系统，那么如果有人未经授权访问他们的系统，就有可能出现大问题。因此，需要非常小心地确保该系统的安全性。例如，使用系统库可以降低这种风险。

使用 Ansible

Ansible 有企业版和社区版。企业和社区产品都有两种可以安装的 Ansible。有可以使用的图形界面和命令行版本。

命令行

在第二章中，我们简要讨论了如何安装和使用 Ansible 命令行工具。我们讨论了与通过 pip 安装相比，使用像 Yum 这样的包管理系统安装有哪些额外的好处。我们还讨论了如何运行一些基本命令。

Ansible 命令行通常被称为 Ansible Core，但是命名可能会改变，如果还没有改变的话。Red Hat 一直在努力让 Ansible 变得更好，并一直在研究如何使用 Ansible 或将其与其他产品集成；出于这个原因，名称可能会改变以适应使用。

有一点要记住:如果你选择只使用 Ansible 的命令行版本，从功能的角度来看，使用社区版还是企业版并没有太大的关系。据我所知，这两种产品的功能是一样的。如果你需要帮助，最大的问题是支持。

Recommendation

使用 Ansible 的图形化工具是推荐的方法，主要是因为您在功能上不容易用命令行工具复制。

图形用户界面

Ansible 吸引新用户的似乎是可以与 Ansible 自动化平台一起使用的图形用户界面。和任何流行的东西一样，开发人员关注用例并根据需求进行调整。因此，Ansible 的新版本更有可能是由图形工具驱动的，而不是命令行。因此，当前的 Ansible Tower 工具是第一次学习 Ansible 时推荐的方法。

使用 Ansible 的理由

  • 易于学习和入门

  • 拥有大量可用代码资源的不断增长的社区

  • 优秀的文档和示例

  • 能够管理任何可以打开远程连接的内容

  • 灵活的

  • 可攀登的

  • 企业支持

  • 正在开发的新功能可能无法在 AWX 上市

不使用 Ansible 的理由

  • 如果你不需要企业级产品，这个可能不适合你。

  • 如果您用很少的预算监控数千个系统，Ansible Tower 许可费用可能会很高。

  • 如果您要管理的系统数量较少，则可能不需要。

  • SSH 密钥安全相关问题。

  • 在执行任务之前缺乏对系统状态的了解。

经编毛圈提花布

红帽收购 Ansible 的时候，Ansible Tower 还没有开源。为了纠正这一点，Red Hat 开发人员和工程师尽快开发了开源的 Ansible Tower。由此产生的产品是 AWX 项目。

除了一些企业功能外，AWX 几乎与它的企业对等物(Ansible Tower)相同。一个例子是基于角色的认证已经从社区版本中排除。如果用户需要这些功能，他们需要购买一个 Ansible Tower 许可证。

使用 AWX 的理由

  • 易于学习和入门

  • 拥有大量可用代码资源的不断增长的社区

  • 优秀的文档和示例

  • 能够管理任何可以打开远程连接的内容

  • 免费的社区产品

  • 灵活的

不使用 AWX 的理由

  • 如果您需要企业功能，您将需要考虑 Ansible 自动化平台或其他产品。

  • 在 AWX 上做的测试和工作比在安塞布尔塔上做的要少。

  • 不建议用于生产环境。

  • 并不是 AWX 所有的安全设施都像安西布尔塔一样通过了安全检查。

  • 不支持版本之间的直接就地升级。

  • SSH 密钥安全相关问题。

  • 在执行任务之前缺乏对系统状态的了解。

盐堆

另一个可以使用的基于 python 的配置管理工具是 SaltStack。SaltStack 有社区版本和企业支持版本。

服务器到客户端的通信

与 Ansible 不同，SaltStack 可以配置为在连接到它管理的系统时以几种方式运行:

  • 直接 SSH

  • 代理和服务器

  • 只有代理，没有管理服务器

远程执行

与 Ansible 连接到系统并运行特定命令的方式类似，SaltStack 能够执行远程执行命令。这种功能与卫星服务器目前的功能和太空行走服务器过去的功能非常相似。

结构管理

SaltStack 在配置管理方面比过去更传统一些。在 SaltStack 主服务器上管理配置，并将其推送到已更改或需要更新配置的系统。SaltStack 主系统通过了解系统需要的状态和主系统正在监控的附属系统上已经触发的事件来控制其管理的客户端(附属系统)的状态。如果有任何不应该更改的内容，盐栈主服务器会恢复未经授权的更改。

使用消息总线

Salt 使用了不同于其他产品的方法，因为它使用了消息总线 ZeroMQ。当客户端系统或附属程序触发事件时，会在消息总线上创建一条消息，供主服务器在准备就绪时执行。这种使用消息总线的方法允许一个主机管理大量的系统。

使用 SaltStack 的理由

  • 不那么陡峭的学习曲线。

  • 模块化方法。

  • 非常灵活。

  • 可扩展。

  • 在规模上表现良好。数以千计的奴才可以同时管理，效率相当高。

  • 事件驱动的配置管理。

  • 比其他产品更安全。

  • 功能丰富。

不使用盐堆的理由

  • 由于较慢的发布周期，它可能不适合快速移动的环境。

  • 过去曾有过模块不能管理自己的依赖关系的问题。要求用户运行单独的虚拟环境。

  • 不是对非 Linux 系统最好的支持。

  • 安装和配置可能更具挑战性。

  • 文档可能难以理解和使用。

木偶

Puppet 是一个基于 Ruby 的配置管理系统，在引入 Ansible 之前使用得比较多。

红帽和木偶

Satellite 6.x 首先使用 Puppet 进行配置管理，但后来引入了使用 Ansible 的选项。puppet 还没有被移除，对于那些投入大量时间开发 Puppet 模块的用户来说仍然可用，但是不应该想当然地认为 Puppet 在 Satellite 中的可用性会永远存在。

基于服务器代理

Puppet 需要一个傀儡主人来管理它所管理的所有系统的状态。所有的客户端都需要有一个代理运行，以检查傀儡主人。

潜在的低采用率

像 Ansible 和 SaltStack 这样的产品为用户带来了不太陡峭的学习曲线，并对像 Puppet 和 Chef 这样的产品构成了强大的威胁。更糟糕的是，Red Hat 已经开始在尽可能多的产品中引入 Ansible，以进一步推动 Ansible 的普及。SaltStack 也包含在 SUSE 和 Ubuntu 使用的新版太空行走克隆中。这些发行版和它们各自的管理软件的流行对 Puppet 来说不是好兆头。

企业和社区

Puppet 有社区和企业两个版本，可以满足所有用户的需求。企业支持适用于出于合规性或法规原因需要支持协议的企业组织，也有适用于不需要支持的用户的社区版本。

使用木偶的理由

  • 基于状态的配置管理。客户端不断地向 Puppet masters 登记配置更改。

  • 出色的社区支持。现成的示例代码。

  • 安装是无痛和简单的。

  • 几乎可以在所有操作系统上运行。

  • 幂等平台。

不使用木偶的理由

  • Ruby 支持在下降。

  • 基于 Ruby 的命令行界面。

  • 陡峭的学习曲线开发定制木偶模块。

  • 代码可能很复杂，令人费解。

  • 比其他产品更少的控制。

厨师

大概 Puppet 后面配置管理使用最广泛的产品之一就是 Chef 了。Chef 是一个类似 Puppet 的基于 Ruby 的产品，在服务器代理架构中工作。Chef 最初是专有组件和开源组件的混合体；然而，自 2019 年 4 月以来，Chef 宣布他们将开放 Chef 的所有资源。忠于他们的工作，今天在撰写本文时，Chef 有一个社区版本的配置管理工具可供下载和使用。

使用 Chef 的方法

Chef 目前有三种方式供用户使用他们的自动化平台。

托管服务

Chef 为不希望构建任何内部系统的组织或小型企业提供托管服务。任何托管服务都会涉及额外的成本。

内部部署

对于拥有封闭网络或希望完全从内部管理其资产的组织，Chef 确实提供了自行下载和安装基础架构的能力。如果您需要支持，则需要额外的成本，并且定价模式已经从系统价格转变为每月管理的每个节点的价格。

社区

由于 Chef 现在是开源的，Chef 的社区开源版本可供下载和使用，但带有不支持的标准警告。

使用 Chef 的理由

  • 与 Git 的良好集成

  • 网上有大量的社区模块和食谱

  • 灵活的

  • 减少安装复杂性的可用工具

  • 类似 Puppet 的基于状态的配置管理

不使用 Chef 的理由

  • Ruby 支持在下降。

  • 新用户的陡峭学习曲线。

  • 没有推送功能。

  • 文档不如其他产品好。

  • 如果使用大型资产，企业支持和内部成本可能会增加。

  • 不适合拥有小房产的组织。

做决定

如果您是自动化的新手，决定使用什么自动化工具可能会很困难。以下是一些你可以用来做出正确决定的建议。

市场趋势

观察市场或竞争对手的当前趋势可以帮助你做出更明智的决定。我并不主张你从众，不管是好是坏，我建议你看看什么对别人有用，什么没用。市场趋势不会告诉您在设置环境方面付出了多少努力，也不会向您展示投资回报，但它确实会让您更好地了解一种产品是否比另一种产品使用得更多。你最不想做的事情就是把时间投入到将在 6-12 个月内被取代的东西上。

亲自看

如果你不确定哪个产品适合你，我建议你自己安装和测试每个平台。我的建议是采用一个简单的用例，比如构建一个 web 服务器。不是安装操作系统，而是简单地安装和启动服务，将系统变成 web 服务器。这些任务很简单，应该很容易在每个不同产品的官方文档中找到。这种方法可以让你看到产品之间的比较。然后你可以比较一些东西，比如

  • 文件。

  • 平台安装起来有多容易？

  • 编写和运行的代码有多简单？

  • 入门的学习曲线有多陡？

这些要点将有助于您向组织的持有人展示您的发现，并证明在试用不同产品上花费的时间是合理的。

企业对社区对成本

您需要企业产品还是可以使用社区产品？对于一些组织来说，这个问题通常会在提出这个问题后的几毫秒内得到回答，这主要是由于法规遵从性要求或其他类似原因。无论使用哪种产品的原因是什么，还有一个非常重要的方面需要考虑。

产品将带来的真实成本。这并不总是来自供应商的许可或订阅成本，而是使平台对您的组织有效的努力成本。许多人被基于好例子和预构建用例的供应商出售产品。这些供应商可能会忽略解释所需的培训或让所有东西都处于可用状态所需的时间。这可能会误导新用户，让他们认为平台是开箱即用的，几乎总是以平台未被使用而告终。当您花费时间测试和试用产品时，请确保您考虑了使您的组织能够尽可能有效地使用产品所需的努力。

产品寿命周期

关于产品的路线图信息几乎和产品本身一样重要。该产品可以提供所有最强大的功能，并且看起来非常吸引人，但是如果您选择的产品只有很短的生命周期，并且不会有任何新版本发布，那么您就是在浪费您的时间，甚至可能是您组织的金钱。在承诺任何产品之前，确保路线图看起来是健康的。

借助管理工具实现自动化

为了更好地使用各种管理工具附带的自动化工具，让我们讨论一下您可以做些什么来改进您的资产管理。

国家管理

您希望自动化平台或遗产管理工具提供的一个非常重要的功能是保持遗产状态可控的能力。您希望配置您的资产管理或自动化平台工具，以监控和纠正可能出现的任何配置偏差。无论是出于意外还是恶意，您都希望确保下次系统重启时不会出现令人讨厌的意外。控制所有系统的状态将确保您的系统完全按照首次构建和测试时的状态运行。这对于进一步减少消防工作至关重要。

企业产品

不幸的是，提供最佳标准操作环境配置功能的资产管理工具通常是企业产品。Red Hat 的“卫星服务器”产品或 SUSE 的“SUSE 管理器”产品是当今 Linux 产业的最佳选择之一。两者都将包括木偶或盐栈。这些产品非常适合让您管理您的资产中系统的“状态”。它们的实现非常不同，需要一些提升技能的时间。不过积极的一面是文档非常好，而且由于您是付费服务，如果您需要任何帮助，也可以获得支持。在某种程度上，大多数支持公司都会尽力提供帮助。企业支持并不意味着供应商将免费提供专业服务，但他们会尽最大努力让您满意。最终，你是在为一个产品买单，你继续使用它符合他们的利益。

用例示例

要理解为什么使用某物很重要，看一个例子通常会有帮助。这是一个标准操作环境可以防止以后出现重大问题的基本示例。

平台工具

在本例中，我们使用的是 Red Hat 资产管理工具“Satellite server 6.x”。这是 Red Hat 正在开发的卫星系统的最新版本。如果您愿意，这个示例也可以使用 SaltStack。只需在您的脑海中相应地调整命名和功能。

平台工具配置

Red Hat Satellite 6 能够用特定的 Puppet 模块配置内容视图。这些模块可以进一步增强智能参数，帮助管理您的资产配置。

在这个例子中，一个主要的 Linux sysadmin 非常聪明地包含了一个 puppet 模块，它控制资产的标准 ssh_config 文件的配置。这使得整个资产以这样一种方式配置，即任何人都不能以 root 用户身份登录。

庄园中的所有系统都被配置为运行傀儡代理，这些代理定期向傀儡主人报告。

错误

这个用例有趣的地方是当一个简单的错误发生时。

一个新的 Linux sysadmin 被分配了一项任务，在资产中的一个预生产系统上调试登录问题。在调试过程中，ssh_config 文件中偶然出现了一个简单的打字错误。不幸的是，如果输入错误，可能会导致 sshd 服务在重启时失败。由于 Linux sysadmin 不知道 ssh_config 文件的这一变化，他们不会重启任何服务，因为他们不相信有任何变化。他们为什么要重启服务，尤其是如果他们不想引起任何不必要的停机，不管停机的程度有多小。

躺在阴影中等待

如果不选中，Linux sysadmin 所做的不需要的更改将在下一个维护窗口中应用。通常，在这些维护窗口期间，通常会应用更新或补丁。在大多数情况下，系统会重新启动。由于这个以前未被发现的错别字隐藏在阴影中等待着，因此在这个阶段，当时沉睡的问题将被唤醒，抬起它丑陋的头。如果在系统重新启动之前没有采取任何措施来纠正这个问题，那么 ssh 守护进程在重新启动之后将处于失效状态，不允许任何人通过 ssh 登录。

安全网

由于组织足够聪明，有一个配置管理工具来监听不需要的配置更改，所以系统管理员的输入错误从来没有成为问题。

在 Linux sysadmin 输入错误后不久，受害者系统的本地 Puppet 代理在 Red Hat Satellite 服务器上向 Puppet master 登记，并将配置恢复到为环境配置 Puppet 时被认为是正确的配置。

如果没有安全网，一个简单的错误(如打字错误)可能会导致问题产生后可能发生的任何停机的调试延迟。如果这是一个生产系统，并且由于草率的工作而导致停机时间延长，那么对于不幸的 Linux 系统管理员来说，可能会有更大的影响。

是的，这个例子有办法通过登录到一个控制台来解决这个问题，但是如果这个配置比 grub 配置更严重呢？这意味着系统在预定的重新启动后可能没有启动，这实际上造成了一个本不应该出现的问题。

建立一个国有企业

为了避免与所解释的用例类似的问题，管理资产配置状态是至关重要的。要配置成功的 SOE 平台，您需要确保按照良好实践配置您的资产管理工具。这需要适当的计划、准备，在某些情况下还需要组织文化的改变。

根据标准构建

要构建将由 SOE 环境管理的系统，您需要确保做到以下几点:

  • 从标准系统构建模板/映像或 kickstart 文件构建。

  • 新系统应该构建有所有必需的代理或服务，以便将新系统注册到您的配置管理平台。

  • 确保您的系统注册到正确的环境中，并让配置管理将配置保持一致。

  • 更新了配置漂移，以反映配置的当前状态。这样，如果有任何变化，您将有一个事件日志。

源代码管理

任何管理遗产的代码都应该经过适当的代码开发过程。这意味着应该发生以下情况:

  • 任何自动化的所有代码都应该存储在一个源代码控制平台中，比如 Git。

  • 所有代码都应该通过林挺系统来检查基本的格式和语法问题。

  • 应该通过拉请求或合并请求来完成更改。

  • 两个不同的人应该参与代码评审。

  • 如果没有经过分阶段的测试过程，就不应该将代码推入生产环境。

分阶段测试

分阶段测试是在进入生产环境之前，通过不同的环境测试您的自动化和配置管理的过程。该方法应该类似于以下内容。

代码开发

  • 在沙盒环境中开发和测试的代码。

  • 应该为新的配置管理制定一个测试计划，解释配置更改的情况以及如何对其进行验证。

代码测试和同行评审

  • 新代码被提交到一个本地 Git 存储库，该存储库具有 webhooks 或类似的管道工具，该工具运行基本的限制或语法测试。如果代码通过了测试，那么只有在那时才会打开一个新的合并或拉取请求以供同行评审。

  • 第二个人应该对代码进行同行评审，并批准任何合并或拉取请求。

代码升级

  • 然后，代码可以被提升到第一个现场测试环境中。通常，这是一个开发环境或类似的环境。请记住，开发环境仍然是活跃的，因为它们上面有用户，所以建议谨慎。如果可能，避免理想情况下不能有停机时间的环境。

  • 现在应该遵循设定的测试计划，以确保没有任何东西被破坏或导致任何问题。

  • 如果一切都如预期的那样工作，并且变更已经被签署为成功的，那么将代码提升到您的下一个环境中。

自动化自动化

一旦您有了您的自动化平台，并且您熟悉自动化实践，您将想要开始发展您的实践，以包括更多的自动化途径。

自愈

让您的平台完全自动化是一个了不起的成就，任何 Linux 系统管理员都应该为此感到骄傲。采取下一步措施会把你的价值提升到一个全新的水平。

构建一个在灾难来袭时能够自我修复的平台是所有 Linux 系统管理员应该开始做的下一个主要进步。在过去，让您的平台能够识别系统故障并应用解决方案，而无需动动手指，这只有科幻电影才能做到。今天，您可以使用一系列工具或自行开发的技术来实现这一点。

自我修复层

有几个层次可以发生自愈。有一个硬件层，“平台”层，最后是应用层。

每一层都有自己的失败区域和自己的恢复方法。如果我们从底层开始，我们来看看硬件层。

消除所有单点故障

如果没有冗余，硬件可能很难自我修复。如果一个物理磁盘或主板出现故障，如果没有备用系统可供故障转移，再多的自动化或智能工具也救不了你。你总是做的第一件事是查看你的单点失败。因此，您需要为您的资产中运行的所有东西准备备份硬件。听起来很贵，对吧？是的，但是您倾向于只为无法承受停机时间的组织进行这种级别的智能资产恢复。

Ken’s Law 1

如果因停机而损失的金额超过了冗余硬件的成本，那么金钱就不应该是一个考虑因素。

硬件层自我修复

大多数组织不在一套硬件设备上运行，或者至少不应该在一套硬件设备上运行。通常有第二个或第三个设备可供故障切换使用。

巧妙之处在于如何识别硬件故障，以及如何从故障硬件切换到健康硬件。

您需要聪明的逻辑，这需要关注平台监控和日志工具。这些工具可以让您的自我修复平台关注警报、事件和日志。不仅所有硬件都应该报告其自身组件的健康状况，硬件还应该寻找与它最接近的硬件的性能线索。

在硬件故障的情况下，自我修复系统应该有自动化的决策点来运行特定的操作。在发生完全未知的情况时，应该触发故障安全选项，这可能很简单，只需标记重大事故并让人员参与即可。从这些事件中吸取教训，会让你的平台得到提升，所以在你还在完善平台的时候，不要心灰意冷。不可能预测每一种可能的情况。

硬件自动化修复的基本流程应该如下所示。

报告

  1. 监控和日志记录系统应该接收到硬件未签入的事件。

  2. 可疑的硬件故障也应通知财产管理工具。

确保平台可用性

  1. 故障转移应该自动发生，以确保停机时间有限或没有停机时间。

  2. 如果故障转移失败，该过程将会中断。重大事件要提出来，要有人叫出来。

自动恢复

  1. 一旦发生故障转移，就可以开始自动恢复。

  2. 应触发自动调查的第一轮。也就是说，离系统最近的任何其他硬件可以到达故障系统吗？

  3. 如果已确定硬件出现故障，则应开始第一次尝试恢复。这可能是访问控制硬件的电源管理 API，并执行冷重启以查看硬件是否恢复。

  4. 经过一段时间后，应触发第二轮调查，以查看故障硬件是否已开始响应。

  5. 如果硬件已经恢复，应该运行一整套自动化测试来确认系统的健康状况。如果通过，平台可以回切到之前怀疑的硬件故障。

  6. 如果硬件仍然没有响应，则逻辑应该做出决定，要么通过关闭当前硬件并从备用硬件供应新系统来废弃当前硬件，要么重建故障系统。

    1. 如果选择重建当前系统，则需要进行一项检查，以确定重启后是否可以通过网络启动选项访问失效的硬件。如果可以通过网络引导访问系统，则可以开始自动重建过程。

    2. 如果决定废弃故障硬件，自动自愈平台将需要联系电源管理 API 并引导备用硬件。需要完成操作系统的网络构建，然后按照资产配置进行配置，以使系统恢复在线工作负载。

  7. 无论从步骤 6 中选择哪个选项，恢复的系统都需要重新加入任何群集，并将系统标记为可进行回切。

平台层自我修复

鉴于硬件自我修复的复杂性，您可能不会惊讶于平台层往往具有一定程度的自我修复能力。“平台”通常是编排层，如 OpenShift 或 Tanzu(如果您使用容器),或者是虚拟化平台，如 VMware 或 Red Hat 虚拟化。这些平台旨在通过允许工作负载从停止响应的节点进行故障转移，自然确保工作负载继续工作。这与负载平衡器和冗余网络相结合，应该允许平台保持相当的弹性。

这是这些平台自我修复的终点。让整个平台恢复正常工作取决于您聪明的资产自我修复逻辑。在硬件自我修复部分，我们谈到了将硬件重新加入集群。这就是你的智能逻辑发挥作用的地方。与硬件自我修复一样，应该有一系列自动执行的步骤来确保平台自我修复:

  1. 检查硬件可用性。应当有可供使用的系统的记录。这是您的重建系统或新建系统应该报告它们可用的地方。对于熟悉 OpenStack 的人来说，这就像一个报告可用性状态的裸机服务器列表。

  2. 移除故障系统。在添加新硬件之前，应将标记为失效的系统从集群中删除，并完成所有清理工作。

  3. 添加到集群。然后，应该将可用系统配置为新的节点或主机。配置应该包括将系统添加到集群并测试工作负载。如果全部通过，可以在节点或主机上重新安排工作负载。

应用层自我修复

应用程序的自我修复通常应该由承载应用程序的应用服务器来完成，但是如果您更多地考虑应用程序的内部工作方式，也可以完成额外的自我修复。

可以通过自动化来控制应用程序数据健康或数据库连接的改善。如果数据库服务器变得不可用，可以进行重建并复制数据库。有相当多的事情可以做，但理想情况下，如果您的应用程序足够简单，所有需要做的就是重新部署和重定向流量。

对于更复杂的应用程序，开发人员需要内置应用程序从故障中恢复的功能。这个问题最好留给开发者。

何时自愈

构建您的自动化和自我修复平台应该基于您希望自我修复何时发生。您是希望只在出现故障时才注意，还是希望观察问题内在的迹象？

你想主动还是被动？

我相信你会同意，在问题变成更大的问题之前抓住它要好得多。通过积极主动，您可以让您的自我修复系统以一种更少干扰的方式解决问题。这可以让您的一个或多个系统正常关闭并重建。当流量减少时，可以安排故障转移，然后可以优雅地而不是强制地排空节点。通过允许以受控的方式进行重建，可以安排停机来适应组织过程，如适当的变更控制。有了这个流程，一切都可以自动化，包括获得平台变更批准的管理工作。

如何实现自我修复

从理论上讲，谈论自我修复是很简单的，但是你如何为你的产业实施这样的解决方案呢？为了充分讨论自我修复技术并做到公正，我们肯定需要另一本完整的书。但是，让我们简单地看一下如何从一些面包屑开始，以便进一步研究。

盖茨

就像你需要闸门来控制运河中的水流一样，你也需要闸门来控制你的自我修复环境。这些门应该是验证刚刚发生的事情的停止点。如果没有首先检查一个简单的解决方案，您不会想要开始一个冗长的补救过程。也就是说，重启有效吗？

Gates 也不一定是技术配置。一个高度监管的组织可能不希望聪明的逻辑在未经批准的情况下重建系统。为此，您可以引入一个变更控制门。主动自我修复平台可以识别潜在问题并提出变更请求。如果变更请求获得批准，补救措施将在规定的变更窗口内继续进行。

另一个有用的方法是，在故障系统重建后，在故障流量返回之前暂停，以防未检测到潜在问题。

一般来说，在开发自我修复平台时，门应该是您首先要构建的东西。当你证明你的逻辑有效时，把它们看作是诊断停止。

工具:自动化和状态管理

使用状态管理工具和自动化平台的组合，您应该能够将足够的逻辑串联起来，进行一些有趣的自我修复。您将需要解决如何解析日志中的重要信息。拥有一个像 Splunk 这样不断被清理的日志收集系统将允许您建立一个潜在问题的数据库。如果您的自我修复逻辑与任何可能的问题相匹配，那么您可以向消息总线报告问题。然后，您的自我修复资产的另一大部分可以监控消息总线，寻找需要自我修复作业运行的不同类型的作业。

一起运行的配置和应用程序可能会很快变得过于复杂。在开始构建之前，花足够的时间来设计您的方法，看看这是否是您的最佳选择。

机器学习

开发你自己的自我修复平台的另一种方法是教它理解在特定条件下该做什么。为此，你需要建立一个场景的神经网络。这可能包括查看日志、警报和事件。然后，您的自我修复逻辑应该权衡与触发一系列自动化任务的条件相匹配的数据的百分比。然后可以从资产管理工具和自动化平台运行任务。目前可用的大多数工具还能够与服务台平台集成以提出事件，甚至能够启动与备用工程师的通信。

然而，机器学习是一个陡峭的学习曲线，需要一定的资质才能掌握。如果这是你感兴趣的东西，花些时间玩几个基本的例子，然后从那里开始。互联网是一个学习的好地方，到处都是你可以尝试的好例子。

关于开始机器学习的一个重要注意事项是，你将需要一些庞大的数字处理硬件来编译你的机器学习程序。如果你有幸拥有一个不错的 GPU，你可以从它开始。添加更多的 GPU 将减少你的编译时间，但随着 GPU 的普遍短缺，你可能会面临一场艰苦的斗争。

Tip

不要害怕二手硬件；当你开始使用时，使用别人不喜欢的旧硬件可能仍然会对你有所帮助，也会为你节省一些钱。

现成的产品

如果您有预算，但没有时间或耐心来构建自己的平台，您可以考虑一些“现成的”选项。

这些产品可以提供相当多的功能，但可能无法满足您的所有需求。请密切注意开箱即用的内容以及您自己需要配置的内容。它可能是一个美化了的自动化引擎，仍然需要你写逻辑，或者更糟。购买一些组织的专业服务来为你构建逻辑。

动态跟踪

我过去听说过的一种产品是 Dynatrace。我对该产品知之甚少，因为我以前从未使用过它，也不会根据我所知提出任何建议，所以我将让您自己研究和检查。我只记得 Dynatrace，因为几年前我参加了波士顿红帽峰会的一次演讲。

在演示过程中，演示者解释了他们如何使用 Dynatrace 来管理自己的资产，而在演示过程中，他们的一台 web 服务器发生了中断(可能是故意为之)。Dynatrace 平台基本上启动并开始运行其诊断和潜在的补救工作。然而，它确实通知了演示者有问题，我想任何监控平台都可以这样做。

我得到的印象是，Dynatrace 可以做一些聪明的事情，可能是一个很好的选择。就像我提到的，在开始之前做好自己的检查和测试。

自动化最佳实践

说到房产自动化，最终没有一份你可以遵循的最佳实践清单。在这方面，最好的建议是了解您决定使用的自动化平台的所有最佳实践。熟悉配置文件的位置以及应该如何配置它们。

不要再重复发明轮子了…

这是一个很多人都失败的领域，我相信你已经厌倦了我提到它，因为我已经说过至少几次了。这是很多人一直在做的事情，包括我自己，所以我希望在这本书结束时，通过一直提到它，它会如此深入你的内心，以至于你再也不会尝试重新发明任何东西。

永远不要试图从头开始开发任何东西，尤其是如果你能从网上得到与你想要的东西相似或不相同的东西。真的没有理由花时间在已经存在的东西上。尽一切办法，获取代码并调整它以适应您想要做的事情，但不要每次都从头开始开发。我知道有时候写一个角色或者木偶模块可能会更快，但是要诚实地问自己。

“这要写多久？”

如果答案超过五分钟，你就知道你在不必要的地方花了时间。您最好花额外的时间来测试和完善您的平台配置。

代码库

大多数(如果不是所有的话)主要自动化平台都有大量的在线示例和代码库可供下载。如果您的第一步是决定使用哪个自动化平台，那么您的下一步应该是找到等价的在线代码或模块库。

安塞波

在神秘世界里，你可以利用神秘星系。Ansible Galaxy 有大量不同的 Ansible 角色，你可以通过人们与它们相关联的标签来搜索和使用。

https://galaxy.ansible.com/

木偶

和 Ansible 一样，Puppet 也有一个很棒的类似 Ansible Galaxy 的库，叫做 Puppet Forge。

https://forge.puppet.com/

盐堆

SaltStack 没有完全相同的设置，但是有一个名为 SaltStack formulas 的 GitHub 位置，里面有大量的内容。

https://github.com/saltstack-formulas

Note

Ansible 是我个人的选择；这就是为什么我经常用它作为例子。我尽量不直接推荐任何东西，因为我想避免偏向某个特定的供应商或产品。始终根据明智的意见做出自己的决定。

[计]元数据

一旦你有机会向你选择追随的社区贡献代码，确保你了解如何格式化和构建你的代码，以便正确的元数据可以用于编目你的工作。没有什么比提供没人能找到或使用的代码更令人沮丧的了。

使用您选择的提供商提供的示例可以帮助您入门。下载一个示例，并从那里“借用”代码。

要避免的事情

无论您决定使用什么平台，自动化时都要避免一些事情。

Shell 脚本

如果可能，使用您选择的自动化工具提供的模块和代码。例如，Ansible 有丰富的 Ansible 模块库。不是所有的东西都是默认安装的，但是可以和 Ansible 集合一起安装。类似的方法也可用于其他平台。在使用 shell 脚本之前，一定要研究运行任务的最佳方式。

Shell 脚本往往是非等幂的，需要更多的代码来确保它们是等幂的。使用一个与平台 API 或类似的东西对话的预构建模块将为您处理所有额外的编码，并留给您整洁干净的代码。

不需要时重新启动服务

如果您的自动化代码有一个服务重启任务，千万不要为了重启而重启。使用控制代码检查服务是否确实需要重新启动。即使这可能是服务的轻微下降，但如果配置不正确，它会带来风险。一些服务可能会拒绝启动，最终导致停机。

使用旧版本

这似乎是显而易见的，但是请确保您使用的是您所选择的自动化工具的最新版本。如果您编写的代码将被弃用，文档可能不会总是更新。

正确版本文档

阅读最新的文档，或者至少是与您正在使用的自动化工具版本相匹配的文档。代码变更和模块被弃用，所以当您以后需要重构代码时，遵循旧的示例或旧的知识库文章会让您受到阻碍。

良好做法

因为在编写自动化代码时，有些事情你应该避免，所以在你的工作方法中也应该包含一些好的实践。

排除故障

记住删除添加到代码中的额外调试步骤或任务。当你测试和开发你的代码时，它可能是有用的，但是在生产中使用时，它可能看起来不整洁。这也可能会让你遇到一些不必要的问题，这些问题来自那些不理解为什么在执行你的自动化任务时到处都有红线的人。

不要忘记自述文件

当你不是独自工作时，记录你的代码供他人使用是非常重要的。自动化的全部意义在于节省时间；花时间向别人解释如何使用你的代码是违反直觉的。当您通过不同的共享门户在线共享代码时，这也是非常值得推荐的。开始时就习惯做，是继续做下去的最好方法。

源代码管理

将你的代码提交给 GitHub/GitLab 或者任何你喜欢的 git 提供者，但是要经常这样做，并且总是在你一天停止工作之前。你的代码不仅是安全的，而且允许你建立一个作品集供他人使用。

摘要

在本章中，我们讨论了以下内容:

  • 该理论围绕着自动化，什么时候自动化，什么时候不自动化。

  • 开发幂等的代码意味着什么。

  • 当今可用的各种自动化平台。为什么你会用它们，为什么你不会用它们。

  • 什么是标准操作环境，以及如何将您的资产配置为标准操作环境。

  • 如何配置硬件、系统平台和应用程序进行自我修复。

  • 自动化最佳实践和应该避免的事情。

六、容器

这一章与前几章的方向略有不同。这将是我们讨论组织工作量以及如何管理该工作量的第一章。之前，我们讨论了平台、自动化和一般的 Linux 系统管理。在这一章的最后，我们将会更多地讨论平台，但是将会围绕本章的主题:容器展开。

本章将深入探讨集装箱化的世界，以及如何在其中管理工作负载。我们将讨论什么是容器，你如何开始使用它们，你应该做什么来管理它们，以及应该做什么和不应该做什么。最后，我们将结束这一章，讲述如何使用当今可用的工具来管理集装箱的全部资产。

本章的目标是帮助您对容器和用于管理它们的编排工具有一个基本的了解。

入门指南

作为一名 Linux 系统管理员，您很可能已经听说过容器；您可能已经在您的组织中使用它们了。

容器是 Linux 产业的下一个重大发展。作为一名 Linux 系统管理员，您必须完全了解它们是什么，它们是如何构建的，最重要的是，它们是如何管理的。

简而言之，容器是在它自己的隔离环境中管理的一个或多个进程和文件的集合。

虚拟机与容器

虚拟机是一个完整的操作系统，拥有自己的文件和资源，而容器是操作系统的一个独立部分，不仅拥有自己的二进制文件和文件，还与其主机操作系统共享库和二进制文件。容器是在被称为容器运行时的系统层之上创建和运行的(图 6-1 )。

图 6-1

演示虚拟机和容器所需的不同层

虚拟机和容器的区别如图 6-1 所示。

集装箱历史

容器的概念根本不是一个新概念，这个概念比 Linux 本身存在的时间还要长。容器在 20 世纪 70 年代末和 80 年代初开始了他们的概念之旅，首次引入了使用 chroot 来创建隔离环境。在 21 世纪早期，Solaris 和 FreeBSD 扩展了这一思想，实现了提供隔离的平台。

直到 Google 后来通过引入 Cgroups 引入了分离 CPU 和内存等资源的能力，容器世界才真正开始发展。有了 Cgroups 的概念，像 LXC (Linux 容器)和 systemd-nspawn 这样的公司可以创建他们自己的早期容器。LXC 着眼于创建完整的系统容器，其中 systemd-nspawn 可以管理命名空间进程并由 systemd 控制。两者都是容器的早期领导者。Docker 早期的大部分开发都基于 LXC，但后来放弃了 LXC，转而支持开始一个容器标准。这就是开放容器倡议(OCI)的诞生，并成为所有容器运行时的标准。

现在有许多容器运行时可以用来创建容器，这主要是因为所有的容器运行时都遵循这个标准。

容器运行时

容器运行时使得在您的系统上运行容器成为可能。容器运行时允许容器与主机内核对话并运行进程。

最初的容器运行时很简单，可以在隔离的环境中运行，但是随着时间的推移，这些运行时变得越来越复杂，需要多个层来管理复杂环境中的容器。为了理解当今创建和管理容器的完整流程，您需要了解容器运行时的三个类别:

  • 低级运行时或 OCI 运行时

  • 容器运行时接口

  • 集装箱发动机

低级或 OCI 运行时

使用容器时，最底层是 OCI 运行时。OCI 运行时主要关注容器生命周期。这是容器的基本创建和运行。

低级运行时有两种变体，本地的和“虚拟化的”

本机运行时

本地 OCI 运行时在运行 OCI 运行时的主机系统的同一个内核上运行它们的进程。

Note

由于主机与本机运行时共享其内核，因此人们担心受损的容器可能会影响运行它的主机。出于这个原因，您应该始终了解您可能构建到容器中的所有安全问题。

一些本地 OCI 运行时的例子是 runc、crun 和 containerd。

虚拟和沙盒运行时

与本机运行时不同，虚拟和沙盒运行时与主机内核更加隔离。

沙盒运行时

沙盒运行时创建了一个称为 unikernel 的代理层，它将请求代理到主机内核，减少了容器被破坏时可能出现的问题。截至本文撰写之时，可用的沙盒运行时是 gVisor 和 nabla-containers。

虚拟运行时

虚拟运行时不使用代理层，而是创建一个虚拟机来代替主机内核。这些运行时可能较慢，但提供了另一个强大的保护层。截至本文撰写之时，可用的虚拟运行时有 Katacontainers、Sysbox 和 bracket-container d 等。

容器运行时接口

随着容器工作负载的增长和 Kubernetes 等工具的发展，有必要摆脱内置于 kubelet 守护进程中的硬编码运行时。想法是创建一个新的接口，允许像 Kubernetes 这样的工具与任何容器运行时对话，而不需要在每次使用新的运行时重新编译 kubelets。这种新的接口允许更大的灵活性来切换出本地运行时。

CRI 需要能够做到以下几点:

  • 启动和停止窗格

  • 管理 pod 内的启动、停止和终止类型操作

  • 从容器注册表中提取和推送图像

  • 协助度量和日志检索

目前有两种主要的 CRI 选项能够完成上述步骤。它们是集装箱和 CRI-O。

包含在内

Containerd 是 Docker 用 runc 开发的一个高级运行时，它包含了 CRI 的所有功能，被认为是 CRI 的一个很好的例子。

把他养大

CRI-O 是一个更精简的 CRI 实现。Red Hat 目前支持将 CRI-O 集成到 Kubernetes 及其 OpenShift 产品中。Docker 被移除以支持迁移到 CRI 类型的架构，从而支持切换低级运行时的灵活性。

集装箱发动机

您需要理解的最后一类容器运行时是您可以实际创建一些容器的层。这一层是容器引擎。就像虚拟机需要虚拟机管理程序才能运行一样，容器需要容器引擎。

从“虚拟机与容器”一节的图表中，您可以看到容器引擎层在容器和操作系统之间的位置。这是集装箱发动机。

表 6-1 列出了目前使用的两种常见集装箱引擎；他们是多克和波德曼。在本章中，我们将使用 Podman 作为任何容器示例或练习的容器引擎。

表 6-1

容器引擎示例

|

工具名称

|

描述

|
| --- | --- |
| Docker | 发布于 2013 年 3 月。首批大量使用的容器运行时之一 |
| Podman | 与 Docker 不同，Podman 不运行底层守护进程来运行容器 |

码头工人

今天，当我和人们谈论集装箱时，他们仍然经常称集装箱为“码头集装箱”Docker 是大多数人使用的第一个真正的容器引擎；许多人仍然在使用 Docker，并且仍然信赖它。

如果你是一个 Docker 或 Podman 的人，如果你只是在你的笔记本电脑或测试实验室使用它，这并没有太大的关系；最后，您想要做的就是基于图像创建一个容器。

然而，自从我第一次使用 Docker 以来，它已经变得有点难以安装了。过去，Docker 二进制文件可以与 dnf 或 yum 一起安装，但现在您可能需要启用单独的存储库或进行特殊订阅。如果你想选择 Docker，你需要阅读文档。

我已经使用以下命令在我的 Fedora 系统上安装了“Docker ”:

# dnf install docker -y

一旦安装了 Docker，您可能想要阅读关于如何使用 Docker 的手册页。

您需要了解如何启动容器，了解容器是否正在运行，以及完成后如何删除容器。表 6-2 列出了一些可以使用的 docker 参数选项。

表 6-2

Docker 帮助中的 Docker 示例选项

|

工具名称

|

描述

|
| --- | --- |
| start | 启动一个或多个停止的容器 |
| stop | 拦住集装箱 |
| ps | 列出正在运行的容器 |
| attach | 将本地标准输入、输出和错误流附加到正在运行的容器 |
| search | 在 Docker 注册表中搜索容器映像 |
| history | 显示图像的历史 |
| images | 显示所有已经提取到本地系统的图像 |
| create | 创建新容器 |
| build | 从 Dockerfile 文件构建映像 |
| events | 从服务器获取实时事件 |
| kill | 终止一个或多个正在运行的容器 |
| rmi | 移除容器图像 |

托普曼

Podman 是在 Docker 之后出现的，在如何创建和管理容器方面与 Docker 相似。Podman 和 Docker 的一个主要区别是，Podman 不需要运行服务或守护程序。这是因为 Docker 运行在 runc 容器之上，而 Podman 不是。相反，波德曼直接使用 runc 容器。

所有 Docker 命令都应该与 Podman 一起工作；当您开始时，Podman 的帮助和手册页也将是一个很好的信息来源。

Podman 和 Docker 可以使用相同的图像和 Docker 文件，所以如果你找到任何 Docker 的例子，他们也应该和 Podman 一起工作。

安装 Podman 非常简单，只需为您的本地软件包管理系统运行 install 命令。对于 Fedora，安装 Podman 的命令是

# dnf install podman -y

要查看 Podman 的手册页，您可以运行

# man podman

如果手册页太长而无法阅读，而您只想开始阅读，请运行

# podman help

类似于 Docker，可以搜索图像，可以列出本地图像和容器。如果您有任何 docker 文件，您可以使用它们来构建自定义图像，最重要的是，您可以创建容器。

Podman 简单到足以让你摸不着头脑，在线上有大量 Podman 和 Docker 的例子。

如果你不熟悉码头工人或波德曼，不要太担心。我们将快速浏览一些实例，供您尝试。

容器图像

如果您要构建一个虚拟机，您需要在虚拟机管理程序中创建一个“虚拟机 Shell”，启动虚拟机，并安装操作系统。由于容器与操作系统共享库，它们通常不需要安装自己的操作系统。相反，容器映像是用容器运行其工作负载所需的文件和库创建的。

一个例子是将被用作 nginx web 服务器的容器映像。基本配置和库需要安装在映像中，因为不是所有运行容器运行时的主机都安装了 nginx。对于可能需要的任何应用服务器二进制文件，也是如此。

正是这种为应用程序传送二进制文件和文件的能力，真正允许容器完全可移植。在这一章中会有更多的介绍。

集装箱登记处

您可以想象容器图像变化会变得非常大；光是想想几个例子，你就能看到这个数字在增长。因此，存储这些图像以备后用非常重要。没有人会希望每次部署特定的工作负载时都创建新的映像。如果您有过构建应用服务器的经验，您会理解一些配置可能相当耗时。我不建议为每个新环境重复配置过程。

这就是容器注册变得有用的地方；它们不仅存储您为组织创建的自定义映像，还存储您可能拥有的特定工作负载的下载映像库。例如，您可以找到一个 php 容器映像，其中包含运行 php 应用程序所需的一切，而不是构建一个 php 映像。

您可以通过几种方式使用容器注册表。有云或互联网注册表，你可以从中提取你可能需要的图片。然后，您可以自定义这些映像，并将其推送到您的私有云存储库(如果您愿意),或者您也可以将它们推送到您的本地本地注册表。

云注册表

如果您要管理的资产不多，云注册表是处理图像的一个很好的方式。就像为您的资产中的少量系统构建资产管理平台没有意义一样，对于小型容器资产也是如此。如果您使用容器只是为了一些不经常改变的基本应用程序，那么将您的图像托管在云注册表中是非常合理的。

像 IBM 和 Google 这样的公司有云注册选项，可以让你托管你的容器映像。根据您的组织需求，Google 可能是一个不错的起点。他们提供 300 美元免费测试谷歌服务，包括注册表选项。审判结束后，当然会有一笔费用；就像评估遗产管理工具一样，你需要找出最适合你的方法。

本地注册表

如果您对容器映像存储有更深层次的需求，您可能希望考虑本地容器注册选项。可用的选项很大程度上取决于您需要的服务级别。这可能很简单，只是在一个断开的或有空气间隙的环境中有一个存储容器图像的地方，也可能更复杂，因为出于安全原因，您需要进行图像扫描。无论你的需求是什么，尝试和测试来确认什么适合你。

容器注册提供者

如果您需要一个容器注册表，有许多选项可供选择。就像我们在本书中讨论的大多数东西一样，有社区产品，也有企业产品。使用社区产品，您可以获得基本的功能，并且在大多数情况下还可以获得非常好的特性。借助企业产品，您可以获得安全性和合规性扫描的所有优势。

选择时，你需要再次考虑从价格到功能的一切。

实践中的集装箱

现在，理论上已经涵盖了容器的基础知识，让我们获得一些创建容器工作负载的实践经验。

先决条件

对于本书的这一部分，如果您希望测试将要讨论的一些配置，您需要准备好以下内容。

购物单

  • 具有 root 权限的 Linux 系统

  • 从 Linux 系统访问互联网

  • 安装软件包的能力

系统准备

在我们创建任何容器或配置之前，您需要准备您将使用的系统。

安装软件包

如果您不熟悉这个过程，请使用官方文档安装 Podman、Docker 或任何运行时包。在大多数情况下，这将像运行“dnf install podman -y”或“apt-get -y install podman”一样简单。

Docker 安装可能与 Podman 有点不同，因为您可能需要启用额外的存储库来获得所需的包。请查看官方文档以确定这一点。

Note

对于这一部分，我将使用波德曼；出于这个原因，使用 Podman 来避免额外的配置或谷歌搜索可能是值得的。

创建容器

在接下来的几页中，我们将介绍开始使用基本容器所需的基本实践经验。本节的目标不是让您成为容器专家，而是向您展示如何创建一个简单的容器环境来积累经验。

Warning

以下练习不适用于生产或实际环境。他们没有足够的弹性，会给你带来比他们的价值更多的问题。对于生产类型的环境，您将需要更多地关注容器编排工具。

拖动容器图像

在创建或运行容器之前，您需要从云注册中心获取一个基础映像，或者，如果您走在前面，从本地注册中心获取。

要从注册表中提取正确的映像，您应该知道容器工作负载将运行什么。容器会是 nginx 服务器吗？你打算运行一个 php 应用程序吗？还是你有完全不同的想法？

查找容器图像

一旦您知道您将运行什么类型的容器，您就可以搜索与您的预期工作负载非常相似的容器映像。如果您想找到一个 nginx 映像来运行一个基本的 web 服务器容器，您应该运行类似下面的内容:

#podman search nginx

输出将列出包含 nginx 关键字的所有可用图像。注意星星的数量，如果图片来自官方来源:

INDEX      NAME                     DESCRIPTION              STARS  OFFICIAL
docker.io  docker.io/library/nginx  Official build of Nginx.   15732  [OK]
...output reduced
拖动容器图像

从您使用 podman search 命令发现的可用容器映像列表中，您现在可以将映像提取或下载到您的本地系统。正是这个过程允许您在本地对任何想要运行的容器使用映像。

要从前面的搜索命令中提取容器图像，可以使用与下面非常相似的命令:

# podman pull docker.io/library/nginx

输出应该类似于以下内容:

#root@localhost ~]# podman pull docker.io/library/nginx
Trying to pull docker.io/library/nginx:latest...
Getting image source signatures
Copying blob fca7e12d1754 [==============>-------] 20.6MiB / 25.4MiB
Copying blob 858292fd2e56 done
Copying blob 1c84ebdff681 done
Copying blob a4723e260b6f done
Copying blob b380bbd43752 done
Copying blob 745ab57616cb done

如果您需要将容器映像保存到另一个系统的便携式存储设备上，可以将其作为归档文件下载。

本地容器图像

要查看您下载了哪些容器映像，您可以运行类似下面的命令。这些映像可用于在本地系统上创建容器。

# podman images

输出应该类似于以下内容:

[root@localhost ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED        SIZE
docker.io/library/nginx    latest      87a94228f133  3 weeks ago    138 MB

运行容器

如果您找到了想要使用的容器映像，并且成功地下载或获取了它，那么您可以在您的测试系统上运行该映像的一个基本容器实例。要从以前下载的 nginx 映像运行基本的 nginx 容器，您可以运行类似于下面的命令:

[root@localhost ~]# podman run -d --name kentest -p 8080:80 nginx

输出将是创建的容器的 ID:

95bf289585a8caef7e9b9ae6bac0918e99aaac64d46b461180484c8dd1efa0a4

命令中的“-d”选项告诉 podman 从正在运行的容器中分离出来，让它在后台运行。“-p”设置容器将监听的端口。

运行容器

一旦创建了容器，您可能想看看它是否正在运行。最简单的方法是运行容器列表命令，如下所示:

[root@localhost ~]# podman container list
CONTAINER ID  IMAGE   COMMAND   CREATED  STATUS PORTS                NAMES
95bf289585a8  dock....  nginx...  7 sec...   Up     0.0.0.0:8080->80/tcp kentest

从这个列表中，您可以看到您已经设法在本地系统上启动的所有容器。nginx 示例运行在所有接口上，并监听端口 8080。

图 6-2 中的截图显示了 nginx 在本地主机的 8080 端口上服务请求。

图 6-2。

自定义图像和容器

既然我们知道了如何从在线映像注册中心下载和运行基本容器，我们就可以探索如何定制一个映像来承载您自己的工作负载。

创建一个波德曼图像注册表

在接下来的几节中创建的定制图像需要存储在本地注册表中。无需购买或支付任何在线服务来充当容器注册表，我们可以在您的本地系统上设置一个。为此，我们将创建一个基本的 podman 注册中心，并将我们的新图像推送到本地容器运行注册中心。

为要存储的数据创建目录
# mkdir -p /var/lib/registry
创建注册表容器

创建运行容器的命令如下:该命令包含一个“-v”参数，它告诉容器将一个目录从主机系统挂载到正在运行的容器。在这种情况下，这是为了在容器重启时帮助容器注册中心保留容器映像。

# podman run --privileged -d --name registry -p 5000:5000 -v /var/lib/registry:/var/lib/registry --restart=always registry:2
将 Podman 设置为使用不安全的注册表

因为容器注册中心通常希望是安全的，所以您需要告诉 podman 使用不安全的注册中心。您可以将您的注册中心配置为使用签名证书，但是您应该遵循 podman 文档。

要设置 podman 使用不安全的注册表，您需要编辑“/etc/containers/registries . conf”文件并找到“[registries . unsecured]”部分。在“[registries . unsecure]”部分下，找到“registries = [ ]”行，并将其更新为“registries = ['localhost:5000']”。

最后，在保存 registries.conf 文件后，您需要重新启动 podman 服务:

# systemctl restart podman

使用波德曼注册表

现在，有了上一节中配置的自己的本地 podman 注册表，您现在可以将自己的映像添加到注册表中进行保护。然后，在构建新的应用程序或映像时，您可以从自己的注册表中提取映像。

标记图像

当您下载了本地图像后，您需要做的第一件事是用您的内部 podman 注册表标记它们。这样，您可以指示 podman 将图像推送到本地注册中心，而不是远程注册中心。可以把它看作是改变容器图像路径的一种方式。

要标记图像，可以运行 podman tag 命令。如果我们以目前使用的 nginx 为例，我们可以用下面的命令标记 nginx 图像:

# podman tag docker.io/library/nginx localhost:5000/nginx
推送图像

标记好 nginx 映像后，下一步是将 nginx 映像推送到或上传到本地存储库。这可以通过以下命令完成:

# podman push localhost:5000/nginx
远程注册表

如果您在不同的主机上创建了一个 podman 注册表，并在网络接口而不是回送地址上公开了该注册表，如果您愿意，也可以标记您的映像并将其推送到该地址。只需确保打开所有防火墙端口，允许流量通过 podman 注册表。

这同样适用于任何内部映像注册表；只要您拥有推送图像的能力和权限，podman 标记和推送命令将允许您使用本地注册表。

自定义图像

到目前为止，我们所做的只是使用容器图像，而没有添加任何我们自己的定制。

没有任何内容的 web 服务器有什么用呢？容器图像也是如此；如果你不在 nginx 或 apache web 服务器上托管任何 web 内容，那么运行它们又有什么意义呢？

让我们来看看如何向 web 服务器添加我们自己的定制内容。

Dockerfile

为了理解如何向容器映像添加一些基本的定制，我们需要使用一个构建文件。这个构建文件通常被称为 Dockerfile 文件。Podman 和 Docker 都可以使用 Dockerfiles。

这些 docker 文件用于在容器映像中创建您想要的任何定制。将这些文件视为映像安装文件。

要使用 Dockerfile，您只需创建一个名为 Dockerfile 的新文件。不要更改名称或添加任何扩展名。该文件需要存在于当前目录中，或者您需要在运行 podman build 命令时指定位置。

例子

像以前一样，我们来看一个例子。对于本例，我们将构建一个安装了 apache httpd 的 CentOS 映像。一旦安装了 web 服务器包，该示例将从我的 GitHub 帐户中下载一个示例 HTML 文件。最后，我们将运行一个包含新图像的新容器。

下拉 CentOS 图像

在我们开始之前，您需要下载 CentOS 的一个版本:

# podman pull docker.io/library/centos
Dockerfile

接下来，您需要创建一个 Dockerfile 文件。请记住，Dockerfile 应该准确地命名为“Dockerfile”当您尝试构建新映像时，请确保您与 docker 文件在同一个目录中。

在我的例子中，Dockerfile 将获取它所能找到的最新的 CentOS 图像，如果您还没有获取的话。一旦映像可用，yum 将安装“httpd”和“git”包。这些将构成我们的自定义映像所需的所有包。随意添加任何你想用的东西，比如 PHP。一旦安装了这些包，git 克隆将下载我们的 web 内容的源代码，并将其移动到/var/www/html 目录供 web 服务器使用。在这个例子中，我写了一个非常基本的 HTML 页面。这可以是你想要的任何东西，所以如果你想尝试一些不同的东西，可以根据你自己的内容来改变。

下面是我用的 Dockerfile 的样子:

FROM centos:latest
RUN yum -y install httpd git; \
git clone https://github.com/kenhitchcock/basicwebapp.git; \
mv basicwebapp/index.html /var/www/html/index.html
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]
EXPOSE 80
构建图像

要基于我们之前的 docker 文件构建映像，您需要确保与您的 docker 文件在同一个目录中，然后运行 podman build 命令:

# podman build -t centos .

Note

的“.”告诉 podman 命令使用当前目录。这就是为什么在运行 build 命令时，需要与 Dockerfile 在同一个目录中。构建的图像的名称可以是您想要的任何名称，只需更改“-t”参数后面的文本。此示例使用 CentOS 名称。

创建容器

使用新构建的容器映像和定制内容，我们可以运行并测试新映像:

# podman run  -p 80:80 -dit localhost/centos

Challenge

apache web 服务器的默认端口是 80。作为一项挑战，尝试找出如何定制您的 docker 文件以使用不同的端口。

确认容器正在运行

要仔细检查您的容器是否已经实际启动，您可以运行以下命令:

# podman ps

输出应该类似于以下内容:

# podman ps
CONTAINER ID   IMAGE                      COMMAND               CREATED       STATUS             PORTS               NAMES
08832f29f46e   localhost/centos:latest    /usr/sbin/httpd -...  24 hours ago  Up 12 minutes ago  0.0.0.0:80->80/tcp  elated_jepsen
删除容器

要删除容器，首先需要停止容器，然后才能删除它。这可以通过类似于下面的命令来完成:

# podman stop 08832f29f46e
# podman rm 08832f29f46e

输出应该类似于

# podman rm 08832f29f46e
08832f29f46edab6bdd41227a542bf494f926831d099a0a83ee8838bfe71fdf9

集装箱业务

随着对什么是容器以及如何管理它们有了更好的理解，您现在需要理解什么是好的和坏的实践。

云原生

在处理容器化工作负载时，您需要理解的第一件事是云原生意味着什么。

对云原生的最简单解释是，它是使用云技术以轻量级和快速的方式部署工作负载的实践。

云原生工具通常涉及在私有或公共云中使用自动化、可扩展的平台、容器、服务网格，并且通常具有不可变的基础设施。使用这些工具和许多其他工具可以实现高速度的产品工作负载发布。网飞就是一个很好的例子。网飞每天发布大约 100 个生产版本，通过使用自动化和其他工具将轻量级、快速的工作负载简化到生产中。

良好做法

保持小规模

运行任何容器或云原生工作负载的首要规则是保持工作负载尽可能小。不建议创建千兆字节大小范围内的工作负载。工作负载越小，部署和可伸缩性就越好。如果您的工作负载需要更高的规模，那么您可能需要重新设计工作负载的编写方式。这可能是将工作负载分解为微服务，并从那里开始工作。

如果您被迫创建大型工作负载部署，请始终向后推。从长远来看，运行较小工作负载的好处是值得的。

动态部署

永远不要手动部署工作负载。代码应该提交到您的源代码控制中，并推向生产。利用管道工具、源代码控制 webhooks 和任何其他可以触发工作负载部署的工具。

在图 6-3 中可以看到这样一个基本示例。

图 6-3。

可攀登的

任何将部署在云类型环境中或被视为云原生的工作负载或应用程序都必须是可扩展的。当需求增加时，扩展能力对于良好的云工作实践至关重要。如果您正在部署的工作负载不能动态扩展，您需要考虑重新架构工作负载。无法动态扩展是过时工作负载和潜在旧代码的症状。

“会云吗”？

仅仅因为您正在部署到云平台中，并不意味着您的工作负载是云本地的。还有许多其他事情可以使工作负载成为云本地的，但是当您想知道您的工作负载是否是针对云的时，您应该问的三个问题是

  • 工作量小吗？

  • 工作负载可以扩展吗？

  • 工作负载可以动态部署吗？

带着前面的问题，你现在可以问自己，“它会云吗”？如果您对任何一个问题的回答都是否定的，那么在有效地迁移或部署到云环境之前，您还有很多工作要做。

不要试图将虚拟机构建到容器或云原生风格的超大规模服务器中，以免落入陷阱。仅仅因为你能并不总是意味着你应该。当你不能利用云计算的优势时，这样做的陷阱会回来咬你。大型工作负载可能会导致效率低下和浪费，抵消您可能期望的成本节约。

如果您需要大型工作负载，那么容器或云平台可能不是您现在需要的。后退一步，首先仔细观察工作负载，重构代码，将整体分解成更小的应用程序，这些应用程序可以按照云的意图“云”。

不良做法

有很多好的做法，也有很多不好的做法。这些被称为反模式。这里有几个应该尽可能避免的常见做法。

容器不是虚拟机

容器与虚拟机不同，不应被同等对待。容器是一个只有一个用途的简化实体。这种实践确保云原则保持不变。如果您试图复制虚拟机所做的事情，那么您可能还没有准备好使用容器。

不同的图像

诱惑可能是对不同的环境使用不同的映像，因为这似乎是构建工作负载映像的更安全的方法。但是，构建用于测试的测试映像、用于开发的开发映像和用于生产的生产映像可能会出现未经测试和签署的差异。测试环境中使用的映像很可能没有漏洞，但生产环境中使用的映像却有。因此，在您的环境中迁移应用程序烘焙的映像。通过这种方式，您可以确保安全检查已经完成，代码已经过适当的测试，并且最重要的是，已经签字同意投入生产使用(图 6-4 )。

图 6-4。

关于如何测试和提升图像的基本想法应该类似于图 6-4 。

从代码构建产品

这一点和上一点类似。不要将容器映像直接投入生产。您的映像应该在开发中构建，然后通过不同的登台环境进行提升。您最终可能会遇到不同代码被部署到不同系统的情况。拥有一个从中央映像注册表进入生产环境的单一入口点将大大降低发生这种情况的风险。您还可以确信测试的代码就是部署的代码。

核心秘密或配置

应用程序应该不知道平台配置或秘密。硬编码的需求应该是应用程序不是云原生的警钟。配置和机密应该由将要部署应用程序的平台来管理；其他任何事情通常都被认为是不好的做法和潜在的安全风险。

构建幂等容器

构建容器应该是一个幂等的过程。您的 docker 文件不应该试图对它正在构建的映像进行外部更改。不应提交任何代码或推送任何外部更改。简单地说，容器构建应该遵循类似于图 6-5 的流程。

图 6-5。

构建容器映像应该只关注容器运行所需的内容。流程应该如图 6-5 所示一样简单。

集装箱发展

到目前为止，在这一章中，我们已经简单地介绍了如何开发容器。我们探讨了一些简单的好的和坏的实践，希望能让您对什么是原生云有一个好的了解。对于本节，让我们了解如何使用容器开发来创建有意义的工作负载。

发展考虑

编码语言

为容器编写代码与为本地开发环境或笔记本电脑编写代码没有什么不同。您仍然可以选择和使用您喜欢的开发语言，并且仍然可以将代码推送到您喜欢的源代码控制平台。没有硬性规定说你不能使用某一种语言。然而，并不是所有的开发语言都是一样的。使用旧语言可能不会像新语言那样有效地转换到云中。在开始编写任何新的应用程序之前，花些时间看看下面的一些选项。表 6-3 列出了目前在容器化应用中使用的一些开发语言选项。

表 6-3

开发语言或框架

|

语言名

|

描述

|
| --- | --- |
| Quarkus | 针对云环境优化的 API Java 框架 |
| React | 用于 UI 开发的 Java 框架 |
| Python, Ruby | 通用高级编程语言 |
| Golang | 快速而强大，通常用于物联网设备 |
| .Net | 如果你需要坚持使用基于微软的语言 |

代码编辑器

要编写有用的代码，你需要练习，并且拥有一个足够好的编辑器，而不会倾家荡产。有几个可供你使用，但它总是归结为个人喜好和你愿意生活中没有什么功能。表 6-4 列出了一些可以使用的代码编辑器选项。

表 6-4

代码编辑器

|

工具名称

|

描述

|
| --- | --- |
| VSCode | 免费使用，简单易懂，并有一个伟大的插件和附加选择 |
| Eclipse | 强大的编辑器，能够添加应用服务器进行代码测试。通常是一个 Java 开发工具 |
| NetBeans | 另一个 Java 编辑器 |
| Notepad++ | 比标准文本编辑器更高级，当您选择有限时，这是一个有用的选择 |
| Vim | 并不总是安装在 Linux 系统上，但是可以用来开发代码。插件可以安装，但往往比 GUI 选项更受限制 |
| Nano, Emacs | 可以使用更多的命令行编辑器，但是缺少 GUI 工具提供的丰富特性 |

Tip

VSCode 可以免费使用，有很棒的插件，而且使用起来非常简单。在你花太多时间在其他编辑器上之前，试试 VSCode，如果发现更好的就改。

源代码管理

不管你希望使用哪种源代码控制平台，只要确保你使用一个就行了。不使用源代码控制对于任何开发人员或组织来说都是一个巨大的错误。您失去了以有效的集中方式对代码进行同行评审的能力，并且您面临着代码丢失的风险。不值得冒这个险。表 6-5 列出了可用于控制源代码的源代码控制选项。

表 6-5

源代码管理选项

|

工具名称

|

描述

|
| --- | --- |
| Git | 基本 git 可以部署在任何 Linux 系统上；代码可以被推和拉 |
| GitHub | 基于互联网的 Git 源代码控制平台 |
| GitLab | 类似于 GitHub，只是您可以在内部运行自己的 GitLab |
| Bitbucket | 另一个可以在内部运行的 Git 产品 |
| Subversion | Git 之前流行的选项，目前正在失去流行性 |
| Mercurial | 处理各种规模的项目，这是一项免费的分布式控制管理服务 |
| Microsoft Team Foundation Server | 微软开发的源代码控制系统 |

Note

Git 可能是当今最流行的源代码控制系统。尽快熟悉它。

集装箱加工

一旦您开发了代码并且有了容器的想法，您将想要开始简化您的容器映像创建。有很多方法可以做到这一点，既有正确的，也有不那么正确的。您还将有相当多的工具可供选择。

CI/CD

首先要研究的领域是您的集装箱运输系统。这就是所谓的持续集成和持续交付系统。这些将有助于将您的工作负载部署到您的各种环境中，并使您能够灵活地利用您的容器映像或工作负载部署做更多的事情。表 6-6 列出了 CI/CD 管道的一些可用选项。

表 6-6

CI/CD 选项

|

工具名称

|

描述

|
| --- | --- |
| Jenkins | 流行的免费开源工具，易于使用，有很多插件选项 |
| TeamCity | 与 Visual Studio 集成，对 Windows 开发和测试很有用。有免费和专有选项 |
| GitLab | 能够直接从 GitLab 存储库构建和运行任务 |
| Travis CI | 可以自动检测 GitHub 中的提交，并在托管的 Travis CI 平台上运行测试 |
| Tekton | 另一个开源 CI/CD 工具，支持跨不同云或本地平台的部署 |

Jenkins 示例

Jenkins 是当今最流行的流水线工具之一，可以免费用于测试。要了解 Jenkins 管道代码的样子，下面是一个使用伪代码的基本示例:

node {
    def app

    stage('Clone repository') {
        /* Basic comment about cloning code*/
        checkout scm
    }

    stage('Build image') {
        /* Build your container image */
        app = docker.build("jenkinsproject/helloworld")
    }

    stage('Test image') {
        /* Run your unit testing of some type */
        app.inside {
            sh 'echo "Tests passed"'
        }
    }

    stage('Push image') {
        /* With a verified image, push your image to a registry */
        docker.withRegistry('https://someregistry.com', 'registry-credentials') {
            app.push("${env.BUILD_NUMBER}")
            app.push("latest")
        }
    }
}

从这个 Jenkins 示例中，您可以看到在管道中使用了阶段；您可以为不同的任务添加任意多的任务。例如，您可能希望添加一个安全图像扫描阶段。理想情况下，您希望构建尽可能多的自动化和测试。

Challenge

作为一个学习挑战，在您的沙盒环境或笔记本电脑上部署一个 Jenkins 容器。看看您是否可以编写自己的定制 Jenkins 文件来构建一个新的容器映像，该映像是由 git 中更新的源代码触发的。

专门的映像构建者

利用非 Docker 组件构建容器映像。像 Buildah ( https://buildah.io/ )和 Kaniko ( https://github.com/GoogleContainerTools/kaniko )这样的工具更安全，因为它们在用户空间的 docker 文件中运行每个命令。Buildah 和 Kaniko 都不需要运行 Docker 守护进程来构建映像。

图像注册表

当您开发应用程序和容器内容时，您将需要一个地方来存储这些图像。如果您想在需要时进行测试和构建，这是可以的，但是作为一个良好的实践，建议您在开始构建应用程序组合时就开始存储容器映像。如果您打算将任何东西部署到一个真实的环境中，那么强烈推荐这种做法。

在本章前面，我们讨论了如何建立一个波德曼图像注册表；为了扩展这一点，考虑提供存储以确保您的容器不是短暂的。例如，波德曼有能力创建卷；当您创建这些卷时，可以将它们装入您的容器中。

使用像 OpenShift 或 Kubernetes 这样的编排平台可以提供图像注册，但默认情况下通常是短暂的。确保装载了存储卷，以免丢失任何映像。

开发编辑器插件

使用您选择的开发编辑器，查找并安装有助于容器开发调试的插件。可以帮助 Dockerfile 或 Jenkinsfile 创建的插件肯定会对你有所帮助。

Tip

如果您需要免费且易于使用的东西，VSCode 是一个很好的选择。总的来说，对我来说这是一个赢家，但你自己测试一下。

林挺工具

在推送或提交任何类型的代码之前，无论是 YAML 还是 Dockerfiles，都要使用林挺工具。对于 Dockerfiles，有一个很好的在线林挺工具，你可以复制并粘贴你的 docker files 内容进行检查。

www.fromlatest.io/#/

DevSecOps

当今平台管理领域的一个关键词是 DevOps。DevOps 是一套重要的实践和工具，它在开发人员和运营团队之间架起了一座桥梁。DevSecOps 是对这一概念的补充，其中每个人都对安全负责。

DevSecOps 工具

DevSecOps 使开发人员和操作团队能够理解安全性需求，并将安全性构建到他们的工具中。

管道

在没有使用 DevOps 或 DevSecOps 实践的标准情况下，安全团队需要在每次构建新系统或平台时扫描并报告问题。安全团队负责组织的安全，如果发生违规事件，他们必须回答一些棘手的问题。因此，他们在扫描时非常小心，确保在真实环境中不会暴露任何漏洞。此过程可能涉及额外的安全工具，可能需要一段时间才能完成。如果新的平台或系统不断发布，这也可能是一项令人沮丧的工作。

通过遵循 DevSecOps 实践，可以将安全性考虑因素构建到管道或映像构建工具中。有了这个过程，开发人员和运营团队负责安全，从而大大减少了与安全团队的来回奔波。

安全门

借助 Jenkins 等管道工具中内置的安全性，可以构建安全门，如果某个映像由于某种原因未能通过安全扫描，可以停止构建过程，从而在发布到实际环境之前进行补救。

GitOps

当今庄园管理和容器平台管理的另一个关键词是 GitOps。

“GitOps 是一个运营框架，采用了用于应用程序开发的 DevOps 最佳实践，如版本控制、协作、合规性和 CI/CD 工具，并将它们应用于基础架构自动化。”

https://about.gitlab.com/topics/gitops/

GitOps 工具箱

下面是一些有用的工具，可以帮助你学习 GitOps。您可以使用许多其他工具和变体，但是由于这个主题可以单独作为一本书的主题，所以我只提到了几个。

饭桶

使用 GitOps 的第一步是开始使用 Git。这可以是 GitLab、Bitbucket 或 GitHub，任何允许 CI/CD 管道检测合并请求的 Git 平台。

基础设施作为代码

然而，从技术上讲，它不是一个工具，你为自动化或配置你的平台所写的一切都应该是代码的形式。这可能是 YAML 为您的 OpenShift 或 Kubernetes 配置或 Ansible 建立一个新系统。一切都应该从代码中构建或配置；任何地方都不应使用手动配置。

管道工具

选择管道工具，并将其配置为在 git 环境中检测合并或拉取请求。每次进行新的更改时，都应该启动管道来构建或部署新的应用程序版本或构建新的系统。

阿尔古德

另一个越来越常用的 GitOps 工具是 ArgoCD。ArgoCD 有助于 GitOps 工作流，可用作独立工具或 CI/CD 管道的一部分。

在配置 OpenShift 或其他 Kubernetes 变体时，ArgoCD 与 Git 一起充当“事实的来源”。维护容器编排平台的状态很有用。这与 SaltStack 等资产管理工具如何维护其管理的资产中的系统状态非常相似。

ArgoCD 通过 pull 或 merge 请求的方式关注任何配置文件的更改，从而与 Git 协同工作。当 Git 中合并了一个变更时，ArgoCD 会提取新的配置，并配置该配置所针对的平台(图 6-6 )。

图 6-6。

图 6-6 显示了 ArgoCD 配置应采用的基本流程。

容器编排

在定期部署应用程序的环境中，几个容器可能会迅速增加到数百个甚至数千个。为了管理这种增长，对容器编排的需求变得更加重要。Kubernetes、Docker Swarm 和 OpenShift 等工具为管理员提供了管理大量容器工作负载并确保其可用性的能力。每种工具都有自己的优点和缺点，可能需要花更多的章节来详细讨论；然而，由于我们目前并没有过多地关注容器编排，所以现在让我们只涉及一些基础知识。

它是做什么的？

容器编排是在最终用户使用容器之前必须存在于容器之上的层。一个好的容器编排工具应该具有以下特性:

  • 可攀登的

  • 灵活的

  • 安全的

  • 自动化的

  • 使用方便

这些属性确保容器工作负载能够得到有效和安全的管理，能够插入到 CI/CD 系统中，并具有动态更新的内容。

为什么不用波德曼？

例如，使用像 Podman 这样的东西来托管一系列 pod 和 Kubernetes 之间的区别在于，Podman 不能让您监控性能和调整 pod 的数量来自动处理额外的负载。

Podman 不具备为特定工作负载在不同节点之间创建隔离网络的灵活性。

由 Kubernetes 或 OpenShift 等编排层提供的所有这些更高级别的配置和自动化服务都是针对大型资产部署的。波德曼有能力容纳大量内部装有许多容器的容器，但缺乏大规模管理这些容器的能力。添加更多的节点和连接 pod 网络将被证明更加复杂，并且会破坏容器编排层易于使用的目的。

Podman 适用于本地或小型部署，但不适用于大规模部署。你可以开发自己的包装工具来管理 Podman，但是你只是在重复发明轮子。最好的办法是投入时间使用 Kubernetes 或其他企业产品，如 OpenShift，如果你能得到它的话。如果不行，你还可以使用名为 OKD 的社区产品。

业务流程选项

忽必烈忽必烈忽必烈忽必烈忽必烈忽必烈忽必烈忽必烈忽必烈忽必烈

Kubernetes，或 K8s，是一个开源项目，最初由 Google 开发，基于他们最初的“Borg”系统(集群管理器系统)。

红帽是 Kubernetes 正式上线前的首批贡献者之一。

2015 年，谷歌向 CNCF(云原生计算基金会)捐赠了 Kubernetes 项目。

库伯内斯·福克斯

由于 Kubernetes 是开源的，今天有许多 Kubernetes 的下游版本，如 Red Hat 的 OpenShift，VMware 版本的 Kubernetes，以及许多云平台，如 AWS 和 Azure，它们提供自己的托管服务。

这些云托管服务允许终端用户部署其容器工作负载，而无需构建自己的编排平台或管理任何与之相关的系统。用户注册一个帐户，获得分配的资源，并部署工作负载。

OpenShift 和 Kubernetes 可以部署在云中和本地，它们需要安装、配置和管理。如果您需要部署非常大的资产，并且乐于自己完成所有管理工作，这将非常有用。

主组件

Kubernetes 有一些基本的集群组件，使它能够为 pod 和其中的容器提供编排。

控制平面

控制平面由以下部分组成:

  • 存储所有集群配置的 ETCD 键值数据库

  • 通过 JSON over http 提供 Kubernetes API 的 API 服务器

  • 负责调度节点上工作负载的调度程序

  • 控制器管理器用于管理不同的 Kubernetes 控制器

控制平面由一群主节点提供；这些节点在它们之间复制配置，以确保控制继续提供群集功能。

节点

节点是 Kubernetes 集群的工人。他们负责托管用户部署的容器工作负载。节点由几个子组件组成:

  • Kubelet 确保节点的状态和运行在其上的容器的健康。

  • Kube-proxy 负责将流量路由到您的容器。

  • 容器运行时。

命名空间

名称空间旨在提供一种方法来隔离一个 Kubernetes 集群，以便多个用户可以部署工作负载，而无需相互通信。

达蒙塞特

通常，调度程序负责将 pod 放在资源可用的节点上，以确保不会只有一个节点过载。然而，当您需要强制一个 pod 在每个节点上运行时，可以使用 Daemonsets。日志容器通常就是这种情况。

工作节点组件

工作负载对象是在工作节点上部署和使用的对象。如果不是所有工作节点，也是大多数工作节点都使用以下内容。

分离舱

集装箱在吊舱中运行；这些豆荚是在工作者节点上产生的。通常，一个容器在一个 pod 中运行，但是这并不是一个硬性的规则。

服务

服务是将同一应用程序的多个单元绑定在一起的东西。当不同的工作节点上产生多个 pod 时，您需要平衡它们之间的流量。服务是提供该“服务”的层

卷

默认情况下，所有容器都是短暂的，这意味着在 pod 重新启动或重新创建后，它们无法存储数据。通过将卷或永久卷安装到 pod，您可以从以前销毁或重启的 pod 中恢复任何数据。

配置映射

在容器中，有时需要配置配置文件。例如，web 服务器可能需要配置有关其托管的网站的详细信息。Configmaps 使您能够将配置从容器映像抽象到编排平台。当使用 configmap 部署 pod 时，将在部署阶段应用配置，类似于使用 Dockerfiles 配置容器映像的方式。

openshift(打开 hift)

OpenShift 之前是 OpenShift，是一家叫 Makara 的公司的 PaaS 产品。Red Hat 在 2010 年收购了 Makara 的 PaaS 平台，该平台在当时是基于 Linux 容器技术的专利。

早期开班

在 OpenShift 3.0 之前，Red Hat PaaS 平台是专有的和定制开发的。收购后，Red Hat 花了两年时间发布了第一个开源版本，然后又花了三年时间从定制平台转向当时更“成熟”的 Kubernetes。

OpenShift 3.0 是 Red Hat 首次将 Docker 用于容器运行时，将 Kubernetes 用于编排层。

OpenShift 3.11 是 OpenShift 3 的最后一个次要版本，也是 Docker 用作容器运行时的最后一个版本。

当前 OpenShift

Red Hat 目前有 OpenShift 4.9 可供公众使用。“硬编码”Docker 的分离已经允许 OpenShift 4.x 转移到容器运行时接口方法，在该方法中可以使用任何低级容器运行时。

OpenShift 已经发展成熟，成为企业的领先容器编排平台，因此已经成为许多组织的头号容器编排产品。Red Hat 的持续投资继续增长 OpenShift 新功能和收购。

高级集群安全性(StackRox)、高级集群管理、监控、日志记录和许多其他企业级功能使 OpenShift 成为任何大型混合云组织的首选产品。

OpenShift 组件

由于 OpenShift 是基于 Kubernetes 的，所以大多数组件都非常相似，并且以非常相似的方式命名。当然也有一些变化，比如 Kubernetes 中的名称空间在 OpenShift 中被称为项目。Kubernetes 的 kube 命令是 OpenShift 的“oc”命令，但最重要的是，以下是一些主要的区别。

产品

OpenShift 是一个产品，不是 Kubernetes 那样的项目。Kubernetes 是一个任何人都可以参与的社区项目。如果 Red Hat 认为这些变化有用的话，它们会进入 OpenShift。

企业

企业与社区的争论再次强调，OpenShift 是一个企业产品，而 Kubernetes 是一个社区项目。像 Google 这样的公司提供付费的企业支持选项，但是仍然基于社区项目。

安全

OpenShift 的构建考虑到了安全性，为安全性意识更强的组织提供了采用机会。最近对 StackRox 的收购进一步强化了这一观点。

Web 控制台

OpenShift 默认有一个 web 控制台。Kubernetes 要求您单独部署它，并让集群 kube-proxy 将流量导向控制台。

更多的

虽然没有列出所有的差异，但 Red Hat OpenShift 在 Kubernetes 上还提供了其他功能，如图像管理和企业存储解决方案。如果你感兴趣，你应该按照本书中推荐的大多数产品去做。建立一个概念证明，并自己比较不同之处。

摘要

在本章中，向您介绍了以下内容:

  • 概述什么是容器，它们的运行时，如何构建容器，以及如何定制容器

  • 容器的一些实际用途以及如何创建本地容器注册表

  • 云原生意味着什么以及使用容器的各种好的和坏的实践

  • 不同的容器工具以及 DevSecOps 和 GitOps 实践

  • 容器编排以及可供您使用的选项

七、监控

任何新的 Linux 系统在被贵组织的生产或现场环境接受之前，必须具备哪些最重要的特性？给出的常见答案是监控、日志记录和安全性。同样有充分理由的是，任何没有被监控、记录或保护的系统都只会导致灾难，并且几乎在每一种情况下都会被任何严肃的运营团队拒绝。

本章将深入探讨 Linux 系统应该具备的首要功能之一:监控。我们将讨论过去使用过的工具，以及大多数 Linux 发行版都有哪些现成的工具。然后，我们将看看过去五年中使用的一些更新的工具和趋势。

最后，我们将从监控的角度讨论开发人员和应用程序的要求，如何更好地监控应用程序，以及如何与开发人员讨论如何开发应用程序来支持这一点。本章不会给出所有不同监控用例的所有答案。它将告诉您可以做些什么，以及哪些工具可以帮助您解决当前的一些监控问题。它甚至会产生一些你没有意识到你需要问的问题。

Linux 监控工具

几乎从 Linux 出现开始，就有工具可以监控系统上发生的事情。这些工具可以像“top”命令一样简单，也可以像使用 systemtap 一样复杂，以了解当一个新设备添加到您的系统中时内核正在做什么。

一旦你知道了如何使用 Linux 系统的基本知识，下一个合乎逻辑的步骤应该是知道如何确认你的系统是健康的，以及如何确保它保持健康。为此，有许多不同的工具可以显示您的系统状态。

程序控制

默认过程命令，ps 和 top

默认情况下，在大多数(如果不是全部的话)Linux 发行版上，您会发现“top”和“ps”命令。它们不仅向您显示系统上运行的所有进程，还会给您进程 ID 号，该 ID 号可用于终止已失效或挂起的进程。

如果您不确定某个特定的进程是否正在运行，例如 apache web 服务，您可以运行类似下面的命令:

# ps -ef | grep httpd

也可以使用“top”或其他命令，但是您可能很难在列表中搜索您的流程。使用“ps”和“grep”将使输出更快更清晰。

Note

在第二章中，我们看了“top”和其他一些工具，它们可以用来查找系统中正在运行的进程。我们还讨论了如何杀死进程以及如何识别僵尸进程。

查看进程

查看所有进程和每个进程的父进程的一个快速而好的工具是“pstree”命令。以下是 pstree 的基本输出，但输出有所减少:

# pstree
systemd─┬─ModemManager───3*[{ModemManager}]
        ├─NetworkManager───2*[{NetworkManager}]
        ├─abrt-dbus───2*[{abrt-dbus}]
        ├─3*[abrt-dump-journ]
        ├─abrtd───2*[{abrtd}]
        ... [reduced for length]
        ├─thermald───{thermald}
        ├─udisksd───4*[{udisksd}]
        ├─upowerd───2*[{upowerd}]
        ├─uresourced───2*[{uresourced}]
        └─wpa_supplicant

资源密集型流程

“ps”命令有用还有另一个原因。我相信你经历过一个占用大量 CPU 或内存的过程。如果您试图弄清楚进程是如何从“top”或类似的命令中消耗资源的，那么发现有问题的进程有时会有点棘手。以下是两个“ps”命令，您可以使用它们来查找前五个 CPU 和内存密集型进程。

内存密集型进程
# ps -auxf | sort -nr -k 4 | head -5
CPU 密集型进程
# ps -auxf | sort -nr -k 3 | head -5

Tip

有关使用 ps 的更多选项，请查看 ps 帮助和 ps 手册页。

磁盘和 IO

可能会出现磁盘性能缓慢或磁盘已满的情况。一些可以用于磁盘和 IO 监控的有用工具现在仍在使用，如"iostat、" "iotop、" "du、"df"

iostat 和 iotop

“iostat”和“iotop”是提供输入输出系统信息的基本工具:

# iostat
Linux 5.13.4-200.fc34.x86_64 (localhost.localdomain)       22/11/21      _x86_64_       (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.17    0.06   12.21    0.11    0.00   59.46

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
dm-0              1.16         1.79        59.42        24.16   16712024  554638596  225476964
nvme0n1           1.15         1.79        59.43        24.24   16724756  554741532  226295700
zram0             0.20         0.16         0.64         0.00    1482776    6013392          0

# iotop
Total DISK READ:         0.00 B/s | Total DISK WRITE:    108.61 K/s
Current DISK READ:       0.00 B/s | Current DISK WRITE:    3.19 K/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 733973 be/4 ken         0.00 B/s   57.50 K/s  0.00 %  0.00 % chrome --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-han~be2ad25, --shared-files=v8_context_snapshot_data:100 --enable-crashpad [ThreadPoolForeg]
 729143 be/4 root        0.00 B/s   51.11 K/s  0.00 %  0.00 % [kworker/u8:6-btrfs-endio-write]
      1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd rhgb --system --deserialize 51
      2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
      3 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_gp]
      4 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_par_gp]

杜和 df

这些用于显示磁盘使用情况和磁盘安装位置:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         12G     0   12G   0% /dev
tmpfs            12G  181M   12G   2% /dev/shm
tmpfs           4.7G  2.0M  4.7G   1% /run
/dev/dm-0       238G   93G  144G  40% /
tmpfs            12G   61M   12G   1% /tmp
/dev/dm-0       238G   93G  144G  40% /home
/dev/nvme0n1p1  976M  272M  638M  30% /boot
tmpfs           2.4G  216K  2.4G   1% /run/user/1000

# du -h /etc
0       /etc/.java/.systemPrefs
8.0K    /etc/.java/deployment
8.0K    /etc/.java
0       /etc/NetworkManager/conf.d
0       /etc/NetworkManager/dispatcher.d/no-wait.d
0       /etc/NetworkManager/dispatcher.d/pre-down.d
0       /etc/NetworkManager/dispatcher.d/pre-up.d
0       /etc/NetworkManager/dispatcher.d
0       /etc/NetworkManager/dnsmasq-shared.d
0       /etc/NetworkManager/dnsmasq.d
28K     /etc/NetworkManager/system-connections
32K     /etc/NetworkManager
... [reduced for length]
80K     /etc/gimp/2.0
80K     /etc/gimp
28K    /etc/pcp/derived
28K    /etc/pcp
37M    /etc/

中央处理器

可以使用发行版附带的许多工具和可以很容易安装的工具来检查系统上的 CPU 统计数据。下面是两个比较常用的工具。

顶端

大多数 Linux 系统管理员会使用 top 命令并按“1”键。这将产生类似于以下内容的输出:

top - 23:56:10 up 108 days,  1:38,  1 user,  load average: 1.31, 1.73, 1.54
Tasks: 373 total,   2 running, 370 sleeping,   0 stopped,   1 zombie
%Cpu0  : 10.0 us,  2.3 sy,  0.0 ni, 87.0 id,  0.0 wa,  0.3 hi,  0.3 si,  0.0 st
%Cpu1  :  6.6 us,  7.9 sy,  0.0 ni, 83.8 id,  0.0 wa,  1.0 hi,  0.7 si,  0.0 st
%Cpu2  : 10.7 us,  3.3 sy,  0.0 ni, 85.3 id,  0.0 wa,  0.3 hi,  0.3 si,  0.0 st
%Cpu3  : 10.3 us,  3.6 sy,  0.0 ni, 83.4 id,  0.3 wa,  2.0 hi,  0.3 si,  0.0 st
MiB Mem :  23679.7 total,   3091.2 free,  13131.6 used,   7456.8 buff/cache
MiB Swap:   8192.0 total,   6207.6 free,   1984.4 used.   8940.7 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2021 ken       20   0 1448452 123008  73736 S  18.2   0.5 252:05.89 Xorg
 728039 ken       20   0  749048  52472  36696 S   6.9   0.2   6:54.61 gnome-system-mo

从前面的输出中，您可以看到我的笔记本电脑中有四个内核。可以看到平均负载大约为 1.33，这意味着我的四个 CPU 中大约有 1.33 个正在用于运行进程。

系统的工具

另一个有用的 CPU 统计命令是 mpstat 命令。“mpstat”命令显示每个可用 CPU 的活动。

要查看每个 CPU 的所有统计信息，可以运行以下命令:

# mpstat -P ALL

记忆

检查系统内存的一些方法包括查看/proc/meminfo 文件或运行类似“free”或“top”的命令。以下是您可以在系统上做的一些事情，以便更好地了解它的内存。

自由的

提供系统内存所需的所有信息的基本实用程序:

# free -h
        total    used    free   shared   buff/cache   available
Mem:     23Gi    12Gi   3.2Gi    1.2Gi        7.2Gi       8.8Gi
Swap:   8.0Gi   1.9Gi   6.1Gi

页面大小

如果您需要了解系统的页面大小，可以使用以下命令:

# getconf PAGESIZE

巨大的页面尺寸

在进行应用服务器调整时，可能会要求您启用或检查是否启用了大页面调整。您可以在/proc/meminfo 文件中检查这一点:

# cat /proc/meminfo |grep Hugepage
Hugepagesize:       2048 kB

最不发达国家

另一个有用的工具是“pmap”实用程序。"pmap"报告一个进程的内存映射。pmap“可以很有用的找到内存瓶颈的原因。

虚拟内存

偶尔确实会发生需要研究虚拟内存或 slabinfo 相关问题的情况。“vmstat”工具对于这种调查很有用。

显示虚拟内存状态

可以运行 vmstat 工具来提供关于您的系统的不同信息。

运行基本 vmstat 命令，如下所示:

# vmstat

将给出以下输出，在表 7-1 中有解释:

表 7-1

vmstat 输出说明

|

vmstat 列

|

描述

|
| --- | --- |
| r | 等待运行时的进程数 |
| b | 处于不间断睡眠状态的进程数 |
| swpd | 使用的虚拟内存 |
| free | 空闲内存 |
| buff | 用作缓冲区的内存 |
| cache | 用作缓存的内存 |
| si | 从磁盘换入的内存 |
| so | 内存交换到磁盘 |
| bi | 从块设备接收的块 |
| bo | 发送到块设备的块 |
| in | 每秒中断数 |
| cs | 每秒的上下文切换次数 |
| us | 运行非内核代码的时间百分比 |
| sy | 运行内核代码的时间百分比 |
| id | 空闲时间的百分比 |
| wa | 等待 IO 所用时间的百分比 |

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b  swpd     free     buff  cache    si  so  bi   bo  in  cs us sy id wa st
 0  0  2032024  2086144  1056  8923084   2   8  21  701  40  50 28 12 59  0  0

网络

当您需要排除故障或确认端口正在监听流量时，监控网络配置或流量的工具非常有用。以下是我过去用过的几个工具。

Netstat

当我需要检查端口是否在监听流量时，我倾向于使用的第一个工具是“netstat”命令。

“netstat”命令将显示网络连接、接口统计等。我用来检查哪些端口正在监听的最常用命令如下:

# nestat -nap | grep LIST
# netstat -planet

Note

Netstat 仍然是 net-tools 包的一部分，但在某个时候将被删除，因为 netstat 现在已经过时了；最好使用 ss 命令。

悬浮物

要获得一些关于套接字统计的快速信息，可以使用“ss”命令。

要在带有 ss 的 Linux 系统上查看所有 TCP 和 UDP 套接字，可以使用以下命令:

# ss -t -a

伊普鲁

如果您喜欢使用 initiative 工具来查看网络统计数据，您可以使用“iptraf”命令。“iptraf”可用于监控各种网络统计数据，包括 TCP 信息、UDP 计数、接口负载信息、IP 校验和错误以及其他有用信息的负载(图 7-1 )。

图 7-1。

# iptraf-ng

图 7-1 是打开 iptraf-ng 时呈现给你的画面。

当我需要监控特定接口的流量时，这个工具帮了我不少忙。它不是默认安装的，但是如果你还没有安装的话，绝对值得使用。

从主屏幕，您可以选择监控 IP 流量；在那里，您选择想要监控的接口，然后观察该接口上的连通性。

Tcpdump

大多数(如果不是全部)网络工程师会使用 wireshark 来监控网络流量。“tcpdump”命令允许 Linux sysadmin 转储特定网络接口、所有接口或特定服务(如 DHCP 或 DNS)上的流量。

如果您想要监控接口 eth0 上所有向端口 80 发送流量的流量，对于 web 服务器，您可以运行类似的命令:

# tcpdump -n -i eth0 -s 0 -w tcpdumpoutput.txt src or dst port 80

然后可以使用 wireshark 工具打开前面命令的输出文件(图 7-2 )。

图 7-2。

Note

一个有用的方法来寻找任何可能在您的网络上传输的明文。

网虫

如果您在 Linux 系统上遇到网络负载的高突发，并且想知道谁应该对此负责，您可以尝试“nethogs”工具来查看哪个 PID 导致了带宽情况(图 7-3 )。

图 7-3。

# nethogs

NetHogs 按进程名(如 Firefox 和 chrome)对带宽进行分组，如图 7-3 所示。

iftop

这是一个非常类似于“top”的简单命令，但用于界面信息(图 7-4 )。

图 7-4。

# iftop

从图 7-4 中，您可以看到 iftop 的布局类似于常规的 top 输出，只是更侧重于网络数据。

图形工具

Gnome 系统监控器

像 Gnome 这样的 Linux 桌面并不是没有你可以使用的监控工具。熟悉 Windows 的人都知道“任务管理器”，这是一个简单的工具，可以让你大致了解正在运行的进程和系统的当前性能。Gnome 系统监控器并没有太大的不同。第一个选项卡给出了进程列表，第二个选项卡列出了正在使用的 CPU 和内存资源，最后一个选项卡给出了已挂载文件系统的明细(图 7-5 )。

图 7-5。

从图 7-5 中，您可以看到当前在您的 Linux 系统上运行的所有进程。

克西斯加德

如果 Gnome 工具对您不起作用，您还可以使用名为 ksysguard 的 KDE 工具。Gnome 系统监控器和 KDE ksysguard 工具的区别在于 ksysguard 有监控远程系统的能力。可以创建新的选项卡，并且可以监控来自远程系统的不同资源。对于快速简单的监控工具非常有用，只需很少甚至不需要真正的配置工作(图 7-6 )。

图 7-6。

与 Gnome 系统监控器类似，您也可以查看系统上运行的所有进程，如图 7-6 所示。

历史监控数据

到目前为止，我们已经研究了一些可以在 Linux 发行版上使用的有用的监控工具，但是都有一个问题(可能除了 tcpdump)。这些工具都没有保存历史数据。显示的统计数据是当前时间来自系统的实时数据。一个简单的例子，想看看前一天的 CPU 负载情况。Top 和其他这样的命令没有任何用处。

这就是前面提到的工具用于当前系统活动和实时系统检查的原因。在问题发生后试图使用它们进行根本原因分析将会使您的选择有限。

特别行政区

查询历史系统指标的一个有用工具是“sar”“sar”实用程序随 sysstat 软件包一起安装。除了“sar”，sysstat 包还有其他一些实用程序，比如 iostat、mpstat 和 nfsiostat。

“sar”实用程序将系统统计信息和指标存储在本地系统文件中，以后可以查询这些文件中的系统统计信息。sar 文件可在以下位置找到:

/var/log/sa/

表 7-2 中解释了常见的 sar 参数。

表 7-2

sar 选项

|

转换

|

描述

|
| --- | --- |
| d | 块设备统计 |
| r | 内存利用率 |
| u | CPU 利用率 |
| F | 文件系统统计 |

性能副驾驶员

在我看来，一个比“sar”更好使用的工具是随 pcp 包一起安装的工具。pcp 包安装了一些用于指标查询和指标收集的有用工具。表 7-3 列出了与 pcp 包一起安装的工具。

表 7-3

电脑工具

|

名字

|

描述

|
| --- | --- |
| pmstat | 关于您的系统、CPU、内存等的实时信息。 |
| pminfo | 列出了可以查询的指标 |
| pmval | 查看度量数据 |
| pmlogger | 将度量数据存储到文件中，pmval 以后可以查询这些文件 |

vnstat

不要忘记网络指标，vnstat 工具是保存历史网络信息的另一个有用工具。vnstat 记录选定接口每小时、每天和每月的网络流量。

中央监控

现在对本地监控和指标收集工具有了很好的理解，我们现在可以转到开源世界中可用的中央监控工具。这些工具可用于从一个位置监控您的整个房产，并保留历史数据，以便日后进行潜在的根本原因分析。

纳吉奥斯

许多人可能知道并在某个时候开始使用的第一个工具是 Nagios。Nagios 是另一个递归的开源名称。纳吉奥斯的意思是“纳吉奥斯不会坚持要成为圣徒。”

版本

Nagios 有一个社区和一个付费产品，可以安装在大多数 Linux 发行版上。然而，CentOS 和 RHEL 是企业级 Nagios XI 产品现阶段的支持平台。然而，Nagios Core 可以安装在许多不同的 Linux 发行版上。如果您决定使用付费产品，最好与供应商讨论这些选项。

核心

Nagios 的社区支持版是核心版本，它提供了 Nagios 的基本监控功能，但是需要您使用社区论坛来获得帮助和支持。

那吉乌斯十一世

Nagios 的企业或付费解决方案附带了标准核心组件以及更多。这还包括通过电话和电子邮件对产品的所有支持。

基于代理的

Nagios 由一个服务器和基于代理的部署组成，带有一些可以使用的代理选项。

nrpe！nrpe

Nagios 远程插件执行器(NRPE)使用托管在客户端系统上的脚本。NRPE 可以监控磁盘使用、系统负载或登录用户总数等资源。Nagios 使用 check_nrpe 插件定期轮询远程系统上的代理。

NRPE 还可以与 Windows 代理插件通信，允许 Nagios 在远程 Windows 机器上执行脚本和检查指标。

Note

NRPE 已被弃用，在此仅供参考。

NRDP 的

NRDP 或 Nagios 远程数据处理器是您可以使用的另一个 Nagios 代理。NRDP 具有灵活的数据传输机制和处理器，允许 NRDP 轻松扩展和定制。NRDP 使用标准端口和协议(HTTP 和 XML ),可以用来代替 NSCA (Nagios 服务检查接受者)。

NSClient++

作为 Nagios 的 Windows 代理，NSClient++监听 TCP 端口直到 12489。用于从这个附加组件收集信息的 Nagios 插件称为 check_nt。

NSClient++类似于 NRPE，因为它允许 Nagios 监控内存使用、CPU 负载、磁盘使用等。

NCPA(全国大学生体育协会)

可以使用的最后一种试剂是 NCPA 试剂。NCPA 或 Nagios 跨平台代理是 Nagios Enterprises 维护的一个开源项目。

NCPA 可以安装在 Windows 和 Linux 上。与其他代理不同，NCPA 利用 API 为 Nagios 收集信息和度量。主动检查是通过“NCPA 监听器”服务的 API 完成的，而被动检查是通过“NCPA 被动”服务发送的。

Nagios Forks

也可以使用 Nagios 中的许多分支。Nagios 的一些分支如下:

  • 伊辛加

  • 守护进程

  • 真肯

所有这些都与 Nagios 有相似之处，但随着时间的推移，它们已经发展成了自己的解决方案。例如，Icinga 十多年来一直在开发自己的功能。

装置

Nagios 的安装可以通过几种方式完成，Nagios 文档站点上有很好的文档记录:

  • 遵循官方文档，一步一步地运行。

  • 构建虚拟机并运行自动化脚本。

  • 提取 Nagios 容器映像并运行容器。

推荐的方法是使用像 Ansible 这样的自动化工具在专用系统中部署 Nagios，但是为了快速测试和运行，请使用容器。

普罗米修斯

Prometheus 是一个开源警报和事件监控系统，它将数据存储在一个时间序列数据库中。Prometheus 是存储度量数据的中心位置，通常与其他软件配合使用，以提供整体监控解决方案。

出口商

出口商是普罗米修斯时间序列数据库的数据来源。在客户机或服务器系统上可以使用多个导出器。有专门的出口商用于不同的目的；在获取节点信息的情况下，有一个专用的 node_exporter，它将导出本地系统指标，如 CPU 或内存利用率。

警报工具

任何与其重量相当的监控平台都必须有一种方法来告诉 Linux 系统管理员什么时候出现了问题。这通常是您的警报工具。一个有用的开源工具是 Alertmanager，它可以用来触发基于 Prometheus 指标的警报。

仪表板

尽管 Prometheus 确实有一个可以用来查询指标的 web UI，但是将指标发送到仪表板工具更有意义。例如，Grafana 就是一个很好的选择，它是当今最流行的开源工具之一。

查询语言

PromQL 是用于创建仪表板和警报的查询语言。

装置

同样建议安装 Nagios，我会建议安装 Prometheus。文档非常清晰，并且经过深思熟虑。如果您想手动安装，安装步骤非常简单，但是我仍然建议您使用自动化方法。互联网上有很多可以为你做这件事的角色，或者，如果你愿意，也有一些容器映像可以用来部署一个容器。

忽必烈还是 openshift

像 Kubernetes 或 OpenShift 这样的平台也可以在其上部署 Prometheus，但它们往往用于平台本身。您需要创建一个新的名称空间，并部署您自己的 Prometheus 和 Grafana 来用于外部系统监控。

配置

一旦安装，普罗米修斯不需要太多的配置就可以开始。通常名为 prometheus.yaml 的简单 YAML 文件可用于所有配置。普罗米修斯官方网站的基本配置如下:

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']
全球的

全局部分用于普罗米修斯全局配置。例如，告诉普罗米修斯多久刮一次。

规则 _ 文件

rule_files 部分是我们希望 Prometheus 使用的自定义规则。这种情况下的示例配置没有任何 rule_files 可使用。

Scrape_configs

scrape_configs 部分告诉 Prometheus 要收集哪些指标。在配置示例中，将通过端口 9090 联系本地主机，并在/metrics 端点上搜索指标。

启动普罗米修斯

通常，监控平台应该从服务启动，Prometheus 也可以配置为这样做。在启动 Prometheus 时，您至少应该指定一个参数，这就是您正在使用的 Prometheus 配置文件的名称。

要手动启动 Prometheus，可以从 Prometheus 安装目录运行以下命令:

# ./prometheus --config.file=prometheus.yml

谢谢你

Prometheus monitoring 本身就相当不错，可以从一个简单的监控平台提供您可能想要的一切，除了可能的长期历史数据或高可用性。

这就是可以利用灭霸的地方。灭霸旨在提供一个高度可用的解决方案，可以从多个 Prometheus 部署中保持无限制的指标保留。

灭霸是以普罗米修斯为基础的，要求在同一个网络中至少有一个普罗米修斯实例。灭霸通过一系列组件管理指标收集和查询。

边车

sidecar 是允许灭霸连接到普罗米修斯实例的组件。然后，它可以读取数据进行查询或上传到云存储。

商店网关

这允许查询云对象存储桶内的度量数据。

压土机

这将压缩或压缩数据，并对存储在云存储桶中的数据应用保留。

接收器

这是负责从 Prometheus 的远程写入功能接收数据的组件。接收者还可以公开指标或将其上传到云存储。

尺子/规则

这用于根据灭霸的数据评估记录和警报规则。

问题

这利用了 Prometheus 的 v1 API 从底层组件获取和查询数据。

查询前端

通过使用 Prometheus 的 v1 API，查询前端可以一次评估所有实例的 PromQL 查询。

灭霸基本布局

图 7-7 是各种灭霸组件如何相互通信的基本示意图。

图 7-7。

企业监控

对拥有不同团队的大型组织进行监控通常是一个有争议的话题，主要是因为不同的团队都希望使用更适合他们的工具。有一些优秀的专有 Windows 工具，也有相当好的开源 Linux 工具可以使用。因为这本书关注的是开源技术和 Linux 的采用，所以让我们简单看一下您可以使用的一些开源企业监控工具。

扎比克斯

Zabbix 是一个很好的企业级监控工具，可以用来监控您的资产。Zabbix 引以为豪的是，他们可以监控从服务器平台到网络系统的任何东西。Zabbix 是一个基于服务器和代理的系统，但也可以在不使用代理的情况下监控一些设施。

企业支持

Zabbix 有一个付费的支持设施，可以用于企业支持，或者你可以通过社区论坛来支持自己。

装置

安装相对简单，在 Zabbix 网站上有很好的文档。他们有一种非常好的方式，通过一系列基于您的偏好的选择框来呈现安装步骤。

有用的功能

Zabbix 可以提供一些非常好的特性。例如，直接通过 JMX 监控基于 Java 的应用程序的能力，使用 VMware 工具监控虚拟机的能力，以及与 Puppet 或 Chef 等系统管理工具集成的能力。

CheckMk

另一个很好的企业监控工具是 CheckMk。CheckMk 是一个像 Zabbix 一样的可扩展解决方案，可以监控从标准 Linux 平台到物联网设备的各种系统。

企业支持

CheckMk 提供了一个免费版本和一个企业付费解决方案，免费版本具有无限的监控功能，您可以在其中支持自己，企业付费解决方案具有额外的功能。

装置

支持主要的企业 Linux 发行版，CheckMk 文档中有关于您正在使用的发行版的详细步骤。

有用的功能

CheckMk 一直着眼于未来构建他们的平台。他们内置了监控 Docker、Kubernetes 和 Azure 等工具。

整体解决方案是可扩展的，并且将在具有分布式布局(多个数据中心)的大型组织中很好地工作。自动化是确保配置和设置尽可能简单的主要开发点之一。

OpenNMS(打开 NMS)

我安装的第一个监控工具是 OpenNMS，那是很多年前我第一次接触开源技术的时候。在为这本书进行研究时，我印象深刻地看到，OpenNMS 不仅仍然是一个开发的产品，而且看起来也非常令人印象深刻。

企业支持

像大多数企业平台一样，通常有两种选择:带有社区支持的“免费”版本和企业付费版本。

OpenNMS 版本如下:

  • Horizon:社区驱动和支持的版本

  • Meridian:基于订阅的服务，提供最新稳定的企业版

装置

OpenNMS 的安装不像其他可用的工具那么简单，但同时安装起来也并不十分困难。官方文档足够清晰，并且会一步一步地指导您完成所有需要做的事情。如果你遇到困难，也有一个很好的社区论坛来回答问题。

有用的功能

真正突出的一个特性是 OpenNMS 使用 Grafana 作为仪表板工具，在我看来，这是一个非常好的举措，这主要是因为当今越来越多的用户正在开发自己的仪表板。

OpenNMS 指标也可以通过多种方法收集，包括 JMX、WMI、HTML、XML 等等。

仪表盘

监控的一个方面几乎与收集的指标一样重要，那就是以有意义的格式查看指标的能力。这就是仪表板工具至关重要的地方。

这些年来，我遇到过一些监控工具，它们过去和现在都很好，但在浏览器中看起来很糟糕。对于一些应用程序监控工具，我还发现仪表板很难配置。调整窗口大小是一场噩梦，连接外部工具总是不可能。

似乎我不是唯一一个受这些工具困扰的人，一些聪明人已经开始开发专用的仪表板工具，可以与各种工具集成。

仪表板工具

表 7-4 列出了一些现在可以使用的仪表板工具。

表 7-4

仪表板工具

|

名字

|

描述

|
| --- | --- |
| Grafana | 当今最流行的仪表板工具。最初发布于 2013 年 |
| Chronograf | 如果您的大部分指标来自 InfluxDB 数据库，这将是一个非常好的工具 |
| Netdata | 一个基于插件的仪表板工具，支持度量显示的推拉架构 |
| Kibana | 主要与 Elasticsearch 和 Logstash 一起使用，以形成 ELK 堆栈 |

格拉凡娜

由于 Grafana 是当今最受欢迎的工具，因此值得探究 Grafana 提供了什么。

格拉夫纳是什么

Grafana 是一个开源的基于插件的仪表板工具，具有广泛的数据源选项，可用于显示指标而无需复制任何数据。Grafana 几乎可以部署在今天使用的所有平台上，从 Windows 到 Debian(图 7-8 )。

图 7-8。

Grafana 仪表板的基本示例如图 7-8 所示。

使用 Grafana

有几种方法可以使用 Grafana:

  • 在内部安装您自己的环境。

  • 使用托管的 Grafana 云服务。

云服务

如果您不想在本地运行自己的 Grafana 实例，可以在云中运行您的仪表板。免费的永久计划包括 Grafana，10K 普罗米修斯系列，50 GB 日志，等等。

现场安装

Grafana 有几种部署方式:

  • 按照 Grafana 文档页面上的官方文档进行手动安装。

  • 使用 podman 提取预构建的 Grafana 容器映像，并运行 Grafana 容器。

Recommendation

使用像 Ansible 这样的自动化工具，并下载一个预构建的 Ansible 角色来为您进行部署。

数据源

在创建仪表板之前，您需要有一个从中提取指标数据的源。这些是你的数据来源。在尝试创建仪表板之前，您需要创建一个数据源。Grafana 支持许多数据源，包括以下一些:

  • Alertmanager

  • AWS 云观察

  • Azure 监控器

  • 弹性搜索

  • InfluxDB

  • 关系型数据库

  • 一种数据库系统

  • 普罗米修斯

  • 贼鸥

仪表板创建

一旦有了数据源，就可以开始创建仪表板了。Grafana 能够创建许多不同的仪表板，当您首次登录时，可以从 Grafana 主屏幕创建这些仪表板。

如果您希望下载预构建的仪表板或希望共享您的配置，可以导入和导出仪表板。

嵌板

一旦您有了第一个仪表板，您将想要开始创建您的指标可视化。为此，仪表板使用面板。可以使用多个面板来显示您从预配置的数据源中选择的指标。每个面板都有一个特定于面板中所选数据源的查询编辑器(图 7-9 )。

图 7-9。

可以复制面板以进行快速配置，并且可以定制为您的时间序列数据使用不同的颜色，如图 7-9 所示。

行

要排列所有面板，您需要创建行；行是所有面板的逻辑分隔线。为了便于组织，可以将面板拖到不同的行中。

救援

当您添加了新的面板或行时，请始终记住保存您的仪表板。如果您碰巧打开了一个新的仪表板，您的更改将会丢失。

应用程序监控

应用程序监控是一种特殊的监控，它可能有点复杂，而且通常在资源和时间上都更昂贵。应用程序监控要求基础设施工具和开发应用程序的开发人员公开可以监控的指标。

跟踪工具

跟踪工具通过使用专门的日志记录来“跟踪”应用程序及其事务的执行路径。通常，开发人员使用这些来帮助确定特定问题发生的位置。

不应将跟踪与事件监控相混淆。事件监控主要由 Linux 系统管理员用于高级故障排除，通常不会太“嘈杂”在那里，用“追踪”噪声是好的。信息越多，故障排除就越能准确地缩小根本原因的范围。

现在有一些可以使用的跟踪工具。像 AppDynamics 这样的专有平台是具有丰富功能的优秀工具，但价格昂贵。幸运的是，也有开源的选择，因为我们主要关注的是开源的，我们可以跳过那些不开源的。

贼鸥

Jaeger 最初由优步开源，其灵感来自于 OpenZipkin 和 Dapper 项目，用于监控和故障排除基于微服务的分布式系统。因此，耶格承诺帮助解决以下问题:

  • 分布式事务监控

  • 性能和延迟优化

  • 根本原因分析

  • 服务依赖分析

  • 分布式上下文传播

分布式跟踪

在 Jaeger 之前，Zipkin 是作为基于 Google Dapper 项目的开源项目开发的。Zipkin 是一个基于 Java 的应用程序，它为用户提供了一个界面来查看来自一系列数据后端的跟踪数据。Zipkin 支持 RabbitMQ 和 Kafka 这样的传输机制。

Zipkin 可以作为容器部署，也可以通过下载最新的二进制文件在本地运行。所有这些步骤在 Zipkin 官方网站上都有详细的记录。

公开指标

监控工具的好坏取决于它们所能收集的数据。对于标准平台监控，可以使用代理提取指标，这些代理反过来与运行它们的系统对话，以返回它们需要的数据。然而，应用程序需要从应用程序内部公开数据，以便监控代理可以将数据传递给监控平台。在那里，可以配置警报以及任何控制面板。

“开发者”怎么讲

作为 Linux 系统管理员，我们需要构建包含应用程序指标的监控系统；为此，开发人员需要确保编写的代码能够公开指标。开发可以使用 Jaeger 这样的追踪软件追踪的应用程序也是如此。

在尝试诊断问题时，与开发人员进行对话并构建概念验证应用程序来展示跟踪的好处以及公开的应用程序指标是至关重要的。随着您的应用程序组合的增长，拥有这些工具将大大减少潜在的停机时间和消防。尽早构建这些良好的实践比以后再尝试改进它们更值得。如果您的应用程序使用第三方，这可能会更加困难。

摘要

在本章中，向您介绍了以下内容:

  • 什么样的监控工具可以从标准的 Linux 发行版中运行

  • 可以从 Linux 桌面使用的图形替代监控工具

  • 什么工具可以用来在标准 Linux 发行版上存储历史指标数据

  • Nagios、Prometheus 和灭霸等中央监控解决方案

  • 企业监控开源工具，如 OpenNMS 和 CheckMk

  • 可以用来以简洁的方式显示度量数据的仪表板工具

  • 用于跟踪的应用程序监控工具，以及应用程序指标对资产管理的重要性

八、日志记录

在这一章中，我们将重点讨论一个我们作为 Linux 系统管理员花费大部分时间进行故障诊断的主题:日志。

我们将探索您可以使用的不同日志记录系统，如何读取日志，如何增加我们从日志中获得的信息，以及如何保护我们的系统，使日志不会给我们带来更多问题。最后，我们将探索日志应该如何以简洁和安全的方式卸载到外部日志记录系统。

Linux 日志系统

有几个不同的选项可用于系统和应用程序日志。默认情况下，所有 Linux 系统都安装了 syslog 来管理本地日志。有一些 syslog 的替代品可以使用，或者您可以选择开发自己的系统。

我们将简要介绍的两个日志系统是 Rsyslog 和 Fluentd。

rsyslog(rsyslog)

Rsyslog 默认安装在所有 Linux 系统上，并且几乎总是被使用，它是一个非常快速的日志记录系统，能够从运行在 Linux 平台上的几乎所有系统接收日志。Rsyslog 不仅可以从任何地方接收日志，还可以将日志从文件卸载到 MongoDB。

模块化的

Rsyslog 以模块化的方式设计，允许用户选择他们想要使用 rsyslog 的内容。目前有许多可用的模块，从 snmp 陷阱配置到内核日志。有关您可以使用的所有不同模块的完整列表，请访问 rsyslog 官方网站:

www.rsyslog.com/doc/v8-stable/configuration/modules/index.html

装置

如果由于某种非常奇怪的原因，rsyslog 没有被默认安装，您可以从您的标准包管理系统安装，比如 dnf 或 apt:

# dnf install rsyslog

如果您选择将 rsyslog 容器用作中央日志记录系统，也可以运行它。需要围绕存储和连接进行更多思考。

服务

默认情况下，rsyslog 服务处于启用和启动状态，但可以通过标准的 systemd 方式停止或禁用:

# systemctl status rsyslog

配置文件

rsyslog 的配置文件通过两个配置位置进行处理:

  • 整体中央配置文件"/etc/rsyslog.conf"

  • 的”。d "要存储的自定义配置文件的目录"/etc/rsyslog.d/"

您需要熟悉 Rsyslog 配置的三个主要部分:

  • 全球指令

  • 模板

  • 规则和操作

全球指令

rsyslog 的通用全局配置。示例包括启用和禁用附加模块和库位置。

模板

模板使您能够格式化记录日志的方式，并允许动态生成文件名。如果您正在构建一个中央 rsyslog 系统，并且想要记录发送日志的系统的主机名，那么这是一个非常有用的配置。

规则

规则由选择器和操作组成。这些字段设置了将记录的内容以及日志将发送到的位置。

选择器字段

选择器字段由两部分组成，设施和优先级。这两部分由“.”分开性格。

以下条目是有效的工具类型:auth、authpriv、cron、daemon、kern、lpr、mail、news、syslog、user、uucp 和 local0 到 local7。

以下条目是可以使用的有效优先级:调试、信息、通知、警告、错误、关键、警报、紧急。

通配符“*”可用于替换区段字段的设施和优先级中的一个或两个。

选择器字段的示例可以是“*.*”、“auth.*”和“auth.debug”。

行动领域

动作字段通常由日志文件的位置组成。但是，如果您愿意，其他操作也可以应用于特定的选择器。例如，写入数据库或将日志文件发送到远程日志系统。

行动也可以相当灵活；可以配置不同的协议、端口和接口来向远程系统发送日志。如果您运行一个专用的日志记录网络而不影响生产网络，这是很有用的。

Tip

利用不同的选择器来监控系统中不同文件中的关键错误。然后，这些日志可以导出到远程系统，以便在仪表板上立即发出警报。

流利

Fluentd 是一个开源项目，最初由一家名为 Treasure Data 的公司创建。

基于插件

Fluentd 是用 C 和 Ruby 编写的，它让用户能够灵活地使用 Fluentd。Fluentd 拥有超过 125 个用于输入和输出的插件，几乎可以用于任何可用的系统或云提供商。

大规模使用

使用 Fluentd 运行大规模环境是完全可能的，用户案例报告称 Fluentd 可以处理超过 50，000 个发送数据的系统。

装置

Fluentd 可以通过几种方式安装:标准包安装、从源代码安装或从容器运行。

先决条件

安装 Fluentd 之前，需要满足几个先决条件:

  • 配置 NTP。

  • 将最大文件描述符增加到 65535。

  • 针对性能敏感型环境优化网络内核参数。

  • 使用粘滞位符号链接/硬链接保护。

关于这些先决条件的更多信息可以在 Fluentd 的官方安装文档中找到。

手动安装

根据您的系统，可以通过运行与您的发行版匹配的脚本或安装所需的 Ruby gems 来安装 Fluentd。对于不受支持的平台，建议使用 gem 安装；对于受支持的平台，如 RHEL，建议使用 Fluentd 提供的脚本进行安装。

详细步骤应始终遵循官方文档。

集装箱部署

Fluentd 也可以作为容器来部署，并且经常以这种方式部署。官方文档详细强调了成功部署需要遵循的所有步骤。

基本的高级步骤如下:

  1. 从可靠或可信的来源获取 Fluentd 容器映像。

  2. 创建一个基本的 fluentd.conf 配置文件。

  3. 运行容器并发送日志。

Note

除了前面的步骤，还会有更多的步骤。此外，不要忘记你的防火墙。

配置

Fluentd 的主要配置文件是 fluentd.conf 文件。可以在官方在线文档或手册页中找到配置参数。基本配置文件如下所示:

<source>
  @type http
  port 9880
  bind 0.0.0.0
</source>
<match **>
  @type stdout
</match>

理解日志

让日志可用是发现或防止问题的第一步。理解日志实际告诉你的是另一个非常重要的步骤。

日志文件在哪里

在所有主要的企业级 Linux 发行版中，日志文件通常存储在“/var/log”目录中。这个目录通常应该安装在一个单独的磁盘分区上，以避免根文件系统在发生任何失控的日志记录时被填满。

Tip

如果您遵循任何强化准则，则/var/log 应该始终位于单独的分区上。

如何读取日志文件

可以使用安装在 Linux 发行版上的各种工具来查看日志。在普通系统上，您至少可以使用“vi”工具，但是您可以安装和使用任何您更喜欢的文本编辑器。

Warning

不要在生产系统上使用 vim 之类的工具打开几千兆字节大小的大型日志文件。文件内容将消耗大量内存，并可能导致您的问题。将大型日志复制到不同的系统以避免任何问题。

基础设施日志

告诉您关于 Linux 系统的事件、服务和系统的所有信息的日志是您的基础设施日志。这些日志是在 rsyslog.conf 配置文件中配置的标准日志，告诉您系统在后台正在做什么。这些日志将用于对任何系统问题进行故障排除，并可用于在问题发生前查找问题。

重要日志

应该监控系统问题的日志如下。

/var/日志/消息

该日志用于存储有关系统的所有一般事件和信息。其他发行版如 Ubuntu 或 Debian 使用一个名为 syslog 的日志文件。如果您需要对任何问题进行故障诊断，该日志应该始终是您首先检查的地方之一。它可能没有所有的信息，但当你不知道从哪里开始时，它可以让你开始。

/var/log/secure

该日志文件用于身份验证事件。这个日志或 Ubuntu 和 Debian 中的/var/log/auth.log 是解决认证失败或登录尝试的最佳起点。

/var/log/boot.log

这一个的目的相当简单。这用于解决与引导相关的问题。这是一个非常有用的日志，可以用来查看系统停机的时间。

dmesg 日志所在位置

这用于记录有关系统硬件更改和故障的信息。如果您在检测添加或删除新硬件时遇到问题，这将非常有用。

(登录中)

如果使用 yum 作为软件包管理系统的发行版，您可以看到所有添加、更新或删除的软件包的历史记录。

在哪里登录/cron

这是一个简单的日志，用于捕获所有成功或失败的 cron 相关任务。

应用程序日志

根据您的应用程序或您使用的应用服务器，日志文件可以存储在任何地方。应用程序开发人员需要确保记录重要信息，以便解决问题或跟踪事件。增加或减少冗长的能力也应该包括在内。

良好实践

应用程序日志记录的一些良好实践应该包括以下内容。

对日志使用/var/log 目录

确保所有日志都在/var/log 目录中，最好是在应用程序专用的子目录下。如果应用程序无法调整日志的发送位置，则可以将它们的目录符号链接到/var/log 目录。

安全

在保存长期历史记录时，应该保护包含敏感信息的日志。日志目录的权限应该锁定给有权读取日志的用户和组。ACL 的使用有助于保持日志的安全。

警告或以上

生产中的日志绝不能处于调试模式。日志应仅设置为警告或错误。这将使日志保持较小，并且仅在出现问题或报告错误时才进行报告。将日志级别设置得太低会导致/var/log 磁盘被填满。

Warning

在生产中调试从来都不是一个好主意。如果经常需要这样做，那么您的应用程序没有得到正确的测试，应该建议您不要部署新版本，除非经过严格的测试。

增加冗长度

当问题发生时，可能需要获得比已经提供的更多的信息。

日志详细级别

编写良好的应用程序或平台都倾向于能够增加或减少日志的详细程度。在设置日志记录级别时，用户通常可以使用以下日志级别:

  • 致命的

  • 错误

  • 警告

  • 信息

  • 调试

  • 微量

生产应用程序或平台的默认设置通常应该设置为“警告”或“错误”如前所述，不建议在生产中调试，原因有二:

  1. 打开调试通常需要重启应用程序或平台，当平台上有实时流量时，这并不容易做到。

  2. 调试将增加磁盘使用量，并增加系统的额外负载。如果应用程序或平台出现重大问题，调试日志可能会快速增长，并可能会填满所有日志磁盘。

然而，当出现非常罕见的需求时，将日志详细度设置为“Debug”肯定会记录更多的信息，但会被限制为应用程序或平台认为是调试消息的信息。要得到你需要的信息，最好是从“警告”开始，一直到“追踪”，直到得到你需要的信息。一旦完成，总是将日志级别设置回“警告”或“错误”

日志维护

一个好的 Linux 系统管理员会确保所有的日志在不被使用的时候被循环使用和归档。一个优秀的 Linux 系统管理员将日志维护内置到所有的系统配置自动化中，再也不用担心这个问题了。

如果您以前从未管理过日志，则以下情况很可能是真的:

  • 到目前为止，你很幸运。

  • 您支持的平台没有记录足够的信息，因此不会成为问题。

  • 日志被转发到由其他人管理的专用日志平台。

日志管理工具

Logrotate

对于任何 Linux 系统管理员来说，进行日志维护的第一步是配置 Logrotate。Logrotate 可以旋转、压缩和邮寄日志文件。Logrotate 由以下配置文件和目录管理:

  • /etc/logrotate.conf 文件

    • 用于全局配置

  • /etc/logrotate.d

    • 自定义配置文件
装置

缺省情况下，Logrotate 安装在所有 enterprise Linux 发行版和大多数社区发行版上。

Logrotate 通过其手册页提供文档，为您提供足够的入门信息，包括示例。

日志转发

日志转发是当今大多数人的首选。像 Fluentd 这样的企业工具是将本地日志转移到一个中心位置的好方法。它消除了本地系统长期保留日志的需要，并减少了磁盘占用空间。

中央测井系统

现在有一些可以使用的中央日志记录系统，既有专有的也有开源的。在过去十年中，中央日志领域的知名公司有 Splunk、网络安全管理软件产品、Rsyslog、ElasticStack 和 Fluentd。最后三个是开源的，值得花时间去了解。

弹性堆叠

也称为 ELK stack，由表 8-1 中列出的四种工具组成。

表 8-1

弹性堆叠工具

|

工具

|

描述

|
| --- | --- |
| Elasticsearch | 用于日志分析和搜索 |
| Kibana | 弹性搜索的用户界面 |
| Logstash | 用于日志摄取 |
| Beats | 用于向 Logstash 发送日志记录信息的代理 |

流利

正如本章前面所讨论的，Fluentd 可以用作本地日志记录的替代品，也可以用作集中式日志记录平台。要将 Fluentd 用作中央日志记录平台，您的网络中需要有两个元素。

日志转发器

日志转发器监控本地系统上的日志，筛选所需的信息，然后将信息发送到中央系统。对于 Fluentd，这将是一个日志聚合器。

Fluentd 有一个名为 Fluent Bit 的日志转发器，Fluentd 推荐使用。

Fluentd 转发器配置的示例如下所示:

<source>
  @type forward
  port 24224
</source>
<source>
  @type http
  port 8888
</source>
<match example.**>
  @type forward
  <server>
    host 192.168.100.1
    port 24224
  </server>
  <buffer>
    flush_interval 60s
  </buffer>
</match>
日志聚合器

日志转发器的目的地是日志聚合器。它们由不断运行并接受日志信息进行存储的守护程序组成。然后，可以将日志导出或迁移到云环境中进行异地存储。

Fluentd 日志聚合配置示例可能类似于以下内容:

<source>
  @type forward
  port 24224
</source>
# Output
<match example.**>
  # Do some stuff with the log information
</match>

rsyslog(rsyslog)

如果您不想使用标准 enterprise Linux 发行版之外的任何东西，您可以坚持使用 Rsyslog 进行集中日志记录。

Rsyslog 聚合器

与 Fluentd 配置为使用日志转发器和聚合器非常相似，Rsyslog 也可以配置为使用日志转发器和聚合器。Rsyslog 可以配置为通过 tcp 或 udp 发送和接收日志。Rsyslog 也可以配置为使用证书安全地发送和接收日志。

作为 Rsyslog 服务器作为中央日志记录系统接收日志的最低要求，您需要确保具备以下条件:

  1. 防火墙被禁用或配置为允许 tcp/udp 端口 514 或 6514，这取决于您是否使用转发日志的证书方法。

  2. 如果启用了 SELinux，您将需要配置 SELinux 以允许 rsyslog 流量将消息记录到您的中央系统:

    semanage -a -t syslogd_port_t -p tcp 514
semanage -a -t syslogd_port_t -p udp 514

  3. 配置 NTP。

  4. 配置 rsyslog.conf 使模块能够接收日志:

    $ModLoad imtcp
$InputTCPServerRun 514

  5. 重新启动 rsyslog 服务。

Rsyslog 货运代理

要将日志发送到中央 Rsyslog 服务器，还需要在 Linux 客户机系统上配置 rsyslog.conf 文件，以便将日志发送到中央服务器。使用 tcp 集中发送所有日志的简单配置如下:

*.*  @@192.168.0.1:514

Note

一个@用于 udp，而两个@@用于通过 tcp 发送。

与中央 Rsyslog 服务器一样，一旦更新了配置文件 rsyslog.conf，就需要重新启动 rsyslog 服务:

# systemctl restart rsyslog

摘要

在本章中，向您介绍了以下内容:

  • 不同的 Linux 日志系统，包括 rsyslog 如何被 Fluentd 取代

  • 如何理解日志以及在哪里可以找到它们

  • Linux 系统中的重要日志是什么，这些日志有什么用途

  • 日志维护以及可以使用什么工具来防止日志填满您的 Linux 系统

  • 可以使用什么将日志发送到中央日志记录系统

九、安全

安全性是作为 Linux 系统管理员可以讨论的最重要的主题之一。所有组织都至少需要最低限度的安全性，以避免被寻找简单目标的随机黑客暴露或破坏。

像银行这样的大型组织需要高度重视安全性，并且需要不惜一切代价确保它们受到保护。这将包括确保系统被强化到第 n 级。

本章将重点介绍如何加强安全性，以及如何检查系统以确保它们不仅符合良好的安全实践，还符合合规性法规。在本章中，我们将探索开源社区中可以用来构建安全平台的不同工具，以及如何验证系统是否尽可能安全。

最后，我们将讨论 DevSecOps 以及文化的改变如何提高安全性。我们将看看今天的 DevSecOps 实践如何改进保护 Linux 系统的过程。

Linux 安全性

构建和配置安全 Linux 环境的传统方法是利用防火墙、SELinux，在某些情况下还会使用防病毒软件。

然而，今天我们在我们的资产中部署的不仅仅是标准的 Linux 系统。有容器映像、虚拟机映像和云实例映像等等。如何检查这些映像上的漏洞，以及如何检查用于运行您组织的应用程序的第三方软件？

作为一名 Linux 系统管理员，您如何在不妨碍日常工作的情况下管理这些风险呢？有什么工具可以简化这一流程，并确保发放到您遗产中的所有东西都是安全的？

让我们先来看看标准的 Linux 安全性，它可以在您的 Linux 发行版上轻松配置。然后看看文化的改变和新的工具如何为新的构建和部署简化这个过程。

标准 Linux 安全工具

开箱即用，大多数 Linux 发行版都已经安装了工具，或者可以安装工具，这将允许您在基本级别上保护平台。常见的工具有防火墙、SELinux 和一些入侵检测。

防火墙

对 Linux 防火墙的基本描述是，Netfilter 工具集允许在 Linux 内核模块级别访问网络堆栈。

要为 Netfilter 配置规则集，您需要一个规则集创建工具。默认情况下，所有企业 Linux 系统都安装了防火墙规则集工具，某些云映像版本除外。这些图像往往更加精简，并不总是包括防火墙工具。这是因为保护应该在云协调层处理。

大多数 Linux 发行版安装了 iptables 或 firewalld 作为它们的规则集工具。这两个选项都有高度的配置，可以用来保护您的 Linux 系统。

Iptables

以前的 Linux 发行版和一些决定不继续使用 systemd 的发行版仍然使用防火墙规则集配置工具 iptables。Iptables 可能会变得很复杂，但是如果你有一个基本的理解，并且知道如何检查一个规则是否已经被启用，那么你就已经做得很好了(表 9-1 )。

表 9-1

基本 iptables 命令

|

LVM 司令部

|

描述

|
| --- | --- |
| iptables -L -n | 以数字格式列出所有链中的所有规则 |
| iptables --help | 关于可用参数的帮助 |
| iptables -A INPUT -p tcp --dport 22 -j ACCEPT | 添加 tcp 端口 22 的示例 |
| iptables -F | 刷新 iptables 配置中的所有规则 |
| iptables-save > /etc/iptables/rules.v4 | 在 Debian/Ubuntu 上保存 iptables 配置 |
| iptables-save > /etc/sysconfig/iptables | 在 RHEL 上保存 iptables 配置 |

防火墙！防火墙

如果您使用的是企业版的 Linux，那么您很可能会使用 systemd。使用 systemd，您将使用 firewalld 作为 Netfilter 的规则集配置工具。

Firewalld 的设计比 iptables 更简单易用。像 iptables 一样，Firewalld 有一些所有 Linux 系统管理员都应该知道的命令。表 9-2 列出了一些需要记住的基本命令。

表 9-2

基本防火墙命令

|

LVM 司令部

|

描述

|
| --- | --- |
| firewall-cmd --list-all | 列出当前配置的所有规则 |
| firewall-cmd --add-port=80/tcp --permanent | 打开 tcp 端口 80 |
| firewall-cmd --add-service=ssh --permanent | 通过引用服务名打开端口 22 |
| firewall-cmd --help | 帮助 |
| firewall-cmd --reload | 重新加载防火墙以启用新规则 |

Tip

如果可能，请使用 firewall-cmd，并且永远不要禁用防火墙服务。相反，了解需要哪些端口并打开这些端口，而不是让整个系统都打开。

防火墙

另一种在大多数 Linux 发行版上使用的安全措施是 SELinux，它最初是由美国国家安全局概念化和开发的。

总之，SELinux 是一个 Linux 内核安全模块，它允许访问 Linux 操作系统的某些部分。

如果你把你的 Linux 系统想象成一个安全的建筑，那么外面的栅栏和墙、大门、主门和窗户就是你的防火墙。安全建筑的内部及其房间和设施由值班保安人员管理。安全人员的工作是检查谁有权使用什么房间和什么设施。在这种情况下，安全团队将充当 SELinux。

正如你需要理解你的 Linux 防火墙的基础一样，你也需要理解 SELinux 的基础(表 9-3 )。现在，您需要知道的是如何启用、禁用和恢复基本配置。更复杂的配置会随着经验而来。

表 9-3

基本 SELinux 命令

|

LVM 司令部

|

描述

|
| --- | --- |
| getenforce | 显示当前 SELinux 状态 |
| setenforce 0 | 暂时禁用 SELinux |
| setenforce 1 | 临时启用 SELinux |
| /etc/selinux/config | 配置 SELinux 的永久状态 |
| restorecon -Rvv /path/to/file | 通过目录上的当前标签恢复 SELinux 配置集 |

有两种入侵检测可用于任何服务器资产:基于主机的入侵检测和基于网络的入侵检测。出于本书的目的，我们将只讨论我们可以在我们的 Linux 平台上部署什么。

基于主机的入侵检测

大多数 Linux 系统管理员经常忽略并且没有配置某种形式的基于主机的入侵检测。在大多数 Linux 企业发行版上，至少应该安装以下选项之一。如果没有，你可能需要从社区库安装，如 EPEL。

表 9-4 列出了一些可用于基于主机的入侵检测的选项。

表 9-4

入侵检测选项

|

工具名称

|

描述

|
| --- | --- |
| Aide | 标准存储库提供了高级入侵检测环境 |
| Fail2ban | 另一个流行的入侵检测解决方案，但是需要从某些发行版上的 EPEL 库安装 |
| Samhain | 完整性检查器和主机入侵检测系统 |

Warning

当从社区存储库安装时，如果您安装第三方工具，请务必咨询您的 Linux 供应商是否支持该平台。

推荐的 Linux 安全配置

如果您需要快速构建一个 Linux 系统，并希望确保它尽可能安全，那么您至少应该配置以下内容。

禁用 Root 登录

通过编辑 sshd_config，禁用通过 ssh 登录到 root 的功能。您仍然可以通过控制台登录，或者如果您需要通过单用户模式来拯救您的系统。

最小安装

用选择的最小软件包安装您的 Linux 服务器。最好从一个基本的构建开始，然后添加您需要的包。在构建安全的 Linux 服务器时，少即是多。

磁盘分区

表 9-5 列出了所有应该配置相应挂载选项的独立磁盘分区。

表 9-5

磁盘布局和装载选项

|

唱片

|

装载选项

|
| --- | --- |
| /var |   |
| /var/log |   |
| /var/log/audit |   |
| /var/tmp | 挂载到与/tmp 相同的磁盘上 |
| /tmp | nodev， nosuid， noexec |
| /home | 转移 |
| /dev/shm | nodev， nosuid， noexec |
| removable media | nodev， nosuid， noexec |

磁盘加密

仅当服务器可以轻松带出数据中心或服务器机房时，才考虑使用磁盘加密。这将适用于笔记本电脑或任何便携式系统。一个常用的磁盘加密工具是 LUKS。

没有桌面

不要安装 Linux 桌面或“X Windows 系统”如果已安装，请删除桌面和“X Windows 系统”软件包。

Remember

在尝试删除包之前，请将运行级别设置为 3。

加密网络通信

尽可能使用加密通信。打开 ssh 连接时使用证书或密钥。使用安全的方法挂载网络文件系统，无需传输明文密码。

删除和禁用不安全或未使用的服务

删除潜在的不安全软件包，如 telnet 或 ftp，并使用安全版本，如 sftp。还建议删除或禁用未使用的服务。

应用更新和修补内核

听起来显而易见，但是请确保您的 Linux 系统已经被修补到最新的版本。一旦你确认你的系统可以很好的使用新的内核，升级内核并移除旧的内核。

SELinux 和防火墙

确保 SELinux 和 Linux 防火墙都已启用，并且有必要的配置。

改进的身份验证配置

如果强制使用本地用户，请为 Linux 用户帐户配置密码时效，确保不能使用以前使用过的密码，并在登录失败后锁定帐户。最后，确保没有帐户的密码为空。

如果可能的话，使用中央用户认证服务，比如使用 Kerberos 认证的 LDAP 服务器。

检查打开的端口

检查当前打开了哪些端口，并验证是否有任何端口不应该打开。检查本地主机上打开了哪些端口的一个非常有用的命令如下:

# nmap -sT -O localhost

全局可写文件

检查是否有任何可写的文件或目录。检查这一点的有用命令如下:

# find /dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

不属于任何人的文件

Linux 系统上不属于任何人的任何文件都可能带来潜在的安全风险。使用以下命令检查任何文件:

# find /dir -xdev \( -nouser -o -nogroup \) -print

美国学术团体委员会

使用 ACL 为需要访问系统的用户配置对磁盘和文件的特定权限。不要为非管理员用户打开系统范围的权限。

将日志发送到中央日志记录服务

配置所有的 Linux 系统，将日志发送到中央日志服务。这将确保您在清除日志之前跟踪所有登录尝试。

入侵检测

安装和配置入侵检测工具，如 Aide 或 Fail2ban。如果使用 Aide，请确保将数据库复制到被监控的服务器之外的安全位置。这可以在以后用于比较目的。

应用服务器安全性

如果将 Linux 系统用作 web 服务器或应用程序服务器，请确保为安全通信配置了证书。

发展合作

所有这些安全措施都取决于应用它们的人。如果一个组织没有接受安全不仅仅是安全团队的责任这一事实，那么当出现安全漏洞时，那些令人讨厌的人就会有机可乘。这就是为什么文化安全观必须有所发展。

过去几年中，组织文化上最大的变化之一就是这样。每个人都对安全负责。

这是什么？

同样，DevOps 是一套实践和工具，旨在通过采用开发实践将开发和运营团队聚集在一起，DevSecOps 旨在使组织内的每个人都使用安全实践和工具(图 9-1 )。基本上，它代表着每个人都对安全负责。

图 9-1

维恩图，不同的团队聚集在一起创建开发团队

每个人都对安全负责

正如每个人都需要通过社会工程和了解物理安全的简单安全实践来警惕潜在的攻击者一样，DevSecOps 努力让每个人在技术工作的各个方面都考虑安全问题。

从部署新代码或构建新系统，所有东西在发布之前都需要通过安全门。从互联网上拉第三方内容需要在发布前进行扫描和测试。

安全需要被视为一个不断发展的实体。需要检测威胁，发现问题需要做平台补救。安全管理流程应遵循类似于图 9-2 所示的流程。

图 9-2

安全的循环

扫描环境，检查扫描结果，补救问题，观察所需的更改，最后应用更改以避免重复出现问题。

工具

Linux 系统管理员、开发人员和用户需要意识到，添加到 Linux 资产中的任何新东西都必须满足安全需求。手动运行扫描和测试不会支持这种文化转变，并且会将您置于安全被忽视的境地。

所有这些安全检查都需要以自动化的方式完成。当检测到安全问题时，应该停止该过程并进行补救。例如，如果构建一个新的容器映像，构建一个不安全的容器映像和浪费存储空间是没有意义的。最好停止，修复问题，然后重新运行构建。

安全门

整合 DevSecOps 实践的一个好方法是将安全门构建到管道工具中，如 Jenkins 或 Tekton(图 9-3 )。

图 9-3

代码被推送、检查，并与提取的映像一起烘焙

将用于部署新容器的结果映像在部署之前进行检查。如果安全门发现一个漏洞，该过程就会停止，部署就会失败，从而防止安全漏洞被部署到实际环境中。

任何自动化工具都可以用来包括安全门。例如，Ansible Tower 能够利用工作流。Red Hat Satellite 或 Uyuni 有一个自动化的构建过程，也可以使用。

第三方工具

强烈建议您的安全门使用第三方工具来扫描和检查代码。使用 SonarQube 这样的产品能够扫描漏洞和检查代码的语法问题。

系统合规性

系统符合标准有许多原因。能够存储一个人的信用卡详细信息的能力决定了应该如何在金融组织内保护系统。不这样做将意味着经济处罚或更糟。

要使系统兼容，需要遵循一些强化要求。这些要求需要应用于所有系统，并在审计时间到来时提供证据。

系统硬化

强化 Linux 系统是一个消除系统中任何潜在攻击面的过程。

潜在的攻击者可以暴露系统的许多方面。例如，最近发现的一个漏洞使得非 root 用户能够利用 sudoedit 命令中的漏洞。该漏洞允许用户在未经授权的情况下运行特权命令。

作为 Linux 系统管理员，我们能做的最重要的事情就是找到这些类型的漏洞，并在暴露之前修复它们。当构建数百个甚至数千个系统时，减少问题发生的几率甚至更为重要。这就是为什么系统加固和系统漏洞扫描对于确保您的系统在上线前尽可能安全至关重要。

硬化标准

现在有许多标准可以用来强化您的 Linux 资产。使用的两种主要方法是 CIS 和 STIGs。两者非常相似，很大程度上是因为一个人能做的安全调整是有限的。然而，这两者都是确保您的平台达到良好标准的良好起点。

对于不同的组织，还必须遵循一些其他标准，例如针对美国联邦机构的 NIST 800-53 和针对金融组织或任何希望存储信用卡/借记卡详细信息的组织的 PCI DSS。这些标准通常应用于 STIGs 或 CIS 指南之上。

互联网安全中心

如果您过去曾经做过系统加固，那么您可能已经熟悉了 CIS 标准。CIS 是一个非营利组织，旨在尽可能确保互联世界的安全。CIS 向任何需要的人免费提供他们的安全指南，并且还提供付费服务，CIS 可以提供已经加固的资源，如系统映像。

作为 Linux 系统管理员，下载强化指南并按照步骤保护您的平台就足够了。指南写得很好；它们解释了安全配置的用途，以及如何在发现平台存在漏洞时进行补救。指南甚至给你运行的命令。

过去，我通过复制和粘贴这些指南中的命令来编写 shell 脚本。今天，有更好的方法可以做到这一点，我将在本章中简要介绍。

安全技术实施指南

与 CIS 非常相似，你也可以遵循 STIG 指南来强化你的平台。这些指南也是免费的，但是更符合美国政府的要求。

STIG 指南也不像独联体指南那样多种多样。与 CIS 相比，STIG 指南可能没有针对基于社区的平台或应用的指南。如果 CIS 有可以使用的专用指南，则必须使用通用指南。

强化 Linux

有几种方法可以强化您的 Linux 系统。

手动配置

我加固 Linux 系统的最后一种方法是手动操作。光是需要遵循的硬化步骤的数量就会让你忙得不可开交。大多数硬化指南都超过了 100 页，远非引人入胜的读物。

如果需要手工强化一个系统，那么你可以遵循的最好的工具就是因特网上的强化指南，比如 CIS。

每种不同的可用强化指南都附带了用于确定系统是否存在漏洞的命令，如果漏洞确实存在，还会提供补救命令。在这种情况下，你的朋友会复制并粘贴，直到你看完这本内容丰富的指南。

我的建议是尽可能地推迟手动操作。它所花费的时间将远远超过建立下一个强化系统的方法所花费的时间。

自动化

自动化是你的朋友。互联网上充斥着像您这样需要强化系统的 Linux 系统管理员编写的内容。很有可能你会找到一些能完全按照你的意愿行事的天使或木偶。你还将获得过程可重复的额外好处，当你的老板告诉你强化另外五个系统时，这将非常方便。

Tip

记得搜索那些互联网资源星系，如 Ansible Galaxy 或 Puppet Forge 的内容。

OpenSCAP

如果您需要从一个不同的已经加固的系统中复制配置，那么从互联网下载的自动化可能会让您稍感失望。可能有一个特定的系统具有特定的强化，但由于某种原因并没有应用所有的强化。

那么，您将如何运行标准强化来适应相同的设置呢？

对于这个用例，您可以使用 OpenSCAP。OpenSCAP 能够扫描一个或多个系统，并生成系统配置报告。可以将此配置与另一个系统进行比较，并运行后续报告来列出差异。

OpenSCAP 的惊人之处在于，它还可以生成 Ansible 或 Puppet 代码来弥补这些差异，使您不必编写自己的自动化代码。

OpenSCAP 可以使用现成的 CIS 配置文件运行，也可以使用其他配置文件。大多数(如果不是全部)将通过 Ansible 或 Puppet 为您提供漏洞补救。

OpenSCAP 将要求您在 Linux 桌面上安装 OpenSCAP workbench 工具，以允许您配置配置文件。

Tip

在开始编写自动化代码之前，检查 OpenSCAP 是否能为您做到这一点。

漏洞扫描

密切关注您的财产，确保没有漏洞，这对于确保您不会有任何令人讨厌的惊喜等着您是至关重要的。

Linux 扫描工具

open vas！open vas！open vas

Nessus 是许多系统管理员在职业生涯中可能听说过的工具。在 Nessus 成为 Tenable 的 close sourced 之前，OpenVAS 是 Nessus 的一个分支。OpenVAS(开放漏洞评估系统)是名为 Greenbone Vulnerability Manager 的大型工具集的扫描器组件。

OpenVAS 还从具有良好历史记录并每天更新的实时提要中获取检测漏洞所需的测试。

OpenSCAP

OpenSCAP 是另一个非常好的漏洞扫描工具，它不仅仅是前面讨论过的扫描工具。OpenSCAP 能够使用多种配置文件，并且可以根据您组织的要求进行完全定制以进行扫描。

我在呼唤

如果你需要一个开源的反病毒软件，ClamAV 可以帮助你检测病毒、木马和许多其他类型的恶意软件。ClamAV 可用于扫描个人电子邮件或文件中的任何恶意内容。ClamAV 也可以作为服务器端的扫描器。

“付费”ClamAV 产品会自动定期更新其数据库，以便能够检测最近的威胁。社区产品需要进一步配置 cron 作业。

集装箱图像扫描工具

今天运行 Linux 资产需要管理的不仅仅是标准的 Linux 系统。与标准 Linux 系统一样，需要对容器和构建它们的映像进行漏洞扫描。

海港

从技术上讲，是一个容器映像库。Harbor 是一个开源项目，它提供了对其容器注册表的基于角色的访问，并具有扫描图像寻找漏洞的能力。VMware 采用 Harbor 作为其 Tanzu Kubernetes 平台的容器注册中心。

基于角色的访问

Harbor 通过策略和基于角色的访问控制来保护工件，确保图像经过扫描并且没有漏洞。

特里维

Harbor 在 2.2 版本之前使用 Clair 作为其漏洞扫描器，但此后开始使用 Trivy。Harbor 还可以连接到多个漏洞扫描器。通过将 Harbor 连接到多台扫描仪，您可以扩大防御漏洞的范围。

单个或多个图像

可以启动 Harbor 来扫描港口环境中的特定图像或所有图像。还可以将策略设置为以特定的时间间隔自动扫描所有图像。

jfrog 射线

JFrog Xray 是 JFrog 提供的漏洞扫描工具。Xray 与 Artifactory 本机集成，用于扫描漏洞和软件许可证问题。x 射线能够扫描所有支持的包类型，从二进制文件到容器映像。

深度扫描

深度扫描允许 Xray 在发布用于实时部署之前，通过 Artifactory 中的包或工件的依赖性递归扫描任何威胁。

克莱尔

Clair(来自法语术语，意思是 clear)是一个开源项目，它为容器映像和应用程序容器提供静态安全性和漏洞扫描。

支持的图像

Clair 目前支持的可以扫描漏洞的映像包括本书中讨论的所有主要企业发行版。它们如下:

  • 人的本质

  • 一种自由操作系统

  • 红帽企业版

  • 注意

  • 神谕

Clair 还支持目前在不同环境中使用的以下图像:

  • 阿尔卑斯山的

  • linux

  • VMware 光子

  • 计算机编程语言

企业版

Clair 目前是 Red Hat Quay(读作“kway”而不是“key”)产品中使用的漏洞扫描工具。Clair 为 Red Hat 支持的容器注册表提供了一个企业级漏洞扫描工具。

连续扫描

Clair 扫描推送到 Quay 的每张图像，并持续扫描图像，以提供您的集装箱中已知漏洞的实时视图。

仪表盘

Clair 也有一个详细的仪表板，显示码头内存储的集装箱图像的状态。

管道

在 DevSecOps 方法中，Clair API 可以在 Jenkins 或 Tekton 等管道工具中使用，以扫描烘焙阶段创建的图像。

集装箱平台扫描工具

Kubernetes 的 Red Hat 高级集群安全性(StackRox)

红帽最近的一次收购是将 StackRox 纳入红帽的投资组合。StackRox 目前是 Red Hat ACS 产品的上游项目，但仍有一个社区版本可用于不受支持的平台。

Red Hat 的企业版 StackRox 提供了以下特性。

漏洞扫描

在 Kubernetes 或 OpenShift 平台内运行的容器中发现并修复漏洞的能力。

合规扫描

在信息仪表板的支持下，Red Hat ACS 可以扫描集装箱和图像，以确保它们符合 CIS、PCI 或 NIST 等标准的合规性要求。

网络分段

能够执行网络策略，并对进出 Kubernetes 或 OpenShift 环境的允许网络流量进行更严格的分段。

风险预测

从 Kubernetes 或 OpenShift 内的部署中检测到的所有风险都可以在优先列表中查看，以便进行补救。

结构管理

不仅用于管理 Kubernetes 或 OpenShift 中容器工作负载的安全性和漏洞。Red Hat ACS 还可以通过配置管理强化集群组件。

检测和响应

通过结合使用规则、允许列表和基线，Red Hat ACS 能够识别可疑活动并采取措施防止攻击。

法尔科

由 Sysdig 创建的 Falco 是另一个针对 Kubernetes 和 OpenShift 类型环境的开源威胁检测解决方案。Falco 可以检测应用程序中的任何意外行为，并在运行时向您发出威胁警报。

法尔科有以下特点。

灵活的规则引擎

通过使用类似于 tcpdump 的语法，Falco 可以使用 libscap 和 libsinsp 库构建规则，从 Kubernetes/OpenShift API 服务器或容器运行时环境中提取数据。然后，可以从特定名称空间或容器映像上的元数据创建规则。

即时警报

通过即时警报降低财产风险，从而更快地修复漏洞。

当前检测规则

基于最新 CVE 或已知漏洞的最新检测规则。一旦安全平台发现漏洞，您也会发现。

水上安全

Aqua Security 旨在保护使用云原生容器构建并部署到 Kubernetes 或 OpenShift 等混合云基础架构中的应用程序。

Aqua Security 具有以下特性。

开发者指南

Aqua Security 通过确保容器映像中没有任何已知的漏洞，指导开发人员构建安全、干净的容器映像。Aqua Security 甚至检查正在开发的容器图像没有任何已知的密码或秘密，也没有任何可能使这些图像易受攻击的安全威胁。

信息仪表板

Aqua Security 有一个清晰而有用的控制面板，提供关于所管理平台的实时信息，以及发现的所有问题。如果发现任何漏洞，Aqua Security 会将问题报告给开发人员，并提供修复易受攻击的映像所需的建议。

摘要

在本章中，向您介绍了以下内容:

  • 应该使用并且永远不要禁用的标准 Linux 安全工具

  • 保护新系统时应至少使用的 Linux 配置

  • 理解什么是 DevSecOps，以及这种新的实践需要如何被组织中的每个人所接受

  • 系统合规性和 Linux 强化

  • 可用于强化 Linux 系统以满足合规性要求的指南

  • 漏洞扫描工具

十、维护任务和计划

任何 Linux 系统管理员都会熟悉 Linux 资产所需要的可怕的维护。在本章中，我们将讨论在管理 Linux 资产时应该做的各种维护工作。我们将了解应该完成哪些实际维护工作，应该在何时运行维护作业，以及如何计划维护以使停机时间最少。

本章还将简要介绍如何同步维护任务和官僚任务，以减少日常维护有时会带来的总体痛苦。最后，我们将讨论如何使用自动化来改善所有相关人员的整体维护体验。

应该做哪些保养

在 Linux 服务器上应该进行一些检查。有些可能不需要在每个维护周期进行，但有些需要尽可能经常进行。有时你甚至需要运行紧急维护。

Note

为了确定维护是否至关重要，请注意您对潜在问题迹象的监控。这方面的例子可能是磁盘即将被填满。

修补

维护的首要原因是打补丁和系统更新。这一过程的重要性怎么强调都不为过，也绝不能忽视。修补不仅包含软件包更新和修复，还提供漏洞补救。

脚手架

在确认当前一轮更新不会破坏任何东西之前，修补您的生产/现场或面向客户的环境从来都不是一个好主意。

这就是为什么应始终采用分阶段修补方法的原因。确定修补环境的顺序，并分阶段进行修补。

图 10-1 是我过去经常使用的配线订单示例。

图 10-1

修补顺序

沙箱

从沙盒类型的环境开始，至少有一个系统运行与您的生产环境相似或接近相同的应用程序。这种环境不应该面向用户，也不需要变更控制批准。整个环境应该是一次性的和自动化的。沙盒是您的环境，用来证明配置不会在其他环境中引起问题。

自动化测试

如果可能，利用自动化测试来证明更新或补丁配置没有破坏测试应用程序的功能。有许多开源和专有的选项可用于自动化应用程序测试。与您组织的开发人员交流，或者联系为您提供应用程序的人员。他们很可能会建议你应该使用什么。

这里有一些选项，你也可以看看，可能会有所帮助:

  • 硒

  • 加泰罗尼亚工作室

  • Appium(用于移动应用程序)

  • 机器人学

自动修补

如果您的修补过程计划得很好，并且平台测试可以自动化，那么就没有什么可以阻止您自动化实际的修补工作。

利用自动化工具，如 Ansible Tower 或 Jenkins 或任何允许您运行阶段或工作流的工具。这样，您可以分阶段运行以下内容:

  • 预检

  • 确认故障转移已经发生

  • 修补操作系统文件

  • 重新启动

  • 自动化测试

反转

如果检测到问题，管道或工作流工具也可以应用回滚，确保当维护窗口关闭时，不会留下任何有问题的状态。自动化是伟大的，但是内置同样多的风险管理将使您不必解释为什么环境被您的自动化破坏。

Hint

您希望确保尽可能多地降低风险，以确保您的自动化不会因系统停机而受到指责。这让你的生活变得更容易，应该避免反对者。

文件系统

如果没有很好地维护，随着时间的推移，有一个领域可能会增长并引起关注，那就是您的文件系统。文件系统不仅存储日志，还存储用户留在主目录中的文件。在文件系统成为问题之前关注它们对于避免可预防的停机至关重要。

清除

在系统维护期间，浏览以下不同的文件系统并检查是否有不再需要的文件绝对是值得的。建议删除这些文件和任何临时文件。

检查错误

一旦您检查了未使用的文件并尽可能地清除了这些文件，那么运行文件系统健康检查就非常值得了。这将有助于识别任何潜在的问题，以免它们成为下一步的问题。

文件系统检查命令

表 10-1 中的命令在运行文件系统维护或通常希望解决磁盘问题时非常有用。

表 10-1

基本文件系统检查命令

|

Linux 命令

|

描述

|
| --- | --- |
| du -k /var/log &#124; sort -n &#124; tail -10 | 检查目录中最大的十个文件 |
| find . -type f -size +100M -ls | 在当前目录中查找任何大于 100MB 的文件 |
| find /var/log -mtime +90 -ls -exec rm {} \; | 找到任何超过 90 天的文件并删除它们 |
| tar -zcvf var_log.date +%Y%m%d.tar.gz /var/log/*.log | 在/var/log 目录中创建一个包含所有日志文件的 tar 文件 |

防火墙

防火墙检查只是为了确保没有意想不到的新规则进入您的 Linux 系统。从技术上讲，这些应该由配置管理工具来管理，但是在没有运行的 SaltStack 或 Puppet 的情况下，检查防火墙是一项快速而简单的任务。在维护窗口期间这样做只是意味着您可以删除任何不需要的更改，前提是您被任何更改控制所覆盖。

Important

设计平台的内部架构师应该始终推荐防火墙规则。如果出现了任何没有意义的规则，请参考原始设计来确认它们应该存在。

备份

这个真的不用说了。对于任何无法通过代码重建的系统，都应该在可接受的时间范围内进行备份。虚拟机可以完整备份，但物理系统需要根据服务器的功能备份特定的目录。

在维护窗口期间，仔细检查所有备份是否都已运行，以及最近的备份是否到位。

Important

在修补系统或对系统进行任何可能会使您处于停机状态的操作之前，请确保您有一个可从中恢复的最新备份。

您的房产应该多久进行一次维护取决于几个因素:

  1. 您希望多久修补一次您的环境？

  2. 您是否遇到过磁盘已满或磁盘损坏的问题？

  3. 您的平台上是否出现了意想不到的配置？

前面两点表明你的房产有比维护更大的问题；在试图解决症状之前，建议先解决这些问题。

尽可能经常

应该定期执行的明显任务是打补丁。修补周期取决于组织的策略，可以是每 7 天或每 90 天。在我看来，90 天太长了，应该缩短到至少 30 天，但这也太长了一点。

如果让您来做决定，我会建议尽可能频繁地打补丁。应使用自动化，并通过定期维护帮助减少人为因素。通过运行非常定期的维护和修补程序，您可以降低新发现的漏洞可能带来的任何风险。

没有测试就没有实时修补

定期修补还允许您使用分阶段的方法进行修补，从而减少未经测试的配置或更新可能出现的问题。

结构

通过为每个环境建立一个定期维护窗口，您可以计划和组织如何应用和测试更新。这样做，您就大大降低了您的实际环境中出现问题的可能性，包括错误和漏洞。

应该如何进行维护

很简单，自动化维护是当今的发展方向。在我们维护和构建平台的过程中，需要减少人为因素。这是你能真正扩展的唯一方法。让一个人或一个团队来运行维护是疯狂的，更不用说维护是否会像应该做的那样定期进行。

自动化

我相信我提到自动化的次数已经足够多了，以至于你们已经厌倦了这个术语，我也相当有信心你们大多数人现在已经在自动化了。

显而易见，自动化维护和自动化构建过程一样重要。以下是您应该自动化的项目:

  • 备份

  • 修补

  • 磁盘清理

  • 磁盘检查

  • 防火墙和 SELinux 配置

  • 软件删除

前面的几项应该由配置管理工具来管理，但是如果您没有使用任何工具，那么您的维护自动化应该会处理它们。

您的自动化也应该按照类似于以下的顺序运行:

  1. 检查并确认最近进行了备份。

  2. 应用任何系统更新。

  3. 运行自动化测试以确认更新没有破坏任何东西。

  4. 磁盘清理

  5. 配置检查。

  6. 如果测试失败，回滚更新。

  7. 更新监控或生成报告以反映状态。

零停机环境

如果您的环境被认为是关键的，并且能够承受零停机时间，那么您将需要在蓝/绿风格的部署中运行多个数据中心或每个站点的多个环境。

蓝色/绿色

这种方法包括将流量转换为蓝色或绿色，然后修补非实时环境。

如果您愿意，蓝/绿方法确实让您能够直接更新到您的实时环境中，因为从技术上讲，您并没有更新“实时”端。如果您做了所有的尽职调查，并确保您修补的环境在切换回来之前 100%运行，您应该不会遇到宕机。

一旦您完成了一侧的维护，您可以将相同的维护应用到第二侧。因为你已经证明了没有问题，你应该完全可以继续你的第二个网站。

我个人仍然建议采取分阶段的方法，但是如果你时间紧迫，你至少可以切换回第二个环境。

故障切换

运行多个数据中心是减少单点故障的另一种常用方法。将实时流量转移到第二个数据中心将允许在实时流量不停机的情况下进行维护。

在回切到主数据中心和修补辅助站点之前，应该应用相同的维护原则。

维护计划

执行和计划一样好。对于任何维护计划，都有一些重要的事情需要考虑。

同意维护窗口

为每个环境的维护找到一个固定的时间段。自动化官僚主义的繁文缛节，以确保维护可以在这些定期运行。通过为您的组织寻找和规划一个已知的时间段，您将始终能够应用更新和更改，而无需每次都争论原因。

这并不意味着您必须每次都运行维护，您只需要在需要时自由地进行维护。

如果你已经自动化了这个过程，那就更好了。然后，您的环境可以不断保持最新状态并尽可能平稳地运行，减少不断修复问题的需要，让您有更多时间专注于更令人兴奋的事情。

一口大小的块

如果你有大量的维护工作要做，并且还没有自动化这个过程，把你的维护工作分成小块。宁可运行多个小维护窗口，也不要运行一个大窗口。

Remember

疲惫的眼睛对任何人都没有帮助。

评估的艺术

在计算完成一项任务所需的时间时要小心。宁可高估早完成，也不要低估，给自己压力。向其他 Linux 系统管理员寻求帮助，在计划时估算时间。

将流程和任务一起自动化

自动化不仅仅是技术任务的实现。今天，在你的组织中自动化“繁文缛节”过程也是可能的。

在系统维护的情况下，这个功能可以很好地与任务自动化结合起来。所有批准都可以自动化，并输入到您的技术自动化平台，以便在维护窗口到来时继续进行。你不仅不必再做手工的技术实现，还可以避免官僚主义的工作。

工序自动化

现在有一些不同的产品和项目可以帮助您自动化流程，但是值得一提的是 Red Hat Process Automation Manager，或者 PAM。

红帽子帕姆

Red Hat PAM 提供了自动化业务流程和决策的工具。通过使用高级业务规则和流程引擎，以及复杂的事件处理和案例管理，Red Hat PAM 可以帮助解决复杂的计划和调度问题。PAM 利用 Drools 的全部功能，Drools 是一个强大的、广泛使用的开源规则引擎。通过使用内置的规划求解工具，PAM 甚至可以帮助解决复杂的优化问题。

像大多数其他 Red Hat 产品一样，Red Hat PAM 的上游项目是 jBPM 项目，这是一个完全开源的产品，可以在社区支持下使用。

Warning

Red Hat PAM 是您需要用来开发流程任务的工具，就像您在自动化技术任务时使用 Ansible 一样。

摘要

在本章中，向您介绍了以下内容:

  • Linux 系统需要做哪些维护

  • 何时应该运行 Linux 维护

  • 零停机运行维护的方法

  • 如何规划 Linux 维护

  • 如何将维护流程和技术任务一起自动化

十一、故障排除

如果您不了解正确的方法，故障排除可能是一项难以掌握的技能。仅仅挖掘日志或配置文件可能有助于解决简单的问题，但是理解如何找到问题的根本原因才是真正的技能所在。在这一章中，我们将看看应该如何看待一个问题，应该如何分析这个问题，最后你应该如何根据你所看到的信息采取行动。在猜测之前花时间去理解对更快更有效地解决你的问题是至关重要的。

一旦我们讨论了应该如何处理问题，我们将讨论在社区中提问时应该使用的适当礼仪。第一步是学会不要让别人替你做工作，或者至少用一种你似乎已经尝试过的方式来提出你的问题。在这一章中，我们将探讨寻求帮助的最佳方式。

最后，我们将讨论您应该尽量避免的不太好的故障排除方法。

观察，分析，然后行动

成为一名有效的故障排除者的艺术是成为一名调查者。跟着线索，问正确的问题。注意每一个小细节，最重要的是理解为什么问题会首先出现。太多时候，绷带被用于症状，而根本问题并没有得到解决。解决了根本原因，你就可以省去以后所有的痛苦。

理解问题

为了完全理解如何修复一个问题，你需要理解问题的影响是什么；这很可能会给你第一个线索，告诉你从哪里开始找。

为了有效地解决问题，你需要了解你正在诊断的是什么，如果你不知道它是如何工作的，猜测是没有意义的。你将只能得到部分答案，并有可能浪费时间在错误的地方寻找答案。

例如，如果你有一个网络问题，但不知道如何跟踪网络流量，你最好找一个知道如何解决这个问题的人。边走边学是我们获取经验的方式，所以不要害怕寻求帮助。适当的做就好；我们很快会谈到这一点。

知道从哪里开始

知道从哪里开始是让你彻底了解问题的一半。从顶部开始听起来像是老生常谈，但这就是你如何通过证据沿着面包屑工作，最终将你带到根本原因。

开始时问正确的问题会让你知道从哪里开始挖掘。当问题被描述为“它坏了”或“它坏了”时，这意味着你的问题需要从简单开始，然后随着你的深入变得更加复杂。请记住，您的问题要基于与您一起工作的人的知识水平，并且要有耐心。

开始时要问的标准问题

当您初次遇到某个问题时，您需要从报告该问题的人的角度来理解该问题。为此，你应该问我们在 IT 学校都学过的标准问题。类似于下面的问题:

  • 你能告诉我发生了什么吗？

  • 问题是可重复的还是间歇性的？

  • 有什么变化吗？

Note

问自己这些问题没有错。如果有的话，它可能会让你加深对这个问题的理解。

解释问题

当一个问题很复杂时，它需要深入思考、质疑和理解。只有通过解释，它才变得更加清晰。通过多次解释和提问，你增加了对问题的了解，直到得到答案。

这里有一些技巧可以用来解释你的问题。

向自己解释

几十年来我们已经知道，向自己解释一个问题可以大大增加我们解决它的机会。通过向自己解释这个问题，你获得了关于这个问题的新知识，你问自己问题，并且挑战自己对这个问题的理解。如果有帮助的话，大声对自己说，继续对自己谈论这个问题。不要沉默不语，如果有必要的话，找一个安静的房间，彻底解决这个问题。

橡皮鸭

如果在向自己解释完问题后，你仍然没有什么有形的东西，那就抓住一个无生命的物体(橡皮鸭)，向它解释你的问题。只是第二次解释的过程可能会有帮助。

另一个人

如果橡皮鸭选项失败了，试着向另一个人解释你的问题；他们甚至不必是技术性的。事实上，如果他们不是，可能会更好。这可以让你简化你的解释，让他们理解，并可能在这个过程中帮助你发现一些你可能忽略的东西，因为它太简单了。

使用工具

解释时使用白板或碎纸片也能让你把想法和想法从脑子里赶出去。向自己重读解释可能会更加清晰。

分解问题

复杂的问题会涉及许多不同的活动部件。一点一点地理解这些部分不仅会让你对问题更加清晰，还会让你开始消除可能的原因。

将问题分解成各个部分，开始向自己解释这些部分的作用，询问问题是否存在于每个部分，然后排除可能不是问题的部分。

使用白板或一张纸是一种很好的方法，可以将您的问题可视化到不同的部分。

洋葱，它们有层次

当你分解问题时，记得考虑所有相关的层面。如果您遇到应用程序问题，请查看从应用程序到物理硬件的所有内容。通过排除所有的不可能，你只剩下最有可能的。

五个为什么

虽然不是每个人都喜欢自言自语或涉及无生命的物体，但有另一种类似的方法可以用来解决复杂的问题:一种称为五个“为什么”的技术

在这种方法中，故障诊断人员通过五个问题来解释为什么会出现问题。

例子

如果我们假设一个场景，在晚上的维护之后，你组织的内部内部网无法加载，那么可以问一下图 11-1 中所示的“为什么”。

图 11-1

尝试确定潜在问题时“为什么”应遵循的流程示例

内部网坏了。为什么呢？应用了更新，系统重新启动。为什么呢？web 服务器没有监听任何端口。为什么呢？启动后 web 服务器服务不会启动。为什么呢？配置文件中有语法错误。为什么呢？最后一个为什么会让你找到根本原因。有人更改了 web 服务器配置，但没有测试语法。这种改变并没有通过重启 web 服务来实现，只有在应用了系统更新后重新启动 web 服务器时，真正的问题才显现出来。

在这个例子中，问题归结于发生在内部网 web 服务器上的一个未记录的变更。该更改从未在语法检查中测试过，并且该服务从未重新启动以应用该更改。在服务器更新和重新启动后，web 服务器尝试在启动时启动，但由于语法错误而失败。

基于证据的理论

在对困难或间歇性问题进行故障诊断的过程中，您可能需要找到不同的调查途径。每种途径都需要调查，并需要证据来证明它是确凿的证据，然后才能将修复应用到受影响的实际环境中。

假设构建

图 11-2 所示的工作流程可以通过建立一系列假设来帮助你进行根本原因分析。

图 11-2

建立故障排除假设时应遵循的流程

Tip

在建立你的假设之前，不要太快忽视不可能的事情，除非你 100%确定它不是问题所在。

建立你的理论

一个好的理论应该总是从一个好的假设或有根据的猜测开始。为了检验假设，需要收集关于可疑区域的所有信息。这可能包括配置文件、系统负载、内存使用情况或任何有助于您重现实际环境中遇到的问题的信息。

因果关系

在建立你的假设时，要避免陷入不理解某个组件的因果的陷阱，例如，因为一个新的显卡加载失败而责怪内核版本。即使内核负责设备驱动程序，它仍然需要在内核中编译的硬件驱动程序。

证明你的理论

因为在真实环境中调试和测试从来都不是一个好主意，所以在你可以将任何东西应用到真实环境之前，你的理论需要坚实的证据来支持你的主张。为此，你需要证明你的理论。

重现问题

为了证明你的理论，你首先必须重现这个问题。收集到证据后，您必须尝试复制与真实环境相同的条件，看看您是否会遇到相同的问题。如果你不能重现问题，可能你有错误的理论，或者你没有收集所有的证据。

在测试环境中修复

如果您能够重现该问题，则可以测试您的潜在修复方法，并证明问题已经解决。理想情况下，整个过程应该是可重复的。

补救

最后，通过验证您的理论和准备好的解决方案，可以在几乎没有风险的情况下修复实际环境。

请求帮助

在我职业生涯的早期，我被告知要经常寻求帮助，不要浪费超过解决问题所需的时间。如果我被卡住了，我不应该在问之前“敲打我的头”太久。毕竟，我们都还在学习；我们在一个不断发展变化的行业中工作。坐在你旁边或在互联网上的某个人可能已经经历了你遇到的同样的问题，并且可能有你可能正在挣扎的答案。

在寻求帮助之前应该做什么

当你寻求帮助时，你是在要求别人放弃一些时间来帮助你解决你的问题。帮助你的人必须花精力去理解你的问题；他们需要想出一个他们过去可能用过的可能的解决方案，然后试着用你能理解的方式向你解释。

为此，作为请求者，您至少应该在提出问题之前完成以下工作:

  • 尝试修复问题，但失败了

  • 阅读软件或硬件供应商提供的文档

  • 在互联网上搜索其他人已经尝试过的例子，并检查没有人已经问过你想要帮助的问题

培养

如果你足够幸运，可以接触到培训材料，检查一下你在练习中可能学到的东西是否有帮助。

如果你从未接受过任何培训，可以和你公司的经理谈谈，让你参加合适的培训课程。如果做不到这一点，你也可以利用大量的在线资源来学习。

如何寻求帮助

以下是你在寻求帮助时需要考虑的一些非常重要的要点。

适当的语法

尽可能使用正确的语法和拼写。如果英语不是你的第一语言，那么尽你所能，用类似这样的话开始你的问题:

“很抱歉我的英语不好，希望我的问题有意义。”

尽量避免使用俚语，尽可能使用正确的单词拼写。记住你是在寻求帮助，确保你的问题尽可能清楚。

拼写

使用任何可用的工具对你的问题进行拼写检查。谷歌文档有不错的拼写检查功能(我希望如此，因为这本书是用它写的)，而且是免费的。

将您的问题写或复制到一个新文档中，并检查语法和拼写错误。

如何表达你的问题

现在，随着正确拼写和语法的使用，你需要理解你的问题应该如何措辞的重要性。

简单地问“有人知道为什么我的显卡不能在我的 Linux 桌面上工作吗？”不够或者写得不好。

问一个让人们立即向你询问更多细节的问题不会给你想要的答案或任何答案。

将你的问题改为包含以下信息，你会得到更好的回答:

  • 陈述你尝试过的。

  • 给出所有组件的详细信息，比如显卡的品牌和型号。告诉读者你用的是什么 Linux 发行版。

  • 说明您已经阅读了文档并浏览了其他示例。

  • 在你的问题主体中非常具体地说明你的问题，并在上面用一行字概括你的问题。

一个更好的问题

镭龙 RX 5700xt 驱动程序不支持 Fedora 34

我正在尝试在新安装的 Fedora 34 中安装镭龙 RX 5700XT 显卡。在阅读了 AMD 网站上的官方文档并查看了 install 命令的帮助后，我仍然无法找到解决方案。

我已经尝试运行命令

./amdgpu-install-pro --opencl=pro,legacy

和 ./amdgpu-install-pro --opencl=rocr,legacy

但是两者都给了我错误。

“找不到设备”

下面是我的日志文件的输出。

“日志文件条目”

任何帮助我都会非常感激，或者你可能有的任何我可能错过的文件也会非常有帮助。

Tip

不要急着提问；花点时间以清晰、平和的方式问问题。人们会对花时间和精力正确提问的人提出的问题做出回应。

在哪里提问

如何提问对于获得积极的回应至关重要，但在哪里问措辞正确的问题同样重要。

正确区域

人们真的不喜欢被问到与你提问领域无关的问题。在提问之前，请确保您选择了正确的论坛或聊天室，甚至支持电子邮件。

一般礼貌的回答会把你引向正确的地方，但是没有耐心的人可能会给你一个稍微有点讽刺的回答。所以一定要避免尴尬或至少浪费你的时间。在应该提问的地方提出你的问题。

论坛

如果你对某个特定的产品或项目有问题，检查一下他们是否有你可以提问的论坛。确保首先检查您的问题是否还没有被问过。

GitHub，堆栈溢出

在很多网站上，你可以就你可能遇到的任何问题提出技术问题。Stack Overflow 是一个我能找到答案的常见网站，但是像 GitHub 这样的地方也能提供一些很好的见解。

支持案例

如果您的问题与您或您的组织付费订购的企业产品有关，请向他们的帮助台提出支持案例。这毕竟是你花钱买的东西。

但是，一定要清楚你的问题是什么。尽可能附加日志文件和潜在的诊断输出。只需添加所有相关文件，有时就可以更快地解决问题。

排除故障时要避免的事情

故障排除通常不是我们为了好玩而做的事情；它通常有时间压力，要求你尽快解决问题。

为了避免浪费时间，有几件事你应该尽量避免。

现场调试

不要在真实环境中调试；谁要是说现场调试还可以，那就是如履薄冰。只需一个语法错误或一个配置文件留在调试模式中，就会导致停机。

构建测试环境和非生产环境是有原因的。用它们来找到根本原因，而不是你的生活环境。

相关性与因果关系

当你寻找问题的根本原因时，运用逻辑思维关注问题可能出在哪里。将问题从可能有责任的组件中分解出来，避免关注依赖于可能有故障的组件的组件。基本上，避免浪费时间在可能是根本原因的受害者而不是原因的地方。

在服务没有启动的情况下，如果您没有首先检查应用程序配置，就不要浪费时间查看服务文件。我并不是说不要检查服务文件的语法问题或潜在的变化，只是不要区分它的优先级。

做一只孤独的狼

不要默默忍受；寻求帮助，两人一组。两对眼睛总会比一对好。两个大脑思考问题的方式不同，会从不同的角度处理问题。不要花几个小时独自战斗。

猜测和撒谎

这确实与团队故障排除有关。如果你对已经发生的事情负有责任，并且你已经请求帮助你摆脱困境，那么 100%诚实，不要猜测你可能在哪里犯了错误。

承认一个错误通常只会被当作“一个错误”对问题撒谎，由于缺乏诚实而导致延误，很可能对你没有好结果。拥抱你的错误，并从中吸取教训。

鬼

不是每个人都理解“红鲱鱼”这个词，但在英国我们用这个词来指代不存在的东西。一个幻影。避免寻找不太可能成为你问题根源的东西。当你寻找根本原因时，要坚持运用逻辑思维。

所有的小事

不要认为所有的大问题都有大的原因。不要忘记检查简单的事情，如域名系统或磁盘已满？

通常，我们最意想不到的事情会导致最大的问题；坚持从基础做起，然后从基础做起。

记录你已经尝试过的事情

阿尔伯特·爱因斯坦说过:“疯狂的定义是重复做同样的事情，却期待不同的结果。”说到故障排除，没有什么比这更不真实的了。如果你有健忘的天性，记录下你检查的地方和结果。这样你就会避免重复自己，浪费时间。

测量两次，切割一次

这句老话同样适用于解决方案。为了让事情立即工作而应用肮脏的变通方法，但随后不得不在短时间内修复相同的问题是徒劳的。找到根本原因并应用永久修复应该是你的首要任务。

如果您的实际环境出现故障，您最好在灾难恢复站点或辅助站点中运行。如果不是这样，那么我会担心比停机更大的问题。

什么更有意义？

修复问题以便它不会再次中断，还是应用会导致另一次中断的解决方法？

争论用更长的时间来修复潜在的问题比解释为什么现场环境再次下降要好得多。

别忘了你的回顾展

故障排除的最终目的是找到问题的根源。第二个目标应该是永远不要让它再次发生。为此，与所有相关人员进行讨论并计划如何避免该问题至关重要。

记录问题以及问题是如何解决的。如果问题不知何故再次发生，有一些参考资料可以节省时间。

摘要

在本章中，我们探讨了以下有关故障排除的内容:

  • 通过向自己和“他人”解释，学会理解你的问题

  • 把你的问题分解成最小的部分，然后从那里着手。

  • 五个为什么以及简单地问为什么一个东西坏了可以帮助你找到罪魁祸首。

  • 在将任何解决方案应用到您的生活环境之前，如何建立一个关于可能导致您的问题的原因的理论，并证明您的理论。

  • 寻求帮助的正确方法，包括在寻求帮助之前应该做些什么。

  • 排除故障时要避免的事情。

十二、高级管理

《21 世纪 20 年代的 Linux 系统管理》的最后一章将探讨作为 Linux 系统管理员的你如何更深入地挖掘 Linux 操作系统，以找到你需要的信息。

本章将从研究系统分析开始，并帮助你理解如何从你的 Linux 系统中获得更多的信息，而不必花时间去做这些。我们将讨论什么样的工具可以用来提取和破译系统信息，让你更快地得到答案。

当系统分析工具和技术不能给你所需要的所有信息时，就需要使用额外的工具来获得更多的信息。我们将在本章的剩余部分探讨如何从 Linux 操作系统中提取最后一点信息。

系统分析

作为一名 Linux 系统管理员，您会花时间查看配置文件和一般的系统健康状况，试图查明用户问题的根源。这个过程通常会很痛苦，而且会花费你不想花的时间。拥有正确的工具有助于深入了解问题，并让您专注于更有趣的事情。

这里有一些快捷的工具，您可以使用它们来获得关于 Linux 系统的信息。

系统管理员的工具

如果您有合适的工具，并且知道如何以对您有意义的方式使用它们，那么维护或运行 Linux 资产会是一项更简单的工作。

Sosreport

对于所有的企业 Linux 系统，“sosreport”用于为支持团队提取信息。Sosreport 是一个基于插件的工具，可以使用不同的参数来导出不同的信息。当出现支持案例时，企业支持团队经常会请求 Sosreport 的输出，每当出现新的支持案例时，它总是值得上传。

Sosreports 是有问题的系统配置和日志的存档。支持团队能够使用 sosreport 更好地了解所遇到的问题，而无需请求不同的配置文件。

可以在不指定任何参数的情况下创建 sosreport，如下所示，但也可以传递附加参数以减少输出或增加提取的内容:

# sosreport

作为一名 Linux 系统管理员，您可能希望使用 sosreports 进行自己的诊断查询。如果您希望从自己的测试系统中调查用户的问题，可以手动提取 Sosreports。

如果您对手动提取 sosreports 不感兴趣，可以使用一些工具来提取和总结报告中的配置。

xsos

一个这样的工具是 xsos，由社区成员开发和维护；xsos 可以接受 sosreport 输入，并创建系统的良好摘要。对于支持人员来说，这比大多数人意识到的要节省更多的时间，因为不需要提取或筛选配置文件来快速浏览。

要运行 xsos 的基本测试，您可以运行以下命令:

# curl -Lo ./xsos bit.ly/xsos-direct; chmod +x ./xsos; ./xsos -ya

前面的命令将只输出运行它的系统的详细信息。如果您想要查看 sosreport 输出，您将需要安装 xsos 工具并将路径传递到您的 sosreport。

基本 xsos 报告将输出以下区域:

  • 汇总 dmidecode 输出

  • 操作系统详细信息

  • Kdump 配置

  • CPU 详细信息

  • 中断和软中断

  • 记忆

  • 仓库

  • 兰斯普奇

  • 网络信息包括防火墙

  • 内核调整配置

Tip

自动化您的 Linux 系统，定期自动生成这些报告，并将输出上传到中央共享。如果您遇到了重大问题，您可以参考这些 SOS 报告，寻找可能出错的线索。

系统信息

关于您的 Linux 系统的所有设备信息都可以在“/proc”目录中找到。在“/proc”中，有不同的文件，如“meminfo”或“cpuinfo ”,它们将向您显示每个组件的相关信息。例如,“cpuinfo”文件将向您显示与您的 Linux 系统相连的所有 CPU 的所有信息，包括 CPU 标志。

快捷工具

如果对“/proc”文件不感兴趣，表 12-1 中列出的工具也可以用来获得关于您的 Linux 系统的基本信息。熟悉这些工具有助于您在需要快速诊断任何问题时快速访问设备信息。

表 12-1

硬件信息的基本 Linux 系统工具

|

Linux 命令

|

描述

|
| --- | --- |
| lshw | 将列出系统识别的所有硬件的完整摘要 |
| lscpu | 所有 CPU 信息的摘要，类似于运行# cat /proc/cpuinfo |
| lsblk | 所有连接的存储设备的快速列表 |
| lsusb | 插入 Linux 系统的所有 USB 设备的列表 |
| lspci | 列出插入 PCI 插槽的所有 PCI 控制器和设备 |
| lsscsi | 列出连接到系统的所有 scsi 和 sata 设备 |

更多细节

如果快捷工具中的细节不够，您可以使用表 12-2 中列出的工具来提供更多细节。

表 12-2

了解更多细节的工具

|

Linux 命令

|

描述

|
| --- | --- |
| hdparm | 打印出存储设备的几何图形等细节 |
| dmidecode | 可用于提供有关您的系统的更深入的信息。使用"-t "参数，后跟" memory "、" processor "、" system "或" bios "，将为您提供每个参数的更多细节 |

系统跟踪

当你被一个棘手的问题困住时，了解幕后发生的事情有时是必要的。作为 Linux 系统管理员，有一些工具可以帮助您获得这些底层细节。

失去了

“strace”是一个非常有用的工具，可以用来查看进程或正在运行的应用程序的情况 Strace 可以作为命令或应用程序的前缀运行，也可以附加到正在运行的“pid”上

装置

在几乎所有的 Linux 发行版中，Strace 都可以在大多数常见的存储库中找到。对于 Fedora，strace 可以按如下方式安装:

# dnf install strace -y

以下命令将显示运行 free 命令时发生的一切:

# strace free -h

输出到文件

使用 strace 时，一个非常有用的事情是将输出发送到一个文件中；从那里，您可以搜索字符串或值。

要将 strace 命令输出到文件中，您可以运行类似于下面的命令:

# strace -o testfile.txt free -h

然后可以在文本编辑器中查看输出文件，在某些情况下，甚至可以用不同的颜色显示不同的调用，以使解释稍微容易一些。

要找什么

以下是使用 strace 可以找到的一些有用的东西:

  • 任何试图打开但不存在或显示潜在权限被拒绝的文件-13 个错误

  • 正在写入有权限问题的文件

  • 来自通过网络传输的进程或应用程序的网络流量

有用的 Strace 参数

表 12-3 列出了一些可以和 strace 一起使用的有用参数。

表 12-3

Strace 参数

|

参数

|

描述

|
| --- | --- |
| -p | 允许 strace 连接到正在运行的 pid |
| -c | 创建为该进程运行的所有不同系统调用的摘要 |
| -t | 显示每一行运行的时间戳 |
| -e trace=open | 过滤所有系统调用，只包括打开的调用。其他选项包括全部、写入、信号、缩写、详细、原始和读取 |
| -q -e trace= | 允许跟踪设置为文件、进程、内存、网络和信号 |

安装

另一个从 Linux 系统中提取信息的好工具是“systemtap”Systemtap 是一种脚本语言，它使用带有“.”的文件。stp”扩展名。Systemtap 可用于诊断基于内核的 Linux 平台的复杂性能或功能问题。

装置

Systemtap 可以手动安装，也可以使用自动安装方法安装。

手动安装

systemtap 需要的基本包是 systemtap 和 systemtap-runtime。在 RHEL 系统上，以下命令将安装您的软件包:

# yum install systemtap systemtap-runtime -y
自动安装

Stap-prep 是一个简单的实用程序，它将计算出 systemtap 的需求并为您安装它们。要使用 stap-prep，需要安装软件包“systemtap-devel”。

一旦安装了 systemtap-devel 包，运行 stap-prep 命令。将安装当前运行的内核所需的文件。

Systemtap 用户

如果您使用的是普通的 Linux 内核模块后端，那么您可以 root 身份运行“stap”。但是，如果您希望允许其他用户创建和运行 systemtap 脚本，则必须创建以下用户和匹配组:

  • stapusr

  • 斯塔德夫

“stapdev”和“stapusr”组中的任何用户都可以像拥有 root 权限一样运行 systemtap。“stapusr”中的用户只能启动(使用“staprun”)预编译的探测模块。

“stapusr”组中的用户也可以创建自己的基本无特权 systemtap 脚本。

Systemtap 脚本

在安装了 systemtap 的所有系统上，您都可以访问示例脚本。这些可以在以下位置找到:

/usr/share/systemtap/examples/
运行 Systemtap 脚本

如上所述，systemtap 文件保存在。stp 扩展和使用 stap 命令运行。

要测试 systemtap，请使用提供的示例，如 disktop.stp 示例脚本。该脚本显示了当前哪些进程正在向磁盘写入数据。该脚本可在以下位置找到

/usr/share/systemtap/examples/io/disktop.stp

该脚本的作用是探测内核以获取有关所连接的块设备的信息:

# stap -v /usr/share/systemtap/examples/io/disktop.stp

一旦脚本运行，您将看到脚本探测内核的任何磁盘操作。

要对此进行测试，请在新窗口中运行类似于以下内容的 DD 命令:

# dd if=/dev/zero of=file.txt count=1024 bs=1048576
交叉仪器

通常在实际环境中，不可能安装所有的 systemtap 包来运行探测或测试。因此，只需安装 systemtap-runtime 包就可以创建 systemtap 模块并执行它们。

这将允许一个系统被用作可用于编译 systemtap 仪器模块的编译器。然而，内核版本需要匹配，系统需要相同的架构。要为不同的内核版本构建不同的模块，只需将构建系统重启到不同的内核。

要创建跨工具 iotop 模块，可以运行以下命令:

# stap -p 4 -m iotop /usr/share/systemtap/examples/io/iotop.stp

创建后，这些模块需要由 sysadmin 复制到要在其上执行模块的系统的/lib/modules/uname-r/ systemtap 中。

系统调谐

Linux 系统管理的另一个重要方面是了解如何针对需要执行的任务调优 Linux 系统。

如果您没有任何供应商的指导，或者如果您是管理 Linux 系统的新手，这个过程可能会很困难。

调整

调整 Linux 系统的过程可能涉及到对内核参数和系统配置的深入理解。但是，有一个非常好的工具叫做“tuned ”,它能够使用不同的概要文件来调整系统。

装置

Tuned 可以通过 yum 简单地安装在 RHEL 系统上，如下所示:

# yum install tuned

Tuned 还需要启用并启动服务:

# systemctl enable tuned
# systemctl start tuned

使用调谐的

Tuned 在安装过程中提供了许多概要文件。要查看当前活动的配置文件，您可以运行以下命令:

# tuned-adm active

要列出所有可用的配置文件，您可以运行命令

# tuned-adm list

最后，要切换到不同的概要文件，您可以运行

# tuned-adm profile <name of profile>

摘要

在本章中，向您介绍了以下内容:

  • Linux 系统分析工具，如 sosreports，以及如何以快速简单的方式阅读它们

  • 可用于提取系统信息的标准系统工具

  • 系统跟踪工具，如 strace 和 systemtap

  • 使用调优的实用程序以简单的方式进行系统调优

第一部分：基础

Laying the Foundation

在深入探讨管理大型或小型 Linux 资产的高级或中级主题之前，非常重要的一点是，我们需要建立必要的基本技能来充分理解这本书。这是第一部分的主要目的。

第二部分：强化核心技能

Strengthening Core Skills

既然第一部分已经完成，并且表达了作为 Linux 系统管理员应该达到的水平，那么第二部分将关注在您可能还没有接触过的领域中构建新的技能。

第三部分：练习和保持

Day Two Practices and Keeping the Lights On

在第二部分中，我们讨论了如何通过探索您可以或者应该使用什么工具来改进您正在做的事情。这些最初的章节是以这样一种方式写的，它让你的头脑能够用更少的资源做更多的事情。我们谈到了管理工具、自动化和集装箱化。

这一部分的目标是了解如何继续保持正常运行，应该考虑使用什么工具，以及应该如何尽可能保持环境的安全性，同时又足够灵活，不会限制创新。

第四部分：观察，分析，然后行动

See, Analyze, Then Act

排除故障和寻求帮助可能是一个优秀的 Linux 系统管理员应该具备的最重要的技能。我们中的大多数人都是通过反复试验来学习这些技能的，或者希望通过别人的经验来学习，比如我的书。接下来的章节将向你展示如何处理和解决难题。

posted @ 2024-08-02 19:34  绝不原创的飞龙  阅读(2)  评论(0)  编辑  收藏  举报