傳統.NET 4.x應用容器化體驗(4)

 上一篇我們試着將.NET 4.x的鏡像推送到harbor私有鏡像倉庫,本篇我們來使用一下阿里雲的鏡像倉庫服務並了解一下攜程的實踐。

1 關於阿里雲鏡像倉庫

阿里雲容器鏡像服務(簡稱 ACR)是面向容器鏡像、Helm Chart 等符合 OCI 標準的雲原生製品安全託管及高效分發平台。ACR 支持全球同步加速、大規模/大鏡像分發加速、多代碼源構建加速等全鏈路提效,與容器服務 ACK 無縫集成,幫助企業降低交付複雜度,打造雲原生應用一站式解決方案。

阿里雲容器鏡像服務有兩種類型:

(1)容器鏡像服務ACR個人版

容器鏡像服務ACR個人版面向個人開發者,提供基礎的容器鏡像服務,包括應用鏡像託管能力、鏡像安全掃描功能、穩定的國內外鏡像構建服務以及便捷的鏡像授權功能,方便用戶進行鏡像全生命周期管理。

(2)容器鏡像服務ACR企業版

容器鏡像服務ACR企業版面向企業客戶,是企業級雲原生應用製品管理平台,提供容器鏡像、Helm Chart,符合OCI規範製品的生命周期管理;支持大規模、多地域、多場景下應用製品的高效分發;與容器服務ACK無縫集成,幫助企業降低交付複雜度。

其中,個人版是免費使用的,但命名空間有限額3個,不過對於我們學習調研完全夠用了。因此,本篇主要使用個人版實例來進行實驗。

個人版具體的功能如下:

  • 多架構鏡像託管支持

    支持Linux、Windows、ARM等多架構容器鏡像

  • 靈活的地域選擇

    • 您可以根據自己的業務需求,選擇不同的地域創建和刪除鏡像倉庫。

    • 每個鏡像倉庫都提供了公網、內網、VPC網絡下對應的網絡地址。

  • 鏡像安全掃描

    • 支持便捷的鏡像安全掃描功能,展示詳細的鏡像層信息。

    • 提供鏡像漏洞報告,展示漏洞編號、漏洞等級、修復版本等多維度漏洞信息。

可以看到,阿里雲容器鏡像倉庫也同時支持Linux 和 Windows多平台的容器鏡像,完美符合我們的需求。

2 配置阿里雲鏡像倉庫

創建命名空間

我們可以先創建幾個命名空間,用於區分不同環境的鏡像。

創建鏡像倉庫

我們在指定命名空間下創建幾個鏡像倉庫,後面我們在 Windows Server 端推送鏡像到這幾個鏡像倉庫中。

後面的示例,我們就在客戶端推送鏡像到 dotnet-sdk、dotnet-runtime 以及 dotnet-samples 三個項目中。

3 推送鏡像到阿里雲鏡像倉庫

公網環境下

(1)登錄阿里雲docker registry:

$ docker login --username=**********@***.com registry.cn-chengdu.aliyuncs.com

這裡 registry.cn-chengdu.aliyuncs.com 就是阿里雲容器鏡像服務的公網地址。
(2)將.NET鏡像推送到阿里雲docker registry:

$ docker tag reg.edisonzhou.cn/dotnet/sdk:framework-4.8 registry.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-sdk:framework-4.8
$ docker push registry.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-sdk:framework-4.8

容器鏡像的推送速度取決於網絡環境(如帶寬)

推送後鏡像倉庫效果:

(3)在Windows Server從阿里雲docker registry拉取鏡像:

$ docker pull registry.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-sdk:framework-4.8

內網環境下

如果使用阿里雲ECS,可以直接選擇阿里雲鏡像倉庫的內網地址,可以大幅度提高傳輸效率並減少公網流量開銷。如果你的阿里雲ECS是VPC專有網絡,你可以參考下面的shell:

$ docker login --username=********@***.com registry-vpc.cn-chengdu.aliyuncs.com
$ docker push registry-vpc.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-sdk:framework-4.8

