Docker 公式フォーラムで最も多くの返信があった投稿の 1 つは、「データ コンテナー内のデータのアップグレード」です。

Docker 公式フォーラムで最も多くの返信があった投稿の 1 つは、「データ コンテナー内のデータのアップグレード」です

matlehmann
私は、ボリューム (/var/data など) に永続的なデータを含むデータを含むコンテナーを持っています。コンテナには、別のコンテナ内のソフトウェアの永続データが含まれています。
ソフトウェアの新しいバージョンの場合、上記の永続データをアップグレードする必要があります (構造またはレイアウトの変更など)。その結果、同じ場所にアップグレードされたデータを含む別のデータ コンテナー (/var/data 内) を作成し、データがそのままの状態で古いデータ コンテナーを保持したいと考えています。
こうすることで、何か問題が発生した場合に備えて、古いデータ コンテナと古いバージョンのソフトウェアを使用できます。
でも、どうすればいいでしょうか？望ましい結果を達成するために必要な手順が私にはわかりませんでした。
docker run -i -t --name temp --volumes-from data -v /upgraded image /upgrade_script.sh のようなコマンドを実行してコンテナをアップグレードできます
しかし後で、アップグレードされたデータを元に復元するにはどうすればよいですか古いデータを上書きせずに場所を確認できますか? docker run -i -t --volumes-from temp image cp /upgraded /var/data を実行すると、古いデータが上書きされます。アップグレードされたデータにはホストにマウントされたボリュームを使用する必要がありますか? それとも、より良い解決策はありますか?

sam
ここで一般的に私は直接ホストにマウントされたボリュームを使用することを好み、データコンテナーのユーティリティを見つけるのに苦労しています。
しかし...データコンテナをコミットしてから画像などを保存できますか?
sven
ああ、docker commit スナップショット コンテナー SAM を使用するという提案も検討してください。素晴らしいです
keeb
私は実際に UNIX パイプのようなデータ コンテナーを使用しています。パラダイムにより自然にフィットするように感じます
docker run -name some_pipe_storage some_container_that_generates_data
docker run --volumes-from some_pipe_storage something_that_operates_on_data
構文、非常に面倒です。非常に強力ですが原始的です。

sven
ボリューム管理ツールとして docker を使った興味深い作業がいくつか進行中です - 彼らは 1.4 に向かって進んでいると思いますので、少し調査してみます。 （Dockerボリュームリストと操作するものがあるでしょう）
おそらくコンテナ内にbackup_dataボリュームを作成してから、データ移行イメージを実行します。データとbackup_dataに接続されたイメージを実行したいと思います - まず最初に実行しますおそらく実行します。データをbackup_dataにコピーしてから、データの移行を実行します。
その後、それぞれのデータバックエンドに接続して古いものと新しいものを実行できます (読み取り専用のバックアップをアタッチする可能性があります?)
これを行うと、直接またはスタイル経由で使用している場合、ホストのセットアップはほぼ同じになるはずですデータコンテナの表現。

matlehmann
あなたの提案は私の最初のアイデアラインですが、プロセスの後、移行されたデータと元のデータは異なるパスに従っており、方法が見当たらないため、私の期待には応えられません。この状況は変化します。 -host ボリュームを別のパスに再マウントすることはできません。データ コンテナからボリュームへのパスは、「--volumes-from」によって継承されたボリューム コンテナの場合でも静的です。
docker run 呼び出しごとにホストボリュームのマウント場所を変更できるため、これはホストボリュームとは異なります。
これらのボリューム管理ツールについて話すことは非常に必要だと思います。私にとって、このデータ コンテナーの Docker のイディオムはむしろ回避策のように思えます。
すみません、「docker commit は素晴らしい」と言っているのですが、それが見えないからですか。少なくともユースケースを把握した上で。私の知る限り、私への docker commit にはコンテナーの現在の状態の新しいイメージが含まれています。これには、永続データを除く、関心のあるすべての OS データが含まれます。

