MixPanel代码部署工具的演变

在MixPanel，我们有了云的起伏。我们在2011年将云移回到2011年到部署在软层上的专用硬件。虽然我们摆脱了我们在Rackspace上看到的一些嘈杂的邻居问题，但它以过度配置的加工能力为代价，因为它很难让机器按需获取。经过大量的灵魂搜索，我们终于决定在2016年回到云端。当时，Kubernetes（K8S）被涌现为集装箱管理的行业领导者。我们真的很喜欢谷歌的托管K8S提供（GKE），并于2017年底，大部分MixPanel的基础设施正在谷歌云平台上运行（GCP）。

当我们第一次移动到GKE时，我们建立了两个相同的集群。两者都在相同的地区，而是在不同的区域中进行冗余和高可用性。每个团队都会在自己的命名空间下部署服务。这给了我们一种扩展我们的K8S部署的方法，因为越来越多的工作负载移动到云。我们开始为每个工作负载中的手工制作的yaml文件。工程师会编辑并应用这些文件ad-hoc。要保持两个群集同步，它们必须两次部署代码。偶尔，有人会忘记部署到第二个区域，这导致了难以调试的细微差异。随着时间的推移，我们创建了一个名为mix的包装器，它将弥补新文件，以防止在生产中运行的内容，以便了解将应用更改的内容，然后如果一个区域与另一个区域不同步，则会提醒您。很快，Mix成为手动构建和部署代码的De-Facto工具。假设您想要部署一个服务foo的新版本，＆＃39; d运行以下命令。

在我们让我们的服务上运行并运行时，手动部署令人惊讶的是。添加了越来越多的功能来混合以与K8S相互作用，而且还添加了其他GCP服务。为避免直接处理原始的YAML文件，我们将K8S配置管理移动到JSONnet。 jsonnet允许我们为常用的范例添加模板，并在不同的部署中重用它们。

与此同时，我们一直在添加更多的K8S集群。我们添加了更多地理上分布式的集群，以运行处理传入数据以减少摄入API客户端感知的延迟的服务器。截至2018年底，我们开始评估欧洲数据居住产品。这需要我们在欧盟两国部署我们所有服务的另一个完整副本。

我们现在最多12个独立的集群，其中许多人运行相同的代码并具有相似的配置。

当手动部署工作时，我们在只有两个区域中运行代码时，它很快就会发出手动连续12个独立的群集。在所有团队中，我们运行了100多个单独的服务和部署。许多这些服务彼此依赖，所以有时我们必须仔细协调部署以确保在然后更新服务之前完全更新依赖项。在添加集成测试和更好的警报系统时帮助改善了事物，我们很快意识到我们需要从第一个原则接近这个问题。我们对我们来说非常清楚，我们需要一种自动部署代码和CI / CD设置的自动化方法。我们决定使用两个最受欢迎的建议：Spinnaker和Argo。

我们发现Spinnaker更加用户友好。看到建造的管道的视觉表现非常出色。 Spinnaker的内置Slack Messaging与我们现有的部署监控程序很好地集成。我们的工程师监控Slack，并在通知未发生故障的部署时快速响应。 Spinnaker最大的痛点是无法代表代码中的管道。我们尝试通过使用JSONnet创建自定义库来解决此限制，但这不是最容易维护和运行的事情。最后，Spinnaker使用Java。这并不坏;我们在MixPanel上运行了一些Java服务。但是，我们的工程团队更熟悉Golang，我们更喜欢尽可能使用基于Golang的解决方案。

ARGO是不少的自以为是，建立在K8S上。没有GUI建造管道，但文件在解释一切方面都很善良。因为一切都在引擎盖下使用了K8S Yaml文件，我们可以使用Git轻松地控制所有更改。要对管道进行更改，您所需的就是使用更改，测试它并将其与主分支合并到主分支中的所有新分支。我们还可以重用许多jsonnet模板和工具来创建这些工作流，这是一个奖金。

最终，这是一个相当近的决定，但我们决定与阿尔戈一起去。

正如我们之前提到的，我们正在寻找的一个关键功能是MixPanel任何工程师都可以定义和更新管道部署其服务的流水管。由于ARGO工作流只是YAML文件，我们可以扩展JSONNET库以帮助使此过程更顺畅。为了说明这一点，MixPanel的工程师最常见的工作流之一是这样的：

虽然我们还没有想到以自动化我们的工程师＆＃39的方式;撰写功能和错误修复的工作，其余部分与我们使用JSONnet建造的模板相当微不足道。这是建立管道的示例看起来像：

这为您提供了部署服务的工作管道。添加Slack通知也很容易。我们使用单独的任务和顺序工作流来通知相关频道：

它确实需要更多的工作，而不是Spinnaker，但我们对更多的自定义消息感到满意。

现在，工程师可以更容易地定义管道，我们想专注于部署过程的最终用户体验。我们的部署选项由YAML配置目录的目录结构指定，因此确定要部署的潜在服务或特定服务运行的群集并不简单。为了解决这个问题，我们制作了一个简单的交互式工具（基于https://github.com/alecaivazis/survey），它会提示用户每个服务的潜在服务和集群。代替部署者必须记住运行特定服务的所有群集，服务所有者在将服务部署到新群集时更新配置。下次部署到包括该服务的新实例时，将提示Deployer。下面可以在“交互式”部署工具的一个示例。

此外，此更全面的部署工具允许依赖和配置协调。由于我们的工程团队缩放，因此我们的工程团队已经获得了复杂性，积极预防的部署变得更加重要。到目前为止，我们对Argo非常满意;它解决了我们所阐述的所有问题。

在过去的几个月里，我们的许多服务已经转移到Argo。下图显示了每个月的ARGO基部署数。

虽然我们一直非常满意K8S和ARGO，但我们意识到提高开发人员体验是一个连续的过程（没有双关语）。在接下来的几个月里，我们真的很想到达一个稳定的管道，以便为我们最关键的服务持续集成和部署。

MixPanel的DevInfra团队充当了力量乘法器，在团队中实施最佳实践和复杂的开发人员工具，为我们的工程师构建世界一流的平台。我们通过顶部缺口内部分析和可观察性来确定高影响力项目 - 即使使用MixPanel本身也是如此！如果对您感兴趣，请达到[email protected]。