微软NET下的Docker容器实现.docx

微软NET下的Docker容器实现.docx

《微软NET下的Docker容器实现.docx》由会员分享，可在线阅读，更多相关《微软NET下的Docker容器实现.docx（16页珍藏版）》请在冰豆网上搜索。

微软NET下的Docker容器实现

微软.NET下的Docker容器实现

许多与我交流的开发者要么在积极地使用Docker，要么计划在他们的环境中采用容器技术。

容器是我们这个行业的一个重要趋势，.NET是其中的一部分。

Microsoft和Docker一直在合作，以便在开发.NET应用时，使用Docker可以有一个良好的体验。

Docker生态系统始于Linux技术。

你可以在Linux和.NETCore上使用同其他开发平台一样的Docker工作流。

.NET团队经常会在DockerHub的 microsoft/dotnet 仓库中更新Debian镜像。

Windows团队最近发布了WindowsServer2016，并更新了Windows10，而且在Windows上支持了容器。

现在.NETCore和.NETFramework都可以与Windows容器结合使用。

上述支持在使用Docker构建和打包.NET应用的方式上提供了很多选择。

这篇文章介绍了其中的一些选择，并提供了入门信息，即使你是个Docker新手也没关系。

为什么选择容器？

下面列出了开发人员迁移到容器的关键原因：

▪一致性：

容器包括应用程序及其所有依赖项。

不管是在计算机、本地环境或是云端，应用程序都执行相同的代码。

▪轻量级：

通过使用基于主机操作系统的最小量级抽象，并在容器之间共享公共资源，容器可以快速启动并使用最少量的RAM。

▪共享性：

容器镜像可以通过 DockerHub、DockerStore 和私有Docker仓库（如 Azure镜像仓库）轻松实现分享。

▪简单而强大：

DockerFile格式（容器镜像的recipe）是一种可以实现强大场景的简单格式：

优雅地将操作系统和容器的特定命令结合，并且还可以创建Docker镜像层。

想象一下，五年前如果有人在面试中告诉你，他们非常关心一致性，所以需要经常与应用一起部署操作系统。

当时你可能不会雇佣他们。

然而，这正是目前Docker的典型应用场景！

例如，如果需要为.NET团队添加容器的测试用例。

我们会将基础设施的重要部分转移到容器上，以便从容器的优势中受益，而不是简单地“在Docker容器中测试.NET”。

这种方法为我们提供了双重优势：

在容器中运行.NET的高度信心以及更加高效的整体流程和更低的成本。

在这个案例中，我们每年为基础设施实验室节省了一个人力的时间成本和每年10万美元的云服务机器成本。

我很高兴我们能够节省这些费用。

Docker在.NET应用中的使用场景

使用Docker和.NET应用程序的最典型场景是用于生产环境部署和托管。

事实证明，生产环境部署只是一种场景，而针对其他场景Docker同样有用。

这些场景虽然不是.NET特有的，但应同样适用于大多数开发平台。

▪低摩擦安装——在机器上无需安装任何东西，只需下载一个预装.NET的Docker镜像，你就可以尝试使用.NET。

▪在容器中开发——你可以在一致的环境中开发，开发环境和生产环境非常相似（这样可以避免一些诸如开发机中的全局状态等此类的问题）。

VisualStudioToolsforDocker 甚至可以直接从VisualStudio中启动容器。

▪在容器中测试——你可以在容器中进行测试，减少由于环境配置错误或上次测试遗留的其他更改导致的失败。

▪在容器中构建——你可以在容器中构建代码，无需为多个环境正确配置共享的构建机器，而是转为“BYOC”（自带容器）的方法。

▪在测试环境、staging环境、生产环境以及其他环境中部署——你可以在所有环境部中部署同一个镜像，减少由于配置不同导致的失败。

通常只通过外部配置（例如，注入的环境变量）来更改镜像的行为。

如何入门

现在可以在 Windows、MacOS 或 Linux 上使用.NET容器。

首先，你需要一个Docker客户端，最佳获取途径是 D。

如果是在Windows平台上，请下载 DockerforWindows（稳定版本）。

Docker同时支持Windows和Linux容器。

如果你是Azure用户，可以查看 DockerEditionforAzure（

如果你是Docker新手，建议你在Docker文档中查看 Docker入门（Linux容器，但如果你不是Linux用户，也不用担心，你可以找到与你使用的操作系统对应的Docker客户端使用说明，以及针对通用Docker概念和机制的指南。

