yml ファイルの環境変数からバックアップページで実行中のコンテナを指定

[neounix (Dark Matter)]

提案されたプラグイン: discourse-container-names.git

何をしてほしいですか？

バックアップページにコンテナ名（複数可）を表示するシンプルなプラグインを作成してほしいです。以下のような表示を想定しています（例）：

コンテナ名は、yml ファイル内の環境変数から取得する必要があります。以下のように設定します：

アプリケーションノート：

1. コンテナ名は、上記の画像に示されている環境変数から取得する必要があります（例：docker ps からの取得は不可）。

2. データ用コンテナとアプリケーション用コンテナの両方がある場合、データ用コンテナの名前も表示されると幸いです：

• Container: app # 単一コンテナの基本的な例
• Containers: socket-only, data # 2 つのコンテナを設定する基本的な例

3. この要望の理由は、複数のアプリコンテナを実行しているため、管理ページ、特にバックアップページ（最初の画像参照）でどのコンテナが実行されているかを常に確認したいからです。

いつまでに完了してほしいですか？

いつでも構いません。急ぎではありません。Discourse プラグインの専門家にとっては非常にシンプルなプラグインのようです。管理用のバックアップページに「あったら便利な機能」を求めているだけで、自分で作成する意欲がないため、適切な報酬を支払って誰かに作成してもらうことに喜んで協力します！

このタスクに対して提示できる予算（米ドル）はどれくらいですか？

PM でご連絡ください。

このプラグインは、複数のコンテナを実行している他の Discourse システム管理者が、管理パネルのバックアップページで現在実行中のコンテナ名を確認したい場合や、単一モードで実行中のコンテナ名をバックアップページで確認したい人など、Discourse コミュニティ全体に自由に公開されるべきです。

[RGJ (Richard - Communiteq)]

素晴らしいアイデアですね。実際のコンテナ ID も追加するのはどうでしょうか？

コンテナ内からは、以下のようにして取得できます：
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

ありがとうございます。しかし、プラグイン内でプラットフォーム依存のコマンドラインユーティリティを使用して情報を取得する方法は、私の要件では機能しません（以下のコマンドから Docker ID を取得する処理が、当社の Ubuntu 18.04 環境では動作しません）：

# cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

#. (結果なし)

これでも結果は得られません：

# cat /proc/self/cgroup|grep "systemd:/docker"

#  (結果なし)

参考情報（docker ps の出力）：

CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS                  PORTS                               NAMES
63c52bc571b5        local_discourse/socket-only     "/sbin/boot"             28 minutes ago      Up 28 minutes                                               socket-only
631fbabedda9        local_discourse/socket-only2    "/sbin/boot"             26 hours ago        Up 26 hours                                                 socket-only2
123743e12208        mysql/mysql-server              "/entrypoint.sh mysq…"   2 days ago          Up 20 hours (healthy)   33060/tcp, 0.0.0.0:6603->3306/tcp   mysql-man
7a145366268c        registry.unix.com/unix:condor   "/run.sh"                6 days ago          Up 20 hours             3306/tcp, 0.0.0.0:8999->80/tcp      unix
3cc0c90c3e3a        registry:2                      "/entrypoint.sh /etc…"   7 days ago          Up 7 days               0.0.0.0:5000->5000/tcp              hubby
ca7b55fc5a0c        local_discourse/data            "/sbin/boot"             2 weeks ago         Up 8 days                                                   data

つまり、実行中のコンテナ名を指定する文字列は、yml ファイル内の環境変数から取得する必要があります。これにより、情報がプラットフォームに依存せず、複数のコンテナが同時に実行されている場合でも機能します。

例えば、当社は複数の Discourse アプリと他のコンテナを同時に実行しており、docker-cli コマンドを使用しても、必要な正確な情報（リバースプロキシ設定によって決定され、Docker 自体ではなく Web 上で「その瞬間」に実行されているコンテナ名）を取得することはできません。

どのコンテナを表示するかは、リバースプロキシ設定で Unix ソケット名（または公開されたコンテナポート）を変更することで選択します。これにより、ゼロダウンタイムで 1 秒未満でコンテナを切り替えることができます。したがって、コンテナ名は yml ファイル内の環境変数から取得する必要があります。これにより 100% 信頼性が高く、正確になります。

したがって、文字列（コンテナ名、コンテナ ID など）は yml ファイル内の環境変数からのみ取得するという要件です。

コンテナ ID を好む方は、以下のように環境変数に追加することもできます（例）：

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

あるいは：

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

また、私の元の投稿にある通り（私たちが使用したい方法）：

DISCOURSE_APP_CONTAINER_NAME = 'socket-only'
DISCOURSE_DATA_CONTAINER_NAME = 'data'

どの文字列（トークン）識別子（名前、コンテナ ID、またはその両方）を使用するかは、システム管理者（またはビジネス）の要件に基づいて決定されます。

そのため、情報は docker ps のような CLI コマンドや、他の OS（プラットフォーム）依存のコマンドからではなく、メインのアプリ yml ファイル内の環境変数としてハードコードされなければならないと明確に指定しました。

これで私の要件がより明確になったことを願っています。

これをプラットフォームや設定に中立にし、CLI コマンドやシステムコマンドに依存しないようにしたいと考えています。当社のサーバーでは Discourse だけでなく、Dockerized LAMP アプリ、Docker プライベートレジストリなど、他の多くのアプリも Docker で実行しています（上記の docker ps 出力サンプルをご参照ください）。

[RGJ (Richard - Communiteq)]

@neounix

プラットフォームに依存するコマンドラインユーティリティ

おっしゃる通りです！

[neounix (Dark Matter)]

@RGJ

おっしゃる通りです！

@RGJ さん、こんにちは。

一点、追っての考えをお伝えします。

コンテナの識別子（コンテナ ID、名前、またはその両方）を YAML 環境変数としてハードコーディングするアプローチが機能しない極端なケースは、Docker Swarm や Kubernetes（例）のような環境です。なぜなら、これらの環境では負荷や障害に応じてコンテナが動的に生成・破棄されるため、YAML 内で環境変数をハードコーディングしても機能しないからです（私はまだ実際に試していないため、確信を持って断言はできませんが）。とはいえ、現時点では「シンプルなアプローチ」（YAML 内の環境変数）を採用することにします。

いずれにせよ、私はまだ Swarm や Kubernetes を用いて Discourse をデプロイしたことがありません。そのため、その問題は実際に直面した時点で対処するつもりです

この件については非常に慎重に検討した結果、現時点では最も適切な方針は、Discourse の環境変数を YAML ファイル（複数可）にハードコーディングすることだと判断しました。

これらの環境変数をサイト設定として取り込み、管理画面のバックアップページに表示するのは、比較的簡単な作業のはずです。以下は私の簡易的なモックアップです。