ランチャー実行アプリがバックアップ時にエラーを出します

Redisの起動でエラーが発生します。

/var/discourse/launcher run app "echo 'BackupRestore::Backuper.new(Discourse.system_user.id, with_uploads: false).run' | rails c"

rails cのルートを使用するとバックアップは機能しますが、このワンライナーでも機能するはずです。2020年(あるいは-22年だったか…)には機能していました。

そして、私が本当にやりたいことは、データベースダンプを取得し、それをパックしてS3に移動できる場所に置くことです。手動で行いたくはありません。バックアップは自動化される必要があります。また、1日1回では不十分です。何かがひどく悪くなった場合に、24時間分のデータを失いたくないからです。

更新が必要な場合に備えて、参照(2020年)をクロスリンクしておきます。

Redisへの接続についてですか? 実際のエラーメッセージは何ですか?

launcher run app は新しいコンテナコンテキストでコマンドを実行するため、Redis は実行されません。これは Redis が外部にある場合にのみ機能します。

既存のコンテナのコンテキストで実行されるため、以下は機能するはずです。

docker exec -i app rails c <<'BackupRestore::Backuper.new(Discourse.system_user.id, with_uploads: false).run'

例えば、より簡単な discourse backup --sql-only ではなく、なぜ上記を実行しているのですか?

必要であれば、Discourse に直接 S3 をバックアップの保存場所として使用するように指示することもできます。

「いいね!」 2

Dockerやコンテナはひどい場所で、crontabやnanoのようなものが何も機能しないからです😂 分かっているような、分からないような、/var/discourseを見たときに何をするかは分かりますが、./launcher enter appの後では完全に迷子になります。だから私のMastodonサーバーはバックアップされますが、Discourseはそうではありません(まあ、1日に1回はそうですが、それでも)。

はい、discourse backupが私が望むことをしてくれることは知っています。ダンプをS3に送信することさえしますが、それをいつ実行するか分かりません。なぜなら、そのひどくて恐ろしいコンテナの仕組み、つまりOSの中のOSだからです。

コンテナ にスケジューラが利用可能ですよね?

そこにスケジュールできます。例:

# ホストのcrontabに記述
# 4時間ごとに、毎時バックアップを実行
0 */4 * * * docker exec app discourse backup --sql-only
「いいね!」 5

それは非常に簡単だったので、その日はほとんど最大のアンチクライマックスでした。そして今、私は完全に役に立たないawscliを1つ持っています。

docker exec が鍵です…これで、グーグルで検索するための確かなものが1つできました。

ありがとうございます!

「いいね!」 3

ああ、あのエラーですね:

Redisに接続できませんでした
bundler: コマンドの読み込みに失敗しました: pry (/var/www/discourse/vendor/bundle/ruby/3.3.0/bin/pry)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection': Redis on localhost:6379への接続エラー (Errno::ECONNREFUSED) (Redis::CannotConnectError)

そしてその後、すべての行が from で始まり、数えきれないほどの異なる Ruby のものや gem などがあった、1マイルもあるようなリストがありました。あまり興味深いものではありませんでした。

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.