接下来，可以尝试使用我们提供的.NET与Docker结合使用的示例。

这些示例应该可以帮助你开始使用.NET和Docker。

我们创建了两组样本，因为.NETCore和.NETFramework之间的关键不同在于需要不同Dockerfile和其他组件。

▪.NETCore+Docker示例（

▪.NETFramework+Docker示例（

我们push了一些镜像到Dockerhub，以便大家可以更加容易地使用它们：

▪.NETCore示例镜像（

▪.NETFramework示例镜像（

通过使用示例镜像，你可以在机器上尝试.NET，而无需安装任何东西（Docker除外）。

也就是说，我认为在本地环境中尝试示例仍然是充分体验和评估.NET与Docker的最佳实践。

例如，针对.NETCore，可以尝试以下Linux镜像（如果使用DockerforWindows，请务必切换到Linux容器）：

docker run microsoft/dotnet-samples

DockerHub中的.NET

使用.NET与Docker的一个重要方面是要依赖.NET团队提供的.NET基础镜像。

为什么使用.NET基础镜像是一个好主意呢？

至少有以下四个原因：

▪.NET团队提供了基础镜像，所以你不必再造轮子。

▪.NET团队会定期更新镜像，其中包括一些针对安全性的更新。

▪当多个应用程序在同一台机器上使用相同镜像时，Docker共享这些镜像的内存。

镜像必须相同才能共享。

▪Docker会扫描镜像来发现安全漏洞，可以提供有关环境的更多信息。

我们将Docker镜像发布在 DockerHub 上几个不同的仓库中。

镜像分割很重要，这样可以在DockerHub以及 dockersearch 命令中更容易找到它们。

▪microsoft/dotnet——适用于Linux和NanoServer的.NETCore运行时和SDK镜像。

▪microsoft/aspnetcore —适用于Linux和NanoServer的ASP.NETCore镜像。

▪microsoft/aspnetcore-build——适用于Linux和NanoServer的ASP.NETCore镜像，用于构建应用程序。

▪microsoft/dotnet-framework——适用于WindowsServerCore的.NETFramework3.5和4.6.2镜像。

▪microsoft/aspnet——适用于WindowsServerCore的.NETFramework3.5和4.6.2ASP.NET镜像。

我们也在DockerHub上发布了示例，以便大家可以更加容易地使用。

▪microsoft/dotnet-samples——.NETCore示例。

▪microsoft/dotnet-framework-samples——.NETFramework示例。

基础镜像的使用说明及示例可以参照上述提供的DockerHub链接。

如果你刚刚接触Docker分层概念，我们建议你阅读Docker关于理解镜像、容器和存储驱动（

定义Docker镜像

Docker镜像（包括.NET镜像）由一个相对简单的 Dockerfile格式文件定义。

你可以在上述提供的DockerHub仓库中找到每个镜像的Dockerfile文件的链接。

这些文件定义镜像内容和其他特征。

在多数情况下，我们会研究其他平台对镜像的处理，并尝试遵循行业规范。

也有一些情况下，我们会选择做一些最适用.NET应用程序的工作，这些工作可能会也可能不会适用于其他平台。

通常情况下，Docker员工为其他平台创建初始化镜像，所以我们在DockerHub上看到的自由“复制”模式实际上只是在追随Docker。

随着Docker规范的变化，我们将尽最大努力地将这些变化应用在.NET镜像上。

Dockerfile源文件存储在GitHub上。

你可以关注我们关于镜像的进展。

如果你愿意的话，也可以看看我们制作镜像的原因并参与讨论。

Docker镜像标签化

Docker镜像具有隐藏ID（例如，d99acb94e777），用于默认识别。

因为ID对用户来说并不是很有用，所以我们可以给Docker镜像打标签。

标签通常是描述镜像用途的的友好名称，例如“hello-world-app”。

该机型在本地运行良好。

在DockerHub上，仓库名称为镜像的名称，标签通过版本号或其他标志来消除仓库中镜像的歧义。

.NETCore标签

对于.NETCore，标签用于描述以下三个维度的镜像差异：

▪.NETCore版本——.NETCore1.0,1.1and2.0（撰写本文时）。

▪.NETCore分布——.NETCore运行时，.NETCoreSDK,.NETCoredependencies依赖项。

▪操作系统基础镜像——Windows和Linux。

