Docker最全教程——.NET5进一步拥抱容器技术
.NET 5已经发布多时了，众所周知，其对容器的支持又上了一个台阶。那么主要有哪些变化呢，接下来我们一起来了解吧。
.NET 5 简介
在开始之前，我们先来了解一下.NET 5。
.NET 5.0是.NET Core 3.1之后的.NET Core的下一个主要版本。微软将此新版本命名为.NET 5.0而不是.NET Core 4.0的原因有两个：
- 跳过版本号4.x，以避免与.NET Framework 4.x混淆。
- 从名称中删除了“ Core”，以强调这是.NET未来的主要实现。与.NET Core或.NET Framework相比，.NET 5.0支持更多类型的应用程序和平台。
ASP.NET Core 5.0基于.NET 5.0，但保留名称“ Core”以避免将其与ASP.NET MVC 5混淆。同样，Entity Framework Core 5.0保留名称“ Core”以避免将其与Entity Framework 5和6混淆。
值得注意的是，.NET 5并没有计划支持ASP.NET Web Form和Windows工作流（WF），因此.NET 5并不能完全代替.NET Framework。.NET 5的新增功能已经有很多朋友介绍过了，这里我们这里就不介绍了，有兴趣的也可以直接查看官方文档。
.NET 5针对容器的支持和优化
本篇内容侧重说明.NET 5 对容器的支持和优化。这里我们先来看官方的态度：
- 持续投入大量资金支持
我们认为容器是最重要的云趋势，并在这方面投入了大量资金。我们正在以多种方式投资容器，在.NET软件堆栈的多个级别上。首先是我们对基本面的投资，这越来越多地受到容器场景和部署容器应用的开发者的影响。
- 优化体验
我们正在让.NET与容器的协作变得更容易。我们已经添加了OpenTelemeter支持，这样您就可以从您的应用程序中捕获分布式跟踪和指标。DotNet-monitor是一种新工具，旨在作为从.NET进程访问诊断信息的主要方式。特别是，我们已经开始构建dotnet-monitor的容器变体，您可以将其用作应用程序侧车。最后，我们正在构建DotNet/Tye，以此来提高微服务开发人员的工作效率，包括开发和部署到Kubernetes环境。
注意：Tye是一微软开发的一个开发人员工具，可简化开发，测试和部署微服务以及分布式应用程序。Tye包括一个本地协调器，以使开发微服务变得更加容易，并且能够以最少的配置将微服务部署到Kubernetes。
Type是完全开源的，项目地址：https://github.com/dotnet/tye
官方博客介绍：https://devblogs.microsoft.com/aspnet/introducing-project-tye/
- 支持cgroup v2
NET运行时现在支持cgroup v2，我们预计它将在2020年后成为与容器相关的重要API。Docker目前使用的是cgroup v1(已经被.NET支持)。相比之下，cgroup v2比cgroup v1更简单、更高效、更安全。您可以通过我们2019年Docker更新了解更多关于cgroup和Docker资源限制的信息。Linux发行版和容器运行时正在添加对cgroup v2的支持。一旦cgroup v2环境变得更加普遍，.Net 5.0将在cgroup v2环境中正常工作。这归功于Omair Majid，他在Red Hat支持.NET。
- 提供Windows Server Core的镜像
除了Nano Server，我们现在还发布Windows Server Core镜像。我们添加了Server Core，是因为我们收到了客户的反馈，他们想要一个与Windows Server完全兼容的.NET镜像。我们还进行了其他更改，以减小Windows服务器核心镜像的大小。这些改进带来了很大的不同，但都是在Windows Server 2019发布之后做出的。然而，它们将使下一个Windows Server LTSC版本受益。
- 更改仓库名称
作为使用“.NET”作为产品名称的一部分，我们现在将.NET Core 2.1、3.1和.NET5.0镜像发布到mcr.microsoft.com/dotnet系列的Repos中，而不是发布到mcr.microsoft.com/dotnet/core。我们将继续将.NET Core 2.1和3.1双重发布到以前的位置，同时支持这些版本。.Net 5.0图像将仅发布到新位置。请相应地更新您的From语句和脚本。
之前的名称：
- dotnet/core: .NET Core
- dotnet/core/sdk: .NET Core SDK
- dotnet/core/aspnet: ASP.NET Core Runtime
- dotnet/core/runtime: .NET Core Runtime
- dotnet/core/runtime-deps: .NET Core Runtime Dependencies
- dotnet/core/samples: .NET Core Samples
- dotnet/core-nightly: .NET Core (Preview)
- dotnet/core-nightly/sdk: .NET Core SDK (Preview)
- dotnet/core-nightly/aspnet: ASP.NET Core Runtime (Preview)
- dotnet/core-nightly/runtime: .NET Core Runtime (Preview)
- dotnet/core-nightly/runtime-deps: .NET Core Runtime Dependencies (Preview)
新的名称：
dotnet/samples -> available once .NET 5.0 releases as GA
- 减小镜像大小，尤其是显著的减少在多阶段构建时运行时镜像的大小
作为.NET5.0的一部分，微软将SDK镜像重新建立在ASP.NET镜像之上，而不是构建包-dep，以显著减小在多阶段构建场景中拉取的聚合镜像的大小。
此更改对于多阶段构建有以下好处，其中包含一个示例Dockerfile：
Ubuntu 20.04 Focus的多阶段构建成本：
| Pull Image | Before | After |
|---|---|---|
| sdk:5.0-focal | 268 MB | 232 MB |
| aspnet:5.0-focal | 64 MB | 10 KB (manifest only) |
减少了约: 100 MB (-30%)
Debian 10 Buster的多阶段构建成本：
| Pull Image | Before | After |
|---|---|---|
| sdk:5.0 | 280 MB | 218 MB |
| aspnet:5.0 | 84 MB | 4 KB (manifest only) |
减少了约: 146 MB (-40%)
有关更多详细信息，请参见Dotnet/Dotnet-docker#1814。
此更改有助于多阶段构建，其中SDK和您的目标aspnet或运行时镜像的版本相同(我们预计这是常见的情况)。在进行此更改时，(例如)aspnet拉入将是不可行的，因为您将通过最初的SDK拉入拉出aspnet层。
围绕对Alpine和Windows Nano Server做了类似的更改。Alpine和Nano Server都没有Buildpack-dep镜像。但是，Alpine和Nano Server的SDK镜像之前并不是在ASP.NET镜像之上构建的。
最后
从.NET Core开始到.NET 5，我们看到了微软紧跟前沿技术踏实前进之心，我们也相信.NET尤其是随着.NET 5的到来会让.NET重铸辉煌——积极拥抱前沿技术，完全开源，积极创新和改变，生产力爆棚，性能爆表，没有理由不会越来越好。当然在我们使用的过程中，多少可能会遇到一些问题，但是容器方面的问题笔者很多都已经讲过了，比如《如何让Docker镜像飞起来》和 《自动构建自己的ASP.NET Core基础镜像》。如果对容器完全没有基础，可以阅读本人书籍： 《Docker+Kubernetes应用开发与快速上云》以及【麦扣聊技术】公众号的系列Docker教程文章。
最后，附上本人已构建好的腾讯云.NET 5公共镜像，以方便各位直接享用：
- ccr.ccs.tencentyun.com/magicodes/aspnetcore-runtime:5.0
- ccr.ccs.tencentyun.com/magicodes/aspnetcore-sdk:5.0
- ccr.ccs.tencentyun.com/magicodes/netcore-sdk:5.0
- ccr.ccs.tencentyun.com/magicodes/netcore-runtime:5.0
构建脚本见本人的开源库：https://github.com/xin-lai/aspnetcore-docker
