传统.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应用的容器化迁移,我们也还在探索,相信探索和实践的深入,我会分享更多相关的内容。