- 主题:借问 mysql redis这些数据存储服务在生产环境一般会打包进docke
之前考虑到容器的IO效率不太推荐
现在似乎大有改善
【 在 m10170783 的大作中提到: 】
: 一般情况下会这样部署吗？
--
FROM 116.233.89.*
至少统一管理方便
比如集群这种复杂场景，docker compose可以一键搞定
【 在 Xjt 的大作中提到: 】
: 拜托，你说的这些都不是优点啊，优点是真正能变成业务上有利益的点，比如系统更稳定了，系统持续性更好，系统可扩展性更好，都是对项目能产生的经济利益有提升的。
--
修改:oldwatch FROM 116.233.89.*
FROM 116.233.89.*
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.*
没准人家是私有云呢？没准人家就是在企业内部搞云原生呢？
【 在 Xjt 的大作中提到: 】
: 除非你是部署mysql cluster（一般也没人这么玩吧？）
: 否则放在docker里的mysql稳定性比paas的差了至少2个9吧？docker里随便一下子没配置好，就被销毁了也说不定。。。这损失是paas贵的那点钱能找回来的嘛。。。
: 而且一个paas的mysql都买不起，我觉得lz应该考虑的是跳槽换个有钱的地方，而不是讨论是否把mysql部署docker里了吧
: ...................
--
FROM 116.233.89.*
还好吧
大企业/组织，IT资源虚拟化这块作的还是比较彻底的
基于这个再作容器化也是顺理成章了
【 在 shocker 的大作中提到: 】
: 其实是你输了。
: 现在大量2b业务尤其是公家的都是私有云（非钱因素），其所为私有的概念其实就是自家机房用vm来建。而且it运维能力之差几近为0，作为开发商最简单的就是每次坏了或者每次发布直接扔一个自己配置管理好（开发商管里）的镜像上去。如果你试图去修改已有部署，叫客户运维做根本不
: 会，你上手去搞各种审批流程走完小一个礼拜过去了。
: ...................
--
FROM 116.233.89.*
早期的事情了，
现在这么多资源砸这么久
应该已经优化的差不离了
【 在 stub 的大作中提到: 】
: 容器有这个问题？没听说啊
--
FROM 116.233.89.*