アプリの再構築ができません: サポートされていないDockerストレージドライバー (btrfs)

インストール
1

サーバーと Discourse のインストールを移行します。
btrfs ファイルシステムを備えた新しいサーバーを使用します。

テストマシンでテストを行っています。すべてのファイルをコピーし、必要なすべてのパーツ (nginx、docker、Discourse 自体) をインストールしました。

ext4 ファイルシステムで試したところ、問題なく動作しました。
しかし今、btrfs フォーマットのファイルシステムで同じことを行うと、「launcher rebuild app」を実行したときに次のエラーが発生します。

Docker インストールでサポートされているストレージドライバーが使用されていません。続行した場合、インストールが破損する可能性があります。
overlay2 が推奨されるストレージドライバーですが、zfs や aufs も機能する場合があります。
その他のストレージドライバーは問題があることが知られています。
「docker info」を実行し、「Storage Driver」行を確認することで、使用しているファイルシステムを確認できます。

既存のサポートされていないストレージドライバーを使用して続行する場合は、
launcher のソースコードを読み、このチェックをバイパスする方法を見つけてください。

明らかに、docker info は btrfs を使用していると述べています。
このフォーラムで、Discourse は一部の Docker ストレージドライバーに問題があり、それが再構築を拒否する理由であると読みました。

btrfs ファイルシステムからファイルを取得できる、Discourse と互換性のある「overlay」またはその他のドライバーに変更する方法はありますか?

Docker をどのように設定すればよいですか?
Discourse コンテナーのみでこれを実行し、Docker の残りの構成はデフォルトのままにしておくことは可能ですか?

ありがとうございます。

2

注意

overlay と overlay2 は現在 btrfs またはその他の Copy on Write ファイルシステムではサポートされておらず、ext4 パーティションでのみ使用してください。

Docker は btrfs の上に overlay2 ドライバーを使用することをサポートしていないため、ランチャーツールの推奨事項が選択肢の範囲となります。つまり、Docker が ext4 でバックアップされているシステムで Discourse を実行し続けるか、ランチャーを修正してストレージドライバーを無視して最善を期待するかです。

お好みのテキストエディタで、以下の launcher スクリプトの行にある exit 1 行をコメントアウトする（行頭に # を追加する）ことで、後者の方法を実行できます。

「その他のストレージドライバーは問題があることが知られています」という点を考慮すると、それを行うことはお勧めしません。

「いいね！」 1
3

迅速なご対応ありがとうございます。

もし私の理解が正しければ、btrfsのようなCOWファイルシステムを使用している場合、dockerは基盤となるシステムファイルにアクセスするために他の代替ストレージドライバーを使用できないということですね。

したがって、discourseがdockerのbtrfsストレージドライバーの使用に問題を抱える可能性があるため、良い解決策はないということになります。

ext4へのロールバックは選択肢にありません。なぜなら、すべての移行は、スナップショット機能とそのデータをクリーンに保つ能力のために、データファイルがCOW btrfsファイルシステムの下に保持されることを確実にするためだったからです。

システムの他の部分でbtrfsを使用しても意味がありません。なぜなら、その主な目的はdiscourseフォーラムへのアクセスを提供することだからです。

COWファイルシステムの保護機能とともに実行できれば素晴らしいので、残念です。

–skip-prereqsフラグを使用する方が簡単です。しかし、本番システムで使用すると危険を伴う可能性があります。
テストマシンで試したところ、今のところ問題なく動作していますが、問題は長期的に発生するようです。

4

--skip-prereqsを使用すると、他にも多くのテストがスキップされるため、言及されているように、再構築を実行する際にさまざまなリスクが生じます。その1行をコメントアウトすることは、btrfsで実行することとリスクの度合いは同じではなく、ランチャーが自己更新するときに自動的にマージされるはずなので、一度変更すればほとんど忘れることができるはずです。

「いいね！」 1
5

はい、ありがとうございます。その点には気づきませんでした。

6

