使用 launcher 构建的 Docker 镜像在 docker-compose 中

开发
1

I’ve been asked to make a docker-compose file for a discourse project I’m working on to make it as simple as possible for developers and sysadmins we’re working with to fire up a discourse instance to test against.

I’ve read through Can Discourse ship frequent Docker images that do not need to be bootstrapped? and came away the notions that ./launcher was really necessary in order to keep the right versions of software in play, to make installation of plugins seamless and deterministic, and to enable software upgrades via the web UI, all ./launcher was doing was working out the correct command line options to send to docker, using docker-compose to build the image did not work given the complexities involved, and interestingly, that I could just use the docker image created by ./launcher and use that with docker-compose.

I rebuilt the app, copied the final command to launch the instance, converted that to a docker-compose.yml file and started the container. I just have the init scripts to go.

I’m thinking I’d have the scripts … the initial init scripts being accessible in the shared folder and getting using docker-compose run or docker exec to get to the bootstrapping.

Has anyone done this?
Are there any guides as to what subset of scripts need to be run is the base image has already been built?

Cheers and thanks

Keith John Hutchison

Background Research.

I’ve read through install-with-docker-compose and it works well enough … main issues is it’s slightly behind the official release, and there is no command line support for discourse and rails.

I’ve since discovered that adding discourse and rails command line support will be trivial as they are bash scripts.

I’ve read through Beginners Guide to Install Discourse for Development using Docker and I got a local instance of docker running on my Mac.

The main issue here was I had to bootstrap the image which is something I’ve been asked to avoid.

I restored locally after running discourse enable_restore from a staging backup and it looks good.

I’ve investigated bitnami/discourse. It worked … main issues was it was a fair bit behind the official image, quite a bit different with paths and it was slower than Install with Docker compose

2

Yes.

No. The only supported way to run discourse is through launcher. If you do it at other way, you’re on your own. If you use bitnami you will need to get support from them, and I’m pretty sure they provide none

If you have a budget, I might be able to help. My contact info is in my profile.

3

G’day Jay

I wasn’t asking for help with Bitnami … that was just background. It would be too different from the staging environments that uses .launcher.

I’m following the lead from Can Discourse ship frequent Docker images that do not need to be bootstrapped? - #26 by sam which basically said using the output from .launcher is the way to go if you want to use docker-composer.

4

But is it simple if said image ends up not being representative, lags behind official releases and said developers and sysadmins are unable to get support here?

It’s always frustrating for users when tell them their install is completely unsupported, you’re effectively asking for guidance in building another unsupportable install. Do the IndieHosters understand that you/they will be totally on their own with this?

5

I totally agree. That’s why I suggested to our dev lead not to use the bitnami/discourse images, why he asked me to research the best way forward and why I’ve chosen to use the image(s) created by ./launcher as suggested by

So the question for me now is, how to generate the base image(s) using launcher and bring up the environment using compose?

I’ve already tried using the image created by ./launcher rebuild app.
I’m about to look at ./launcher bootstrap app.

6

… bootstrap is called by rebuild so there would be no difference in the resultant image …

7

The image from bootstrap is fine, in fact it is running here on meta, PG is running on AWS RDS, Redis in a dedicated container.

8

I know the image is fine Sam. We’re using it on a staging server. I clearly understand that what is lacking here currently is my knowledge on how to run the scripts required to setup the shared folders within docker-compose.

9

I am super confused at why you would even want to involve compose.

This gives your devs an ultra easy setup path on local:

In production … why would you even think about deploying with compose? In general production container orchestration happens in either scripts or kubernates or some other dedicated production tool.

10

It’s only for testing instances

11

Mainly because I’ve been asked to by our team lead. His argument is when testing … he doesn’t want to rely on sysadmins, or devs knowing how to set up discourse other than doing docker-compose up -d.

12

I agree … I followed the instructions and it didn’t take a lot of time to set up. The main issue I will have is selling the idea of running the scripts

13

I am still not following at all, maybe ask your dev manager to post here explaining why our officially supported docker dev setup is a problem.

14

I asked if Beginners Guide to Install Discourse for Development using Docker would suffice.

The answer was yes.

15

I am not associated with the OP here, but I can tell you why I want a docker compose file rather than a shell script:

  1. Shell scripts tend to not work on Windows.
  2. The shell script requires git, my docker hosts only have a bare OS and docker installed. They are, by design, incredibly lean and bare.
  3. Docker compose files can, with a little work, be converted to docker swarm files which can be run on my infrastructure and managed with docker swarm management tooling.
  4. Every other piece of my infrastructure is managed via docker-swarm tooling. Having a single piece of infrastructure that is an outlier adds a large amount of cognitive overhead that I need to store somewhere and will certainly be lost/forgotten when it comes time to upgrade (every other piece of our infrastructure gets upgrades by just updating image version in docker swarm file).

