上个月15日，上海MVP做了一次线下的技术分享活动，我分享的主题是《快速构建容器化的 Core应用程序》，有关这次活动的简报，可以参考这里。另外，我的主题分享的PPT也可以点击这里下载。由于线下活动时间紧迫，没有办法把所有的内容完全仔细地讲解一遍，最后使用一个小时左右的时间做了一个tasklist的案例演示，但也是走马观花，很多细节没有覆盖到。因此，特撰此文，将之前分享的内容再细化一下，希望能够给关注这方面内容的读者带来帮助。

我会尽量将细节问题解释清楚，于是，文章篇幅会比较长，因此，我会分三个部分进行介绍：

Core应用程序容器化需要注意的内容

持续集成、持续部署与Azure DevOps

Azure Kubernetes Service介绍

Core应用程序的构建

构建 Core应用程序的方式有很多种，你可以使用Visual Studio 的项目模板直接创建，也可以在安装了.NET Core SDK之后，使用dotnet new命令创建，具体步骤在此也就不再细表，我仍然使用Visual Studio 的 Core项目模板进行创建。在新建项目对话框中，我们可以选择启用Docker容器支持，这样的话，Visual Studio会在新建的 Core项目中添加Dockerfile文件，同时会在解决方案中增加一个Docker Compose的项目，用以实现容器编排。然而，我并不太喜欢使用这一功能，虽然它能够带来很多方便，原因主要有二。首先，一个复杂的应用程序解决方案，项目往往不止一个，各项目的运行环境和配置都会有所不同，使用项目模板创建的Dockerfile和Docker Compose文件有可能还是需要进行修改，甚至重写；其次，我们需要对IDE自动生成的代码了如指掌，这样才能理解并在实际项目中正确使用，与其如此，不如自己根据实际需要自己编写，这样可以让自己对整个项目的各个技术细节都有着深刻的理解和认识。

新建 Core项目之后，就可以开始编写代码来实现我们的业务逻辑了。有关Visual Studio 开发 Core应用程序的详细步骤在这里就不多介绍了，作为这次线下活动的演示案例，我开发了一个简单的App：tasklist，这个App使用Angular 6作为前端框架，TypeScript进行前端编程，后端使用 Core Web API构建，基于MongoDB数据库，完整的代码可以在/daxnet/tasklist找到。该案例项目使用MIT许可协议开源。

Tasklist的业务非常简单，就是允许用户能够增加、删除任务项目，它的界面如下：

在这个界面中，用户可以在文本框中输入需要完成的任务项目，点击“新增”按钮可以将任务项目添加到列表，也可以在列表中点击“删除”按钮删除指定的项目，文本框下方列出了所有已添加的任务项目。整个后端 Core Web API解决方案中各项目的依赖关系如下：

具体的代码实现部分就不多介绍了，这里重点介绍一下 Core应用程序容器化时需要注意的几点问题。

Core应用程序容器化所需注意的问题

应用程序的配置信息

容器化的应用程序往往都是在容器启动的过程中，将所需的配置信息通过环境变量注入容器，此时运行于容器中的应用就可以读取环境变量来获得运行参数。比如，使用docker run命令启动容器时，就可以使用-e参数来指定环境变量。因此，理解 Core应用程序的配置系统是非常重要的，它有助于应用程序配置体系的设计。在《 Core应用程序的参数配置及使用》一文中，我已经简要介绍过 Core应用程序的配置系统，可供参考。

在此需要注意的一点是， Core配置系统通常使用冒号（:）来分隔配置数据模型中不同层次的名称。比如，有如下配置数据模型：

如果在C#代码中要访问host，那么就需要使用下面的代码：

然而，如果应用程序需要运行在容器中，这个配置就需要写在容器的编排文件里，比如docker-compose.yml文件。但是，有些容器的编排系统，例如Kubernetes，就不支持在环境变量设置时出现冒号这样的“非法字符”，为此， Core的配置也支持使用双下划线分隔。比如：

这样的话，不仅 Core应用程序在容器中能够获得环境变量的配置，而且诸如Kubernetes这样的系统也能在启动容器时，将配置信息设置到环境变量中。

端口侦听

Core应用程序的端口侦听设置也是一个在容器化过程中非常重要的内容。通常，在开发阶段，我们偏向于在Main方法中通过代码的方式指定应用程序所侦听的端口号，比如：

但是这种方法缺点是很明显的：我们无法在部署应用程序的时候动态设置需要侦听的端口。对于 Core应用程序而言，常见的做法有两种：通过命令行参数指定侦听端口，或者使用环境变量。通过命令行参数，只需要在启动应用程序时，指定—server.urls参数即可：

或者，如果是使用环境变量，只需要配置ASPNETCORE_URLS变量即可，如下：

因此，事实上我们并不需要在Main函数中去显式地指定侦听端口，只需要在最终部署的时候，设置ASPNETCORE_URLS环境变量即可。现在，让我们看看tasklist代码库中，docker-compose.yml文件中有关后端服务的环境变量配置：

在上面的配置中：

ASPNETCORE_ENVIRONMENT：指定 Core应用程序运行环境，该参数将决定应用程序配置信息的读取方式

ASPNETCORE_URLS：指定 Core应用程序的侦听端口

mongo__server__host：MongoDB的服务器名称

