NGINX现代应用参考架构1.0.0版正式发布

NGINX | 2022年4月28日

2021年8月，我们在Sprint 2.0上发布NGINX 现代应用参考架构（MARA）时，明确说明了设计目标。我们希望创建一个在Kubernetes中运行的现代应用架构示例，旨在支持安全性、可扩展性、可靠性、监控和内省。该项目需要能够部署在不同的基础设施上，并以“即插即用”的方式组合功能组件，无需耗时的集成工作。

自Sprint以来的几个月里，我们一直在按路线图推进。与任何项目一样，我们既取得了成功，也经历了失败。我们将成功经验融入MARA，同时不断总结经验教训。我们希望通过记录这些问题，并在设计中充分考虑相关经验，帮助其他人避免遇到同样的问题。

最近，我们迎来了一个里程碑：MARA version 1.0.0。该版本重新组织了项目目录，并更改了环境的实例化和销毁流程。我们消除了重复代码，创建了便于日后扩展的目录结构，并对管理脚本进行了标准化。鉴于该版本是MARA发展历程中的一个重要节点，我们希望借此机会向社区汇报项目进展，分享一些我们认为较为重要的经验教训，并介绍未来的路线图。

NGINX Modern Apps Reference Architecture 1.0.0版拓扑图

遥测：指标、日志和追踪

MARA的核心贡献者拥有大规模运行软件的经验，并了解从运维、工程和管理角度交付服务需要具备哪些条件。他们深知，当应用出现异常，却无法轻松准确定位问题时，那种令人沮丧的感受。DevOps领域流传的一句话简明概括了这个问题：“调试微服务就像侦破一连串谋杀悬案。”

基于这一考虑，我们将增加可观测性功能列为短期路线图中的优先事项。在此语境下，可观测性包括日志管理、指标和追踪数据。但仅仅收集数据还不够，还必须能够深入分析数据，并对环境中发生的情况作出有意义的判断。

在探索追踪方案时，我们选择了OpenTelemetry（OTEL），因为它支持各类遥测数据，包括日志、指标和追踪数据。我们设想的实现方式是：由OTEL代理收集、处理所有追踪数据并进行去重，再将数据传递给OTEL收集器进行聚合和导出，最后通过工作流末端的可视化系统，让这些数据可供使用。这种方法既能让用户灵活选择数据的显示和分析方式，又能利用OTEL标准简化前期阶段（如收集和聚合）。

我们分两个阶段完成了实施：

部署OpenTelemetry Operator for Kubernetes，用于管理环境中的OTEL收集器
对Bank of Sirius应用进行插桩，使其发出跟踪数据和指标

MARA的原始版本使用Elasticsearch和Filebeat进行日志记录。虽然我们曾考虑将其替换为Grafana Loki，但目前决定保留原有方案。在指标方面，我们意识到需要调整原先基于Prometheus和Grafana的部署，将最初使用的定制Prometheus配置替换为由社区维护的kube-prometheus-stack Helm图表。该图表可部署完整的Prometheus环境，其中包括Grafana、节点导出器，以及一系列适用于管理Kubernetes环境的预配置仪表板和抓取目标。此外，我们还为F5 NGINX Ingress Controller和Bank of Sirius应用程序添加了一些仪表板。

以上只是对实施OTEL所需大量工作的简要概述。为帮助其他人少走弯路，我们在博客文章《将OpenTelemetry集成到现代应用参考架构：进展报告》中记录了整个过程。

部署选项：Kubeconfig

在MARA的初始版本中，我们选择了Amazon Elastic Kubernetes Service（EKS）作为部署环境。此后，许多用户表示，出于成本考虑，他们希望在资源需求较低的“本地”环境（例如实验室或工作站）中运行MARA。可移植性过去是、现在仍是原项目的关键目标，因此这正是验证我们能否实现这一目标的机会。为简化这项工作，我们决定设计一套部署流程，使其能够在满足最低要求的任何Kubernetes集群上运行。

