fbpx

HashiCorp Vault ㄧ eBay 以 HashiStack 的基礎架構即程式碼達成全面容器化平台

公司介紹

eBay Classifieds 如何快速從地端管理的基礎架構遷移到私有雲?本文講解了 eBay 如何選擇其技術堆棧以及建立穩定、高度可擴展平台的決策。 

挑戰

eBay Classifieds Group 的網站營運團隊投入大量精力從地端管理的基礎架構遷移到私有雲。隨著 eBay Classified Group 宣佈在柏林成立新的全球策略技術中心,工程團隊被賦予開發一個創新的計劃來建立新產品的挑戰。其中,最大的挑戰是要在極短的時間內打造全新產品。

使用產品

Vault, Terraform

解決方案

產品開發建議

ebay 需要穩定且共享的前期製作,在實際的基礎架構和實際的元件進行測試。
ebay 在 OpenStack 私有雲上運行。基本上是給每個登錄過一次的員工提供一個小租戶。而我們有個特別的想法,讓我們在正式、非正式和開發租戶中建立完全相同的平台,服務開發租戶中的每個人。

全面容器化

我們在 OpenStack 私有雲的基礎上運作,但如果只是打開 Horizon(OpenStack 的 UI)並點擊每個開發人原的實例,這是不可行的實例。它不適用於開發人員,也不適用於非正式與正式環境。所以我們需要基礎架構即程式碼(infrastructure as code)。
一切事物都需要可重複性,易於理解,也易於複製。

易於理解:每個使用過 Terraform 的人都知道,在大多數情況下它很容易理解。可重複性和易於複製的部分基本上意味著如果我們擴展到一個新的區域,因為它是基礎架構即程式碼,我們只需輕鬆的複製整個基礎架構。如果crash,我們也只需輕鬆的複製整個基礎架構。藉由運行 Terraform,它會為我們產生所有東西,包含:實例、網路、子網路。
當私有雲中只有虛擬機,那確實做得不夠好。因為這意味著我們需要透過部署實例,解決產品開發團隊所生產的任何東西。而我們認為將內容放在容器化 files 中較為容易。

全面容器化的優點

  1. 較少的配置管理想像一下,您有一個 VM,並且想在上面運行 Java。您需要配置的東西很多。現在假設您有一個微服務架構,您需要為您運行的每個微服務分別配置每個主機。但其實我們只需要將 artifacts 放入容器中並運行它,並且所有的主機幾乎都是一樣易於維護。
  2. 易於部署基本上,我們不必特別關心如何將 artifacts 放到虛擬機中,以便確保它們實際運行。只需要在我們的建立的管道(pipeline)中建立鏡像,並將它們推送到內部註冊表,您所要做的就是在一個實例上運行 Docker 容器。

平台即服務的解決方案

如果您運行超過 1 或 2 個實例,可能就有些吃力。想像您有無數個實例,您必須在每一個實例上運行 Dockerrun 或者調用您的容器,這是不可行的。所以我們需要一個平台即服務的解決方案。

  1. 容器編排引擎:基本上,平台即服務解決方案為我們處理容器,使部署變得更加容易。只需與 API 互動,而不需分別與每個主機互動。
  2. 規模化(Scaling):您無需手動啟動更多容器,您只需與 API 互動。
  3. 提高容錯:如果您在容器編排引擎中有容器 crash,不需要回應。但如果容器不斷的 crash,您確實需要手動檢查它,因為可能存在問題。

容器化圖表

唯一看起來過於複雜的就是各種 OpenStack 元件。但我們不必擔心這一點,我們所有的基礎架構都是程式碼,因此 Terraform 負責與所有不同的元件進行溝通,以建立虛擬機、建立實例、建立子網路、建立網路、安全組織等等。

Saltmaster

我們確實需要最低限度的配置管理,因為其他 2 個元件,PanteraS master 和 Nomad master需要我們配置。有了這個此解決方案,我們不需要把 Salt master 作為 snowflake,因為它是一次性的。只需做一次,其他實例就被建立。因此,如果那個 Salt Master crash 或其他任何原因,只需將其丟棄,再次產生它,然後擷取程式碼即可。

PanteraS 作為一個叢集,而 Nomad 作為另一個叢集。使用 PanteraS,它基本上是一個內部建立的開源解決方案,它是一個結合 Marathon-Visio-Consul-Registrator-and-Fabio-as-a-load-balancer。這就是我們部署所有 Stabilus 應用程式的地方。 幾乎所有 PD 團隊開發的東西都在那裡。

然後我們有 Nomad 叢集,Nomad master workers。這基本上是我們部署所有持久性或持久性層的地方,以及傳輸類型的東西,例如資料庫、Kafka 等等。為什麼我們有 2 個不同的堆棧?因為我們對自己的 Stabilus 應用程式開源解決方案有良好的經驗,但我們對它在 Stateflow 應用程式中的表現並不滿意,所以我們想嘗試 Nomad,而實際上做得很好。

此外,它還具有我們喜歡的批次處理作業,並且比 Chronos 更喜歡, Chronos 是 PanTerraS 堆棧中的同類產品。另外,持久層和前端應用程式之間還有額外的隔離級別。這意味著,永遠不會發生以下的情況,例如,我們的資料庫實例與我們的開發團隊製作的應用程式不會位於同一個容器上,因為它們是 2 個不同的堆棧,2 個不同的主機集。

完全容器化的實踐

歸根究底,完全容器化並不完全可能,由於時間限制和安全性,但我們正在盡最大努力做到這一點。
我們很難將 Vault 放入容器中並在排程器上運行它,因為我們以一種非常複雜的方式使用 Vault,將所有東西都放入其中。我們有我們的機密、確認值等等。意思是,如果沒有 Vault,基本上不能產生任何其他容器。這就是我們不將 Vault 放入容器的原因。我們在額外的叢集中運行它。

唯一沒有放在容器中的是所有基於 ZooKeeper 的東西。 在排程器的容器中運行 ZooKeeper 十分困難,因為 ZooKeeper 需要在叢集開始時就知道其叢集的所有節點。 如果你剛開始在 Drill 中部署一個 ZooKeeper 叢集,比如 Nomad。 但是現在假設其中一個容器 crash,它會在別處重新生成。接下來,如何告訴已經存在的 2 個 ZooKeeper 節點「你的第三個自訂數值改變了」?只要把它放在一個設定檔中就可以做到。我們可以編寫腳本來完成這件事,但是 ZooKeeper 需要重新啟動才能應用新的配置值。

相關文章