Rancher 測試框架實戰指南從集成測試編寫到本地運行與配置詳解【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher導讀本文基于 Rancher 倉庫中的 tests/README.md 及配套的集成測試文檔系統講解 Rancher 測試框架的整體結構與使用方式。你將掌握集成測試Integration與驗證測試Validation的適用場景與前置要求、基于 Shepherd 與 testify Suite 編寫測試的規范、make ci全流程與面向外部 Rancher 實例的本地迭代兩種運行方式以及config.yaml測試配置的每個字段含義。文中所有結論均可回溯到倉庫中的文檔、源碼與 Makefile 目標進行驗證。Rancher 測試框架概述Rancher 測試框架Rancher Test Framework為編寫集成測試與驗證測試提供了一整套工具。它的核心職責有兩項管理被測外部服務之間的交互——測試需要連接運行中的 Rancher 實例、下游集群等外部服務幫助在測試結束后清理資源——通過 Session 機制跟蹤并回收測試創建的資源避免測試之間相互干擾。從組織架構上看框架被劃分為三個學科disciplines學科職責framework框架若干核心庫用于讓測試寫得同構、一致降低不同測試套件之間的寫法差異clients客戶端封裝與 Rancher、Kubernetes、k3d 等外部服務交互的客戶端extensions擴展提供可復用的測試擴展能力如用戶、Token、命名空間、注冊表等場景的輔助函數其中 framework 是核心庫層clients 與 extensions 分別對應文檔中提到的 clients 與 extensions 兩個補充章節當前倉庫內以tests/v2下的集成測試、tests/v2prov下的 provisioning 測試等實際用例體現。運行前置要求Requirements集成測試Integration運行 Rancher 集成測試需要準備一個可訪問 URL 的運行中 Rancher 實例管理員admin用戶的Rancher 訪問 TokenGo 1.22或更高版本倉庫根目錄go.mod聲明了 Go 版本要求tests/v2/integration/setup/README.md 提到 Go 1.24k3d用于創建下游集群setup 文檔建議 v5.8.3 或兼容版本。驗證測試Validation驗證測試與集成測試的前置要求相同但不同測試套件可能還需要云廠商的憑據例如 AWS、Azure 等具體以各套件的配置文件說明為準。核心概念Integration vs Validation理解這兩類測試的邊界是正確選擇測試落點的基礎維度集成測試Integration驗證測試Validation外部依賴不依賴任何外部配置或其他外部服務依賴外部服務必須提供配置文件才能運行運行時長短運行因為每次 PR 都會在 CI 中執行較長按需運行云廠商訪問密鑰不需要可能需要簡而言之集成測試追求“快速、無外部依賴、可反復在 CI 執行”驗證測試追求“在真實外部環境中做深度驗證”因此需要配置文件與可能的云憑據。測試框架ShepherdRancher 的測試框架名為Shepherd是 Rancher 官方維護的獨立測試框架倉庫當前倉庫通過 Go module 依賴引用它例如 tests/v2/integration/setup/main.go 中導入github.com/rancher/shepherd/clients/k3d、github.com/rancher/shepherd/pkg/session等包。Shepherd 提供了客戶端封裝clients/rancher、clients/k3d會話管理pkg/session配置加載pkg/config名稱生成pkg/namegenerator擴展功能extensions/token、extensions/users等。編寫測試時優先使用框架客戶端是保證資源可清理、測試可復用的關鍵。如何編寫測試How to Write Tests測試存放位置測試應創建在tests/v2/integration目錄下——對應倉庫內的集成測試獨立的 tests 倉庫——對應驗證測試。依據上文 Integration vs Validation 的邊界決定落點。分組與組織開發者可以按需將測試分組到文件和包中但原則是讓下一位開發者容易找到且與同一時間點運行的其他測試歸組文件內部測試應分組為Suite基于github.com/stretchr/testify/suite一個 Suite 應在其所有測試間共享客戶端clients和會話session一個 Suite 內的測試應測試同一類功能并復用 Suite 資源。例如如果要驗證不同項目角色對項目資源的訪問權限可以把所有角色對應的測試放進同一個 Suite并共享同一個項目。這樣每個測試都不必重復創建項目顯著節省時間——這正是倉庫中 tests/v2/integration/rbac/rtbs_test.go 的做法。Suite 的代碼骨架以 tests/v2/integration/rbac/rtbs_test.go 為實例可以看到一個典型 Suite 的寫法type RTBTestSuite struct { suite.Suite client *rancher.Client project *management.Project session *session.Session downstreamClusterID string } func (p *RTBTestSuite) SetupSuite() { p.downstreamClusterID local testSession : session.NewSession() p.session testSession client, err : rancher.NewClient(, testSession) p.Require().NoError(err) p.client client // 在 Suite 內共享一個項目所有測試復用 projectConfig : management.Project{ ClusterID: p.downstreamClusterID, Name: TestProject, } testProject, err : client.Management.Project.Create(projectConfig) p.Require().NoError(err) p.project testProject } func (p *RTBTestSuite) TearDownSuite() { client, err : p.client.WithSession(p.session) p.Require().NoError(err) err client.Management.Project.Delete(p.project) p.Require().NoError(err) p.session.Cleanup() }文件末尾通過suite.Run(t, new(RTBTestSuite))啟動測試見 rtbs_test.go。命名規范測試名中不能包含/因為/用于表示測試套件sub-test層級包含該字符會造成測試結構上的歧義。例如-run TestRTBTestSuite/TestUserVsUserBaseGlobalRoleVisibility中的/用于選中 Suite 內的具體子測試。資源清理與 Session測試應盡可能使用框架客戶端確保測試創建的資源會被清理不干擾其他測試每個測試都有責任在下一個測試運行前完整清理自己創建的所有資源資源跟蹤依賴Session機制會話Session會記錄測試過程中創建的資源并在結束時統一清理。上述SetupSuite/TearDownSuite中session.NewSession()與p.session.Cleanup()的配對就是這一機制的落地。更細粒度的做法是為單個測試創建子會話sub-session實現測試級隔離見newSubSession。運行測試的兩種方式倉庫中的 tests/v2/integration/README.md 給出了兩條完整運行路徑。方式一完整 CI 運行make ci推薦用于驗證make ci流程說明在由Dockerfile.runtime構建的 Rancher 運行時容器內執行scripts/testscripts/test會搭建并啟動 RancherRancher 啟動時用k3s創建 local 集群并部署 CRDRancher 與 local 集群就緒后運行測試套件。該方法理論上開箱即用地支持 Mac 與 Linux。需要注意整個集成測試過程會消耗較多 CPU 與內存——出現意外超時往往意味著計算資源不足出現影響容器調度的 OOM 則意味著內存不足。方式二針對外部 Rancher 實例本地運行適合迭代開發該方式將測試指向一個已經在運行的 Rancher 實例而不是在容器內重新拉起一個適合開發調試。快速上手復制即用# 1. 啟動 Rancher如果尚未運行 export RANCHER_IP$(ifconfig | grep inet | grep -v 127.0.0.1 | head -1 | awk {print $2}) docker run -d --name rancher-server --restartunless-stopped \ -p 80:80 -p 443:443 --privileged \ -e CATTLE_SERVER_URLhttps://${RANCHER_IP} \ -e CATTLE_BOOTSTRAP_PASSWORDadmin \ -e CATTLE_DEV_MODEyes \ -e CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head \ rancher/rancher:v2.14-head # 2. 創建 k3d 下游集群并生成 config.yaml export CATTLE_BOOTSTRAP_PASSWORDadmin export CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head make integration-setup # 3. 運行測試 make integration-test-local對應的 Makefile 目標定義在 Makefilemake integration-setup構建 setup 二進制tests/v2/integration/bin/integrationsetup連接 Rancher、創建 k3d 下游集群并將連接信息寫入tests/v2/integration/config.yamlmake integration-test-local讀取config.yaml并運行完整測試套件CGO_ENABLED0 go test -v -failfast -timeout 30m -p 1 ./tests/v2/integration/...。如果之前已生成過config.yaml可以直接跳過第 2 步執行第 3 步。分步詳解Step 1啟動 Rancher Serverexport RANCHER_IP$(ifconfig | grep inet | grep -v 127.0.0.1 | head -1 | awk {print $2}) docker run -d --name rancher-server --restartunless-stopped \ -p 80:80 -p 443:443 \ --privileged \ -e CATTLE_SERVER_URLhttps://${RANCHER_IP} \ -e CATTLE_BOOTSTRAP_PASSWORDadmin \ -e CATTLE_DEV_MODEyes \ -e CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head \ rancher/rancher:v2.14-head等待 Rancher 就緒until curl -sk https://${RANCHER_IP}/ping | grep -q pong; do echo waiting for Rancher...; sleep 5; doneStep 2構建并運行 Integration Setupsetup 程序負責連接 Rancher、創建 k3d 下游集群并導入、最后寫出測試配置文件# 構建 setup 二進制在倉庫根目錄執行 cd tests/v2/integration ./scripts/build-integration-setup # 產出: tests/v2/integration/bin/integrationsetup # 運行 setup回到倉庫根目錄 cd ../../.. export CATTLE_BOOTSTRAP_PASSWORDadmin export CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head export CATTLE_TEST_CONFIG$(pwd)/tests/v2/integration/config.yaml ./tests/v2/integration/bin/integrationsetupsetup 程序會自動探測 Rancher 主機 IP、生成 admin Token、創建 k3d 集群、導入 Rancher并把連接信息寫入CATTLE_TEST_CONFIG指定的路徑。Step 3可選手動創建config.yaml如果已有帶導入集群的 Rancher 實例可以跳過 setup 二進制直接創建配置文件字段說明見下文“配置參考”。Step 4運行測試export CATTLE_TEST_CONFIG$(pwd)/tests/v2/integration/config.yaml # 運行全部集成測試 go test -v -timeout 30m -failfast -p 1 ./tests/v2/integration/... # 運行指定測試套件 go test -v -count1 -timeout 30m -run TestChartsTestSuite ./tests/v2/integration/catalogv2/ # 運行套件內的具體測試 go test -v -count1 -run TestRTBTestSuite/TestUserVsUserBaseGlobalRoleVisibility ./tests/v2/integration/rbac/ # 僅運行 Steve API 測試僅 local 集群無需下游集群 go test -v -count1 -run TestSteveLocal ./tests/v2/integration/steveapi/常用go test參數參數示例說明-timeout-timeout 30m整個測試二進制的硬性截止時間。默認10 分鐘對需要拉取外部倉庫的 catalog 類測試來說太短完整套件建議30m-run-run TestChartsTestSuite只運行匹配正則的測試/套件支持/選擇子測試-run Suite/TestName-count-count1禁用測試結果緩存。運行集成測試時應始終加-count1確保是全新執行-v-v詳細輸出逐個打印測試名與 PASS/FAIL便于定位掛起的測試-failfast-failfast首個測試失敗即停止CI 中用于避免失敗后繼續浪費資源-p-p 1并行構建/運行的測試包數量。集成測試必須為1避免資源沖突配置參考config.yaml測試配置文件的路徑由環境變量CATTLE_TEST_CONFIG指定。最小示例rancher: adminToken: token-xxxxx:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy host: 192.168.1.100 # Rancher 主機不含 https://末尾無斜杠 clusterName: my-k3d-cluster # Rancher 中導入的下游集群名稱 insecure: true cleanup: true全部支持字段字段類型說明是否必填rancher.adminTokenstring用于 admin API 訪問的 Bearer Token。可在 Rancher UI 獲取用戶頭像 → Account API Keys → Create API KeyNo Scope是rancher.hoststringRancher 服務器主機名或 IP不含協議 scheme、末尾無斜杠是rancher.clusterNamestringRancher 中下游集群的名稱。下游相關測試必填僅測 local 集群時填local是rancher.insecurebool跳過 TLS 校驗適用于自簽名證書。默認false否rancher.cleanupbool測試是否刪除其創建的資源。默認true否rancher.adminPasswordstringadmin 密碼adminToken的替代方案否rancher.caFilestring用于 TLS 校驗的 CA 證書文件路徑否rancher.caCertsstring內聯 PEM 編碼的 CA 證書否環境變量變量使用者說明CATTLE_TEST_CONFIG測試 setup必填。config.yaml的絕對路徑。運行測試或 setup 二進制前必須導出CATTLE_BOOTSTRAP_PASSWORD僅 setupRancher 首次登錄的引導密碼。默認adminCATTLE_AGENT_IMAGE僅 setupRancher agent 的完整鏡像引用如rancher/rancher-agent:v2.14-head導入 k3d 集群時使用CATTLE_RANCHER_HOST僅 setup覆蓋自動探測的 Rancher 主機如192.168.1.100:443或localhost:8443。未設置時setup 二進制通過探測機器出站 IP 確定主機關于主機探測機制tests/v2/integration/setup/main.go 給出了實現細節默認通過向8.8.8.8:80建立 UDP socket 讀取本地地址來獲取出站 IP并用fmt.Sprintf(%s:443, ip)拼出host當CATTLE_RANCHER_HOST非空時直接使用該值。rancherConfig中的AdminToken、Host、Cleanup、ClusterName、AdminPassword字段均由 setup 程序生成并寫入配置。測試套件一覽Test Suites僅使用local集群的測試不需要下游集群只需基礎config.yaml即可運行標記為“需要下游集群”的測試必須通過rancher.clusterName引用已導入的集群目錄測試函數測試內容需要下游集群catalogv2/TestChartsTestSuiteChart 安裝、容忍度、pull-through是catalogv2/TestClusterRepoTestSuiteClusterRepo CRUD、OCI 倉庫否catalogv2/TestSystemChartsVersionSuite系統 chart 版本約束否catalogv2/TestUIPluginSuiteUI 插件擴展否catalogv2/TestRancherManagedChartsSuiteRancher 托管的 Helm chart否clusters/TestK8sProxy經 Rancher 的 K8s API 代理是projects/TestResourceQuotaTestSuite命名空間資源配額否projects/TestProjectUserTestSuite項目級用戶訪問否rbac/TestRTBTestSuite角色/ClusterRole 模板綁定、features、impersonation、projects否使用localsteveapi/TestSteveLocalSteve 資源列表 APIlocal 集群否steveapi/TestSteveDownstream下游集群上的 Steve API是當前跳過users/TestUserTestSuite用戶 CRUD 操作否authconfigs/TestAuthConfig認證配置管理否serviceaccount/TestSATestSuiteServiceAccount Token 處理否上述目錄均位于倉庫tests/v2/integration/下例如 tests/v2/integration/catalogv2、tests/v2/integration/rbac。測試環境搭建細節Test Setup Details集成測試的 setup 邏輯分布在scripts/test與 tests/v2/integration/setup/main.go 中。后者主要承擔四項職責生成并保存測試配置文件供集成測試使用創建一個用戶及對應 Token供測試訪問 Rancher在 local 集群中創建新的測試命名空間并以 Secret 形式部署 Docker 容器注冊表憑據在default命名空間部署兩個注冊表。scripts/test中對應流程可參看其build-integration-setup、integrationsetup、go integration tests三段調用。注冊表Registry搭建setup 過程中部署的兩個注冊表各有分工第一個注冊表按常規方式配置支持鏡像的 push 與 pull第二個注冊表配置為pull-through 緩存唯一目的是緩存下游集群創建容器時拉取的鏡像以加速測試過程。創建注冊表的同時會向上述測試命名空間部署對應的 Secret。隨后由scripts/ci本地構建的 cattle cluster agent 鏡像會被推送到第一個注冊表供下游集群拉取。兩個注冊表的配置會被合并用于創建集成測試使用的測試集群——合并后的注冊表配置正是下游集群能夠訪問 local 集群內注冊表的關鍵。下游集群的供應方式集成測試 setup 中創建下游集群的方式與 v2 provisioning 測試完全一致通過github.com/rancher/rancher/tests/v2prov/cluster包提供的cluster.New()函數創建。該函數利用 Rancher 的 v2 provisioning 功能在測試命名空間中創建一個運行 machine provisioner 的容器machine provisioner 再創建systemd-node容器由其自建一個內嵌的 Kubernetes 集群。最終的整體形態為一個運行 Rancher 運行時環境的 Docker 容器其中scripts/test正在運行集成測試RancherRancher 的 “local” 集群k3s 集群其中運行若干容器網絡相關組件以及 rancher-webhook 等 Rancher 特有組件一個systemd-node容器其中運行“下游集群”一個運行 cluster agent 及其他 Rancher 下游組件的 k3s 集群這一嵌套架構說明一次make ci實際上在同一運行時環境內容納了 Rancher 服務器、local 集群與下游集群三層結構這也是它對 CPU 與內存要求較高的原因。小結Rancher 測試框架以 Shepherd 為核心將測試劃分為 framework、clients、extensions 三個層次并明確區分“快速、無外部依賴”的集成測試與“需要外部服務與配置”的驗證測試。編寫測試時遵循“Suite 共享客戶端與會話、測試名不含/、優先使用框架客戶端、測試自行清理資源”的規范即可寫出同構、可復用、可清理的測試。運行時既可通過make ci在容器內一鍵完成端到端驗證也可通過make integration-setupmake integration-test-local對已運行的 Rancher 實例做快速迭代config.yaml的字段與CATTLE_*系列環境變量則提供了從 Token、主機、集群名到 TLS 校驗、資源清理策略的完整可控項。【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Rancher 測試框架實戰指南：從集成測試編寫到本地運行與配置詳解
Rancher 測試框架實戰指南從集成測試編寫到本地運行與配置詳解【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher導讀本文基于 Rancher 倉庫中的 tests/README.md 及配套的集成測試文檔系統講解 Rancher 測試框架的整體結構與使用方式。你將掌握集成測試Integration與驗證測試Validation的適用場景與前置要求、基于 Shepherd 與 testify Suite 編寫測試的規范、make ci全流程與面向外部 Rancher 實例的本地迭代兩種運行方式以及config.yaml測試配置的每個字段含義。文中所有結論均可回溯到倉庫中的文檔、源碼與 Makefile 目標進行驗證。Rancher 測試框架概述Rancher 測試框架Rancher Test Framework為編寫集成測試與驗證測試提供了一整套工具。它的核心職責有兩項管理被測外部服務之間的交互——測試需要連接運行中的 Rancher 實例、下游集群等外部服務幫助在測試結束后清理資源——通過 Session 機制跟蹤并回收測試創建的資源避免測試之間相互干擾。從組織架構上看框架被劃分為三個學科disciplines學科職責framework框架若干核心庫用于讓測試寫得同構、一致降低不同測試套件之間的寫法差異clients客戶端封裝與 Rancher、Kubernetes、k3d 等外部服務交互的客戶端extensions擴展提供可復用的測試擴展能力如用戶、Token、命名空間、注冊表等場景的輔助函數其中 framework 是核心庫層clients 與 extensions 分別對應文檔中提到的 clients 與 extensions 兩個補充章節當前倉庫內以tests/v2下的集成測試、tests/v2prov下的 provisioning 測試等實際用例體現。運行前置要求Requirements集成測試Integration運行 Rancher 集成測試需要準備一個可訪問 URL 的運行中 Rancher 實例管理員admin用戶的Rancher 訪問 TokenGo 1.22或更高版本倉庫根目錄go.mod聲明了 Go 版本要求tests/v2/integration/setup/README.md 提到 Go 1.24k3d用于創建下游集群setup 文檔建議 v5.8.3 或兼容版本。驗證測試Validation驗證測試與集成測試的前置要求相同但不同測試套件可能還需要云廠商的憑據例如 AWS、Azure 等具體以各套件的配置文件說明為準。核心概念Integration vs Validation理解這兩類測試的邊界是正確選擇測試落點的基礎維度集成測試Integration驗證測試Validation外部依賴不依賴任何外部配置或其他外部服務依賴外部服務必須提供配置文件才能運行運行時長短運行因為每次 PR 都會在 CI 中執行較長按需運行云廠商訪問密鑰不需要可能需要簡而言之集成測試追求“快速、無外部依賴、可反復在 CI 執行”驗證測試追求“在真實外部環境中做深度驗證”因此需要配置文件與可能的云憑據。測試框架ShepherdRancher 的測試框架名為Shepherd是 Rancher 官方維護的獨立測試框架倉庫當前倉庫通過 Go module 依賴引用它例如 tests/v2/integration/setup/main.go 中導入github.com/rancher/shepherd/clients/k3d、github.com/rancher/shepherd/pkg/session等包。Shepherd 提供了客戶端封裝clients/rancher、clients/k3d會話管理pkg/session配置加載pkg/config名稱生成pkg/namegenerator擴展功能extensions/token、extensions/users等。編寫測試時優先使用框架客戶端是保證資源可清理、測試可復用的關鍵。如何編寫測試How to Write Tests測試存放位置測試應創建在tests/v2/integration目錄下——對應倉庫內的集成測試獨立的 tests 倉庫——對應驗證測試。依據上文 Integration vs Validation 的邊界決定落點。分組與組織開發者可以按需將測試分組到文件和包中但原則是讓下一位開發者容易找到且與同一時間點運行的其他測試歸組文件內部測試應分組為Suite基于github.com/stretchr/testify/suite一個 Suite 應在其所有測試間共享客戶端clients和會話session一個 Suite 內的測試應測試同一類功能并復用 Suite 資源。例如如果要驗證不同項目角色對項目資源的訪問權限可以把所有角色對應的測試放進同一個 Suite并共享同一個項目。這樣每個測試都不必重復創建項目顯著節省時間——這正是倉庫中 tests/v2/integration/rbac/rtbs_test.go 的做法。Suite 的代碼骨架以 tests/v2/integration/rbac/rtbs_test.go 為實例可以看到一個典型 Suite 的寫法type RTBTestSuite struct { suite.Suite client *rancher.Client project *management.Project session *session.Session downstreamClusterID string } func (p *RTBTestSuite) SetupSuite() { p.downstreamClusterID local testSession : session.NewSession() p.session testSession client, err : rancher.NewClient(, testSession) p.Require().NoError(err) p.client client // 在 Suite 內共享一個項目所有測試復用 projectConfig : management.Project{ ClusterID: p.downstreamClusterID, Name: TestProject, } testProject, err : client.Management.Project.Create(projectConfig) p.Require().NoError(err) p.project testProject } func (p *RTBTestSuite) TearDownSuite() { client, err : p.client.WithSession(p.session) p.Require().NoError(err) err client.Management.Project.Delete(p.project) p.Require().NoError(err) p.session.Cleanup() }文件末尾通過suite.Run(t, new(RTBTestSuite))啟動測試見 rtbs_test.go。命名規范測試名中不能包含/因為/用于表示測試套件sub-test層級包含該字符會造成測試結構上的歧義。例如-run TestRTBTestSuite/TestUserVsUserBaseGlobalRoleVisibility中的/用于選中 Suite 內的具體子測試。資源清理與 Session測試應盡可能使用框架客戶端確保測試創建的資源會被清理不干擾其他測試每個測試都有責任在下一個測試運行前完整清理自己創建的所有資源資源跟蹤依賴Session機制會話Session會記錄測試過程中創建的資源并在結束時統一清理。上述SetupSuite/TearDownSuite中session.NewSession()與p.session.Cleanup()的配對就是這一機制的落地。更細粒度的做法是為單個測試創建子會話sub-session實現測試級隔離見newSubSession。運行測試的兩種方式倉庫中的 tests/v2/integration/README.md 給出了兩條完整運行路徑。方式一完整 CI 運行make ci推薦用于驗證make ci流程說明在由Dockerfile.runtime構建的 Rancher 運行時容器內執行scripts/testscripts/test會搭建并啟動 RancherRancher 啟動時用k3s創建 local 集群并部署 CRDRancher 與 local 集群就緒后運行測試套件。該方法理論上開箱即用地支持 Mac 與 Linux。需要注意整個集成測試過程會消耗較多 CPU 與內存——出現意外超時往往意味著計算資源不足出現影響容器調度的 OOM 則意味著內存不足。方式二針對外部 Rancher 實例本地運行適合迭代開發該方式將測試指向一個已經在運行的 Rancher 實例而不是在容器內重新拉起一個適合開發調試。快速上手復制即用# 1. 啟動 Rancher如果尚未運行 export RANCHER_IP$(ifconfig | grep inet | grep -v 127.0.0.1 | head -1 | awk {print $2}) docker run -d --name rancher-server --restartunless-stopped \ -p 80:80 -p 443:443 --privileged \ -e CATTLE_SERVER_URLhttps://${RANCHER_IP} \ -e CATTLE_BOOTSTRAP_PASSWORDadmin \ -e CATTLE_DEV_MODEyes \ -e CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head \ rancher/rancher:v2.14-head # 2. 創建 k3d 下游集群并生成 config.yaml export CATTLE_BOOTSTRAP_PASSWORDadmin export CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head make integration-setup # 3. 運行測試 make integration-test-local對應的 Makefile 目標定義在 Makefilemake integration-setup構建 setup 二進制tests/v2/integration/bin/integrationsetup連接 Rancher、創建 k3d 下游集群并將連接信息寫入tests/v2/integration/config.yamlmake integration-test-local讀取config.yaml并運行完整測試套件CGO_ENABLED0 go test -v -failfast -timeout 30m -p 1 ./tests/v2/integration/...。如果之前已生成過config.yaml可以直接跳過第 2 步執行第 3 步。分步詳解Step 1啟動 Rancher Serverexport RANCHER_IP$(ifconfig | grep inet | grep -v 127.0.0.1 | head -1 | awk {print $2}) docker run -d --name rancher-server --restartunless-stopped \ -p 80:80 -p 443:443 \ --privileged \ -e CATTLE_SERVER_URLhttps://${RANCHER_IP} \ -e CATTLE_BOOTSTRAP_PASSWORDadmin \ -e CATTLE_DEV_MODEyes \ -e CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head \ rancher/rancher:v2.14-head等待 Rancher 就緒until curl -sk https://${RANCHER_IP}/ping | grep -q pong; do echo waiting for Rancher...; sleep 5; doneStep 2構建并運行 Integration Setupsetup 程序負責連接 Rancher、創建 k3d 下游集群并導入、最后寫出測試配置文件# 構建 setup 二進制在倉庫根目錄執行 cd tests/v2/integration ./scripts/build-integration-setup # 產出: tests/v2/integration/bin/integrationsetup # 運行 setup回到倉庫根目錄 cd ../../.. export CATTLE_BOOTSTRAP_PASSWORDadmin export CATTLE_AGENT_IMAGErancher/rancher-agent:v2.14-head export CATTLE_TEST_CONFIG$(pwd)/tests/v2/integration/config.yaml ./tests/v2/integration/bin/integrationsetupsetup 程序會自動探測 Rancher 主機 IP、生成 admin Token、創建 k3d 集群、導入 Rancher并把連接信息寫入CATTLE_TEST_CONFIG指定的路徑。Step 3可選手動創建config.yaml如果已有帶導入集群的 Rancher 實例可以跳過 setup 二進制直接創建配置文件字段說明見下文“配置參考”。Step 4運行測試export CATTLE_TEST_CONFIG$(pwd)/tests/v2/integration/config.yaml # 運行全部集成測試 go test -v -timeout 30m -failfast -p 1 ./tests/v2/integration/... # 運行指定測試套件 go test -v -count1 -timeout 30m -run TestChartsTestSuite ./tests/v2/integration/catalogv2/ # 運行套件內的具體測試 go test -v -count1 -run TestRTBTestSuite/TestUserVsUserBaseGlobalRoleVisibility ./tests/v2/integration/rbac/ # 僅運行 Steve API 測試僅 local 集群無需下游集群 go test -v -count1 -run TestSteveLocal ./tests/v2/integration/steveapi/常用go test參數參數示例說明-timeout-timeout 30m整個測試二進制的硬性截止時間。默認10 分鐘對需要拉取外部倉庫的 catalog 類測試來說太短完整套件建議30m-run-run TestChartsTestSuite只運行匹配正則的測試/套件支持/選擇子測試-run Suite/TestName-count-count1禁用測試結果緩存。運行集成測試時應始終加-count1確保是全新執行-v-v詳細輸出逐個打印測試名與 PASS/FAIL便于定位掛起的測試-failfast-failfast首個測試失敗即停止CI 中用于避免失敗后繼續浪費資源-p-p 1并行構建/運行的測試包數量。集成測試必須為1避免資源沖突配置參考config.yaml測試配置文件的路徑由環境變量CATTLE_TEST_CONFIG指定。最小示例rancher: adminToken: token-xxxxx:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy host: 192.168.1.100 # Rancher 主機不含 https://末尾無斜杠 clusterName: my-k3d-cluster # Rancher 中導入的下游集群名稱 insecure: true cleanup: true全部支持字段字段類型說明是否必填rancher.adminTokenstring用于 admin API 訪問的 Bearer Token。可在 Rancher UI 獲取用戶頭像 → Account API Keys → Create API KeyNo Scope是rancher.hoststringRancher 服務器主機名或 IP不含協議 scheme、末尾無斜杠是rancher.clusterNamestringRancher 中下游集群的名稱。下游相關測試必填僅測 local 集群時填local是rancher.insecurebool跳過 TLS 校驗適用于自簽名證書。默認false否rancher.cleanupbool測試是否刪除其創建的資源。默認true否rancher.adminPasswordstringadmin 密碼adminToken的替代方案否rancher.caFilestring用于 TLS 校驗的 CA 證書文件路徑否rancher.caCertsstring內聯 PEM 編碼的 CA 證書否環境變量變量使用者說明CATTLE_TEST_CONFIG測試 setup必填。config.yaml的絕對路徑。運行測試或 setup 二進制前必須導出CATTLE_BOOTSTRAP_PASSWORD僅 setupRancher 首次登錄的引導密碼。默認adminCATTLE_AGENT_IMAGE僅 setupRancher agent 的完整鏡像引用如rancher/rancher-agent:v2.14-head導入 k3d 集群時使用CATTLE_RANCHER_HOST僅 setup覆蓋自動探測的 Rancher 主機如192.168.1.100:443或localhost:8443。未設置時setup 二進制通過探測機器出站 IP 確定主機關于主機探測機制tests/v2/integration/setup/main.go 給出了實現細節默認通過向8.8.8.8:80建立 UDP socket 讀取本地地址來獲取出站 IP并用fmt.Sprintf(%s:443, ip)拼出host當CATTLE_RANCHER_HOST非空時直接使用該值。rancherConfig中的AdminToken、Host、Cleanup、ClusterName、AdminPassword字段均由 setup 程序生成并寫入配置。測試套件一覽Test Suites僅使用local集群的測試不需要下游集群只需基礎config.yaml即可運行標記為“需要下游集群”的測試必須通過rancher.clusterName引用已導入的集群目錄測試函數測試內容需要下游集群catalogv2/TestChartsTestSuiteChart 安裝、容忍度、pull-through是catalogv2/TestClusterRepoTestSuiteClusterRepo CRUD、OCI 倉庫否catalogv2/TestSystemChartsVersionSuite系統 chart 版本約束否catalogv2/TestUIPluginSuiteUI 插件擴展否catalogv2/TestRancherManagedChartsSuiteRancher 托管的 Helm chart否clusters/TestK8sProxy經 Rancher 的 K8s API 代理是projects/TestResourceQuotaTestSuite命名空間資源配額否projects/TestProjectUserTestSuite項目級用戶訪問否rbac/TestRTBTestSuite角色/ClusterRole 模板綁定、features、impersonation、projects否使用localsteveapi/TestSteveLocalSteve 資源列表 APIlocal 集群否steveapi/TestSteveDownstream下游集群上的 Steve API是當前跳過users/TestUserTestSuite用戶 CRUD 操作否authconfigs/TestAuthConfig認證配置管理否serviceaccount/TestSATestSuiteServiceAccount Token 處理否上述目錄均位于倉庫tests/v2/integration/下例如 tests/v2/integration/catalogv2、tests/v2/integration/rbac。測試環境搭建細節Test Setup Details集成測試的 setup 邏輯分布在scripts/test與 tests/v2/integration/setup/main.go 中。后者主要承擔四項職責生成并保存測試配置文件供集成測試使用創建一個用戶及對應 Token供測試訪問 Rancher在 local 集群中創建新的測試命名空間并以 Secret 形式部署 Docker 容器注冊表憑據在default命名空間部署兩個注冊表。scripts/test中對應流程可參看其build-integration-setup、integrationsetup、go integration tests三段調用。注冊表Registry搭建setup 過程中部署的兩個注冊表各有分工第一個注冊表按常規方式配置支持鏡像的 push 與 pull第二個注冊表配置為pull-through 緩存唯一目的是緩存下游集群創建容器時拉取的鏡像以加速測試過程。創建注冊表的同時會向上述測試命名空間部署對應的 Secret。隨后由scripts/ci本地構建的 cattle cluster agent 鏡像會被推送到第一個注冊表供下游集群拉取。兩個注冊表的配置會被合并用于創建集成測試使用的測試集群——合并后的注冊表配置正是下游集群能夠訪問 local 集群內注冊表的關鍵。下游集群的供應方式集成測試 setup 中創建下游集群的方式與 v2 provisioning 測試完全一致通過github.com/rancher/rancher/tests/v2prov/cluster包提供的cluster.New()函數創建。該函數利用 Rancher 的 v2 provisioning 功能在測試命名空間中創建一個運行 machine provisioner 的容器machine provisioner 再創建systemd-node容器由其自建一個內嵌的 Kubernetes 集群。最終的整體形態為一個運行 Rancher 運行時環境的 Docker 容器其中scripts/test正在運行集成測試RancherRancher 的 “local” 集群k3s 集群其中運行若干容器網絡相關組件以及 rancher-webhook 等 Rancher 特有組件一個systemd-node容器其中運行“下游集群”一個運行 cluster agent 及其他 Rancher 下游組件的 k3s 集群這一嵌套架構說明一次make ci實際上在同一運行時環境內容納了 Rancher 服務器、local 集群與下游集群三層結構這也是它對 CPU 與內存要求較高的原因。小結Rancher 測試框架以 Shepherd 為核心將測試劃分為 framework、clients、extensions 三個層次并明確區分“快速、無外部依賴”的集成測試與“需要外部服務與配置”的驗證測試。編寫測試時遵循“Suite 共享客戶端與會話、測試名不含/、優先使用框架客戶端、測試自行清理資源”的規范即可寫出同構、可復用、可清理的測試。運行時既可通過make ci在容器內一鍵完成端到端驗證也可通過make integration-setupmake integration-test-local對已運行的 Rancher 實例做快速迭代config.yaml的字段與CATTLE_*系列環境變量則提供了從 Token、主機、集群名到 TLS 校驗、資源清理策略的完整可控項。【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考