【详解】以 ASP.NET Core 为例的CI/CD

在软件开发中，项目部署是很重要的一环。特别是在敏捷开发中，如何快速、高效且顺利的将修改的代码转化成实际效果，一直是一个津津乐道的话题。常见持续集成和持续部署（下文简称CI/CD）的实现方案是Jenkins，通过Jenkins+宿主机服务器，快速实现项目迭代，这样做确实是会给我们带来极大的便利，也是一直比较流行的方案。然而现实中却没这么简单，我们现在更多的是基于容器化实现K8s集群开发，Jenkins总是会显得有些无力，更别说在K8s中实现一整套的基于多环境的CI/CD操作了。那么我们如何才能完美的实现基于K8s的CI/CD呢？
通过本次实验，我们以微软 Azure Kubernetes Service 为例（下文简称AKS），使用 ASP.NET Core 项目，来分析CI/CD操作。

CI篇

前期准备账号

首先，需要注册一个Azure账号。

其次，需要一个源代码管理仓库，可以新建并使用Azure DevOps代码库，有很好的看板和操作提示，推荐使用。

也可以使用自己的GitHub账户，自从微软收购Github以来，对Azure的兼容性特别友好！如果在GitHub上已经有项目了，可以直接建一个CI的Pipeline即可，建完后效果如图，具体的操作部署下文会显示说明。

使用Azure来创建Pipeline的目的主要有两个：
1、保证代码的准确性，比如临时修改一个代码，又没有编译器，一般就直接修改，然后提交，让CI来初步检查代码的准确性；
2、可以构建镜像并推送到仓库，甚至还可以下一篇文章说到的直接部署。
真正意义上实现 修改代码 == 预览效果 的目的。
Github的Action也有这样的功能，实现思路大致一样，只不过在CD（持续部署上），不太好操作，具体可以参考我Blog.Core项目的代码，这里不细说。

连接Dockers Registry服务

新建CI的管道，推荐配置一个Docker Registry服务，这样可以将Build完成后的镜像推送到镜像仓库中，方便后续的CD操作。

步骤 1 - 项目设置

点击项目下方的Project settings操作链接：

在弹出的新页面中，选择左侧导航条的Service connections操作：

点击新建服务连接按钮：

步骤 2 - 配置 Docker Registry 选项

搜索docker关键词，选中Docker Registry选项：

选择Registry类型，输入DockerID和密码，给这个连接取一个名字，点击Save按钮。

一个服务连接就创建完成了，在以后的CI操作中，会用到这个连接。

用户名和密码要正确，否则会提示错误，可以点击Verify进行校验：

新建一个Pipeline管道

步骤 1 - 配置 Code 源仓库

选择新建Pipeline，勾选Github，如果源代码管理是在Azure DevOps中的，可以直接第一个选项。因为我使用的是Github，所以直接勾选GitHub，基本都是采用的是YAML的方式。

选择一个自己的项目（PS：这个时候可能需要Github二次密码确认）：

步骤 2 - 配置你的Pipeline

采用容器化部署，点击Docker选项，注意和第二个的区别：

配置YAML文件，系统会默认创建一个，只有build操作，可以去掉默认的task，在后侧选择一个docker的Assistant模板：

也可以直接点击左侧代码中settings链接，自动唤起编辑窗口：

其他都是默认，只需要勾选刚刚的服务连接就行，然后输入自己的容器仓库名，请注意，需要在镜像名中增加前缀，也就是各自的Docker ID，点击Add按钮，左侧就同步变化了。

步骤 3 - 点击运行 Pipeline

然后点击右上角的Save and run按钮，一个完整的CI操作就完成了。

同时会把刚刚为创建Pipeline而产生的YAML文件代码给同步到GitHub上：

Build完成后，我们可以在Docker hub中看到推送的镜像：

以上，我们已经完成了持续集成（下文简称CI）的部分，成功将ASP.NET Core项目进行打包编译，并推送到了指定的Docker镜像仓库中。

现在我们继续完成成品的持续部署（下文简称CD）流程。

CD篇

添加Release管道

步骤 1 - 新建Pipeline

在左侧导航条中，点击Pipelines（管道）下的Release（发布）选项，新建一个Pipeline，如果之前未创建过Release的Pipeline，页面默认展示效果如下所示：

在右侧的模板中，选择一个空模板：

步骤 2 - 配置Artifact

将鼠标移动到左侧的Artifacts（制品）模块上，单击添加一个Artifact，此时右侧会唤起编辑窗口，单击build（编译）选项：

选择之前build的管道，使用Latest最新版本，此刻我们的CD管道便正式和CI管道关联起来。

步骤 3 - 自动构建

单击制品右上角的构建图标，开启自动构建，这样只要提交代码的时候，便会触发CI的Build操作，接着便立即触发CD的Release操作，整个流程一气呵成。

配置好了Artifact，然后就可以配置task任务了。

配置Agent代理

将鼠标放到右侧的Stage（阶段）选项上，可以看到有三块功能选择，分别是：

①、对Stage进行重命名；

②、添加一个新的Stage；

③、编辑task（任务）；

点击任务链接，配置Agent Job（代理工作），这里有两点需要注意：

1、代理池，指部署的地方，目前默认即可，以后可以用自己的服务器；

2、agent specification（代理规格），就是服务器规格配置；

请注意！这里默认的是vs2019规格，是windows环境的，如果不改的话，会出现Docker不能运行的平台问题。所以直接选Linux即可。

配置Task任务

步骤 1 - 删除旧容器

点击AgentJob右侧的加号，筛选docker的task模板

在新唤起的编辑页中编辑命令，删除旧的容器，直接用run命令，所以Task的版本用0.*：

选择容器Registry地址，配置一个action（行为），增加一个删除镜像的命令

rm -f xxxx

步骤 2 - 运行新容器

与第一步删除旧容器的阶段步骤相似，再建一个运行容器的Stage，整体流程一致，配置图如下所示：

Task版本为1.*的Docker容器配置，使用自定义的DockerRegistry，配置镜像名，支持自定义，比如我加了前缀，最后指定端口。

点击Save（保存），一套简单的持续集成管道就建好了

可以手动触发，create release，就可以看到详细的过程：

等一段时间后，新容器已经被成功运行了，只不过目前还没有配置自己的代理池，因此无法查看具体的展示效果。

如何查看效果

目前Azure部署项目有两种常见的方式：

1、配置自定义代理池，用自己的服务器提供代理池，生成镜像和运行容器都会在自己的代理池服务器中运行。

2、直接使用Azure的k8s服务，新建一个Deploy的Task，指定对应的服务连接和Yml文件，这样就会把镜像推送到Azure的镜像仓库，并将镜像运行构建Pod实例。

编者两者都用过，用第二种举例，大致是这样的：

先构建并推送镜像到镜像仓库

接着对镜像部署

总结

本文先以 ASP.NET Core 为例讲解了如何在 Azure 中实现持续集成操作，整体流程简单方便，文档特别清晰，再一次为微软Docs文档而欢呼。

后以 ASP.NET Core 为例讲解了如何在 Azure 中实现持续部署操作，整体流程以持续集成为前提，一步步将我们的Code运行起来，真正意义上实现了自动化操作。

Source Link：
https://docs.microsoft.com/zh...
https://devblogs.microsoft.co...

Github：
https://github.com/anjoy8/Blo...