率直に言って、そのメッセージは信頼性の問題として知られていた古いdevicemapperを対象としたものでした。

長年にわたり、私たちはaufsを使用し、最近ではoverlay2ドライバーを問題なく使用しています。もしbrtfsを試したいのであれば、数ヶ月後にここでレポートを作成してください。

「いいね！」 2
7

ありがとうございます。
本番サーバーでそれを実行するのは恐ろしいです。
Dockerドライバーに問題があり、破損したデータを書き込んだ場合、クラッシュしたときにスナップショットやバックアップがあっても役に立ちません。
バックアップにデータを安全に保持する方法があれば、試すことができます…
過去にはどのような問題が発生しましたか？

しかし、最近では、このCOWファイルシステムは非常に役立ちます。スナップショットを取得でき、書き込み中やその他の障害に対するデータの破損から保護され、スペースの追加やデバイスの移動が容易です…

将来的には、Discourseでそれを見ることができれば素晴らしいでしょう。
テストを手伝うことができるかもしれません。テストマシンで実行しています。

8

問題は、ランチャーファイルを編集して、サポートされているDockerストレージドライバーのリストにbtrfsを追加すると、スクリプトを実行したときに、スクリプトがローカルで変更されたため、リモートバージョン（GitHubから）で上書きされると文句を言うことです。
これをどう解決すればよいですか？

9

表示されている正確なメッセージと、再構築のどの段階で発生するかを教えていただけますか？

テストに使用している VM を起動し、行を変更してから再構築しました。ランチャーが自身を更新する時点で、予想どおり git pull を実行し、ファストフォワード マージを実行したため、変更はそのまま残っていました。

更新元のバージョンにはランチャー自体の変更は含まれていませんでしたが、exit 1 行またはその非常に近い行がリポジトリで変更されていない限り、同じように機能すると予想されます。

「いいね！」 1
10

ご返信とご関心をお寄せいただきありがとうございます。
明確にさせていただきます。

ランチャー スクリプトを変更して、btrfs を受け入れ可能な形式の 1 つとして含めました。
check_prereqs 関数で、次のように変更しました。

if ! $docker_path info 2\u003e /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then

最初にランチャーを再構築しようとしたとき、ランチャーがローカルで変更されたというメッセージが表示され、オリジンからファイルをダウンロードするかどうか尋ねられました。

そのため、そのままにして、再構築を行い、その後アプリを起動するために変更する必要がありました。

しかし、本日再度再構築を試みたところ、変更が検出されたものの、苦情はなく、変更は保持されているようです。

ランチャーで最近何か変更されたのか、それとも元々再構築を行わない古いランチャーを持っていて、昨日更新した後（今日）行うようになったのかわかりません。

btrfs でテストしており、すべて正常に動作しているようです。アプリケーションの起動と停止、バックアップの作成など、現時点ではすべて正常に動作しています。

Docker は、btrfs ファイルシステムで実行されていることを検出すると、コンテナのストレージ データ用に btrfs サブボリュームを作成し、btrfs ストレージ ドライバーを使用しているようです。
そのため、Docker コマンド経由でコンテナをクローンしたりスナップショットを取得したりする際に、何らかの最適化を行っているようです。

しかし、ドライバーに何らかの欠陥がある可能性（Docker の実験的なドライバーではないようですし、btrfs での使用に関するアドバイスも見当たりませんでしたし、見つけられませんでした）や、btrfs ファイルシステムで Docker を実行している場合に overlay2 ドライバーを使用して実行するように Docker 情報を変更する方が良いかどうか（可能であれば）わかりません。
理論的には、Docker がファイル I/O の点で他のファイルシステムと変わらないため、btrfs の機能を考慮せずに btrfs ファイルシステムでファイルを作成したり操作したりすることは可能です。

btrfs Docker ストレージ ドライバーの使用経験や、btrfs ファイルシステムで Docker を使用する際に overlay2 ドライバーを構成して使用した経験があれば、ぜひお聞かせください。

11

