DeveloperWeek Cloud 2022 思考

AJ AJ 于云原生 2022 年 9 月 9 日

这是疫情开始以来第一年，会议真正开始举办。DeveloperWeek Cloud 2022 今年也强势回归，在德克萨斯州奥斯汀举行。两个主要主题是 DevOps 和 DevLead。

会议上的一些演讲深入探讨了可观察性、安全性和可靠性的一些子主题。这让我对开发人员如何在 DevOps 堆栈的不同级别整合 MinIO 以支持各种应用程序，并在过程中确保我们部署了一个可靠且易于管理的 MinIO 集群有了深刻的见解。

可观察性

为了提高任何系统的可靠性，开发人员首先需要对其进行观察，以便能够查看较长时间内的趋势。可观察性是通往可靠性的途径。

有几种方法可以观察您的 MinIO 集群

MinIO 有一个指标端点 /minio/v2/metrics/cluster，可以被 Prometheus 抓取。然后可以通过 Grafana 可视化这些抓取的数据，并在仪表盘上显示。
MinIO 的事件可以发送到几个存储桶通知目标。在过去的博客中，我们展示了如何将存储桶通知事件发送到 Kafka。但您也可以将这些事件发送到 Elasticsearch，以便能够在 Kibana 中查询或绘制图表。
您可以获取 MinIO SystemD 日志并将其发送到 Elasticsearch，这可以帮助您在一个单一的视图中关联各种日志流。
当然，您还可以将这些指标存储在 MinIO 中作为可靠的后端。

定义了您可以达到的 SLA/SLO/SLI 目标

SLA：这是您与最终用户/客户/供应商之间达成的协议。
SLO：您的团队必须达成的目标。
SLI：用于衡量性能的实际数字。

为了进一步将您的应用程序与 MinIO 中的事件紧密集成，您可以使用 OpenTelemetry 将跟踪、指标和日志发送到更进一步观察它们之间的交互。MinIO 为 Python、GO 和 Java 提供 SDK，OpenTelemetry 也是如此，因此您可以快速开始使用您熟悉的语言。

因此，开发人员不仅应该观察和监控他们的应用程序，而且 DevOps 监控应用程序运行在其顶部的基础设施并以有意义的方式关联这些事件也至关重要。

安全

管理和轮换密码是 DevOps 工程师必须处理的那些费力的任务之一，能够拥有无密码体验但仍然拥有身份验证的所有好处将会非常不错。在 MinIO 中，您的应用程序可以使用安全令牌服务请求临时凭据，而不是使用静态预先确定的凭据。这样，您的应用程序就不需要存储任何凭据来访问 MinIO 资源。它只需在需要访问存储桶时请求特定时间段内的凭据，之后这些凭据就会过期。

身份验证只是拼图的一部分；另一个是授权。身份验证允许开发人员验证用户是否有效，但一旦用户被验证，他们需要确定对各种组件的访问权限。这就是授权发挥作用的地方。

例如，一旦用户登录，假设我们希望团队经理和向经理汇报工作的任何人能够访问特定存储桶。在这种情况下，假设 Alice 是经理，Bob 向她汇报工作，但 Joe 向 Alice 的老板汇报工作。我们希望 Alice 和 Bob 能够访问此存储桶，但 Joe 不能访问。请记住，此逻辑可能会发生变化，因为 Alice 在其下有更多下属，或者如果 Bob 不再向 Alice 汇报工作，并且我们不希望 Bob 访问存储桶。

您可以在应用程序中编写复杂的逻辑来处理这些场景，但随着复杂性的增加，管理这些逻辑可能会变得难以处理。这就是 Open-Policy Agent (OPA) 派上用场的地方。它有一种名为 Rego 的专用语言，可以帮助我们定义基于请求定义的策略。Rego 具有内置函数，可以帮助简洁地编写策略，并尽可能接近零决策时间，这意味着从发出授权查询到发送回结果的时间应该在几秒钟内。

可靠性

20 年前的系统工程师可能正在处理一台服务器、一个单体应用程序和一个日志文件。如今，典型的 DevOps 工程师处理数百甚至数千台服务器/虚拟机、100 多个微型应用程序（或微服务）和 1000 个日志流，每秒产生数千条日志。在这种规模和速度下，当今的 DevOps 工程师不仅管理底层基础设施，而且该角色通常还负责数据库等应用程序的性能。例如，如今您很少看到数据库管理员职位可用，因为此功能或多或少已被功能更强大的 SRE 和 DevOps 工程师接管，他们最关心的是确保这些系统得到优化。

在处理多个应用程序和多个云时，开发人员应该开始以细粒度和可重用的方式考虑微服务。如果您使用两个不同的云提供商，并且必须使用两个不同的存储系统，那么这对工程师来说就是技术债务和维护负担。

应用程序开发人员需要在代码库中处理基于云提供商的不同逻辑。
DevOps 工程师将不得不为两个云提供商构建和维护两个不同的解决方案，从而造成更多摩擦并导致新工程师的学习曲线。
即使系统是 *aaS（PaaS、DBaaS、IaaS 等），工程师仍然需要担心速度下降、中断、安全性和最重要的是……成本。架构、设计、配置、调整和优化这些系统是共同的责任。

这就是像 MinIO 这样的云无关系统派上用场的地方。MinIO 可以以分布式设置在任何地方运行；在云中、本地（物理硬件）、物联网/边缘、容器等等。通过拥有一个通用的存储后端，开发人员只需要专注于编写 S3 代码，无论他们身在何处，您的 DevOps 工程师都可以对所有云使用相同的升级和维护策略。您还可以通过根据需要控制硬件、提供商和带宽来节省成本。

管理不同系统面临的挑战之一是无法关联。例如，您可能将应用程序日志发送到 Elasticsearch。如果您无法从存储桶中获取对象，您可能会看到有关由于服务器问题导致 GET 请求失败的错误。通常，这些信息都很模糊，您要么需要一个非常了解应用程序并拥有经验知识的人，要么像我们大多数人一样，需要更多信息来了解为什么无法获取该对象。这是因为日志是为人类故障排除而唯一编码的；他们能够通过以下方式在日志中找到根本原因

1. 检测问题：通过某种类型的堆栈跟踪或指标警报。

2. 注意罕见事件：以前从未见过的事件。

3. 注意时间异常接近的问题和罕见事件：堆栈、部署、流相关。

4. 从问题和罕见事件构建叙述。

根本原因并不总是错误，它有时也可能是调试和信息日志，因为绝大多数日志都基于罕见事件。有一些工具可以“测试”这些罕见事件，称为“混沌工程”工具。最常见的一个来自 Netflix：Chaos Monkey。但还有其他工具，例如 Gremlin、Chaos Mesh 和 Litmus。

最终想法

总而言之，我很高兴今年能够参加这次会议。我特别喜欢大多数演讲都专注于可观察性和安全性等基础知识，这些知识为开发人员构建的大部分基础设施和应用程序奠定了基础。

我相信每个人都听说过“左移”这个词，这意味着在开发生命周期的早期阶段而不是后期开始考虑特定的实践。您可以将相同的原则应用于可观察性。在开发生命周期的早期阶段构建应用程序时，就开始监控、观察和跟踪您的应用程序。这样，您可以确保所有系统从一开始就安全，并考虑规模和可靠性，而不是事后才想到。

如果您对 MinIO 的监控、扩展或安全有任何疑问，请在我们的 Slack 上联系我们！