將來，開發(fā)人員應(yīng)該如何處理生產(chǎn)應(yīng)用程序呢？是應(yīng)該將本地的生產(chǎn)環(huán)境復(fù)制到云，還是應(yīng)該直接在云環(huán)境中編寫和運行所有代碼，或者采用介于二者之間的某種方式？
原文鏈接：https://www.signadot.com/blog/large-engineering-teams-testing-on-k8s/
未經(jīng)允許，禁止轉(zhuǎn)載！
(相關(guān)資料圖)
作者?|?Nica Mellifera? 譯者?| 彎月?
責(zé)編 |?王子彧?
出品 | CSDN（ID：CSDNnews）
在過去的幾年里，我們看到很多開發(fā)團隊從純粹的本地開發(fā)轉(zhuǎn)向基于云的開發(fā)環(huán)境。目標(biāo)是提高開發(fā)速度，并控制無法完美復(fù)制環(huán)境的問題。
在本文中，我們來看看一些企業(yè)團隊的解決方案。
在談?wù)撻_發(fā)人員在哪里編寫新代碼時，我們經(jīng)常提及他們“測試”代碼。這里的“測試”指的是自動化單元測試或端到端測試之前的一個階段，開發(fā)人員需要在這個階段研究如何讓代碼與其他資源交互。在測試驅(qū)動開發(fā)中，這兩個階段可能沒有明顯的區(qū)分。在本文中，為了簡潔起見，我們將統(tǒng)一使用“測試”，盡管這個詞本身還包括單獨的一個部署后期階段。
在嘗試與四個不同的企業(yè)工程團隊交流后，我發(fā)現(xiàn)他們的故事有很多相似之處，所以在此我將他們合并成一個故事。值得注意的是，不僅他們的最終結(jié)論非常相似，而且每個團隊在確定基于云的開發(fā)環(huán)境之前都嘗試了類似的解決方案。
我研究的案例有 Lyft、Reddit、Doordash、Eventbrite 和 Prezi。雖然并非所有團隊最終都選擇使用共享的 Kubernetes 集群，但他們都試圖用類似的方法解決類似的問題，而且都面臨著共同的困難。
在考慮改變開發(fā)人員的環(huán)境時，我們要考慮的一個關(guān)鍵問題是：在開發(fā)陷入停滯之前，如何確定投入精力對開發(fā)工作流程進行重大改革是否值得？
為此，Eventbrite 團隊在一篇文章中討論了這個決策，標(biāo)題是：“為什么我們的開發(fā)環(huán)境運行了一個700個節(jié)點的K8s集群？”首當(dāng)其沖必須考慮的不利因素是：通過共享集群來測試代碼時，工具和集群的開發(fā)時間以及維護成本都會增加。
關(guān)于在共享 K8s 集群上進行測試，Eventbrite 提到了如下好處：
你是否曾聽開發(fā)人員說：“在我本地運行測試時完全沒問題”。在云中運行測試可以提高一致性。事實證明，在探究測試失敗的原因或解決難以重現(xiàn)的問題時，共享開發(fā)人員環(huán)境能給予極大的幫助。
這是在共享集群上進行測試的核心優(yōu)勢：更早地發(fā)現(xiàn)未知的未知數(shù)，并永久消除可怕的一個常見問題：“在我機器上沒問題?！?/p>
為了方便開發(fā)人員搭建環(huán)境，Prezi 等團隊提供了服務(wù)安裝、測試以及運行等方面的hook腳本。他們的工具還可以管理服務(wù)間通信。但是，由于每位開發(fā)者機器的獨特性，hook腳本經(jīng)常會因為依賴沖突而運行失敗。工程師們花了很多時間來解決這些問題，但在幾個月后重新訪問服務(wù)時還是會遇到新的問題。
這種不一致的問題是大型開發(fā)團隊沒有同步所有依賴項的必然結(jié)果。通常這種不一致在經(jīng)過長時間的調(diào)試后才會顯現(xiàn)出來。
當(dāng)談?wù)撌褂萌萜骰ぞ吖蚕黹_發(fā)環(huán)境時，大多數(shù)人都會想到Docker。通過容器化所有依賴項并使用 Docker Compose 進行編排，就可以強制開發(fā)人員每天同步依賴項。與第一階段相比，這種方法的巨大優(yōu)勢在于，無需等到失敗才意識到你的環(huán)境需要更新。
最大的缺點是，很快你就會發(fā)現(xiàn)自己的 macbook 燙手。
每天下載新的容器并重新構(gòu)建，只為了嘗試一些開發(fā)上的小改動，這會極大地影響開發(fā)人員的速度。
Docker Compose 的問題在于，它的成本通常是隱藏的，你的筆記本電腦由于運行復(fù)雜的工作負載而停滯，因此而造成的時間浪費都無法明確地記入損失。也許每個小時它都會時竊取 10 分鐘。但這不會成為阻止我們在一個月內(nèi)發(fā)布新功能的障礙，結(jié)果導(dǎo)致你必須承擔(dān)所有壓力，在截止日期之前完成工作。
為了解決本地機器資源有限的問題，我們可以在云中提供虛擬機， 并在其中運行 docker compose。然而，當(dāng)服務(wù)和相關(guān)數(shù)據(jù)庫等的數(shù)量超過 15~20 時，這類系統(tǒng)將變得難以管理。
對于 Reddit 團隊，此問題已被確定為已知限制。他們開發(fā)了一個自定義工具來最大程度地減少重建和重新下載，以盡量減少每天的啟動時間，并遷移到 kubernetes 集群以共享開發(fā)人員進行試驗時所需的大部分資源。他們?yōu)榇碎_發(fā)了一個名為Tilt的工具進行管理。如果你的團隊有足夠的資源，不僅可以改變開發(fā)環(huán)境流程，還可以維護內(nèi)部工具，那就可以考慮采用這種方式大幅縮短每天早上的構(gòu)建時間。
在 Kubernetes 之上構(gòu)建遠程環(huán)境，這樣開發(fā)人員的代碼和依賴項由開發(fā)者體驗團隊集中管理，而開發(fā)人員的電腦上只需運行一個輕量級命令行工具和幾個庫。
Eventbrite采用的方式與之類似，他們使用了一個名為 yak 的自定義工具來處理開發(fā)人員代碼和共享集群之間的交互。yak 還有一個巨大的好處是可以方便開發(fā)人員體驗Kubernetes：
這種“輕量級”的交互可以為團隊帶來舒適感，逐步過渡到開發(fā)運維。
與共享集群的交互有兩種模式：有些人希望與其他團隊的工作狀態(tài)完美同步；而有些人則希望能夠根據(jù)自己的設(shè)計進行修改。
圖片源自 Reddit Eng 博客，展示了大多數(shù)資源的共享方式，而且不會受開發(fā)人員實驗的影響。
在 Prezi，開發(fā)人員可以自由地在自己的沙箱（Kubernetes 命名空間）中進行試驗，而且可以通過兩種不同的模式運行服務(wù)：
●依賴模式：在這種情況下，工具需要提供一組特定的服務(wù)，并使用 Helm 和 Helmfile 簡單地部署依賴項的預(yù)構(gòu)建和預(yù)優(yōu)化容器。
●開發(fā)模式：這種模式適合正在積極開發(fā)的服務(wù)。我們使用 Skaffold 構(gòu)建圖像并同步更改，以便開發(fā)人員快速查看修改結(jié)果并獲得反饋。
一般而言，你需要設(shè)置“待測”服務(wù)和剩余的“穩(wěn)定依賴項”。依賴關(guān)系可以按需啟動，就像基于命名空間的方法一樣；或者依賴關(guān)系始終存在并通過 CI/CD 工作流不斷更新的共享層來滿足依賴關(guān)系，就像請求路由一樣。
以上所有這些案例都涉及內(nèi)部開發(fā)人員體驗團隊維護的工具。這種開發(fā)者體驗的成本不容小覷，而且我們也不得不思考這樣一個問題：“為什么沒有適用于這種模型的 SaaS 解決方案？”
Signadot 就是這類的一款 SaaS 工具，可以幫助你共享 Kubernetes 集群并僅在你關(guān)心的服務(wù)上進行實驗。
兩名開發(fā)人員可以同時使用共享的開發(fā)集群。環(huán)境不需要模擬，而且運營團隊只需維護一個開發(fā)集群。
Signadot 絕不是通過開源工具共享開發(fā)集群的唯一方式，但它可以處理一些困難的邊緣情況，例如服務(wù)之間的請求路由，從而降低了多個開發(fā)人員共享一個開發(fā)集群的難度。
推薦閱讀：
?小米辟謠武漢總部35歲以上員工只保留10%；豐田致歉！200萬車主車輛數(shù)據(jù)遭泄露；jQuery 3.7.0 發(fā)布|極客頭條
?突發(fā)！沉痛悼念技術(shù)大牛左耳朵耗子（陳皓）
?突發(fā)！OPPO 關(guān)?！霸煨尽睒I(yè)務(wù) ZEKU：近 3000 名員工“原地失業(yè)”，賠償 N+3
關(guān)鍵詞：
營業(yè)執(zhí)照公示信息