第一步，我们在MARA中添加了一个新的Pulumi项目，该项目通过读取kubeconfig文件与Kubernetes集群通信。此项目位于Pulumi Kubernetes项目与基础设施项目之间（后者包括AWS和Digital Ocean项目）。实际上，创建kubeconfig项目降低了集成新基础设施项目的门槛。如果基础设施项目能够将kubeconfig文件、集群名称和集群上下文传递给kubeconfig项目，MARA部署流程的其余部分便可顺畅运行。

在测试中，我们使用了几种易于安装且CPU和内存要求较低的Kubernetes发行版，包括K3s、Canonical MicroK8s和minikube。所有发行版均部署在一台运行Ubuntu 21.10、配备2个CPU和16 GB内存的虚拟机（VM）上。此外，所有发行版均已配置为支持持久卷和Kubernetes LoadBalancer。

此过程中最困难的部分，是处理项目中定制构建的NGINX Ingress Controller所使用的私有注册表。（请注意，部署MARA时，除了这个定制构建的NGINX Ingress Controller，还可以使用基于NGINX Open Source或NGINX Plus的标准NGINX Ingress Controller。）我们发现，需要将注册表逻辑与Amazon Elastic Container Registry（ECR）解耦，改用更不依赖特定平台的方法。目前，这项工作仍在进行中。我们还发现，用于获取出口地址主机名的逻辑高度依赖AWS Elastic Load Balancing（ELB），需要重写才能适用于其他用例。

MARA管理脚本和Pulumi项目目前使用一些特定逻辑来规避上述问题。现阶段，基于Kubernetes配置的部署必须使用官方NGINX注册表中的NGINX Ingress Controller（基于NGINX Open Source或NGINX Plus）。

我们在MARA配置文件中添加了多个调优参数，以适应无法提供云部署所需资源的本地部署。大多数参数与Elastic Stack各组件所需的副本数量有关。随着测试推进，还将增加更多参数，以便根据部署环境的资源限制对MARA进行精细调优。

实施这些更改后，我们可以成功部署到K3s、MicroK8s和Minikube，并已在以下平台上成功测试相关逻辑：Azure Kubernetes Service（AKS）、Digital Ocean、Google Kubernetes Engine、Linode以及Rancher的Harvester。有关更多信息，请参阅博客中的MARA提供商状态页面和MARA：现已可在您的工作站上运行。

与合作伙伴协作

我们的合作伙伴对我们与MARA开展的工作反响积极，并给予了大力支持。许多合作伙伴主动联系我们，希望进一步了解该项目，探讨如何将其与自身产品结合使用，甚至为其添加功能。

我们选择将Pulumi作为MARA的核心组成部分，是因为它易于使用并支持Python。Python应用广泛，因此广大社区成员都能轻松理解MARA代码。此外，Pulumi活跃的社区及其对该项目的积极参与，也为我们希望在MARA中实现的社区参与模式树立了典范。

2021年末，我们与Sumo Logic合作，将MARA纳入其搭配NGINX Ingress Controller的云监控解决方案。这为我们提供了验证MARA可插拔特性的机会。挑战在于使用Sumo Logic解决方案替代MARA中的Grafana、Prometheus和Elastic。令人欣慰的是，我们采用与其他部署相同的逻辑成功部署了该解决方案，并将其配置为不仅可连接到Sumo Logic SaaS，还可从我们的环境中提取指标。

在开展OpenTelemetry相关工作的过程中，我们与Lightstep展开合作，并轻松地重新配置了OTEL收集器，将跟踪数据和指标导出到Lightstep的SaaS产品。我们非常希望进一步探索这一领域，因为我们坚信OTEL代表着可观测性的未来。

迄今为止的经验总结

到目前为止，我们得到的最大启示是，采用模块化方法是明智之举。与Sumo Logic的合作表明，我们可以成功地灵活组合MARA组件。随着OTEL更全面地集成到环境中，我们预计这一点将得到进一步验证。我们之前提到，正在考虑使用Grafana Loki取代Elasticsearch作为日志管理环境，因为这样可以减少该技术栈的资源占用。不过，我们提倡“务实的模块化”，而不是走向极端，将所有功能都做成微服务。例如，使用一项专门服务来处理多个应用的日志是合理的，但是否有必要分别为日志收集、存储和可视化设置独立的微服务，则并不那么明确。

