在软件开发中，我的项目部署是很重要的一环。特地是在麻利开发中，如何疾速、高效且顺利的将批改的代码转化成实际效果，始终是一个津津有味的话题。常见继续集成和继续部署（下文简称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

这里有更多微软官网学习材料和技术文档，扫码获取免费版！
内容将会不定期更新哦！