V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NeverBelieveMe
V2EX  ›  程序员

生产环境的数据库是否要跟项目一起放 docker 里,使用 docker-compose 一起管理?

  •  
  •   NeverBelieveMe · 2023-09-15 15:32:34 +08:00 · 3370 次点击
    这是一个创建于 440 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我看很多开源的项目都是这么搞的。但是自己工作中遇到的情况都是数据库是单独部署在服务器中的,只有测试环境一类的会自己这么搞着玩。
    想问一下这么做的优势和劣势分别是什么。
    21 条回复    2023-09-16 08:20:21 +08:00
    lm930129
        1
    lm930129  
       2023-09-15 15:35:16 +08:00
    开源项目这样搞是为了方便你启动开发环境。。。。生产环境可以用 docker ,但是大部分应该都不是开源项目的 docker-compose 那样写的,比如你启动的 MySQL ,密码一般不直接写在 docker-compose 里面。
    总结下就是,可以用 docker 部署,一般和开发环境会有一定的区别。分开部署是为了避免一锅端。
    hidemyself
        2
    hidemyself  
       2023-09-15 15:39:43 +08:00
    数据库应该不放在 docker 里面吧
    NeverBelieveMe
        3
    NeverBelieveMe  
    OP
       2023-09-15 16:02:41 +08:00
    @hidemyself #2 我看了很多说数据库要不要放 docker 里面的文章,一开始也是这么觉得得,但是反对的声音越来越多,太坚定了。。。
    NeverBelieveMe
        4
    NeverBelieveMe  
    OP
       2023-09-15 16:04:44 +08:00
    @lm930129 #1 生产数据使用 docker 部署要注意哪些方面,方便说一下吗。
    NeverBelieveMe
        5
    NeverBelieveMe  
    OP
       2023-09-15 16:05:45 +08:00
    @NeverBelieveMe #3 上面打错了,最后是不太坚定了
    lm930129
        6
    lm930129  
       2023-09-15 16:30:06 +08:00
    我觉得是可以的,但是我不是专业的 dba ,其实不太有发言权。我觉得可能看项目规模吧,不大的也没啥影响。说是可能会有点性能问题吧。我经历的一些中小型项目,都是直接 docker 的,但是这个不能说明用 docker 就真没有问题。
    yinmin
        7
    yinmin  
       2023-09-15 16:31:22 +08:00 via iPhone
    数据库放容器里,要把配置文件和数据库文件都放宿主机上,做到容器无状态,可以做到任意摧毁/重建容器。对于容器的 cpu 和内存限制,数据库配置文件限制和 docker 限制要内外匹配。
    yinmin
        8
    yinmin  
       2023-09-15 16:32:22 +08:00 via iPhone
    另外,数据库应该是单独的 compose 管理,要和应用的 compose 分开。
    anubu
        9
    anubu  
       2023-09-15 16:50:07 +08:00
    不要被生产环境四个字迷惑了,不同公司的生产环境的差异很大。没什么负载的项目,是用 Docker 跑数据库,做好数据持久化和备份,一般也没什么问题。重负载的项目,整个 DBA 团队恨不得调优再调优,你让他们再套一层容器也不太现实,除非真的有什么运维管理上的特别收益。
    cexll
        10
    cexll  
       2023-09-15 16:56:23 +08:00
    我们都知道虚拟化,容器化 会损耗一定性能,但是容器相比前者损耗很小,但是在 io 处理上,你将数据库的文件映射到本地,其中的映射 io 消耗自己需要测试一下到底大不大,其二就是数据安全隔离,容器大多数都是运行无状态的服务,容器更新 回滚 不用担心自己还有挂载了一个数据在本地 导致数据错乱的问题
    Worldispow
        11
    Worldispow  
       2023-09-15 17:01:53 +08:00
    docker 跑 mysql 启动很简单,但调优什么的就很麻烦,有时调到一半甚至发现原来的 docker 封装方式有问题,不支持某个参数调整,还需要重新写 dockerfile 。。。。
    shimc
        12
    shimc  
       2023-09-15 20:38:43 +08:00
    生产环境的话,我们公司目前都是 docker 容器无状态,集群中随便一台机器都可以启动。 数据库单独部署,或者云服务商的
    me1onsoda
        13
    me1onsoda  
       2023-09-15 20:46:02 +08:00
    我认为,数据库玩意就应该单独部一台,很多 io 型应用比如 es, kafka ,数据库,一台宿主机一锅炖,就是互相拖累
    chendy
        14
    chendy  
       2023-09-15 21:02:29 +08:00   ❤️ 1
    看场景看需求,如果对性能不敏感,对稳定性不敏感,虽然怎么整都行
    容器化的好处是快速部署动态扩缩,数据库对这个特性要求不是很高
    反倒是数据库对 IO 和内存有要求,和应用放一起互相抢资源抢的不亦乐乎…
    MeteorCat
        15
    MeteorCat  
       2023-09-15 21:05:59 +08:00 via Android
    没见过 MySQL 放 docker ,正式应该都是买单独部署云服务吧
    kkanwo
        16
    kkanwo  
       2023-09-15 22:33:08 +08:00
    小项目与测试可 docker ,其它则 RDS 或者物理机。
    ZeroDu
        17
    ZeroDu  
       2023-09-15 22:58:18 +08:00   ❤️ 1
    mysql 放到 docker 里面,数据挂载出来。之前遇到过,移动目录后跑不起来了的情况
    billzhuang
        18
    billzhuang  
       2023-09-15 23:07:22 +08:00 via iPhone
    “ 很多开源的项目都是这么搞”,能否举几个例子
    eDeeraiD0thei6Oh
        19
    eDeeraiD0thei6Oh  
       2023-09-15 23:26:24 +08:00
    我的生产环境就是 这样。唯一不满意的地方就是 DB 数据大,想换机器麻烦。不过一部分在 aws 上的没问题
    studyrun
        20
    studyrun  
       2023-09-16 00:45:13 +08:00
    数据库基本都是单独的机器,上云基本都是买的服务商的数据库实例,主从分离和扩容直接给你弄好了。测试环境是不是 docker 无所谓,docker 升级数据库版本更方便,但绝不是 docker-compose 管理。开源的项目这么搞是为了方便一键部署,不是非得用他提供的 docker-compose.yml ,完全可以自己修改
    GoodRui
        21
    GoodRui  
       2023-09-16 08:20:21 +08:00 via Android
    @billzhuang jumpserver 。我司一个大项目中购买的 jumpserver 就是全 docker 一把梭,数据库 redis 全都是容器化的。部署起真的方便,tar 包一解压,一键安装脚本一运行,连 docker 环境都给你离线安装上。当然堡垒机这种应用,负载应该不会太高吧。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1232 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 18:26 · PVG 02:26 · LAX 10:26 · JFK 13:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.