我们还发现，与其直接省略相关参数，不如在配置中明确写入默认值。这样可从两方面为管理员提供便利：无需记住默认值；如需更改，只需修改配置中已位于正确位置且语法正确的参数即可。

我们还从一次惨痛的教训中认识到，有些解决方案广受欢迎，并非因为它们更出色，而是因为它们最容易安装或拥有更完善的教程。因此，在设计过程中，审视自己的假设并征求同事的意见至关重要。开放沟通的文化有助于尽早发现并解决问题。

不过，我们有几次实现的逻辑虽然可以正常运行，却限制了后续调整空间，或引发了其他问题。例如，刚开始通过Pulumi部署应用时，我们使用YAML清单来创建ConfigMap，并依靠Pulumi转换来更新变量。这种方法虽然可行，但由于多种原因并不理想，其中一个重要问题就是可维护性。在下一次迭代中，我们使用kube2pulumi将清单转换为Pulumi代码，再用这些代码构建ConfigMap，从而提高了代码的可读性和可维护性。

另一个教训源于一次合并操作在部署YAML中插入了无效设置。我们不得不重写并仔细检查大部分YAML，以确保代码语法正确且能实现预期功能。这个过程既令人沮丧又耗时。为避免今后出现类似问题，我们现在已在GitHub推送过程中实现自动化，对通用YAML和Kubernetes专用YAML执行代码检查和验证。

最后，我们从一开始就致力于确保主线分支始终可以运行。签出一个新项目后，却不得不解决维护者在主线中引入的问题，着实令人沮丧。遗憾的是，我们有几次未能做到这一点，其中包括以下与Bank of Sirius子模块有关的示例：

我们疏忽了，没有将URL方案从ssh://更改为https://。这对我们来说不是问题，因为我们都使用ssh连接GitHub。但是，没有GitHub SSH密钥的用户在尝试初始化子模块时，会收到大量错误消息。
某个版本的管理脚本依赖一个常用软件包。我们误以为每个人的计算机上都会像我们的计算机一样安装该软件包。
重写启动逻辑时，我们忘记添加对子模块源的检查。该子模块包含部署Bank of Sirius所需的清单。遗憾的是，缺少这些清单时抛出的错误和警告非常晦涩，导致我们花了数天时间调试异常行为，才发现根本原因。

后续计划

未来几个月，我们计划开展多项开发工作，包括重构NGINX Ingress Controller的构建、镜像仓库推送以及Ingress主机名和IP地址逻辑。

我们注意到，每次启动MARA后，NGINX Ingress Controller很快就会遭到扫描和攻击。因此，我们开始将NGINX Ingress Controller与NGINX App Protect WAF集成到MARA中。这也带来了新的挑战和机遇：如何以适当的方式管理App Protect生成的日志。

我们计划在未来几个月内进行另一项更改，让所有模块都从Kubernetes中提取密钥，而不再同时从Pulumi和Kubernetes中提取。这样，所有模块都将使用统一的密钥存储库，管理员也可以控制密钥的填充方式。我们正在编写一个新模块，用于从用户选择的存储库中读取密钥，并创建相应的Kubernetes密钥。

MARA目前包含一个负载生成工具，它是在Locust工具的基础上升级并略作修改而成。该工具随原版Bank of Anthos应用提供，而Bank of Sirius正是从该应用分叉而来。我们正在开发的新测试工具Cicada Swarm不仅能生成负载，还能在指标超过所设阈值时进行跟踪和报告，从而为云端软件产品提供快速性能测试框架。它采用并行化技术，以所需的置信水平和更高的精度提供测试结果，并支持可自定义的回归分析，用于判断CI/CD流水线中的构建是否成功。

最后，谈到负载测试，就不能不讨论如何衡量其影响，这又回到了遥测。OpenTelemetry潜力可观，我们希望很快能实现更全面的部署。即使尚未全面部署，我们的目标仍是能够运行测试、衡量其影响，并根据数据结果制定运维决策。

一如既往，我们欢迎您提交拉取请求、问题和评论。MARA旨在鼓励社区协作，共同讨论、尝试、测试并迭代各种潜在解决方案，从而加深我们对如何更好地部署和管理现代应用的理解。

本文是系列文章的一部分。随着我们不断为MARA添加新功能，我们会在博客中发布详细信息：