开发人员为什么选择 Docker？
有 Linux Containers (LXC)。有 VM 脚本。你可以创建一个 ISO 安装程序。
LXC 实际上就是容器。
对于系统管理员来说，如果你已经有了带有防火墙等的网络设置，那么这种 Docker 的胡闹是多余且毫无意义的。
我明白这对于那些不知道如何使用 Linux 和保护它的人来说是一个简单的安装，但对于系统管理员来说，学习 Docker 是没有意义的。LXC 和 VM 总是比 Docker 好得多。
对于管理服务器的系统管理员来说，我们在单独的网络中创建 LXC 和 VM。所以，我创建了一个专用的 VM 来运行 Discourse，然后再创建一个 Docker 容器。-_ -
所以现在是一个网络中的网络。一个专用的隔离 VM，仅仅是为了创建一个与一切隔离的 Docker 容器 -_ -
无论是否提供支持，都没有不使用 Docker 的安装指南。没有关于将主机 IP 暴露给容器的指南或帮助。
因为当他们开始开发 Discourse 时，那是当时最好的东西。
如果他们今天这样做，我猜他们唯一会做出的不同之处可能是使用 docker-compose 而不是他们自己定制的 launcher 命令来构建和启动 Docker 镜像。
你上网的方式一定和我不同。根据我看到的一切，大多数管理超过（比如说）5台服务器上软件的人都在使用某种容器来管理事物。越来越多的开发人员在笔记本电脑上使用容器运行软件，以确保所有版本的软件保持一致。
即使在单台笔记本电脑上管理 Discourse/rails/ember 开发环境也颇具挑战性。
这是真的。如果你想要一个可以在没有 Docker 的情况下使用的论坛，那么你不应该使用 Discourse。
Docker 真的那么糟糕吗？
我支持这个。docker-compose 会好 100%，因为我刚看了一个关于 docker 和 docker-compose 的速成班。看起来如果 Discourse 使用 docker-compose，我就可以在无需发帖的情况下解决这个问题。
docker-compose 做了所有繁重的工作，类似于启动器所做的，但使用 docker-compose 我可以轻松配置网络和桥接。
我同意。我确实使用容器。只是纯粹的 LxC 容器。无需额外软件。事情并非如此简单。例如：我的一个服务器有一个青铜套餐，基本上是为开发人员准备的。便宜且设置简单。一旦付款确认，主服务器就会收到一个请求，根据用户的选择创建 lxc 容器或虚拟机，显然需要一个域名或将为服务器（lxc/vm）分配自定义子域名。它还要求用户配置自己的网络，然后该网络无法被主网络访问，反之亦然。它基本上是一个小型 AWS。
对于开发来说，docker 对于笔记本电脑和开发目的来说将是卓越的，可以区分主计算机文件和开发文件，包括网络。
我无法同意也无法反驳，因为我个人没有用 Discourse/rails/ember 开发过任何东西。这超出了我的范围，如果开发人员说它更简单，我无权反驳我不知道的事情。
这是我的问题，我已经对所有可用的论坛软件进行了足够的研究，并使用过其中的一些。
我的选择最终归结为 2 个论坛：
我选择 Discourse 作为各方面最好的论坛软件，并且由于我唯一的 docker 经验是 Nginx Reverse Proxy Manager。
我以为我只需要在 .yml 文件中输入一些我的信息，然后运行 docker-compose up -d。我错了。
我目前遇到的问题是可以解决的，只是需要一些时间来弄清楚。
我拒绝使用 Flarum，因为我在许多平台上都使用过 Discourse，并且无意冒犯其他优秀的论坛软件，但 Discourse 是市场上最好的可用论坛。
也许升级到 docker-compose 会有帮助 
在进行了快速研究、观看了一些 5 分钟指南和 YouTube 视频后。
不，Docker 一点也不差。Docker 非常适合那些使用个人机器进行开发甚至工作计算机的开发人员。由于大多数开发人员不将 Linux 作为他们的主要操作系统，因此创建 LxC 容器并不容易。这时 Docker 就派上用场了。它支持所有主流平台，让开发人员可以轻松协作，而且还有一个好处是不会用不适合主操作系统使用的文件弄乱整个系统。
我其实可以更详细地介绍一下，但最新的 Docker/Docker Compose 对于 Discourse 来说非常完美，因为我看到它需要很多移动部件，而且使用 Docker Compose 可以很容易地将它们捆绑起来。这样，如果出现问题，开发人员就会确切地知道该怎么做。
我有一个关于 Discourse 的想法，但首先我要弄清楚我的安装问题。
这肯定就是原因吧？
为什么你们只官方支持 Docker？
托管 Rails 应用程序很复杂。即使你的服务器上已经安装了 Postgres、Redis 和 Ruby，你仍然需要担心运行和监控 Sidekiq 和 Rails 进程，以及配置 Nginx。使用 Docker，我们完全优化的 Discourse 配置将以一个简单的容器形式提供给你，并附带一个基于 Web 的 GUI，让升级到新版本的 Discourse 变得像点击按钮一样简单。
您不需要启动器，并且可以创建一个定制的 Docker Compose 安装，尽管这需要您付出大量努力。
主要目标不是隔离，而是易于部署……
您不需要隔离容器；您可以在路由桥接网络上运行它，或者在一个拥有属于您内部网络的端口的桥接网络上运行它。前者是我们生产环境的运行方式——请看这里，这是 @mpalmer 的一个视频，解释了它是如何工作的。
如果有人真的想这样做，他们可以遵循 Dockerfile 本身所采取的相同步骤，以获取受支持镜像所使用的所有工具的正确版本。
我们没有指南，因为那将需要有人来维护，而绝大多数想要这样做的人要么：
例如，我知道有些人使用启动器来构建一个镜像，该镜像通过他们自己的工具（无论是 lxc、kubernetes，还是其他什么）进行部署，并且这对他们来说是有效的。
试图（免费）支持所有使用复杂软件的自定义安装版本将是一场噩梦。
Docker 是一个折衷方案。我们的系统并不完美；它随着时间的推移而有所发展，我们当然也感受到了某些积压的重构的痛苦。在 docker-compose 出现之前，我们就已经创建了启动器。
我们打算重构它和/或迁移到 docker-compose，但这目前不是优先事项。
让启动器启动 Discourse 并使用 Nginx Reverse Proxy 所需的 ENV 变量并不难。大多数情况下，你只需将 ENV 添加到 YML 文件中，或者添加到你从 ./launcher start-command app 获取的内容中。
Discourse 刚开始的时候，docker-compose 并没有什么用，甚至可能根本不存在。
我讨厌 Docker（对我来说太简单了，随便哪个小孩都会用，没什么特别的！哈欠）！与其简单地编写代码使其在没有官方 Docker 版本的情况下也能运行……我不明白！甚至官方的方法也不起作用！
而且有些人想要挑战，甚至已经掌握了！对他们来说，Docker 更是个障碍，因为他们还得处理 Docker！
还有什么理由可以使用 Docker？
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.