What I would like to see is a template docker swarm or docker compose file that I can use, which references an image published to Docker Hub, and I can configure by just editing the various swarm file settings.

I haven’t yet tried running the scripts locally to see if I can extract the compose file, but it sounds like that is my best bet to not have Discourse be some oddball outlier in my system. I would prefer if I didn’t need to go run a script just to generate a sample docker-compose/swarm file and if instead I could just see one in docs or a gist or something.

16

我希望能够在独立于生产环境的构建服务器上完成所有 Docker 构建工作。如果 Docker 只是一堆需要在宿主机上运行的脚本，那它的意义何在？

在我的生产主机上，我希望 Docker 以 Swarm 模式运行，并且能够登录我的镜像仓库以拉取所需内容。同时，我还希望能够在三个节点上运行任意容器的三个实例（因此，任何卷或绑定挂载到宿主机的操作都应易于管理）。

我完全愿意在测试服务器上按照 Discourse 官方支持的方式构建和部署。

我所讨论的生产环境 Docker Swarm 集群将包含同一集群中的许多其他产品。

我计划对 Discourse 官方支持的测试服务器上的所有容器执行 docker inspect，将所有预构建的 Docker 镜像推送到镜像仓库，并尝试将其部署到生产环境的 Swarm 集群。

如果成功，我会在这里分享。

我希望将服务拆分为多个容器。据我所见，官方支持的 Discourse 将 Docker 当作虚拟机使用，所有操作都在一个容器内完成（如果必要，如何仅扩展某个组件？）。

也许开源支持的版本故意设计得不兼容编排管理器，以便他们能够承接需要大规模扩展的部署合同。这种模式我完全接受。他们完全有权通过为大型成熟的生产级 Swarm/Kubernetes 系统安装 Discourse 来盈利。

我并非断言这就是他们部分收入的来源，只是在推测。无论实际情况如何都无关紧要，我只是想指出，他们没有任何义务支持除当前官方支持机制之外的任何方案。必须承认，官方支持的方法并不适用于生产级的容器编排集群。

17

我的理解是，这是为了便于支持——CDKC 使用的是开源版本；他们的收入来自托管服务，而这笔收入为他们为官方支持版本提供的免费支持提供了资金。

这里有一份关于拆分容器的指南：Multisite configuration with Docker

我们确实成功地在 docker-compose 下运行了一个实例，因此你所追求的目标肯定是可行的。

18

你们开源了吗？如果能看一些示例就太好了。

19

我们参考了 libre.sh / compose / Discourse · GitLab 的旧版本作为指南。这应该能帮助你上手。

20

你好。
现在是 2020 年 5 月，这仍然是一个极具争议的使用领域。

我查阅了所有能找到的关于 Discourse 当前 Docker 支持的讨论帖，并经历了悲伤的五个阶段——现在我已到了“接受”阶段。

背景：

我们有一个 Docker Swarm 集群，负责运行我们所有网站和业务的全部服务。我不希望为了托管论坛而额外购买或维护新的 VPS。

我只想在这个 Swarm 上部署 Discourse 镜像，使用独立的容器，以便根据需要灵活扩展。但到目前为止，我一直未能成功。这不该如此困难。

我曾在一两个小时内成功部署过比这更复杂但可比的系统，比如 GitLab 和 Sentry。而这是我第三周尝试在 Discourse 上获得一个可工作的解决方案，却依然没有可靠的安装结果。

在我看来：

  • Discourse 功能丰富，已存在多年，拥有热情且技术娴熟的贡献者。
  • Discourse 是容器化的早期采用者，在当时利用现有工具和知识完成了它的工作。
  • 对其实现方式的批评常常引发防御性回应。
  • 针对这一具体问题（即集群编排），多年来许多人曾提出疑问，未来也会有更多人询问，但目前却缺乏明确的指导。
  • Launcher 等工具对于单台 Docker 主机来说没问题，它是一段出色的脚本，适用于常见用例。但我的经验是，用它来创建可移植的镜像以失败告终。

一些令人费解的做法：

  • 对人们提出的合理关切给予被动攻击式的回应，而这些人们只是想完成工作中的一小部分。
  • 坚持认为 Launcher 是唯一可行的方式。
  • 在讨论帖中引用已过时的“文档”，并期望用户花费大量时间阅读这些内容，仅仅为了安装某个软件。

我们可以做得更好。

我的请求与提议：

我愿意花时间与了解 Launcher 工作原理的人合作，共同创建一份逐步指南，说明如何创建可重复使用的独立容器安装方案，并附带视频教程。

谁愿意参与？