- 主题:借问 mysql redis这些数据存储服务在生产环境一般会打包进docke
至少统一管理方便
比如集群这种复杂场景，docker compose可以一键搞定
【 在 Xjt 的大作中提到: 】
: 拜托，你说的这些都不是优点啊，优点是真正能变成业务上有利益的点，比如系统更稳定了，系统持续性更好，系统可扩展性更好，都是对项目能产生的经济利益有提升的。
--
修改:oldwatch FROM 116.233.89.*
FROM 116.233.89.*
如果是部署在云上，paas的资源也可以写脚本一键搞定啊
而且谁没事天天部署新的mysql server？就算部署新的mysql server，部署才占多少工作量，后续新旧系统的data migration和cut over才是占99%的工作量吧，何况mysql server需要的就是稳定性，我不信放docker里能比阿里云mysql RDS稳定。。。
【 在 oldwatch 的大作中提到: 】
: 至少统一管理方便
: 比如集群这种复杂场景，docker compose可以一键搞定
:
--
修改:Xjt FROM 211.144.19.*
FROM 211.144.19.*
PaaS很贵的，
有成熟运维体系的话直接买实例搭环境不算稀罕
有docker/k8s的话，一堆东西原样搭起来也就是几个脚本而已
【 在 Xjt 的大作中提到: 】
: 如果是部署在云上，paas的资源也可以写脚本一键搞定啊
: 而且谁没事天天部署新的mysql server？就算部署新的mysql server，部署才占多少工作量，后续新旧系统的data migration和cut over才是占99%的工作量吧，何况mysql server需要的就是稳定性，我不信放docker里能比阿里云mysql RDS稳定。。。
--
修改:oldwatch FROM 116.233.89.*
FROM 116.233.89.*
除非你是部署mysql cluster（一般也没人这么玩吧？）
否则放在docker里的mysql稳定性比paas的差了至少2个9吧？docker里随便一下子没配置好，就被销毁了也说不定。。。这损失是paas贵的那点钱能找回来的嘛。。。
而且一个paas的mysql都买不起，我觉得lz应该考虑的是跳槽换个有钱的地方，而不是讨论是否把mysql部署docker里了吧
【 在 oldwatch 的大作中提到: 】
: PaaS很贵的，
: 有成熟运维体系的话直接买实例搭环境不算稀罕
: 有docker/k8s的话，一堆东西原样搭起来也就是几个脚本而已
: ...................
--
FROM 211.144.19.*
没准人家是私有云呢？没准人家就是在企业内部搞云原生呢？
【 在 Xjt 的大作中提到: 】
: 除非你是部署mysql cluster（一般也没人这么玩吧？）
: 否则放在docker里的mysql稳定性比paas的差了至少2个9吧？docker里随便一下子没配置好，就被销毁了也说不定。。。这损失是paas贵的那点钱能找回来的嘛。。。
: 而且一个paas的mysql都买不起，我觉得lz应该考虑的是跳槽换个有钱的地方，而不是讨论是否把mysql部署docker里了吧
: ...................
--
FROM 116.233.89.*
你赢了。。。
【 在 oldwatch 的大作中提到: 】
: 没准人家是私有云呢？没准人家就是在企业内部搞云原生呢？
:
--
FROM 211.144.19.*
为啥，放在k8s里，用pv，mysql很稳定，还自带ha
性能，一般的业务系统基本都满足，
【 在 Xjt 的大作中提到: 】
: 除非你是部署mysql cluster（一般也没人这么玩吧？）
: 否则放在docker里的mysql稳定性比paas的差了至少2个9吧？docker里随便一下子没配
: 置好，就被销毁了也说不定。。。这损失是paas贵的那点钱能找回来的嘛。。。
: 而且一个paas的mysql都买不起，我觉得lz应该考虑的是跳槽换个有钱的地方，而不是
: 讨论是否把mysql部署docker里了吧
: ...................
--
FROM 119.139.199.*
其实是你输了。
现在大量2b业务尤其是公家的都是私有云（非钱因素），其所为私有的概念其实就是自家机房用vm来建。而且it运维能力之差几近为0，作为开发商最简单的就是每次坏了或者每次发布直接扔一个自己配置管理好（开发商管里）的镜像上去。如果你试图去修改已有部署，叫客户运维做根本不会，你上手去搞各种审批流程走完小一个礼拜过去了。
没办法的办法，当然不是说是最优解，不过是土解罢了。至于为什么要是xx技术呀，这些都是一些扯淡的事情和话语罢了，不要深究也没必要究。反正等2-3年以后系统新做就行了
【 在 Xjt 的大作中提到: 】
: 你赢了。。。
--
修改:shocker FROM 119.130.231.*
FROM 119.130.231.*
还好吧
大企业/组织，IT资源虚拟化这块作的还是比较彻底的
基于这个再作容器化也是顺理成章了
【 在 shocker 的大作中提到: 】
: 其实是你输了。
: 现在大量2b业务尤其是公家的都是私有云（非钱因素），其所为私有的概念其实就是自家机房用vm来建。而且it运维能力之差几近为0，作为开发商最简单的就是每次坏了或者每次发布直接扔一个自己配置管理好（开发商管里）的镜像上去。如果你试图去修改已有部署，叫客户运维做根本不
: 会，你上手去搞各种审批流程走完小一个礼拜过去了。
: ...................
--
FROM 116.233.89.*
【 在 Xjt 的大作中提到: 】
: 不太懂，这么做的意义何在？。。。
: 你要是redis和ES之类，我还能理解。
k8s，dicker-compose一键部署
--
FROM 123.126.3.*