关于 DeveloperWeek Cloud 2022 的思考

这是自大流行开始以来会议真正开始的第一年。DeveloperWeek Cloud 2022 也于今年在德克萨斯州奥斯汀重磅回归。两个主要的轨道是 DevOps 和 DevLead。

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

可观察性

为了让开发人员提高任何系统的可靠性，他们首先需要观察它，以一种他们可以看到更长时间的趋势的方式。可观察性是通向可靠性的途径。

有几种方法可以用来观察你的 MinIO 集群：

• /minio/v2/metrics/clusterMinIO 有一个可以被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 中，您的应用程序可以使用Security Token Service请求临时凭证，而不是使用静态的预先确定的凭证。这样，您的应用程序无需存储任何凭据即可访问 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 工程师接管，他们最关心的是确保这些系统得到优化。

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

1. 应用程序开发人员需要根据代码库中的云提供商来处理不同的逻辑。

2. DevOps 工程师将不得不与两家云提供商一起构建和维护两种不同的解决方案，这会给新工程师带来更多的摩擦和学习曲线。

3. 即使系统是 *aaS（PaaS、DBaaS、IaaS 等），工程师仍然需要担心减速、中断、安全以及最重要的……成本。架构、设计、配置、调整和优化这些系统是一项共同责任。

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

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

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

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

3.及时发现异常关闭的问题和罕见事件：stack、deployment、stream dependent。

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

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

最后的想法

总而言之，我很高兴今年能够参加这个会议。我特别喜欢这样一个事实，即大多数谈话都集中在可观察性和安全性等基础知识上，这些基础知识为开发人员构建的许多基础设施和应用程序奠定了基础。

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