挑戰
全球最大的長途共乘社群 BlaBlaCar，在 22 個國家/地區連結了 4 千萬名會員。自 2012 年以來，該公司一直經歷指數級成長，需要其基礎架構跟上腳步。「當您考慮將伺服器數量增加一倍時，您會開始思考，『我應該做些什麼才能更有效率？』」BlaBlaCar 基礎架構工程師 Simon Lallemand 說。「答案不是僱用越來越多人來處理伺服器和安裝。」團隊知道他們必須擴展平台，但希望繼續使用自己的裸機伺服器。
解決方案
BlaBlaCar 團隊選擇不轉向雲端虛擬化或在自己的伺服器上使用私有雲，而是成為容器化的早期採用者，使用 CoreOS 執行時環境 rkt，最初是使用 fleet 叢集管理器部署的。去年，公司改用 Kubernetes 協調，現在也使用 Prometheus 進行監控。
影響
「在使用容器之前，有時需要一天，有時需要兩天，才能建立一個新服務。」Lallemand 說。「透過我們圍繞容器所做的所有工具，現在複製一個新服務只需幾分鐘。這真的是一個巨大的進步。由於服務和我們運行的硬體之間存在這種抽象化，我們在資料中心進行容量規劃時做得更好，因為我們的限制更少。對於開發人員來說，這也意味著他們可以專注於他們正在開發的功能，而不是基礎架構。」
然而，在幕後，基礎架構遠遠落後於共乘社群的指數級成長。該公司成立於 2006 年，在 2012 年左右達到目前的規模。「我們的基礎架構非常傳統。」基礎架構工程師 Simon Lallemand 說，他於 2014 年開始在公司工作。「一開始，有點混亂，因為我們必須 [快速成長]。但隨後就到了您必須設計事物使其可管理的時候。」
到 2015 年，該公司約有 50 台裸機伺服器。團隊正在使用 MySQL 資料庫和 PHP，但是，Lallemand 說，「這是一種非常靜態的方式。」他們還使用了組態管理系統 Chef，但在其流程中幾乎沒有自動化。「當您考慮將伺服器數量增加一倍時，您會開始思考，『我應該做些什麼才能更有效率？』」Lallemand 說。「答案不是僱用越來越多人來處理伺服器和安裝。」
相反地，BlaBlaCar 開始了他們的雲原生之旅，但不確定該走哪條路線。「我們可以決定進入雲端虛擬化，甚至在我們自己的伺服器上使用私有雲。」Lallemand 說。「但是進入雲端意味著我們必須在應用程式工作中做出很多變更，而我們還沒有準備好從內部部署切換到雲端。」他們希望保持在裸機上獲得的優異效能，因此他們不想在內部部署上進行虛擬化。
解決方案：容器化。那是 2015 年初，容器仍然相對較新。「當時這是一個大膽的舉動。」Lallemand 說。「我們決定，我們在新資料中心購買的下一批伺服器都將是相同的型號，這樣我們就可以將伺服器的維護外包出去。我們決定採用容器和 CoreOS Container Linux 作為此硬體的抽象化。採用容器似乎具有前瞻性，因為我們可以了解公司已經在容器方面做些什麼。」
接下來，他們需要為容器選擇一個執行時環境，但是「當時在生產環境中部署的案例非常少。」Lallemand 說。他們試驗了 Docker，但決定採用 rkt。Lallemand 解釋說，對於 BlaBlaCar 來說，將 rkt 上的東西整合在一起「要簡單得多」。當時，該專案仍處於 v1.0 之前的階段，因此「我們可以與 rkt 的開發人員交談並向他們提供回饋。這是一個優勢。」此外，他指出，即使在這個早期階段，rkt 也非常穩定。
在 2015 年夏天做出這些決定後，公司制定了一個實施計畫。首先，他們成立了一個任務小組，建立一個工作流程，該工作流程將由 Lallemand 團隊 10 名成員中的 3 名進行測試。但他們注意定期與所有 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 現在約有 3,000 個 Pod，其中 1200 個在 Kubernetes 上運行。Lallemand 領導著一個由 25 名成員組成的「基礎團隊」，他們負責約 100 名開發人員的網路、資料庫和系統。達到這一點遇到了一些挑戰。「rkt 實作仍然沒有 100% 完成。」Lallemand 指出。「它真的很好，但仍然缺少一些功能。我們對如何處理有狀態服務（例如資料庫）有疑問。我們知道我們將如何遷移某些服務；其他一些服務處理起來比較複雜。但 Kubernetes 社群在這方面正在取得很大進展。」
團隊特別高興他們現在能夠更好地規劃公司資料中心的容量。「由於服務和我們運行的硬體之間存在這種抽象化，我們的限制更少。」Lallemand 說。「如果我們因為硬體問題而丟失了一台伺服器，我們只需將容器移動到另一台伺服器即可。這樣效率更高。我們只需更改組態檔中的一行即可做到這一點。使用 Kubernetes，它應該是自動的，因此我們無需做任何事情。」
這些進步最終也惠及 BlaBlaCar 的用戶。「我們提高了我們網站的整體可用性。」Lallemand 說。「當您切換到這種雲原生模型並在容器中運行所有內容時，您必須確保在任何時候都可以重新啟動伺服器或資料容器而不會停機，也不會遺失流量。因此，現在我們的基礎架構更具彈性，並且我們的可用性比以前更好。」
在 BlaBlaCar 的技術部門內部，雲原生之旅帶來了一些深刻的變化。Lallemand 認為，構思階段的定期會議和實施階段的培訓課程有所幫助。「在那之後，每個人都參與了遷移過程。」他說。「然後我們將組織劃分為不同的『部落』——團隊聚集開發人員、產品經理、資料分析師，以及所有不同的職位，以處理產品的特定部分。在之前，他們是按職能組織的。我們的想法是讓所有這些部落以自助服務的方式直接訪問基礎架構，而無需請求。這些人真的非常自主。他們對產品的該部分負責，並且可以更快地做出決策。」
事實證明，這種 DevOps 轉型對公司員工來說是正面的。「團隊對 DevOps 轉型感到非常興奮，因為它是新的，而且我們正在努力使事情更可靠、更具有前瞻性。」Lallemand 說。「我們喜歡做很少有人在做的事情，除了網路巨頭。」
隨著這些變化已經產生影響，BlaBlaCar 正在尋求將越來越多的應用程式拆分為服務。「我沒有說微服務，因為它們不是那麼微小。」Lallemand 說。「如果我們可以劃分開發團隊之間的責任，那將更容易管理且更可靠，因為我們可以輕鬆地新增和移除服務（如果某個服務失敗）。您可以輕鬆處理它，而不是新增我們仍然擁有的大型單體式應用程式。」
當 Lallemand 與其他對 BlaBlaCar 在其基礎架構方面所做的事情感到好奇的歐洲公司交談時，他告訴他們一起搭車。「我告訴他們，與我們以前擁有的基礎架構相比，處理今天的基礎架構是一種樂趣。」他說。「他們只需要記住他們的真正動機，無論是開發的靈活性還是可靠性等等，然後逐步朝著實現這些目標邁進。這就是我們所做的。重要的是不要為了技術而做技術。為了目的而做。我們的重點是幫助開發人員。」