挑战
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 中找到了答案，它刚刚开始支持 rkt 实现。
在与 CoreOS 和 Google 的联系人讨论了他们的需求后，他们确信 Kubernetes 会适用于 BlaBlaCar。Lallemand 说：“我们意识到它周围有一个非常强大的社区，这意味着我们无需维护大量自己的工具。如果我们能为像 Kubernetes 这样更大的项目做出贡献，那就更好了。”他们还开始使用 Prometheus，因为他们正在寻找“面向服务的监控，可以每晚更新”。于2016年12月开始在 Kubernetes 上进行生产部署。他笑着补充说：“我们喜欢在圣诞节前后做一些疯狂的事情。”
BlaBlaCar 现在有大约3,000个 pod，其中1200个运行在 Kubernetes 上。Lallemand 领导一个由25名成员组成的“基础团队”，负责大约100名开发者的网络、数据库和系统。达到这一点存在一些挑战。Lallemand 指出：“rkt 的实现还没有100%完成。它确实很好，但仍缺少一些功能。对于如何处理有状态服务，如数据库，我们存在疑问。我们知道如何迁移其中一些服务；其他一些服务处理起来有点复杂。但 Kubernetes 社区正在这方面取得很大进展。”
团队特别高兴的是，他们现在能够更好地规划公司数据中心的容量。Lallemand 说：“由于有了服务与其运行的硬件之间的抽象，限制更少。如果我们由于硬件问题而丢失一台服务器，我们只需将容器移动到另一台服务器上。效率更高。只需更改配置文件中的一行即可。使用 Kubernetes，这应该是自动的，所以我们就什么都不用做了。”
而这些进步最终惠及 BlaBlaCar 的用户。Lallemand 说：“我们的网站整体可用性提高了。当你转向这种云原生模式并将所有内容都在容器中运行时，你必须确保在任何时候都可以在不停机、不丢失流量的情况下重启服务器或数据容器。所以现在我们的基础设施更具弹性，可用性比以前更高。”
在 BlaBlaCar 的技术部门内部，云原生之旅带来了一些深远的变化。Lallemand 认为，构思阶段的定期会议和实施阶段的培训课程起到了作用。他说：“之后每个人都参与了迁移过程。然后我们将组织划分成不同的‘部落’——聚集开发者、产品经理、数据分析师等不同岗位人员的团队，专注于产品的特定部分。之前，他们是按职能组织的。这样做的想法是让所有这些部落能够直接以自助服务的方式访问基础设施，而无需请求。这些人非常有自主权。他们对产品的那部分负责，并且可以更快地做出决定。”
这次 DevOps 转型对公司员工来说是积极的。Lallemand 说：“团队对 DevOps 转型非常兴奋，因为这是新的事物，我们正在努力让事情更可靠、更面向未来。我们喜欢做很少有人做的事情，除了互联网巨头之外。”
这些变化已经产生了影响，BlaBlaCar 正在考虑将越来越多的应用程序拆分成服务。Lallemand 说：“我不说微服务，因为它们并不是那么微小。如果我们能在开发团队之间划分职责，将更容易管理且更可靠，因为如果某个服务失败，可以轻松添加和移除服务。你可以轻松处理它，而不是添加我们仍然拥有的那个大型单体应用。”
当 Lallemand 与其他对 BlaBlaCar 的基础设施做法感到好奇的欧洲公司交流时，他告诉他们一起来体验一下。他说：“我告诉他们，处理我们今天拥有的基础设施是如此令人愉悦，与我们以前相比。他们只需要牢记他们真正的动机，无论是开发灵活性、可靠性等等，然后逐步实现这些目标。这就是我们所做的。重要的是不要为了技术而做技术。做它要有一个目的。我们的重点是帮助开发者。”