dotnet仓库的一个重要选项是打上 latest 标签。

我们决定 latest 标签总是指向最新的.NETCoreSDK版本。

例如，作为RTM时，latest 将更新指向.NETCoreSDK2.0。

替代方案是将 latest 映射到.NETCore运行时。

我们认为，SDK是你起步的最佳镜像，一旦你体验了较大的SDK，就可以更容易地做出优化的选择。

我们最近做出了一些改变 .NETCoreDocker镜像使用连拱（multi-arch）标签。

此改变可以让你减少对上述第三个维度的考量。

这意味着你的Dockerfile文件不再需要定义要使用的操作系统。

.NETFramework标签

对于.NETFramework，标签仅在一个维度上描述镜像差异：

▪.NETFramework版本—3.5,4.6.2

latest 标签对应最新版本的.NETFramework。

当镜像可用时，latest 将会更新并指向4.7版本。

仓库分割

关于如何构建仓库没有现成的硬性规定。

下面这条是个不错的参考：

从仓库中执行 dockerpull 拉取到的镜像，应当是一个意义明确的镜像，仓库中的其他镜像应当紧紧围绕与默认镜像相关的附加概念而存在。

仓库中的标签越多，其中某些镜像应当属于其他仓库的可能性越大。

这是我们正在讨论的东西，与Docker方面也在讨论这个问题。

我们希望将.NETCore仓库分为两个或三个，这样便于用户使用。

不幸的是，目前没有比较好的机制来找到其他相关联的库。

我们希望这个问题可以得以解决，这样我们可以更加自由的分割仓库。

更新镜像

.NET镜像经常更新，有时是安全性更新。

可以通过执行 dockerpull 下载这些更新，dockerbuild 不会从服务器请求更新。

对于Windows镜像，在.NET的Dockerfile定义中依赖了一个特定的基础镜像，具体可以参考microsoft/dotnet:

1.0-runtime-nanoserver Dockerfile中的第一行，如下：

FROM microsoft/nanoserver:

10.0.14393.1198

在“补丁周二”（每个月的第二个星期二），Windows团队通常会发布补丁并更新其基础图像，.NET镜像也会更新。

对于Linux镜像，.NETDockerfile中定义依赖了一个更通用的基础镜像，该镜会随时间发生变化。

目前，.NETCore选用 DebianJessie，并向Jessie发布更新（例如8.6到8.7）。

你可以在 microsoft/dotnet：

1.0-runtime-depsDockerfile Dockerfile定义的第一行看到，如下所示：

FROM debian:

jessie

Debian仓库包括DebianStretch（Debian9）的镜像，这是DebianJessie（Debian8）之后的一个版本。

我们不会将使用DebianJessie的.NETCore标签自动前滚到DebianStretch，但会像其他平台一样，为其创建一个新标签。

迁移.NETFramework应用到容器

如果有工具可以将VHD转换为容器，岂不是让人很兴奋？

在 DockerCon2017 上，一款名为Image2Docker的工具着实令人兴奋，它可以将WindowsVM迁移到容器。

该工具由Docker在GitHub上维护。

Image2Docker的PowerShell模块可与VHD，VHDX或WIM镜像文件一起使用，并生成可构建Docker镜像的高保真Dockerfile。

该工具可以帮助你构建一个与VHD相同的Docker镜像，同时还能发挥Docker的优势。

Image2Docker虽然不会构建出最漂亮的Dockerfile，但对于希望将.NETFramework应用迁移到容器的用户来说，这是一个不错的开始！

更多信息可参考 DockerCon演讲之Image2Docker（Docker官方文章：

使用Image2Docker将ASP.NET服务转换为Docker（

注：

运行Image2Docker需要安装Windows版本的Docker。

结语

作为一个团队，我们至今已持续大约两年的时间专注于.NET与Docker的结合。

期间，我们针对Docker的方案发生了很大变化，很大程度上是为了适应了Docker生态系统的快速变化。

我们本身也大量使用Docker。

我们将继续调整步伐来确保.NET是容器化应用程序的最佳平台之一。

在此，我想为在Docker工作的同事点赞。

我们一直在与他们其中的很多同事合作，致力于.NET和Docker更好地结合。

当我们提出可以让.NET开发人员更友好的改进时，Docker的同事也很乐意接受建议。

连拱标签和多级构建是我们早期参与而获益的一个良好示例。