MSDN Docker 教程（三）- Docker与.NET Framewwork .NET Core

Docker 容器、映像和注册表

使用 Docker 时，开发人员会创建一个应用或服务，并将它及其依赖项打包到一个容器映像中。 映像是应用或服务及其配置和依赖项的静态表示形式。
若要运行应用或服务，应用的映像会实例化，以创建一个在 Docker 主机上运行的容器。 最初，会在开发环境或 PC 中测试容器。
开发人员应将映像存储在注册表中，该注册表可充当映射库并在部署到生产业务流程协调程序时使用。 Docker 通过 Docker 中心维护公共注册表；其他供应商为不同映像集合提供注册表，包括 Azure 容器注册表。 或者，企业可以拥有一个本地专用注册表，用于其 Docker 映像。

图中显示了 Docker 中的映像和注册表与其他组件相关联的方式。 还显示了供应商的多个注册表产品/服务

Docker 术语和概念的分类

注册表如同用于存储映像的书架，可被拉取以生成容器，从而运行服务或 Web 应用。 本地和公有云上均有专用 Docker 注册表。 Docker 中心是由 Docker 维护的公共注册表，除了 Docker 信任的注册表（企业级解决方案），Azure 还提供了 Azure 容器注册表。 AWS、Google 和其他产品也有容器注册表。
将映射存储到注册表中可存储静态和不可变的应用程序，包括其在框架级别的所有依赖项。 然后可将这些映像部署到多种环境中，并进行版本控制，从而提供一致的部署单元
无论是托管在本地还是托管在云中，在下列情况下都建议使用私有映像注册表：

• 由于保密性，映像不能被公开分享。
• 在映像和所选部署环境之间，希望网络延迟保持最低。 例如，如果生产环境是 Azure 云，为实现最低的网络延迟，需要将映像存储在 Azure 容器注册表中。 同样，如果生产环境是在本地，便需要使本地 Docker 信任的注册表在相同的本地网络中可用。

Docker使用.NET

在以下情况下，将 .NET Core 与 Linux 或 Windows 容器结合使用并用于容器化 Docker 服务器应用程序：

• 用户有跨平台需求。 例如，想同时使用 Linux 和 Windows 容器。
• 应用程序体系结构基于微服务。
• 需快速启动容器且每个容器内存占用较小，以实现更好的密度，或每个硬件单位中的容器较多，以降低成本。
  简单地说，在创建新的容器化 .NET 应用程序时，应考虑将 .NET Core 作为默认选择。 它具有许多好处，并最匹配容器的基本原理和运行方式。

使用 .NET Core 的另一个好处是可在同一台计算机中并行运行 .NET 版本的应用程序。 这一优势对于不使用容器的服务器或虚拟机而言更为重要，因为容器会隔离应用所需的 .NET 版本。 （只要它们与基础操作系统兼容。）
在以下情况下，应将 .NET Framework 用于容器化 Docker 服务器应用程序：

• 应用程序当前使用 .NET Framework 并在 Windows 上具有强依赖关系。
• 需要使用 .NET Core 不支持的 Windows API。
• 用户需要使用不可用于 .NET Core 的第三方 .NET 库或 NuGet 包。
  在 Docker 上使用.NET Framework 可通过最大限度地减少部署问题来提升部署体验。 此“提升和移动”方案对于针对最初使用传统 .NET Framework（如 ASP.NET WebForms、MVC Web 应用或 WCF (Windows Communication Foundation) 服务）开发的旧应用程序实施容器化而言很重要。

Docker 使用 .NET

NET Core 的模块化和轻量级特点使其特别适用于容器。 在部署和启动容器时，使用 .NET Core 时容器的映像大小要远小于使用 .NET Framework 时的大小。 与此相反，若要为某个容器使用 .NET Framework，必须以 Windows Server Core 映像作为映像的基础，此映像在体量上远大于用于 .NET Core 的 Windows Nano Server 或 Linux 映像。
此外，.NET 核心可跨平台应用，这样便可使用 Linux 或 Windows 容器映像部署服务器应用。 但如果使用传统的 .NET Framework，只能够基于 Windows Server Core 部署映像。