Docker を btrfs の上に overlay2 ドライバーを使用するように強制することについては、直接的な経験はありませんが、強くお勧めしません。これは明示的にサポートされておらず、overlay2 ドライバーはファイルシステムに関する前提条件を持っている可能性があり、それは btrfs では真実である場合とそうでない場合があり、さまざまな予期しない結果につながる可能性があります。ファイルシステムレベルでの予期しない結果は 絶対に 避けたいところです。

低レベルのファイルシステム操作は、Docker と btrfs ストレージドライバーによって処理されます。それが成熟しており、適切に保守されており、devicemapper のように既知のバグがない組み合わせであれば、うまく機能する可能性が高いです。

Discourse で btrfs がサポートされていない理由は、それが失敗するという予想があるからではなく、それが機能すると人々に伝えるのに十分な情報がないからだと理解しています。

彼らは独自のサーバーを btrfs で実行するインセンティブが（十分に）ないため、その情報を得る唯一の方法は、コミュニティの人々が本番環境で試してみて、長期間使用した後に報告することです。それはまだ起こっていないため、サポートされていません。

将来的にこの状況に陥った場合は、変更をリセットし、更新してから、ランチャーを実行する前に再度変更を適用することができます。

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
「いいね！」 1
12

どうもありがとうございます。

したがって、btrfsファイルシステム上でdockerのoverlay2ストレージドライバーを使用しようとせず、dockerがbtrfsドライバーを使用するようにし、問題なく正常に動作することを期待します。
Docker Storage Drivers | Learn the Different Storage drivers of Docker では、SLE Linuxで推奨されるアプローチであり、公式にサポートされているが、Ubuntuでは推奨されていると述べています。
Debian 10および11は、変更なしでカーネルでbtrfsをサポートし、btrfsパーティションからのブートをサポートします（UEFIパーティションのみ他のタイプである必要があります）。

したがって、十分にテストされていると想定されます。

Rafaelからの回答は、それを使用しない特別な理由がないことを示唆しているようです。問題はdevicemapperにあり、彼らはよく知られたファイルシステムを使用するように要求しました。おそらく、btrfsや他のCOWシステムにそれほど注意が払われていなかった時期でしょう。

試してみます。
使用経験（良いか悪いか）を報告します。
今のところ、スムーズに動作し、ファイルシステムのサイズ変更、デバイスの追加、削除などを簡単に行うことができ、基盤となるデータが正しく、エラーなく維持されるという自信を与えてくれます。
唯一の注意点は、dockerストレージドライバーが十分にテストされていない場合ですが、SLE（長年btrfsをデフォルトのストレージファイルシステムとして実装している）で広く使用されているようです。

「いいね！」 1
13

言っておきますが、BTRFSファイルシステムで本番サーバーを9日間稼働させていますが、全く問題ありません。

以前はテストサーバーでテストしました。
そして、フォーラムをサブボリュームに移動し、ファイルシステムからディスクやスペースを追加・削除しましたが、問題ありませんでした。

使用時間が長くなったらまた報告します。

BTRFSは初心者で、深くは知りませんが、それほど難しくなく、期待通りに動作します。

「いいね！」 2
14

言っておきますが、私たちは1か月近くディスコースをbtrfsファイルシステムで問題なく実行しています。

スムーズに動作します。
Dockerのbtrfsドライバーは完璧に動作するようです。
他の人がbtrfs上でディスコースを実行することをテストし、btrfsサポートがディスコースディストリビューションに統合されると素晴らしいでしょう。

フォーラムを一時停止し、btrfsを使用してスナップショットを取得し（数秒）、再度実行します。
その後、取得したスナップショットの外部バックアップを作成します。

完璧に動作するようです。

テストのために別のマシンにバックアップを復元しましたが、動作します。

その

「いいね！」 2
15

それは素晴らしいですね！PRを送信していただけますか？

16

やってみます。githubはあまり得意ではないので、うまくできるといいのですが。

完了しました。PRを作成しました。うまくできたことを願っています。

「いいね！」 1
17

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