如果ECS是經典網絡,你可以參考下面的shell:

$ docker login --username=********@***.com registry-internal.cn-chengdu.aliyuncs.com
$ docker push registry-vpc.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-sdk:framework-4.8

推送成功後,測試驗證一下:

$ docker run --name aspnet_mvc_sample_1 --rm -it -d -p 8000:80 --cpus 1 -m 1024m registry-vpc.cn-chengdu.aliyuncs.com/edisonzhou-dev/dotnet-samples:framework-4.8-aspnetmvcapp

訪問URL效果:

4 探究鏡像層信息

在第一次推送dotnet-sdk:framework-4.8鏡像時,由於鏡像倉庫沒有基礎鏡像層,因此推送速度比較慢,因為要全新存儲不能共享。

而在推送完dotnet-sdk:framework-4.8鏡像後,如下圖所示的基礎鏡像層已經可以直接掛載復用了,因此推送速度大幅加快。

可以看到,無論是dotnet-sdk, dotnet-runtime(即微軟官方的aspnet鏡像)還是 dotnet-samples 鏡像,它們都會直接掛載 Windows Server Core base ltsc2019、.NET Framework 等基礎鏡像層 而不是 每次都重新從docker client推送到倉庫來存儲。我們也可以發現,Windows Server Core base ltsc2019、.NET Framework 等基礎鏡像層是文件大小最大的幾個基礎層,因此後續推送的速度會很快。

5 攜程的Windows Container實踐

攜程是.NET應用大戶,並早在多年前就開始了Java轉型,在轉型過程中是需要長時間的多語言技術棧應用系統並行共存的,而如果能統一運行環境和打包部署機制,對於像攜程一樣的轉型期間的公司來說,是有必要的。因此,攜程選擇了Windows Container的實踐,對傳統.NET Framework應用進行了容器化的遷移。

擴展閱讀:《.NET大戶的選擇:Windows Container在攜程的應用

我司是一家建築行業的產業互聯網平台企業,主營的各業務線系統發佈於2016年,也是.NET Framework應用大戶,目前也在進行Java轉型,有.NET 4.x、.NET 5 和 Java 三種技術(請原諒我將.NET 4.x 和 .NET 5劃歸為兩種技術)的開發團隊和應用系統運行,也正在經歷和攜程當年一樣的路程。

如何讓傳統.NET應用享受容器化帶來的紅利,能夠和Java與.NET Core/.NET 5統一運行環境實現Build Once, Run Anywhere的終極目標,是我們在思考的問題。Windows Container是一個解決方案,通過Windows Server 2019的容器化屬性,可以實現不同技術棧應用的統一編排和部署,不需要為Java/.NET 5弄一套持續集成流程,而為.NET 4.x單獨弄一套持續集成流程。

在容器編排領域,Kubernetes 已經成為事實上的標準容器編排器,Kubernetes 1.14 發行版本中包含了將 Windows 容器調度到 Kubernetes 集群中 Windows 節點上的生產級支持,從而使得巨大 的 Windows 應用生態圈能夠充分利用 Kubernetes 的能力。對於同時投入基於 Windows 應用和 Linux 應用的組織而言,不必尋找不同的編排系統 來管理其工作負載,其跨部署的運維效率得以大幅提升,而不必關心所用操作系統。

擴展閱讀:《Kubernetes對Windows Container的支持

此外,阿里雲ACK服務也提供了對Windows Container的支持,即我們可以將Windows Server節點作為Node角色加入K8s集群,由ACK的Master節點進行統一編排。對於沒有基礎運維團隊的企業來說,更推薦這種方式:

阿里雲ACK(容器服務K8s版): //www.aliyun.com/product/kubernetes

6 總結

本文介紹了如何快速配置一個阿里雲容器鏡像倉庫,並將.NET 4.x應用程序鏡像推送到阿里雲容器鏡像倉庫中,最後探究了一下.NET容器鏡像的層信息。

對於傳統.NET 4.x應用的容器化遷移,我們也還在探索,相信探索和實踐的深入,我會分享更多相關的內容。