Docker 安装软件服务时倾向于运行各自依赖的独立容器吗？

[Exp]

标题很难描述清楚，事情是这样的，我打算在群晖上 Docker 同时安装 Miniflux 和 Tiny Tiny RSS ，使用一段时间后看哪个更合适一些。然后看到他俩的安装都是需要依赖 Postgres 数据库，网络上也有各种各自安装的 docker-compose.yml 配置。

然后我想是否可以 Docker 独立安装 Postgres 容器，之后它俩共用同一个容器提供的服务。中间过程中，也是因为自己水平不够吧，没有成功，主要是没有能够成功在建立 Postgres 容器实例之后再添加不同的数据库用户。当然这也算一个此主题贴下的附属问题。

据我有限的理解，Docker 的出现主要是为了解决软件服务部署过程中的不同平台下复杂变化的依赖，而 docker compose 主要是为了将 docker 的部署可配置化以及多容器之间的依赖？不知道我的理解是否有问题。

而我主要想问的是 Docker 部署的原则是不是就是各个服务下的容器及其依赖相互隔离？或者说是无需考虑容器尽可能多的复用？那么这样会产生，一个机器中的 Docker 容器会产生非常多的相同的镜像容器，只不过每个容器都有其特定的服务对象，只在于其配置有所差异？这样是正常的吗？比如说上边我想要安装 Miniflux 和 TTRSS 就会有两个 Postgres 容器产生。或者说是 Docker 部署方式所鼓励出现的吗？

[sunamask]

是两个应用都用到 Postgres ，但不是同一个数据库对吧？

如果是这种情况，应该给每个数据库各自建立独立的容器。相应的 docke network ，docker volume 也应该相互独立。

我理解同一个镜像有复数个容器实例是 docker 应用的常态，反正放在那里也用不了多少系统资源……

[gps949]

是独立还是共用主要取决于业务场景，两者是关联、独立还是互斥。
互斥：绝对要依赖独立；
独立：最好独立分开，把依赖当底层基础设施也不是不行；
关联：应当共用；

像你说的情况，试用相近软件之后可能会需要删掉一个，这种情况应该算介于独立和互斥之间，最好还是依赖各自独立

[iv2usr]

题外话, FreshRSS 更好用

[littleBink]

@iv2usr iOS 端有什么阅读软件能同步 FreshRSS 的标签吗

[cedoo22]

像你这个临时用， 无所谓。
容器化 很重要的一个优势，是 可伸缩性， 你说的复杂依赖没那么重要。
可伸缩就代表着容器要无状态， 数据库很明显基本都是有状态，当然你可以强行将它的容器状态持久化到硬盘上。生产环境 数据库一般不会在容器里。

[Exp]

@sunamask #1 第一句，对的。后边的我明白了，感谢

[Exp]

@gps949 #2 OK ，感谢。现在也是刚刚开始安装各种服务，举目前的两个例子。另外也是看到了 Postgres 本身也有独立的镜像可以建立容器，是想着，可以独立建立一个 Postgres 容器来提供未来的各容器的数据库需求。

再加上我当前尝试没有成功。。。可能目前来看确实各服务建立各自对应的容器会更好，也更贴合 Docker 技术的涉及初衷。

[Exp]

@iv2usr #3 FreshRSS 我原来也搭建过，可能是没有深入去研究吧，肤浅的用了用，感觉它的界面层次有点弄不明白，还有就是刷新策略有点问题，好像是会重复把已读的再次刷新成新的？还有其它一些小问题吧。

所以现在我是打算再试试其它的。

感谢！

[Exp]

@cedoo22 #5 不好意思，有些名词无法理解了，” 可伸缩性“是什么意思？”容器要无状态“是什么意思？”强行将它的容器状态持久化到硬盘上“是做什么操作？”生产环境 数据库一般不会在容器里“又是什么意思？

是跟容器配置中做 volumes 卷挂载相关的概念吗？

确实真真的小白一个，尤其对数据库就更是一无所知了。

还请不吝赐教！😓

[libook]

没有万金油方案，一切都可以按照你的需求来调整。

服务软件提供 docker compose 的目的在于可以让普通用户不需要去关心部署和连接数据库等组件，一键运行一整套可以用的服务。

容器的一种使用思路是不同服务之间互相隔离，不光是服务本身隔离，数据库和中间件等也可以进行隔离，这样就不会在发生故障的时候互相影响，也不会在一个服务受到网络攻击后导致所有服务受到影响。一部分企业应用场景是可以接受每个服务跑自己的单独的数据库服务的开销成本的，来换取这种隔离带来的各种好处，可以更加灵活地调整每台服务器上部署的容器种类和数量（所以出现了 k8s 这种调度工具）。
但你的需求不一定是这样的，比如你无法接受同时运行多个数据库实例所产生的开销，或者不适合你的管理方式，那么你就完全没必要遵循这样的设计惯例。

当你有特殊需求的时候，比如你需要在另一台服务器上跑数据库，又或者是你需要统一管理所有服务的数据库（比如做主从备份会比较方便），你就可以写自己的 docker compose 配置文件，或者使用命令参数直接部署服务容器，然后通过服务配置文件，或者容器环境变量（取决于容器镜像是否提供这种能力）来配置要连接的数据库的地址、用户名、密码。

如果你要用 Postgres ，你就避免不了了解这个数据库的使用方式，包括如何管理用户（角色）和权限，多搜些教程看看吧。

[chinalibra492]

docker 容器本身是倾向于各个应用独立开的，不要公用数据库。因为公用数据库唯一的好处就是省掉那几百兆内存，但依赖的 pg 版本、特性不一致会带来各种麻烦。

[pan20060802]

我理解的 docker 就是减少依赖，有点损耗很正常。

[Exp]

@libook #10 理解，感谢。另外最后一句话，确实如此，简单的搜了一些相关教程配置了一下，没有解决问题。现在看来就分开吧，每个服务有自己独立的数据库比较方便。

[Exp]

@chinalibra492 #11 确实在理。

@pan20060802 #12 嗯，损耗肯定是接受的。且根据目前的硬件设备性能来说，如果不是在购买的服务器上，自己设备上的损耗可以忽略不考虑这个问题。

[iv2usr]

@grahamsa0503 我基本不用标签, iOS 用的 Reeder 5