跨平台开发和部署

显然，如果目标是获得可在 Docker 支持的多个平台（Linux 和 Windows）上运行的应用程序（Web 应用或服务），正确的选择是 .NET Core，因为 .NET Framework 仅支持 Windows。
.NET Core 还支持将 macOS 用作开发平台。 但如果要将容器部署到 Docker 主机，该主机必须（当前）基于 Linux 或 Windows。 例如，在开发环境中，可使用 Mac 上运行的 Linux VM。
Visual Studio 提供用于 Windows 的集成开发环境 (IDE) 并支持 Docker 开发。
Visual Studio for Mac 是一个 IDE，由 Xamarin Studio 演变而来，在 macOS 上运行并支持基于 Docker 的应用程序环境。 对于使用 Mac 计算机工作而又希望使用功能强大的 IDE 的开发者而言，这应当是理想之选。
还可在 macOS、Linux 和 Windows 中使用 Visual Studio Code。 Visual Studio Code 完全支持 .NET Core，包括 IntelliSense 和调试。 由于 VS Code 是轻量型编辑器，可以使用它，同时结合使用 Docker CLI 和 .NET Core CLI 在计算机上开发容器化应用。 还可以使用大多数第三方编辑器（如 Sublime、Emacs、VI）和同时提供 IntelliSense 支持的开源 OmniSharp 项目来面向 .NET Core。
除了 IDE 和编辑器，还可为所有支持的平台使用 .NET Core CLI。

在容器上创建和部署微服务

可使用传统 .NET Framework，通过使用普通进程构建基于微服务的应用程序（不含容器）。 通过这种方式，由于已安装 .NET Framework 并在进程之间共享，进程变得轻量，从而可快速启动。 但如果使用容器，传统 .NET Framework 的映像便也基于 Windows Server Core，这样的话，它对于“容器上微服务”方法，就显得体量过于庞大。 但是，团队也一直在寻找机会来改善 .NET Framework 用户体验。 最近，Windows Server Core 容器映像的大小已减小 40% 以上。
另一方面，如果要使用基于容器的面向微服务的系统，.NET Core 是最佳选择，因为它体量轻。 此外，与之相关的容器映像，无论是 Linux 还是 Windows Nano Server，都精简而小巧，让容器变得轻量，从而能够快速启动。
微服务意味着尽可能得小：可轻松访问、占用空间小、小型的界定上下文（检查 DDD、域驱动设计）、较少的关注度、能够快速启动和停止。 为满足这些要求，需要使用可快速实例化的轻量型容器映像，例如 .NET Core 容器映像。

在可缩放的系统中部署高密度

如果基于容器的系统需要实现最佳密度、粒度和性能，.NET Core 和 ASP.NET Core 是最佳选择。 ASP.NET Core 的运行速度比传统 .NET Framework 中的 ASP.NET 高出 10 倍，领先于其他用于微服务的行业技术（例如 Java servlets、Go 和 node.js）。
这一点对微服务体系结构尤为重要，可以运行数百个微服务（容器）。 在 Linux 或 Windows Nano 上使用 ASP.NET Core 映像（基于 .NET Core 运行时），运行系统时所需的服务器或 VM 数量要少得多，最终可以节省基础结构和托管的费用。

何时为 Docker 容器选择 .NET Framework

将现有应用程序直接迁移到 Windows Server 容器

