Java NIO內存映射文件：提高文件讀寫效率的優秀實踐！
Java的NIO庫提供了內存映射文件的支持，它可以將文件映射到內存中，從而可以更快地讀取和寫入文件數據。本文將對Java內存映射文件進行詳細的介紹和演示。內存映射文件概述內存
最近在給 opentelemetry-operator提交一個標簽選擇器的功能時，因為當時修改的函數是私有的，無法添加單測函數，所以社區建議我補充一個 e2e test.
因為在當前的版本下，只要給 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 這類注解就會給該 deployment 注入 agent。但沒辦法指定不同的 agent 版本（或者不同的環境變量），所以希望可以新增一個選擇器，同時可以針對不同的 deployment 維護不同版本的 Instrumentation(是用于控制需要注入 deployment 的資源)；這樣就可以靈活控制了。
圖片
在這之前我其實也很少做 kubernetes 的 operator 開發，對如何做 kubernetes 的 e2e 測試也比較陌生，好在社區提供了詳細的貢獻文檔。
圖片
簡單來說需要兩個關鍵組件：
安裝 kind 的前提是本地已經安裝好了 docker。
他們的安裝都很簡單，只要本地安裝好了 golang，直接使用 go install 即可：
go install sigs.k8s.io/kind@v0.22.0go install github.com/kyverno/chainsaw@latest在開始前還是先預習下 kind 的基本使用。
安裝好 kind 之后，使用 create cluster 命令可以在本地創建一個 kubernetes 集群。
kind create cluster -hCreates a local Kubernetes cluster using Docker container 'nodes'Usage: kind create cluster [flags]
圖片
之后只需要等待集群安裝成功即可，它會在我們的 cat ~/.kube/config 文件中追加剛才新建集群的連接信息。
k config get-contextsk config use-context xxx這樣就可以使用這兩個命令來查看和切換不同的集群了，雖說是一個本地模擬的 kubernetes 集群，但他的核心功能和一個標準的集群沒有什么區別。
kind delete clusters --all使用完成之后可以使用這個命令將所有集群都刪除掉。
在 opentelemetry-operator 中有給我們準備好一個 make 命令: make prepare-e2e ；使用它會幫我們將 operator 的測試環境初始化好。
大概分為以下幾步：
不過這里的安裝過程可能會遇到問題（本質上都是我們的網絡問題）：
圖片
圖片
這種情況可以想辦法（科學上網）手動先把鏡像拉取到本地，然后 kubernetes 就會從本地倉庫獲取到這個鏡像。
通常我們需要將同一類的測試功能放到一個文件夾里，比如這樣：
圖片
默認情況下 Chainsaw 會查找目錄下名為 chainsaw-test.yaml 作為引導文件。
apiVersion: chainsaw.kyverno.io/v1alpha1 kind: Test metadata: creationTimestamp: null name: instrumentation-java spec: steps: - name: step-00 try: - command: entrypoint: kubectl args: - annotate - namespace - ${NAMESPACE} - openshift.io/sa.scc.uid-range=1000/1000 - --overwrite - command: entrypoint: kubectl args: - annotate - namespace - ${NAMESPACE} - openshift.io/sa.scc.supplemental-groups=3000/3000 - --overwrite - apply: file: 00-install-collector.yaml - apply: file: 00-install-instrumentation-select.yaml - name: step-01 try: - apply: file: 01-install-app-select.yaml - assert: file: 01-assert*.yaml catch: - podLogs: selector: app=my-java-selecttests/e2e-instrumentation/instrumentation-select├── 00-install-collector.yaml├── 00-install-instrumentation-select.yaml├── 01-assert-select.yaml├── 01-assert-without-select.yaml├── 01-install-app-select.yaml└── chainsaw-test.yaml以我這里的這份文件為例，在其中定義了幾個步驟：
00-install-collector.yaml：這里主要是安裝一個 OpenTelemetry 的 collector
00-install-instrumentation-select.yaml：安裝 Instrumentation 注入資源
01-install-app-select.yaml：應用一個我們需要測試的 deployment 資源
01-assert*.yaml：最后對最終生成的 yaml 資源與 assert*.yaml 的進行斷言匹配，只有匹配成功后才能測試成功。
這里的測試目的主要是完成一個完整的 Java 應用的 deployment 注入 OpenTelemetry 的 agent 過程還有一些與 OpenTelemetry 相關的環境變量。
以 00-install-instrumentation-select.yaml 文件為例：
apiVersion: opentelemetry.io/v1alpha1 kind: Instrumentation metadata: name: java-select spec: selector: matchLabels: app: my-java-select env: - name: OTEL_TRACES_EXPORTER value: otlp - name: OTEL_EXPORTER_OTLP_ENDPOINT value: http://localhost:4317 exporter: endpoint: http://localhost:4317 propagators: - jaeger - b3 sampler: type: parentbased_traceidratio argument: "0.25" java: env: - name: OTEL_JAVAAGENT_DEBUG value: "true"它的預期效果是選擇 app: my-java-select 的 deployment 將這些環境變量都注入進去，同時默認也會在 deployment 的容器中掛載一個 javaagent.jar:
ls /otel-auto-instrumentation-java/javaagent.jar而我們的 01-assert-select.yaml:
apiVersion: v1 kind: Pod metadata: annotations: instrumentation.opentelemetry.io/inject-java: "true" sidecar.opentelemetry.io/inject: "true" labels: app: my-java-select spec: containers: - env: - name: OTEL_JAVAAGENT_DEBUG value: "true" - name: JAVA_TOOL_OPTIONS value: ' -javaagent:/otel-auto-instrumentation-java/javaagent.jar' - name: OTEL_TRACES_EXPORTER value: otlp - name: OTEL_EXPORTER_OTLP_ENDPOINT value: http://localhost:4317 - name: OTEL_TRACES_SAMPLER value: parentbased_traceidratio - name: OTEL_SERVICE_NAME value: my-java-select - name: OTEL_PROPAGATORS value: jaeger,b3 - name: OTEL_RESOURCE_ATTRIBUTES name: myapp - args: - --cnotallow=env:OTEL_CONFIG name: otc-container initContainers: - name: opentelemetry-auto-instrumentation-java status: containerStatuses: - name: myapp ready: true started: true initContainerStatuses: - name: opentelemetry-auto-instrumentation-java ready: true phase: Running最終就是把實際的 deployment 的 yaml 內容和這份文件進行對比。
所以這個 e2e 測試就有點類似于集成測試，不會測試具體的功能函數，只需要最終結果能匹配就可以。
當然這個和單元測試也是相輔相成的，缺一不可，不能完全只依賴 e2e 測試，也有可能是概率原因導致最終生成的資源相同；單元測試可以保證函數功能與預期相同。
都準備好之后便可以進行測試了，測試的時候也很簡單，只需要執行以下命令即可：
chainsaw test --test-dir ./tests/e2e-multi-instrumentation這樣它就會遍歷該目錄下的 chainsaw-test.yaml文件進行測試，執行我們上面定義的那些步驟，最終輸出測試結果：
同時 Chainsaw 也提供了 Github action，可以方便的讓我們和 github CI 進行集成。
jobs: example: runs-on: ubuntu-latest permissions: {} name: Install Chainsaw steps: - name: Install Chainsaw uses: kyverno/action-install-chainsaw@v0.1.0 with: release: v0.0.9 - name: Check install run: chainsaw version這樣我們就可以在 github 中查看我們的測試結果了：
最后不得不感嘆作為 CNCF 下面的項目 OpenTelemetry 的開發者體驗真好，只要我們跟著貢獻者文檔一步步操作都能順利通過 CI 測試，同時還能避免一些 Code Review 過程中的低級錯誤。
比如我第一次提 PR 的時候沒有添加 changlog 文件，后面在貢獻者手冊里發現只需要執行 make chlog-new 就會基于當前分支信息幫我們生成一個 changelog 文件模板，然后只需要往里面填寫內容即可。
這些工具鏈讓不同開發者提交的代碼和流程都符合規范，同時也降低了貢獻難度。
以上所有的相關源碼都可以在 https://github.com/open-telemetry/opentelemetry-operator 中進行查看。
參考鏈接：
本文鏈接：http://m.www897cc.com/showinfo-26-87018-0.html自動化測試在 Kubernetes Operator 開發中的應用：以 OpenTelemetry
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號