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

在软件开发中，项目部署是很重要的一环。特别是在敏捷开发中，如何快速、高效且顺利的将修改的代码转化成实际效果，一直是一个津津乐道的话题。常见持续集成和持续部署（下文简称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...

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

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

微软最有价值专家

文章图片

微软最有价值专家是微软公司授予第三方技术专业人士的一个全球奖项。28年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和经验而获得此奖项。
MVP是经过严格挑选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的热情并乐于助人的专家。MVP致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人，并最大程度地帮助微软技术社区用户使用Microsoft技术。
更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn
【【详解】以|【详解】以 ASP.NET Core 为例的CI/CD】这里有更多微软官方学习资料和技术文档，扫码获取免费版！
内容将会不定期更新哦！