私有化部署太难搞了

2024-03-17 17:47:36 +08:00
 eephee

公司的项目是两周一迭代,中途有客户需要私有化部署的时候,我们会选用上个迭代更新到生产环境的版本,拉取镜像部署给客户。

如何在项目(微服务)的快速迭代开发(两周一迭代)的情况下,保证私有化部署的稳定性?

有的企业会将系统做成镜像,到时候直接拷贝到机器里面,但是两周的迭代太快了,这种方法感觉不太现实....

7200 次点击
所在节点    DevOps
27 条回复
eephee
2024-03-17 17:50:46 +08:00
* 部署时不允许联网,只能自己搞离线软件源,有点带着镣铐跳舞的感觉
kkk9
2024-03-17 17:52:03 +08:00
一个字:拆

把公版和 OEM 版统一的部分拆出来,需要独立修改部分单独出两个分支,发版的时候分别合并测试就 ok 了

然后写一个 OTA 独立工具,就像简单的 CI/CD ,你这边推更新,客户那边自己找时间打开,自动化 update
whileFalse
2024-03-17 17:52:33 +08:00
要不用 Docker 要不用虚机镜像
kkk9
2024-03-17 17:53:17 +08:00
不能 online 就都打包好,只在不行上 docker ,给客户镜像……
whileFalse
2024-03-17 17:53:39 +08:00
还有就是你们自己运行一个私有化部署环境这些问题测不出来吗
eephee
2024-03-17 17:59:12 +08:00
唉,也是,搞一个私有部署环境去测测,谢谢两位
likooo125802023
2024-03-17 19:55:53 +08:00
不如改回单体应用
zhonj
2024-03-17 22:30:29 +08:00
私有化部署项目都是用 docker , 每次就上传一下 docker 包,就完事了简单轻松。然后所有项目都不拆直接 boot 一把梭。mysql redis 啥中间件的能不用就不用。以免出现漏洞又要去升级
TH00
2024-03-17 22:49:30 +08:00
做过上百个服务的私有化部署, 一开始也很乱, 但是搞好标准化后面就很流畅了, 软件源问题很好解决, 打包成本地镜像, 通过 helm 来管理部署
beneo
2024-03-17 22:52:17 +08:00
同面对 私有化部署 加 SAAS ,对团队要求是很高,我给团队定的调: 一套代码,插件定制,持续交付,统一运维。我的建议是,有能力就跟我们一样一套代码,没有的话就两套好了,对于私有化部署版本,按月升级,不要 和 master 离的太远。此外以用代测试,在某些时候也不是不行。
akira
2024-03-17 23:35:46 +08:00
仓库代码 做好分支,打好 tag 应该就好了啊。
jsq2627
2024-03-18 05:50:02 +08:00
同时支持 saas 和私有化部署,要求本来就挺高的

如果是单纯以私有化部署为目标的应用,从最初技术选型就会很不一样,开发、发布流程也可能和 agile 相去甚远。

既然你已经提到了你们是按照微服务开发的,那注定私有化部署不是个容易事了。
如果以私有化部署为目标,一开始就应该选择单体应用。

上工具吧,helm 、terraform 、ansible 等等。如果客户是云环境,那还可以用各大云自己的 IaC 方案,比如 AWS CloudFormation 。相比之下,单体应用就没这么复杂,打个 zip 包丢给客户就行。
jsq2627
2024-03-18 05:53:31 +08:00
后期可能私有化客户还有定制需求,分支管理会更复杂。
securityCoding
2024-03-18 07:23:38 +08:00
微服务太多的话只能合并
cat1879
2024-03-18 08:35:16 +08:00
docker 不就是用来解决开发与生产环境不一致的问题吗?
dayeye2006199
2024-03-18 08:39:35 +08:00
Ansible chef ,最好是代码描述的部署过程。用手弄肯定容易错
layxy
2024-03-18 09:06:34 +08:00
我们也有这个问题,很麻烦,虽然后续需求设计的时候会考虑,但是关联系统更新等产生的兼容性问题要解决起来也很费劲
guanzhangzhang
2024-03-18 09:34:56 +08:00
我部门就是做私有化的,
一开始也是企业版本去适配私有化,但是企业版本的开发说过类似的话:给你们修私有化 bug ,并不算到我们的 kpi ,而且历史原因,企业版本会用到很多中间件,在私有化场景下(硬盘 iops 辣鸡,cpu 内存超分)下,中间件是尽可能的少是最好的(利于维护),且要考虑客户提供中间件的情况,还有业务要支持的中间件模式,例如 redis 集群、主从和哨兵模式以及版本,并不是所有业务都支持各种模式,对象存储客户没有就私有化要部署一个
还有安全:
因为很多客户会扫描,需要部署安全的 agent 之类的
客户让不允许 root 运行容器
数据库初始化,检查工具(检查数据库权限和设置对否),甚至有的客户不让业务进程创建表,你要把所有创建表的 sql 导出来给客户
还有升级,因为是 docker ,升级包如何兼容,sql 兼容升级吗,兼容国产数据库吗
还有肯定要部署监控和日志的
以及没网情况下,你肯定要部署时间服务器,如何兼容每个系统
很多细节问题,需要多次迭代才能发现
Lamkin
2024-03-18 09:50:24 +08:00
“项目在快速迭代的情况下,可能两周前的部署配置,在两周后就不适用了”
这个情况跟我们公司的场景挺像
目前解决的办法就是用 sealos 部署(解决离线部署 K8S 的问题),并且使用 sealos 的方式来制作自己的 helm-charts 镜像(解决多台机器下,每次都要手动导入 docker 镜像的问题,还有各种配置项、环境变量的自动模板渲染)
zoharSoul
2024-03-18 10:43:33 +08:00
润 别找 tob 的公司
找 toc 的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1024486

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX