数年間 Discourse を使用しています。半年ごとに新しいインスタンスをセットアップしています。私のセットアップには Docker と nginx ベースのプロキシが含まれているため、おそらく少し標準的ではありません。このため、discourse-setup は使用していません。
半年ごとにこのプロセスを繰り返すとき、Discourse を Git から新規コピーをクローンし、./launcher bootstrap app を実行した後、コンテナが起動しません。ログには次のように表示されます。
anacron: /var/spool/anacron に chdir できません: ディレクトリが存在しません
run-parts: /etc/runit/1.d/anacron はリターンコード 1 で終了しました
run-parts: /etc/runit/1.d/00-ensure-links を実行中
run-parts: /etc/runit/1.d/00-fix-var-logs を実行中
run-parts: /etc/runit/1.d/01-cleanup-web-pids を実行中
run-parts: /etc/runit/1.d/anacron を実行中
anacron: /var/spool/anacron に chdir できません: ディレクトリが存在しません
無限に続きます。
その後、通常は再ブートストラップ、再起動、プラグインの削除、再追加など、多くの手順を実行してようやく機能するようになりますが、最終的に何が機能したのかは決してわかりません。6 か月後に同じことが再び起こります。修正するためだけに作業しますが、その時に行った多くの手順のどれが最終的に機能したのかは明らかではありません。
今回、ようやく問題を見つけたと思います。それは次のとおりです。Discourse が再クローンされ、再ブートストラップされた場合でも、./launcher start app は app という名前の古いコンテナインスタンスを再起動するようです。
不足している手順は docker remove app です。要約すると次のようになります。
./launcher stop app
docker remove app
... これで再クローン、再ブートストラップ、launcher start app が機能します
私の間違いは、./launcher bootstrap app を実行した後、次の ./launcher start app が新しいコンテナイメージを開始すると期待していたことですが、そうではないようです。当然、/var/discourse/shared パスが再初期化されているため、古いコンテナは混乱します。
同じログエラーメッセージを検索する他の人のために、ここに残しておきます。
可能な改善策として、コンテナが /var/discourse/shared ディレクトリが変更されたことを検出できれば良いでしょう。
「いいね!」 2
pfaffman
(Jay Pfaffman)
2025 年 1 月 14 日午後 9:56
2
ブートストラップを実行したい場合、「discourse way」は以下のようになります。
./launcher bootstrap app
./launcher destroy app
./launcher start app
しかし、コンテナが1つしかない場合は、ほとんどすべての例で示されているように、単に以下を実行しても問題ありません。
./launcher rebuild app
これにより、実行中のコンテナが停止し、新しいコンテナがブートストラップされて起動します。何らかの理由でブートストラップが失敗した場合、通常は ./launcher start app で古いコンテナを再起動できます(説明されているように)。
「コンテナインスタンス」と「コンテナイメージ」の混同が原因だと思います。
例えば、10. Post-Install Maintenance を見ると、次のように書かれています。
Usage: launcher COMMAND CONFIG [--skip-prereqs] [--docker-args STRING]
Commands:
start: Start/initialize a container
stop: Stop a running container
restart: Restart a container
destroy: Stop and remove a container
enter: Use nsenter to get a shell into a container
logs: View the Docker logs for a container
bootstrap: Bootstrap a container for the config based on a template
rebuild: Rebuild a container (destroy old, bootstrap, start new)
cleanup: Remove all containers that have stopped for > 24 hours
このヘルプ出力で「コンテナ」という言葉が使われているほとんどの場合、それはコンテナのインスタンスを指しています。ただし、bootstrap ではイメージを指しています。(./launcher bootstrap は docker commit を使用して、後続のコンテナインスタンスを起動できる新しいイメージを作成します。)これは予期しないことでした(そして、私はナイーブにも現在の app インスタンスにも影響すると想定していました)。
rebuild では、「コンテナ」という言葉は、コンテナインスタンスとコンテナイメージの両方に影響を与える一連の操作を含むため、コンテナイメージとインスタンスの両方を指しています。
そして、cleanup で何を指しているのかは不明です。インスタンスのみが削除されるのか、それともブートストラップされたイメージも削除されるのか?
「いいね!」 1