挑戰
全球最大的長途拼車社群 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 的基礎設施所做的工作感到好奇的歐洲公司交談時，他告訴他們一起來體驗。“我告訴他們，與以前相比，處理我們今天擁有的基礎設施是多麼的愉快，”他說。“他們只需要記住自己的真實動機，無論是開發的靈活性還是可靠性等等，然後一步步地實現這些目標。這就是我們所做的。重要的是不要為了技術而技術。要為了一個目的而做。我們的重點是幫助開發人員。”