作者：Daniel Hochman & DerekSchaller
推薦：ysyou
譯者：時間
今天我們很高興地宣布，Lyft 的基礎設施工具可擴充 UI 和 API 平台clutch已開放源代碼，clutch使工程團隊能夠建構、運作和維護使用者友好的工作流，這些工作流還包含特定于域的安全機制和通路控制。clutch相容多種管理平台功能(如 AWS、Envoy和 Kubernetes)，強調可擴充性，是以它可以為堆棧中任何元件提供托管功能。
雲計算的動态屬性顯著地降低了新基礎設施的采用成本。CNCF雲原生計算基金會全景圖跟蹤了300多個以上開源項目和1000多個商業産品。盡管各組織們能快速采用這些項目和供應商，但每種新技術都有它自帶的一套配置、工具、日志和名額。為了讓開發者快速、安全地在整個堆棧中變更，需要在工具方面進行大量前期和持續的投資，而大多數組織都未能考慮到這一點。是以，雖然新基礎設施越來越容易采用，但日益擴大的新元件的規模難以管理，特别是随着整個平台的複雜性和工程團隊規模的增長。Clutch解決了這一難題，通過讓基礎設施團隊向他們整個工程組織提供直覺和安全的基礎設施管理接口。
Clutch是一年開發周期的成果，用來解決“Lyft”開發人員經驗和工具的短闆。Clutch由兩個核心部件組成。go後端設計為可擴充的基礎設施控制平面，将單個由protobuf驅動的API拼湊成具有通用授權，可觀測性和審計日志記錄的系統。React前端是一個可插拔并且面向工作流的UI允許使用者和開發者在單個窗格後建立新功能，這隻需要很少的代碼和很少的JavaScript知識及更少的維護工作。
1 設計和架構
在設計和架構方面，比起其他解決方案，clutch提供了與衆不同的開發人員工具空間。在項目開始時，我們在建構自己的工具前對現有工具做了深入分析。采用工具的主要目的是：
- 減少平均維修時間。基礎設施什麼時候響應告警，工程師們待命時花太多時間在閱讀runbooks和操作複雜的工具。
- 消除意外中斷。當執行維護任務時，當使用者在使用runbook時漏掉警告或者删除錯誤的資源(例如，他們認為沒有使用，但占用了很大流量的資源)，進而導緻嚴重中斷。
- 強化細粒度的權限并以通用格式審計所有活動，一些權限過于寬泛，是因為供應商的通路控制不支援細粒度控件，此外，當我們出于安全目的從各種工具收集審計日志時，很難将那些資料提煉成為如何幫助我們改善工具的可執行見解。
- 提供一個極大簡化未來工具開發的平台。以“Lyft”這樣的規模，如果不考慮團隊外的貢獻資源，項目範圍很大時很難成功，我們沒有足夠的資源來建構Lyft需要的每一個特性，更别說支援它了。
一開始我們看到現有供應商UI的不足：由于缺乏專業化，供應商工具很慢 (并且在某些情況下是危險的)。他們需要不必要的步驟來執行常見任務，并提供超出必要的資訊集。除了簡單的通路控制外，通常很少有防護，結果導緻營運人員可能會執行看似無害但實際降低系統性能的操作。另外，他們也許不太熟悉該工具進而延誤補救。理想情況下，工程師每四到六周隻來一次。人們很容易忘記如何使用這個工具，特别是考慮到沒有用特定的互動系統情況下，又去多種執行任務。
由于碎片化和資訊雜亂無序，依賴供應商工具的後果是高認知負荷。
相比之下，Clutch這樣一個與供應商無關的工具能将不相關的系統一體化為清晰，一緻的使用者體驗，并且提供專用功能來執行常見任務，隻需很少的點選和教育訓練。
然後我們轉向開源社群，發現開源基礎設施管理工具通常仍然局限于單個系統，并不是為廣泛的自定義設計的，它并不能解決認知負荷和碎片化的問題。此外，雖然有用于建構控制台的其他前端架構，但沒有一個架構包含具有身份驗證，授權，審計，可觀察性，API模式和豐富插件模型的內建後端架構。有一個很流行的持續傳遞平台，它解決了與Clutch相同的首要問題(例如，降低MTTR，使用者友好的UI)但是，它需要大量的投入來運作微服務和遷移應用到不同于我們自己的架構上。Clutch後端功能開發簡化，是通過上面列出的內建核心功能為每個API端點免費。它還開發為單個二進制檔案，隻需要很少的操作投入。
最後，我們想要一個平台，可以對它進行投資，對其他内部團隊來說它需要更容易了解和建構。Clutch提供一個內建的和引導式開發模型，使其功能開發成為簡明直接的過程。除了一流的後端功能外，Clutch 的前端還為狀态管理和多步表單提供了獨特的抽象，沒有大量JavaScript 經驗的基礎架構團隊更容易實作前端開發。
2 特性
"控制平面"模型
Envoy 代理是Lyft建立的。如今，它是最受歡迎的代理之一，部署在許多大型網際網路公司，并不斷推進雲網絡标準。我們的團隊從與大社群一起維護Envoy中學到了很多東西。Envoy使用者讨論的最熱門主題之一是控制平面的開發進展，特别是如何系統地內建各種不同的元件，以便Envoy能夠有效地路由和報告網絡流量。Envoy類似于 Clutch，它內建不同的基礎設施系統于統一的API。
Clutch采用了許多envoy代理的核心模式，這些模式是在網絡控制平面多年的工作中脫穎而出的。
像Envoy 一樣，Clutch 是配置驅動、模式驅動的，并利用基于子產品化擴充的架構，使其适用于各種用例，同時不影響可維護性。擴充Clutch不需要分支或重寫，自定義代碼可以很容易地從自定義公共或私有外部存儲庫編譯到應用程式中。這些相同模式使具有獨特技術堆棧的大小組織能夠聚集在單個代了解決方案上，有望使相似的獨特組織聚焦在Clutch這樣的基礎設施控制平面上。
3 安全和保障
此外，Clutch附帶身份驗證和授權元件。OpenID Connect (OIDC) 身份驗證流用于單點登入、RBAC，以及對所有操作的自動稽核，并能夠運作附加的輸出接收器，例如Slackbot。
Clutch 還具有降低事故風險的功能。通常記錄在 Runbook 中的護欄和啟發式方法可以以程式設計方式實作。例如，我們絕不允許使用者一次将群集縮減 50% 以上，因為這種操作曾經導緻過正常維護時的意外中斷。不久以後，我們計劃擷取CPU 和其他使用資料，以便與群集資訊一起顯示，甚至在确定可能導緻停機的情況下，限制縮小規模的下限。通過将護欄和啟發式方法直接實施到工具中，避免了僅僅依靠于教育訓練和運作手冊來防止事故的發生。
4 部署和使用者引導
Clutch作為包含前端和後端的單個二進制檔案進行傳輸，使部署工作變得很簡單。許多更改可以通過配置實作，而不是重新編譯新的二進制檔案。
提供基礎設施生命周期工具的其他系統，則需要一組複雜的微服務或遷移到一種固有的方式管理和部署應用程式。Clutch旨在完善現有系統，而不是更換它們。
5 架構群組件
Clutch由Go後端和React前端驅動。它為後端和前端開發提供了功能齊全的架構。Clutch的所有元件都是可組合的，允許使用部分架構功能或完全自定義功能。
這樣的元件和工作流體系結構讓前端經驗有限的開發人員在不到一個小時的開發時間内，就能使用清晰且易于使用的分步 UI 替換笨重的工具或指令行腳本。
Clutch的前端封裝提供的元件，可輕松建構一緻且連續使用者體驗的分步工作流程，包括：
- DataLayout：是一個工作流-本地狀态管理控件，用于處理來自 API 調用的使用者輸入和資料。
- Wizard：用于向使用者顯示分步表單，自定義元素的 UI 插件，用于在以最少的代碼以一緻的方式顯示豐富的資訊。
- Clutch的後端重度依賴從ProtobufAPI 定義生成的代碼。
Protobuf 工具還生成前端用戶端，随着 API 的發展，該用戶端保持後端和前端的同步。後端的元件包括：
- 子產品：代碼生成的 API 存根的實作
- 服務：用于與外部資料源互動
- 中間件：用于檢查請求和響應資料以及應用稽核、授權等。
- 解析器：一種基于自由格式文本搜尋或結構化查詢查找資源的通用接口
解析器是一個Clutch抽象，我們希望會對将功能抽象到多個組織的方式産生重大影響。解析器使用自定義資源位置代碼可輕松擴充，允許操作員通過組織習慣的通用名稱(而不是普通的規範辨別符)定位資源(如 K8s pod 或 EC2 執行個體)。例如，如果開發人員稱其應用程式為"myService-staging"，則很容易添加一種将此類查詢解釋為結構化元素的代碼"$application_name=-${environment}"。此外，前端自動從後端定義生成使用者輸入表單。
前端有一行代碼：
渲染的表單如下：
在後端配置額外的搜尋次元，将會自動映射在前端渲染表單。
6 Clutch在Lyft公司
在 Clutch 之前，Lyft 工程師依靠一系列大雜燴式指令行工具、Web 接口和 Runbook 來執行簡單的任務。Lyft 最常見的警報需要解決多達六個不同的資訊源：警報、其他服務儀表闆、Runbook、其他文檔源、供應商控制台或腳本以及配置設定。随着 Lyft 在團隊、産品和堆棧方面進行擴張，我們意識到這些工具沒有跟上步伐。我們用現有的架構解決這些問題沒有出路，這導緻了Clutch的第一個疊代開發。
在過去的一年裡，Clutch 在使用和開發方面擁有令人難以置信的内部采用率。Clutch經受住了數千個與基礎設施管理相關的風險操作，每一個操作都有帶來意外或延遲的可能，導緻使用者失去對我們的信任。
在撰寫本文時，七個内部工程團隊已經計劃到 2020 年底添加新功能，其中至少一半面向開源。工程師(包括我們出色的實習生)在有限的指導下能夠開發出有意義的功能。最重要的是，我們終于能夠看到一條路線，通過單一虛拟管理平台傳遞我們的内部平台，使 Lyft 基礎設施成為滿足客戶需求的一個産品，而不是拼湊的系統和工具集合。
我們在内部收到了很多積極的回報，例如：
"我很滿意它的存在， 否則我将仍然在等待頁籤加載到雲提供商的控制台中。
有關 Lyft Clutch的更多細節，可以在 Lyft 案例研究文章中找到。
7 路線圖
在整個建構Clutch的過程中，産品不斷發展，我們的内外部路線圖目前包含了 Lyft 的全體開發人員經驗。我們的長期願景是建構一個情景感覺開發者門戶，不僅向開發者提供一套工具，而且在使用者登入門戶時提供最有價值的工具和資訊。
即将推出的功能包括：
Envoy UI ，為使用者提供一個實時儀表盤，以監視其分布式應用程式的網絡性能和配置。 混沌測試 ，與Envoy內建來允許預定的故障注入和擠壓測試與自動停機條件。自動修正，通過适當的Clutch操作自動響應警報。 安全增強 ，包括性能更新、考察模态和兩階段審批。 附加的基礎設施生命周期管理功能 ，檢視群集的狀态以查找異常值，執行長時間運作的維護任務。 服務健康狀況儀表闆 ，使用可配置的報告機制向開發者提供有關其服務狀态的回報(例如代碼覆寫率、成本、活躍的突發事件)。 通用配置管理 ，允許使用者通過引導式 UI 管理複雜配置，或以其他方式将基礎結構中的變更反映為代碼聲明。 拓撲圖 ，将使用者與其擁有的服務關聯，并在登陸頁上向他們顯示相關的資料和工具。
有關即将進行項目的更多詳細資訊，請浏覽我們的路線圖。
8 社群
Clutch對 Lyft 的開發人員體驗産生了重大影響，允許基礎設施和其他工程團隊将工具傳遞為精美的産品而不是事後的想法。團隊對内部新功能貢獻感到非常興奮，Lyft 的工程師喜歡使用該平台：
"可用性非常高，提高了Lyft 工程師的整體生活品質。”
加入我們吧！Clutch 對于其他大型和小型工程團隊具有同樣出色的潛力。我們期待與社群合作開發其他插件和核心功能，以建構豐富的生态系統。我們的目标是讓每個團隊和技術堆棧通路一流的雲原生工具，并減少認知負載。歡迎所有的貢獻，從想法到實施，我們很樂意幫助您開發第一個功能。
了解更多有關Clutch的消息：
通路網站和文檔：https://clutch.sh。
檢視代碼：https://github.com/lyft/clutch。
Twitter：@clugdotsh。
我們迫不及待想看到開源社群将會把項目帶向何處。一路向前！
原文連結：
https://eng.lyft.com/announcing-clutch-the-open-source-platform-for-infrastructure-tooling-143d00de9713
加入雲原生交流群：
加入雲原生技術交流群，或報名社群志願者，
請加小助手微信：horizon96 或 fudan3070 詳詢！
相關閱讀：
Kong 微服務網關在 Kubernetes 的實踐
微軟開源Kubernetes服務網格項目Open Service Mesh
Nginx Ingress on TKE 部署最佳實踐
CNBPA 2020年成員機關/專家委員會/志願者公開招募！是你在等的機會嗎？