你可能只想使用 Docker 容器来简化部署（即便未创建微服务）。 例如，你可能希望使用 Docker 改进 DevOps 工作流 — 容器可以提供更好的独立测试环境，并且还可以消除在迁移到生产环境时由于缺少依赖关系而导致的部署问题。 在这种情况下，即使部署的是整体式应用程序，也可以为当前的 .NET Framework 应用程序使用 Docker 和 Windows 容器。
对于此方案，大多数情况下无需将现有应用程序迁移到 .NET Core；可以使用包含传统 .NET Framework 的 Docker 容器。 不过，在扩展现有的应用程序（例如，在 ASP.NET Core 中编写新服务）时，建议使用 .NET Core。

使用不可用于 .NET Core 的第三方 .NET 库或 NuGet 包

第三方库正在迅速采用 .NET Standard，这样可跨各种 .NET 版本（包括 .NET Core）共享代码。 在 .NET Standard 2.0 及更高版本中，跨不同框架的 API 接口兼容性已大大提高。 甚至 .NET Core 2.x 和更新版本的应用程序也可以直接引用现有的 .NET Framework 库（请参阅支持 .NET Standard 2.0 的 .NET Framework 4.6.1）。
此外，Windows 兼容包扩展可供 Windows 上的 .NET Standard 2.0 使用的 API 接口。 通过此包，只需略微修改或无需修改即可将大多数现有代码重新编译到 .NET Standard 2.x 以在 Windows 上运行。
但即使 .NET Standard 2.0 和 .NET Core 2.1 取得了如此重大的进展，也可能出现某些 NuGet 包需要在 Windows 上运行并且可能不支持 .NET Core 的情况。 如果这些软件包对于应用程序至关重要，那么将需要在 Windows 容器上使用 .NET Framework。

使用不可用于 .NET Core 的 .NET 技术

当前版本的 .NET Core（撰写本文时为 3.1 版）中没有提供某些 .NET Framework 技术。 虽然某些技术将在更高版本中可用，但其他技术不适用于 .NET Core 面向的新应用程序模式，因此可能永远不可用。
以下列表展示了在 .NET Core 3.1 中不可用的大多数技术：

• ASP.NET Web 窗体。 该技术仅在 .NET Framework 上可用。 目前没有将 ASP.NET Web 窗体引入 .NET Core 的计划。
• WCF 服务。 虽然 WCF 客户端库可从 .NET Core 使用 WCF 服务，但从 2020 年 2 月起，WCF 服务器实现仅在 .NET Framework 上可用。 未来版本的 .NET Core 可能会考虑此方案，甚至会考虑将某些 API 包含在 Windows 兼容包中。
• 与工作流相关的服务。 Windows Workflow Foundation (WF)、工作流服务（WCF + 单个服务中的 WF）和 WCF Data Services（以前称为 ADO.NET Data Services）仅在 .NET Framework 上可用。 尚未计划将其引入 .NET Core。
  除了官方 .NET Core 路线图中列出的技术之外，可能还会将其他功能移植到 .NET Core 或新的统一 .NET 平台中。 请参与 GitHub 上的讨论，发表你的看法。 如果认为遗漏了某些内容，请在 dotnet/runtime GitHub 存储库中提出新的问题。

使用不支持 .NET Core 的平台或 API

某些 Microsoft 和第三方平台不支持 .NET Core。 例如，某些 Azure 服务提供尚不可用于 .NET Core 的 SDK。 大多数 Azure SDK 最终应移植到 .NET Core/Standard，但有些可能因各种原因而未移植。 可在 Azure SDK 最新版本页中查看可用的 Azure SDK。
在此期间，如果 Azure 中的任何平台或服务仍然不支持 .NET Core 及其客户端 API，则可以使用 Azure 服务中的等效 REST API 或 .NET Framework 上的客户端 SDK。
其他资源

• .NET 基础知识
  https://docs.microsoft.com/dotnet/fundamentals

• 从 .NET Framework 移植到 .NET Core
  https://docs.microsoft.com/dotnet/core/porting/index

• Docker 上的 .NET Core 指南
  https://docs.microsoft.com/dotnet/core/docker/introduction

• .NET 组件概述
  https://docs.microsoft.com/dotnet/standard/components