mongo__server__port：MongoDB的侦听端口

mongo__database：MongoDB的数据库名称

Core的容器版本

微软官方发布了.NET Core/ Core的docker容器镜像，可以在/r/microsoft/dotnet/中找到。开发人员需要根据不同的场景来选用不同的tag。比如：

2.1-sdk：包含了.NET Core 2.1 SDK

2.1-aspnetcore-runtime：包含了 Core 2.1的运行库

2.1-runtime：包含了.NET Core 2.1的运行库

此外，在这个repo下，还有一些预览版的tag，可以在/r/microsoft/dotnet/tags/页面找到所有的tag。就 Core而言，在2.0（含）之前，需要使用microsoft/aspnetcore这个docker容器镜像，而从2.1开始，则需要使用上面提到的microsoft/dotnet这个容器镜像。总之，对于容器镜像和tag的选择需要慎重，否则有可能出现一些奇奇怪怪的问题。

docker镜像构建上下文（Build Context）与Dockerfile的配套使用

在上面的docker-compose.yml片段中，我们指定了 Core应用程序的docker镜像构建上下文，为service/tasklist目录，于是，接下来所有与构建docker镜像相关的操作，都会基于这个构建上下文来执行。首先，通过dockerfile指定了Dockerfile的位置是：service/tasklist/TaskList.Service/Dockerfile（注意这里已经将构建上下文路径带入进来）；然后，我们了解一下Dockerfile的具体内容：

这个Dockerfile分成三个部分：第一部分指定运行时会采用microsoft/dotnet:2.1-aspnetcore-runtime这个tag，运行目录为/app目录，并会向外界暴露9020端口；第二部分就是应用程序的编译部分，这里采用microsoft/dotnet:2.1-sdk作为编译环境，先设置容器中的工作目录为/src，然后，将service/tasklist目录下的所有内容全部复制到容器中的/src目录（注意，虽然COPY指令后面是两个点号，但由于我们已经指定了镜像构建上下文，因此，第一个点号就表示service/tasklist目录，第二个点号就表示容器中的当前目录，也就是/src目录），接着就是标准的dotnet restore命令，然后就是进入到/src/TaskList.Service目录，执行dotnet publish指令，从而编译整个项目，并将编译结果输出到/app目录；到了第三部分，将第二部分的输出结果复制到第一部分容器中的/app目录（也就是最后那个点号所指定的目录），然后执行dotnet命令启动服务。

事实上，如果你在创建 Core应用程序时，启用了docker支持，那么Visual Studio会在你的项目中添加一个Dockerfile，内容与上面的Dockerfile类似，不过需要注意的是，使用这个自动生成的Dockerfile之前，需要弄清楚镜像构建上下文，否则直接通过docker build命令是无法正常完成镜像构建的。

在容器化 Core应用程序方面，我暂时先介绍这些内容；接下来看看前端部分需要做些什么。

前端应用：nginx的反向代理

在tasklist案例中，前端我采用的是Angular 6框架，使用TypeScript编写。由于是一个单页面应用，因此，我没有选择相对比较重的Jetty、Tomcat、IIS等Web容器，而是选择使用了比较轻量的nginx。当然，前端通过http请求访问 Core Web API应用程序所提供的RESTful API接口，那么这里就有一个访问URL的问题。使用过Angular框架的开发者都知道，通过environment.ts（或者environment.prod.ts）代码文件，可以针对不同的运行环境（Development, Staging或者Production）来选择设置不同的配置数据，那么，后端服务的URL地址又该如何设置呢？

使用绝对路径：这不是个好的做法，这就要求将后端API的全路径都写死（Hard Code）在environment.prod.ts里，显然不是一种合理的做法

使用相对路径：这种做法会使得前端App调用后端API时，产生一个错误的URL。比如，假设前端运行在localhost:80，而后端是localhost:9020，那么如果我们指定API的URL是相对路径/api/service，那么当前端程序运行时，它请求的API地址就成了http://localhost/api/service，而不是http://localhost:9020/api/service

在tasklist中，我选择了使用相对路径，然后更改nginx的配置，设置了一条反向代理规则：

在这里，当前端页面请求/api路径时，nginx会自动重定向到http://tasklist-service:9020/api，此时就能正确完成RESTful API调用。注意：这里的tasklist-service是 Core应用程序的运行机器名，请参考docker-compose.yml文件中service配置部分的container_name设置。

同样，基于docker镜像构建上下文，我们可以使用容器来编译和运行前端代码：

在容器中运行整个应用程序

在此，我选择使用Docker for Windows来运行整个tasklist应用程序。首先启动Docker for Windows，然后打开Windows命令行工具，进入到tasklist目录，执行：

经过一段漫长时间的构建过程之后，所有的服务都会启动：

在浏览器中打开我们的应用：

总结

本文为 Core应用程序容器化、持续集成、持续部署话题的第一部分，重点介绍了 Core应用程序容器化时需要注意的地方，并展示了整个案例的运行效果。下文会接着讨论基于Azure DevOps的持续集成，看看如何使用Azure DevOps的服务来完成项目的自动编译。

原文地址://10/07/dockerize-aspnetcore-cicd-with-azure-devops-and-kubernetes-part1

.NET社区新闻，深度好文，欢迎访问公众号文章汇总