k8s jenkins pipeline 多分支发布_基于Docker Compose的微服务持续发布

【持续集成】|  作者  / Edison Zhou 这是 恰童鞋骚年 的第 256 篇原创内容

---

最近有童鞋在后台留言说是不是现在每个团队都需要上K8s才够潮流，不用K8s是不是就落伍了。今天，我就通过这篇文章来回答一下。 1先给出我的建议

我想说的是，对于很多的微小团队来说，可能都不是一定要上K8s，毕竟上K8s也是需要成本和人力的。对像我司一样的传统企业做数字化转型的信息团队来讲，人数不多，没有专门的Ops人员，领导又想要尽快迭代支持公司业务发展，而且关键还要节省成本(内心想法是：WTF)。

在此之下，信息团队需要综合引入先进技术带来的价值以及需要承担的成本和风险。任何架构的产生，都会解决一定的问题，但是同样也会引入新的复杂度，正如微服务架构风格，看着香实际吃着才知道需要承受很多的“苦”(比如数据一致性又比如服务的治理等等)。

因此，结合考虑下来，我的建议是开发测试环境使用Docker Compose进行容器编排即可，而UAT或生产环境则建议使用云厂商的K8s服务(比如阿里云ACK服务)而不选择自建K8s集群。

那么，今天就跟大家介绍一下如何使用Docker Compose这个轻量级的编排工具实现.NET Core微服务的持续发布。

2Docker Compose

Docker主要用来运行单容器应用，而Docker Compose则是一个用来定义和应用多容器应用的工具，如下图所示：

使用Docker Compose，我们可以将多容器的定义和部署方式定义在一个yml文件中，这种方式特别是微服务这种架构风格，可以将多个微服务的定义及部署都规范在一个yml文件中，然后一键部署、启动或销毁整个微服务应用。所有的一切操作，只需要下面的一句话：

$docker-compose up

Compose 的安装请参考：https://docs.docker.com/compose/install/#install-compose，这里就不再赘述，它不是本文重点。

安装后验证：

$docker-compose --versiondocker-compose version 1.25.1, build a82fef07

3一个简单的发布示例流程 本示例的流程大概会如下图所示： 阅读过我之前的一篇文章《基于Jenkins Pipeline的ASP.NET Core持续集成实践》的童鞋应该对这个流程比较熟悉了。这里，我仍然延续这个流程，作为一个平滑过渡。 首先，我们在Jenkins上触发容器的发布流水线任务，此任务会从Git服务器上拉取指定分支(一般都是测试分支)的最新代码。 其次，在CI服务器上使用.NET Core SDK执行Build编译和发布Release文件，基于发布后的Release文件进行镜像的打包(确保你的项目里面都有Dockerfile且设置为“始终复制”)。 然后，基于打包后的镜像，将其推送到企业的私有Registry服务器上(即本地镜像仓库，可以基于Harbor搭建一个，也可以直接用Docker Registry搭建一个，不建议使用docker hub的公有库，如何搭建私有镜像仓库可以参考我的这一篇文章：《Docker常用流行镜像仓库的搭建》)。 最后，在测试服务器或要运行容器的服务器上执行docker compose up完成容器的版本更新。 当然，也可以直接在docker-compose.yml文件内设置编译路径完成编译和发布的操作(Dockerfile里面定义进行Build和Publish)。这里目的在于让实例更简单，且能让初学者更容易理解，于是我就分开了。 4.NET Core微服务发布示例 微服务示例准备 假设我们有一堆使用ASP.NET Core开发的微服务，这些微服务主要是为了实现诸如API网关、Identity鉴权、Notification通知、Job中心等基础设施服务，因此我们将他们整合在一起进行持续集成和部署。 这里为了让示例尽可能简单，每个微服务的Dockerfile只有以下几句(这里以一个通知API服务为例)：

FROM reg.xdp.xi-life.cn/xdp-service-runtime:2.2WORKDIR /appCOPY . /appEXPOSE 80ENTRYPOINT ["dotnet", "XDP.Core.Notification.API.dll"