スヴェン
ああ、くだらない。おっしゃるとおり、ボリューム パスは現在静的です。そのため、1 つの手順が必要です
1. /data に既存のデータ コンテナーがあります
2. /mite にある一時データ コンテナーに移行します (元のインストールがある場合)
3. 新しいインストールにデータを移行します アップグレードされたデータ コンテナー/データ (2 番目の移行イメージには元のデータ容量をインストールする必要はありません
@cpuguy83 が新しいツールについて詳しく教えてくれるかもしれません。smile
WRT docker commit - コミットするとき、単一のインクルードではありません。イメージレイヤーでは、コンテナー内で行われたすべての変更を含む新しいイメージレイヤーを作成します (イメージコンテナーの開始時に使用されます)
したがって、ボリュームの代わりにコンテナーを使用する場合は、データを永続化してロールオフします。ロギングなどの場合、docker commit を使用して永続データだけをスナップショット/バックアップすることができます。そして、docker のエクスポートを使用すると、それらのレイヤーを保存できる可能性があります

cpuguy83
そうですね、そのため、私は「commit」に依存しません。イメージをフラット化しない限り、コミットは 127 に制限されます
@matlehmann github.com/cpuguy83/docker-volumes を参照してください
これは完璧な解決策には程遠いですが、当面はかなりうまく機能します

matlehmann
@Sven ご返信と詳細情報ありがとうございます。 「/data にインストールされた新しくアップグレードされたデータ コンテナーにデータを移行する (2 番目の移行イメージには、元のデータ容量をインストールする必要はありません)」のステップ 3 が、現状ではまだ理解できません (docker1.2 と (特別なボリューム コマンドはありません)、コンテナに別のコンテナのボリュームを持たせる方法がわかりません。見たところ、一部がマウントされ、一部がマウントされていないか、または "- -ステップ 2 から移行されたコンテナーに元のデータがマウントされている場合、ステップ 3 のコンテナーはすでにマウントされているため、/mifrated から /data へのコピー操作も元のデータを上書きします。何かを忘れましたか?
「commit」コマンドについてのヒントをありがとう、これについてはもう少し考える必要があります

matlehmann
@keeb これは良いパターンですが、私が見る限りでは機能しません。私が話している問題を解決するには、これらすべての「パイプ」コンテナーは、元のデータを上書きせずに、指定されたパスに異なるデータを持つ別のコンテナーを作成することができずに、「some_pipe_storage」のボリュームを保持します。論点がずれていますか?

sven
では、例を使って説明できるか見てみましょう:
誰かがいくつかの Docker イメージ、webappv10、webappv11、webapp_migratorv10_to_v11 を作成したとします
最初は、すでに実行されています。 1.0 ベースのシステム
docker run -v /data --name datav10 sexybox true
docker run -p 80:80 --volumes-from datav10 --name webv10 webappv10
その後、アップグレードするには、データを要求してアップグレードを提供しました。ステップ 2 を実行していただけますか (ご指摘のとおり、同じディレクトリに 2 つのボリュームを持つことはできません)
docker run -v /migration --name datav10-to-v11 Busybox true
docker run --volumes -from datav10- to-v11 --volumes-from datav10 --name migration webapp_migratorv10_to_v11
次にステップ 3、コピーしたデータを新しいデータ コンテナーに移行し、
docker run -v /data --volumes- を使用して /data ディレクトリにデータを準備します。 from datav10-to-v11 --name datav11 Busybox cp -r /migration /data
次に、バージョン 1.1 の Web アプリケーションを実行します
docker run -p 80:80 --volumes-from datav11 --name webv11 webappv11
追加のクレジットとして、すべてをスクリプト化したほうがよいでしょう。
datav10 から V11 ボリューム コンテナー ステップの追加への更新は、以下の議論によるものです

matlehmann
@sven 詳細な回答をありがとうございます。あなたの考えと時間を感謝します。
ただし、説明した手順は機能しません。これは、ボリュームが「--volumes-from」と同じパスを継承するという前提を覆す、「-v」を使用してボリュームを呼び出します。それが、実際には当てはまらない理由です。 --volumes-from migration --name datav11 Busybox cp -r /migration /data は、元のデータ コンテナ datav10 を上書きします

sam
シンプル ボリューム内のデータ コンテナが好まれるのには特別な理由があります (つまり、簡単です)。理解/処理するため)

sven
私は混乱しています。バッファを移行するために使用する contains/data dils ステートメントから 2 つのボリュームが存在しないように、手順を慎重に作成しました。 v11 コンテナー
@sam - バインド マウントされたボリュームとボリューム コンテナーの間には概念的な小さな違いがあります。同じ 3 つの手順を実行しています。私にとって最大の違いは、バインド マウントがローカルでのみ機能し、それを前提としているということです。あなたにはそのためのディスクスペースがあります (私が持っていたわけではありません)。一方、ボリュームコンテナアプローチは、Docker データパーティションが Docker コンテナを実行するのに十分な大きさであることを前提としており、ローカルで同じように動作します。
docker run -v / を変更した場合。 data ... docker run -v /local/data:/data ... への行、その後、

matlehmann
を表すバインドマウントを使用します @SAM 私は今、バインドマウント（または何でも）の使用に切り替えています正式な用語は、データ コンテナを使用する代わりに「-v /host:/container」) ボリュームを使用することです。これは、私が始めたこのスレッドでリストされている欠点があるためです。データ コンテナの使用は、インターネット上のすべての人によって使用され推奨されている慣用句です。それが「公式の方法」のようです

