docker-compose でビルドされた Docker イメージのランチャーを使用する

開発
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 を使う必要があるのでしょうか？

本番ホストでは、Docker を Swarm モードでインストールし、必要なイメージをプルするために Docker リジストリにログインできるようにしたいと考えています。また、任意のコンテナを 3 ノード上で 3 インスタンス実行できるようにしたいと考えています（そのため、ホストへのボリュームやバインドマウントは容易に管理可能であるべきです）。

ステージングサーバーでは、Discourse が公式にサポートする方法でビルドおよび実行することに全く問題ありません。

ここで話している本番用の Docker Swarm クラスターには、同じクラスター上で多数の他の製品も含まれます。

私は、Discourse の公式にサポートされているステージングサーバー上のすべてのコンテナを docker inspect し、事前にビルドされた Docker イメージをすべてレジストリにプッシュし、それらを本番の Swarm クラスターにデプロイしようと考えています。

もし実現できれば、ここで共有します。

コンテナを複数のコンテナに分割したいと考えています。私が確認した限りでは、公式にサポートされている Discourse は Docker を VM のように扱い、すべてを 1 つのコンテナ内で実行しています（必要に応じて 1 つのコンポーネントのみをスケーリングするにはどうすればよいのでしょうか？）。"

もしかすると、オープンソース版のサポートバージョンは、オーケストレーションマネージャーとの互換性を意図的に排除しているのかもしれません。そうすることで、大規模なスケールを必要とするデプロイを管理するための契約を獲得できるからです。このモデルは私にとっても問題ありません。彼らが大規模な既存の生産環境向け Swarm/Kubernetes システムに Discourse をインストールして収益を得る権利を有していることは当然です。

彼らの収入の一部がそのような方法で得られているとは言っていません。単なる推測に過ぎません。彼らが実際にそうしているかどうかは重要ではなく、彼らが現在サポートしているメカニズム以外のものをサポートする義務が全くないことを指摘しているだけです。サポートされている方法は、生産環境向けのコンテナオーケストレーションクラスターに対して友好的ではないことは認められるべきです。

17

私の理解では、これはサポートの容易さのためです。CDKC はオープンソース版を使用していますが、収益はホスティングから得ており、それが公式サポート版への無料サポートの資金源となっています。
コンテナを分割する方法については、こちらにガイドがあります Multisite configuration with Docker
私たちは docker-compose 下でインスタンスを起動することに成功しましたので、目指していることは確かに実現可能です。

18

オープンソース化されましたか？いくつかの例を見られると嬉しいです。

19

libre.sh / compose / Discourse · GitLab の古いバージョンをガイドとして使用しました。これで始められます。

20

こんにちは。
2020 年 5 月現在でも、これは依然として非常に議論の余地のある利用領域です。

現在の Docker における Discourse のサポートに関するスレッドをすべて読み込み、5 つの悲嘆の段階をすべて経験しました。今はもう「受容」の段階です。

背景:

当社のサイトやビジネスのすべてを運用している Docker Swarm を持っています。フォーラムをホストするために追加の VPS を購入・維持したくありません。

必要に応じて異なるスケーリングが可能になるよう、個別のコンテナで Discourse イメージをデプロイしたいだけです。しかし、これまで失敗し続けています。これほど難しくなるべきではありません。

GitLab や Sentry など、はるかに複雑ながら同等のコードベースであれば、1〜2 時間で実現できました。Discourse の動作するソリューションを得ようと試行錯誤して 3 週間が経過しましたが、いまだに信頼性の高いインストールはできていません。

私の考えでは…

  • Discourse は機能豊富で、長年存在し、情熱的でスキルのあるコントリビューターが多数います。
  • Discourse はコンテナ化の先駆者であり、当時のツールと知識を活用して独自のアプローチを採用しました。
  • その手法に対する批判には、しばしば防衛的な反応が返ってきます。
  • 過去数年間に多くの人々が問い、将来もさらに多くの人々が問うことになるクラスターオーケストレーションに関するこの問題について、明確な指針が欠けています。
  • Launcher などは単一の Docker マシンには問題なく、一般的なユースケースに適した美しいスクリプトです。しかし、ポータブルなイメージを作成しようとした私の経験は失敗に終わりました。

ばかげている点:

  • 単に仕事の小さな一部を完了させようとする人々が提起する正当な懸念に対する、受動的で攻撃的な対応。
  • Launcher が唯一の正しい方法であると主張すること。
  • outdated な「ドキュメント」をスレッドで参照し、人々にインストールするためにその内容を調べるのに時間を費やすことを期待すること。

私たちはこれより良い方法を実践できます。

お願いと提案:

Launcher の仕組みを知っている方と時間を共有し、再現可能な個別コンテナインストールを作成するためのステップバイステップガイド（動画付き）を一緒に作成する用意があります。

一緒に取り組んでいただける方はいますか？