【譯】LogicMonitor 使用 Terraform, Packer & Consul為災難恢復環境
2018年4月05日 RANDALL THOMSON
以下是 LogicMonitor 的資深技術操作工程師蘭德爾. 湯姆森的部落格。你會發現如果他沒有夢想著下一次滑雪探險,那他一定忙於敲擊鍵盤以保持 LogicMonitor SaaS 平臺處於最佳狀態。
構建我們的高可用性平臺
LogicMonitor是一個基於 SaaS 的企業組織監控平臺, 每天從5.5萬多個使用者收集超過200億種指標。毫無疑問,我們需要24/7全天候提供服務。為了確保這種能力, LogicMonitor TechOps 團隊使用 HashiCorpPacker、 Terraform和Consul,以可靠和可持續的方式動態地構建災難恢復基礎設施。
LogicMonitor SaaS 平臺是基於蜂窩的體系結構。執行 LogicMonitor 所需的所有資源 (web 和資料庫伺服器、DNS 記錄、訊息佇列、ElasticSearch 群集等) 都稱為 pod。至關重要的是, 每個資源都要始終如一地調配而不會遺漏任何內容。為了實現這一級別的細節, 我們在公共雲中提供的任何資源都必須通過 Terraform 來完成。過去18月來, 我們作出了很大努力, 不僅使用 Terraform 提供新的基礎設施, 而且還要回填 (匯入並/或重新建立) 現有資源。就這樣發生了, 以一種偶然的方式, 我們的DR計劃誕生了。我們不再需要一種方法來提供我們的生產基礎設施而選擇另一種方法來提供我們的 DR 計劃。因為在Terraform的幫助下, 它們基本上是相同的情況。
即使有了這個萬無一失的計劃, DR 計劃實施過程中仍然難免存在著出於良好的意圖,但易錯的人為失誤。您可能有數百臺 web 伺服器並行運轉, 但如果他們需要手動干預才能為客戶提供服務, 那麼這些任務必須經過序列處理。更糟的是, 一旦自動化停止恢復時間目標 (RTO)就會迅速增加。從基於並行的自動化執行切換到基於序列的手動進行不僅減慢了處理速度, 而且會立即增加壓力負擔。
我們的團隊討論了以前的 DR 實踐的結果, 並制定了兩個目標: 加快速度,刪除手動步驟。應用這些 HashiCorp 產品 (Packer, Terraform 和Consul) 幫助我們實現了這兩個目標。所以下面我將解釋我們是如何克服各種絆腳石。
搭建Blocks
我們使用Packer來生成各種預焙的伺服器模板。使用此方法而不是從一般映像開始, 提供了許多優點: 可以標記模板 (這有助於將有意義的上下文新增到它們所使用的內容), 伺服器會啟動所有安裝的應用程式 (預應用配置管理)以及生成映像的方式被記錄下來並置於版本控制之下。我們還將Packer整合到我們的軟體構建和部署服務中, 以提供更好的可見性和一致性。
==> amazon-ebs: Creating AMI tags
amazon-ebs: Adding tag: "name": "santaba-centos7.4"
amazon-ebs: Adding tag: "approved": "true"
amazon-ebs: Adding tag: "prebaked": "true"
amazon-ebs: Adding tag: "LM_app": "santaba"
amazon-ebs: Adding tag: "packer_build": "1522690645"
amazon-ebs: Adding tag: "buildresultsurl": "https://build.logicmonitor.com/PACK"
==> amazon-ebs: Creating snapshot tags
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: Destroying volume (vol-0134567890abcdef)...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.
'''
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
eu-west-1: ami-1234567876
us-east-1: ami-9101112131
us-west-1: ami-4151617181
隨著這個新流程的實施, Packer提供的一個最重要的改進就是節省時間。我們從需要45分鐘+的啟動時間到僅需5分鐘便可使單個元件能夠提供服務。
精心策劃的擴建
過去, 如果我們想複製現有伺服器的構建方式, 我們必須查詢文件 (交叉手指表示祈禱), 然後評估是否進行了手動更改 (甚至可能沒有同事的. bash_history給予梳理) 或假設有黑色魔法的存在。這導致了應該完全相同的環境的不一致。一次性的, 手動的方法對於必須進行逆向工程去構建一個新pod的工程師來說也是一個很大的時間陷阱。通常還需要多種不同的資源調配技術。
當我們將所有的生產基礎結構移動到 Terraform 中時, 我們意識到我們可以使用相同的程式碼來進行災難恢復。我們將有能力以可重複的方式測試我們的 DR 計劃, 而不會產生很多壓力。Terraform 可以像構建基礎結構那樣輕鬆地拆除基礎結構。它需要120多個不同的資源來建立一個 pod-這是一個很大的量去進行記憶或刪除。
lmconsul
通過開發我們自己的Terraform Providers, 解決了在 DR 過程中需要手動干預的一些情況。我們建立了兩個獨立的providers, 每個都實現一個獨特的任務。由於我們的團隊使用 LogicMonitor 作為停機的真相來源, 我們需要一種方法來載入 Terraform 建立的資源到我們的 LogicMonitor 帳戶中。然後, 我們可以根據需求監控這些資源, 並知道它們何時需要服務。如果Consul健康檢查失敗 (在下一節中對此有更多的瞭解), 我們希望馬上得到通知。
下一個要填充的gaps是應用程式配置管理。我們開發了一個內部使用的 Terraform provider來自動從資源輸出中填充配置資訊。目前, 每個 pod 都需要130個單獨的配置專案, 這給錯誤留下了很大的發生概率。使用 Terraform 提供程式不僅節約了更多的時間, 而且還省略了複製和貼上的需求, 最小化錯誤 發生的可能性(曾經嘗試載入一個 URL, 把其中的 ". com"寫成了 "om" )。
那玩意又跑哪去了?
在Consul中登記服務給我們帶來了一些好處。我們已經可以通過監控自動確定服務的健康狀況, 但是我們不能以有意義的方式將這些資訊應用到我們的pod的元件中。在Consul中使用 HTTP 和 DNS 介面意味著較少的手動或靜態配置, 以便服務知道其他服務的位置。到目前為止, 我們在每個pod中有17種不同的服務。我們甚至註冊了我們的Zookeeper群集, 包括標記領導者, 使我們有一個一致 (和方便) 的方式, 以瞭解是否和在哪裡服務。例如, 管理員客戶端可以使用 zookeeper.service.consul 作為 FQDN 通過Consul DNS。
下面是一個示例Consul健康檢查以確定給定的Zookeeper成員是否是群集中的當前負責人:
{
"name": "zookeeper",
"id": "zookeeper-leader",
"tags": [ "leader"],
"port": 2181,
"checks": [
{
"script": "timeout -s KILL 10s echo stat | nc 127.0.0.1 2181 | grep leader; if [ $? -eq 0 ]; then exit 0; else exit 2; fi",
"interval": "30s"
}
]
}
您可以利用您認為的服務變得更具創造性, 例如客戶帳戶的例項。我們的proxies和負載平衡器使用從consul模板自動寫入其路由配置檔案。這導致錯誤的機會減少, 並提供了可伸縮的模型, 因此我們可以繼續管理更復雜的系統。這些proxies實際上配置自己, 管理數以百計或數以千計的後臺, 從來不需要人類干預。當然, proxies本身也在Consul註冊。
當災難降臨
那一天到來了。您的資料中心失去了電源。現在是 5am, 你和你的孩子已經醒著有半個夜晚了。你想做多少思考?你還能做多少思考?可能很少。
Cue Terraform plan; Terraform apply。複製專案檔案並重復 (並希望您的 VPN 工作正常, 並且在目標區域中具有最新的伺服器模板以及足夠的例項限制...).
執行 HashiCorp Packer、Terraform 和Consul之間的協調已經代替了手動配置的需要, 並提供了一個彈性的 DR 過程。通過使用 LogicMonitor Provider,我們可以在迭代改進時快速驗證測試結果。鍛鍊我們的災難恢復肌肉已經把我們過去害怕的流程變成了無需過多思考的任務。
如果您有興趣瞭解有關這些產品的更多資訊, 請訪問 [Terraform] 的 HashiCorp 產品頁面 (https://www.hashicorp.com/Terraform) 和 [Consul] (https://www.hashicorp.com/consul)。
你是否有興趣告訴別人你的 HashiCorp 故事, 或者 HashiCorp 的產品是如何幫助你製造出的驚人的東西的?讓我們知道。把你的故事或想法發電子郵件給[email protected] [email protected] com.