matlehmann
@sven
?「datav10」には ?"/data" (via -v /data)

?"migration" has ?"/data" (via --datav10 のボリューム)
?"/migration" (`-v /migration' 経由)

?"datav11" には ?"/data" (-v /data 経由)
?"/migration" (経由) --volumes from migration)
?"/data" (via --volumes-from migration)

したがって、「/data」コンテナ「datav11」の 2 つのボリューム定義があります - 私には次のように見えます --ボリューム - 1 つから勝ちます。

sam
@sven AUFS にデータを保存している理由を理解しようとしているだけだと思います。この問題に使用するには間違ったファイルシステムのようです。 BTRFS は問題ありませんが、ログ ファイルや使用する Postgres データベースなどに aufs を選択するのは奇妙なように思えます。データコンテナの仕組みを誤解しているのでしょうか?

@matlehmann 私たちは「ボリューム」を頻繁に使用します。
すべてのログのローテーションと永続化を容易にするために、ホストにマウントされたボリュームを既製のコンテナーに保存します。 (ここにコンテナからストリーミングする別のオプションがありますが、メカニズムは自明ではありません。たとえば、NGINX コンテナを考えてみてください。ログは使用しますか?)
マウントされた GlusterFS ボリュームに一部の構成を保存するため、全体にわたって内容を吸収できます。農場

matlehmann
@sven これは別のスレッドのトピックになります。GlusterFS のセットアップについてぜひお聞きしたいです。 GlusterFS 内の代表ボリュームとして使用できる、すぐに使用できるイメージはありますか? あるいは、どうすればよいですか? GlusterFS の詳細を設定するには

sam
@supermathie が最適ですが、すべて非常に伝統的な方法で設定されており、Gluster をパワーアップするために信頼できる Docker コンテナは使用しません。

sven
OH (*&^、おっしゃるとおりです。
このステップを削除したのはとても賢明だったと思います。
/mite フォルダーを独自のデータ コンテナーに配置する必要があるため、最後のステップ
これを反映するためにサンプルを段階的に更新しました

sven
はい、WRT ファイルシステムで解決すべきことがあります - 私は主に docker で BTRFS を実行しています、インストールも機能すると思います -でも、それでも私はそれらにリンクしてから、上記と同じプロセスを使用します

matlehmann @sven これは試していませんが、意味はありますが、ぎこちないクレイジーチキンダンスですが、うまくいくかもしれません...熱心に。ロールの注文を待っています

スヴェン はい、私は不器用なチキンに焦点を当てています - これらのバージョンでそれを楽しみにしています、そして、グリルチキンレッグは死ぬほど食べます

この記事はから翻訳されていますDocker 公式フォーラム: https://forums.docker.com/t/upgrade-data-within-data-container/205/20

上記は、Docker 公式フォーラムで最も多くの反響があった投稿の 1 つである「データ コンテナーのデータのアップグレード」を、関連する内容も含めて紹介しています。PHP チュートリアルに興味のある友人にとって役立つことを願っています。