挑战
全球最大的长途拼车社区 BlaBlaCar 连接了 22 个国家的 4000 万会员。自 2012 年以来，该公司一直经历着指数级增长，其基础设施需要跟上。BlaBlaCar 的基础设施工程师 Simon Lallemand 表示：“当你考虑将服务器数量翻倍时，你就会开始思考，‘我该怎么做才能更有效率？’答案不是雇用越来越多的人来处理服务器和安装。”团队知道他们必须扩展平台，但希望保留自己的裸机服务器。
解决方案
BlaBlaCar 团队选择不转向云虚拟化或在其自己的服务器上使用私有云，而是成为容器化的早期采用者，使用 CoreOs 运行时 rkt，最初使用 fleet 集群管理器进行部署。去年，该公司转向 Kubernetes 编排，现在还使用 Prometheus 进行监控。
影响
Lallemand 说：“在使用容器之前，创建一个新服务有时需要一天，有时需要两天。而有了我们围绕容器开发的所有工具，现在复制一个新服务只需几分钟。这确实是一个巨大的进步。我们能够更好地进行数据中心容量规划，因为服务与我们运行的硬件之间的抽象减少了限制。对于开发人员来说，这也意味着他们可以只关注他们正在开发的功能，而不必关注基础设施。”
然而，在幕后，基础设施远远落后于骑行社区的指数级增长。公司成立于 2006 年，在 2012 年左右达到目前的鼎盛时期。“我们的基础设施非常传统，”基础设施工程师 Simon Lallemand 说，他于 2014 年开始在这家公司工作。“一开始，有点混乱，因为我们不得不快速（增长）。但后来，你必须设计一些东西来使其易于管理。”
到 2015 年，公司拥有大约 50 台裸机服务器。Lallemand 说，团队使用 MySQL 数据库和 PHP，但是“这是一种非常静态的方式”。他们还利用了配置管理系统 Chef，但其流程自动化程度很低。“当你考虑将服务器数量翻倍时，你就会开始思考，‘我该怎么做才能更有效率？’”Lallemand 说，“答案不是雇佣越来越多的人来处理服务器和安装。”
相反，BlaBlaCar 开启了其云原生之旅，但并不确定该走哪条路。Lallemand 说：“我们可以选择走向云虚拟化，甚至可以在我们自己的服务器上使用私有云。但走向云意味着我们必须对我们的应用程序工作进行大量更改，而我们还没有准备好从本地切换到云端。”他们希望保持在裸机上获得的出色性能，所以他们不想在本地进行虚拟化。
解决方案：容器化。当时是 2015 年初，容器仍然相对较新。Lallemand 说：“那是一个大胆的举动。我们决定在新数据中心购买的下一批服务器都将是相同的型号，这样我们就可以将服务器的维护外包出去。我们决定使用容器和 CoreOS Container Linux 作为这种硬件的抽象。使用容器似乎是面向未来的，因为我们可以看到其他公司已经在用容器做什么。”
接下来，他们需要为容器选择一个运行时，但 Lallemand 说：“当时生产环境中很少有部署。”他们试验了 Docker，但最终决定使用 rkt。Lallemand 解释说，对于 BlaBlaCar 而言，“集成 rkt 上的东西要简单得多。”当时，该项目仍处于 v1.0 之前，所以“我们可以与 rkt 的开发人员交谈并向他们提供反馈。这是一个优势。”此外，他指出，即使在早期阶段，rkt 也非常稳定。
那年夏天做出这些决定后，公司制定了实施计划。首先，他们成立了一个任务组来创建一个工作流，由 Lallemand 团队的 10 名成员中的三名进行测试。但他们注意与所有 10 名成员定期举办研讨会，以确保每个人都参与其中。Lallemand 说：“当你专注于产品时，有时你会忘记它是否真正用户友好，其他人是否也能创建容器。所以我们进行了大量迭代以找到一个好的工作流。”
Lallemand 微笑着说，在确定工作流程后，“我们有一个奇怪的想法，我们应该先尝试最困难的事情。因为如果它奏效了，那么所有事情都会奏效。”所以团队决定将第一个项目容器化的是数据库。“当时没有人这样做，而且我们想要做的，包括构建容器镜像，真的没有现有的工具，”他说。因此团队创建了自己的工具，例如 dgr，它构建容器镜像，以便整个团队拥有一个共同的框架，可以以相同的标准构建相同的镜像。他们还改造了服务发现工具 Nerve 和 Synapse；他们的版本 Go-Nerve 和 Go-Synapse 用 Go 语言编写，旨在提高效率并包含新功能。所有这些工具都已开源。
与此同时，该公司正在努力将其整个平台迁移到容器，并设定了 2015 年圣诞节的最后期限。通过并行完成所有工作，BlaBlaCar 在截止日期前将约 80% 的生产系统迁移到容器中，并在 12 月份有实时流量在容器上运行。（现在已达到 100%。）Lallemand 说：“那是一个流量非常繁忙的时期。我们知道使用这些带有容器的新服务器将帮助我们处理流量。”
在那个拼车旺季中，一切顺利。“我们最大的影响是新服务的部署，”Lallemand 说，“在使用容器之前，我们必须首先部署一个新服务器并使用 Chef 创建配置。创建一个新服务有时需要一天，有时需要两天。而有了我们围绕容器开发的所有工具，复制一个新服务只需几分钟。所以这是一个巨大的进步。对于开发人员来说，这意味着他们可以只关注他们正在开发的功能，而不必关注基础设施，也不必关注他们测试代码的时间，或者部署代码的时间。”
为了满足他们自己设定的最后期限，他们做出的决定之一是，在第一次生产部署中不做任何容器“编排魔术”。相反，他们使用 CoreOS 的基本 fleet 工具来部署他们的容器。（他们确实构建了一个名为 GGN 的工具，并将其开源，以便他们的系统工程师更容易使用。）
尽管如此，团队知道他们会需要更多的编排。Lallemand 说：“我们的工具做得很好，但总有一天你会希望给开发团队更多的自主权。我们也意识到，当开发人员想启动新服务时，我们不想成为他们的单一联系点。”到 2016 年夏天，他们在 Kubernetes 中找到了答案，Kubernetes 刚刚开始支持 rkt 实现。
在与 CoreOS 和 Google 的联系人讨论他们的需求后，他们确信 Kubernetes 将适用于 BlaBlaCar。Lallemand 说：“我们意识到，围绕它有一个非常强大的社区，这意味着我们不必维护很多自己的工具。如果我们能为像 Kubernetes 这样更大的项目做出贡献，那会更好。”他们还开始使用 Prometheus，因为他们正在寻找“可以每晚更新的面向服务的监控”。Kubernetes 上的生产于 2016 年 12 月开始。“我们喜欢在圣诞节前后做一些疯狂的事情，”他笑着补充道。
BlaBlaCar 现在大约有 3000 个 Pod，其中 1200 个在 Kubernetes 上运行。Lallemand 领导着一个由 25 名成员组成的“基础团队”，负责为大约 100 名开发人员管理网络、数据库和系统。达到这一点存在一些挑战。Lallemand 指出：“rkt 的实现仍然没有 100% 完成。它真的很好，但仍然缺少一些功能。我们对于如何处理有状态服务（如数据库）存在疑问。我们知道如何迁移一些服务；其他一些处理起来则有点复杂。但 Kubernetes 社区在这方面正在取得很大进展。”
团队特别高兴的是，他们现在能够更好地规划公司数据中心的容量。Lallemand 说：“由于服务与我们运行的硬件之间存在这种抽象，我们的限制更少。如果一个服务器由于硬件问题而丢失，我们只需将容器移动到另一个服务器上。效率更高。我们只需更改配置文件中的一行即可。而有了 Kubernetes，这应该是自动化的，所以我们什么都不用做。”
这些进步最终会惠及 BlaBlaCar 的用户。Lallemand 说：“我们网站的整体可用性有所提高。当你转向这种所有内容都在容器中运行的云原生模型时，你必须确保在任何时候都可以重新启动服务器或数据容器，而不会出现任何停机，也不会丢失流量。所以现在我们的基础设施更具弹性，可用性也比以前更高。”
在 BlaBlaCar 的技术部门内部，云原生之旅带来了一些深刻的变化。Lallemand 认为，在构思阶段的定期会议和在实施阶段的培训课程起到了作用。他说：“之后每个人都参与了迁移过程。然后我们将组织划分为不同的‘部落’——这些团队汇集了开发人员、产品经理、数据分析师等所有不同职位的人，共同专注于产品的特定部分。以前，他们是按职能组织的。这样做的目的是让所有这些部落能够以自助服务的方式直接访问基础设施，而无需提出请求。这些人真正具有自主权。他们负责产品的那一部分，并且可以更快地做出决策。”
这种 DevOps 转型对公司的员工来说是积极的。Lallemand 说：“团队对 DevOps 转型非常兴奋，因为它是新的，我们正在努力使事情更可靠、更面向未来。我们喜欢做很少有人做的事情，除了互联网巨头。”
随着这些变化已经产生影响，BlaBlaCar 正在寻求将其应用程序更多地拆分为服务。Lallemand 说：“我不会说微服务，因为它们没那么微。如果我们能将开发团队之间的职责分开，那么管理起来会更容易，也更可靠，因为如果一个服务失败，我们可以很容易地添加和删除服务。你可以轻松处理它，而不是添加我们仍然拥有的一个庞大的单体应用。”
当 Lallemand 与其他对 BlaBlaCar 的基础设施所做的工作感到好奇的欧洲公司交谈时，他告诉他们一起来体验。“我告诉他们，与以前相比，处理我们今天拥有的基础设施是多么的愉快，”他说。“他们只需要记住自己的真实动机，无论是开发的灵活性还是可靠性等等，然后一步步地实现这些目标。这就是我们所做的。重要的是不要为了技术而技术。要为了一个目的而做。我们的重点是帮助开发人员。”