昨天看到 https://www.v2ex.com/t/711163
里面有个老哥说有一千多个微服务,惊了,不知道是一千多个服务实例还是一千多种服务。
我们公司有差不多一百种微服务,大半在 k8s 上,小半直接部署在 Tomcat 里。上线靠 jenkins 。 因为有些服务有构建先后次序的问题,所以构建要依次执行很耗时间。因为希望特定时间上线(比如中午 12 点 /夜里 12 点),所以要提前构建,到点再部署。这样每个服务有构建 /部署两个 Job,再加上顺序问题,每次上线涉及的服务一多那是鸡飞狗跳。
我搞了一个自动构建+模板渲染 yaml 的工具,算是极大降低了 k8s 服务的上线难度,预先写好要上线的服务列表,上线时一键执行。解决了两个问题:
但是比较流行的 CICD 工具好像也不太合用。用中文搜了一下,一些国内的 K8s 管理方案主要是可视化。可视化感觉还是给新上手 k8s 的公司用的,跟 Jenkins 没本质区别。 另外有公司用推代码自动构建+手动部署的方式。这也不太适合我司:
1
singerll 2020-09-29 09:26:57 +08:00 via Android
大公司肯定不是自己实现工具啊,都是一个团队在实现工具。
|
2
whileFalse OP @singerll 我意思是有没有现成的工具?如果有现成的自己不知道还傻呵呵写就挺井底之蛙的。
|
3
whileFalse OP @singerll 再说我就是 DevOps 职位,虽然不算“一个团队”,但确实是该写工具的岗位。
|
4
GopherDaily 2020-09-29 09:30:40 +08:00
服务注册、发现,健康检查、流控之类的功能不是强制的,内部调用还是走域名,那么只要你写的代码能跑就行。
另外一种是公司层面针对几种特定的应用类型( web/consumer )提供几种特定语言的支持,业务方在框架内写业务逻辑,框架负责和上面那些东西打教导。 单个应用类型下有多少实现不同业务逻辑的应用,这个数量一点都不关键 |
5
cassyfar 2020-09-29 09:50:17 +08:00 1
Spinnaker
|
6
sampeng 2020-09-29 10:42:36 +08:00 via iPhone 1
你最要解决的是,解决依次构建问题。需要依次部署在微服务就是个架构设计有问题的最明显特征。因为你无论如何都有两个版本同时存在的状态。所以为什么要依次部署呢…这应该是可以通过部署流程优化的。
|
7
whileFalse OP @GopherDaily #4 微服务的部分我们用的 Spring Cloud 。
数量很重要。一次上线包含 3 个和一次上线包含 30 个服务是不同的概念。10 个以内的服务手动点点没啥问题,但手动点一大批就很烦。 |
8
sampeng 2020-09-29 10:45:56 +08:00 via iPhone 1
我司跟你情况一样。加起来上百个微服务。我也是 devops 。所以我不解决问题,我解决提出问题的人。服务不适合我自动化构建就改到合适为止。现在把上线都直接交给研发了…反正构建速度 ok,部署不出错,微服务完全没状态。有应急的情况有 hpa 自动伸缩,再大点的流量高峰是可以预知的。提前把 hpa 改大点完事…
|
9
whileFalse OP @sampeng #6 需要依次构建,不需要依次部署。
构建的时候需要向本地安装一些 snapshot 的包,后续构建要用到这些包,所以需要按顺序。 |
10
ElegantOfKing 2020-09-29 11:19:12 +08:00 1
1.有部署平台,发布的时候运维点点点就行;
2.运维人手多; 3.有项目回滚平台,出现问题运维点点点; 4.有完整的预警平台,出现问题会通过邮件、短信和公司自研的通讯应用推送信息; 5.经常机房灾备演练。 |
11
ElegantOfKing 2020-09-29 11:21:01 +08:00
项目构建,还是用的公司自研的构建平台......可以选择同时构建和依次构建
|
12
yamasa 2020-09-29 11:30:04 +08:00
有点不太理解,‘我搞了一个自动构建+模板渲染 yaml 的工具‘,这是自己实现了一套类 Helm 吗?这功能跟 helm 太像了。
我们这儿是 gitlab cicd + helm + k8s, sde team 自己负责发布和部署,或者 sde team 开发一键式的 ui 供 devops 做部署,让 devops 尽量降低部署的心智负担。 生产上线之后,devops 需要关注各类 online alerts,sde team 预先提供 action table,如果还不行就提交给 sde team 自己解决。 |
13
yamasa 2020-09-29 11:32:56 +08:00
所谓依赖性部署,也很奇怪啊。合理的划分微服务之后,每个 squad 应该自行控制发布周期,一般情况不应该和其他微服务有耦合。每个微服务都应该保证 rolling update,traffic 不能断掉,且尽量做到向后兼容。经常都要一起,且依赖性部署的多个微服务,本身划分就有问题吧?
|
14
xiaket 2020-09-29 11:46:11 +08:00
我们的做法是各个服务的开发负责上线, 自己跑 pipeline 去, DevOps 或者说 SRE 负责审核 pipeline 的改动, 但是不在负责具体上线.
当然我们用的是 Buildkite, 不是我完全不想回头去用的 Jenkins. 两个月推掉了一个 offer, 一个小原因就是他们还是用 Jenkins |
15
sampeng 2020-09-29 12:49:20 +08:00 via iPhone
@whileFalse 依次构建也一样啊。尽可能的并行执行…提高这个速度。部署时间就上来了…不过话说回来。总觉得这一步怪怪的…
|
16
sampeng 2020-09-29 12:50:56 +08:00 via iPhone
@xiaket 我们也一直 jenkins 啊。稳定才是王道…也没啥做不到的功能。你说的对。devops 做不到研发自己上线,这个流程就是没做好
|
17
whileFalse OP |
18
whileFalse OP @xiaket #14 Pipeline 挺好的!我觉得我们应该引入这个玩意儿。我们现在缺自动化测试的功能,流水线能提供;还缺比较优雅的手动批准。
我现在的做法是,运行一次“构建并预览更改”构建镜像并检查变更;没问题的话再运行一次“构建并部署”。第二次会自动跳过已经构建的镜像,不过还是会浪费一点时间,并且不够酷。 |
19
liwl 2020-09-29 14:30:07 +08:00
我们是 Pipeline build 一次 构建镜像一次 推送一次
|
20
xiaket 2020-09-29 17:05:55 +08:00
@whileFalse #17 为啥不在 Jenkinsfile 里面写逻辑直接 trigger 下一个任务的运行? 这样等着不是很浪费时间吗?
|
21
xiaket 2020-09-29 17:15:40 +08:00
@sampeng 嗯, 国内没有用这种付费服务的习惯, Jenkins 在开源实现里相对算好用的了. 但是实际上国外 CICD 的市场很大, 产品也不少, 都值得看看
|
22
whileFalse OP @xiaket #20 那套玩意儿不是我做的,我来了就有了。另外我不是很了解 jenkins 。
请问如果每次要构建的目标不一样,Jenkinsfile 能很好的处理吗? 比如: 有 a-z 共 26 个服务。本次要上线的是 asdfgh 这几个服务,其中 a 要先于 s 构建,d 要先于 f 构建,其他的可以乱序或并行构建。全部构建完之后一起部署。这种需求 Jenkins 能搞定吗 |
23
weimao 2020-09-29 20:13:32 +08:00
用 helm 管理 k8s 上的所有配置文件
持续集成:bitbucket+drone——git tag 触发 docker build 持续部署:drone 配置 pipeline 实现 docker build 成功后触发 helm 配置更新、k8s 部署 |
24
inhzus 2020-09-29 21:01:57 +08:00 via Android
aone tce 一般都有一套完整的平台管理的(虽然用起来都挺屎
|
25
lidashuang 2020-09-29 21:05:30 +08:00
cd 试试 spinnaker ?
|
26
oneisall8955 2020-09-29 21:20:53 +08:00 via Android
pipeline,线上版本和 qa 镜像版本一致,没有上线部署时间长问题啊,最多上 qa 时候,测试等久一点
|
27
firefox12 2020-09-29 23:09:52 +08:00
|