Azure + Core实现CI/CD构建镜像并推送仓库

Posted 2021-10-15 dotNET跨平台

（海上生明月，天涯共此时）

今天是农历八月十六，大家中秋节快乐！

放了三天假，和家人整理下屋子，打扫下卫生，闲着无聊就研究点儿新东西。最近一直再看DevOps相关的内容，自从开始学习Docker以来，DevOps一直是比较感兴趣的事情，今天就给大家简单演示一下，如何使用Azure来实现CI操作——将Github上的代码，自动的构建镜像，并推送到DockerHub上（持续集成）。当然，私库也是可以的。CD相关的内容，我还在看，下篇会讲讲，至于是部署到自己的服务器，还是部署到K8s里，看到时候的设备咯。

每个人应该都是可以的，注册一个Azure账号就可以了，我是国际版的，区别就是域名是https://dev.azure.com，只要有梯子科学上网就行，否则会很慢。

1$ 准备账号

首先，Azure账号就不说了，硬性标准。

其次，既然是要处理CI/CD，肯定需要源代码管理了，想必每个人都有GitHub的账号吧，用GitHub也是可以的，有时候我也会使用Azure上的代码库，毕竟是一体化的，整体操作起来比较顺畅。

如果已经在GitHub上已经有项目了，又不想迁移到Azure上，那也可以的，直接建一个Pipeline就行了，我这里已经建了三个了：

我建Pipeline的目的主要有两个：

1、保证代码的准确性，比如有时候在地铁上想修改一个代码，又没有编译器，一般就直接在Github上修改，然后提交，让CI来检查；

2、可以构建镜像并推送到仓库，甚至还可以下一篇文章说到的直接部署。

真正意义上实现，修改代码 == 预览效果 的目的。

Github的Action也有这样的功能，实现思路大致一样，只不过在CD（持续部署上），不太好操作，具体可以参考我Blog.Core项目的代码，这里不细说。

2$ 连接服务

新建一个Pipeline用来实现持续集成，需要一个DockerRegistry服务，要不然只能到Build这一步，也就只能来校验代码是否正常，不能推送镜像，更别说后续的CD操作了。

一、项目设置

二、在Pipeline中，连接服务

点击新建服务连接按钮

选择Docker Registry选项

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

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

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

3$ 新建Pipeline

选择新建Pipeline，勾选Github，如果你是在Azure中的，可以直接第一个，我这里勾选GitHub，基本都是采用YAML的方式

选择一个自己的项目，这个时候可能需要Github二次密码确认，输入密码即可

配置Pipeline，一般都是直接点击Docker即可

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

也可以直接点击左侧代码里的那个settings，会自动唤起后侧编辑窗口

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

然后点击右上角的Save and run按钮，一个完成的CI操作就完成了，并且会把代码给同步到GitHub上：

然后可以在GitHub上看到推送的镜像

4$ 其他内容

新的每次Pipeline执行，都会有邮件的返回结果，如果是成功与否，这个还是很方便的

可以直接点击地址，查看结果。

打完收工，下一篇，我们来看看如何做CD操作。

预告，在发稿时，CD已经研究七七八八了，总体感觉良好，且很有意思，值得研究下：

不仅有直观的看板界面，更有详细的日志和操作说明，方便定位任何问题，比如我随便写一个错误，就会看到错误日志（具体问题，下篇解析）：