stop/rmが正しい方法です。 ボリューム内のデータは重要である可能性があるため、誤って削除しないようにする必要があります。

おそらくこれをもう少しよく文書化することができます。

このポリシーは、Dockerのベストプラクティスに違反しているようであり、コンテナーの再作成が状態をリークしていた理由のトラブルシューティングに多くの頭痛の種を引き起こしました。 dockerに再作成するように指示した場合、それは「コンテナーの実行全体で一部のデータを保持するが、コンテナー内のプロセスを再開する」という意味ではありません。 それは地球を舗装して最初からやり直すことを意味します。 ボリュームを保存したい場合は、明示的にボリュームをマウントします。 自動マウントされたボリュームがコンテナの実行全体で持続することは決して期待していません。

ボリュームを使用する唯一の理由は、実行間でデータを永続化することです。 永続化されたデータが必要ない場合、なぜそれをボリュームに入れるのですか？

ボリュームを設定していません。 docker-compose.ymlはボリュームが設定されておらず、ボリュームを接続するためにdocker-compose.ymlに何も渡していない。

コマンド：

docker-compose up --force-recreate --abort-on-container-exit --build foo

docker-compose.yml：

version: '2'
services:
  foo:
    build:
      context: .
      dockerfile: src/integration/foo/Dockerfile
    ports:
      - "3306:3306"
      - "33060:33060"

Dockerfile：

FROM mysql:5.7

COPY schema/foo/migration.sql /data/db_schema.sql
COPY src/integration/foo/create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD true

EXPOSE 3306 33060

create_test_db.sh：

#!/bin/bash
set -e
mysql --no-defaults -u root -e "drop database if exists agent_state; create database foo"
mysql --no-defaults -u root foo < "/data/db_schema.sql"

上記を実行した場合は、DBに何かを書き込み、次にSIG_INTを書き込んでから、コマンドを再度実行します。DBに入力したデータは、実行中も保持されます。

これはMySQLイメージの問題です。 ベースにボリュームを作ります
画像。 別のMySQLを使用することで、問題を回避できます。
画像または場合によっては、データに別のパスを使用するように強制します。

2016年10月19日18:36、「MicahZoltu」 [email protected]は次のように書いています。

ボリュームを設定していません。 私のdocker-compose.ymlには何もありません
ボリュームがセットアップされ、docker-compose.ymlに何も渡されていません
ボリュームを接続します。

コマンド：

docker-compose up --force-recreate --abort-on-container-exit --build foo

docker-compose.yml：

バージョン：「2」
サービス：
foo：
ビルド：
環境： 。
dockerfile：src / Integration / foo / Dockerfile
ポート：
-「3306：3306」
-「33060：33060」

Dockerfile：

mysql：5.7から

スキーマ/foo/migration.sql/data/db_schema.sqlをコピーします
コピーsrc / Integration / foo / create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD true

EXPOSE 3306 33060

create_test_db.sh：

！/ bin / bash

セット-e
mysql --no-defaults -u root -e "存在する場合はデータベースを削除しますagent_state;データベースfooを作成します"
mysql --no-defaults -u root foo <"/ data / db_schema.sql"

上記を実行する場合は、DBに書き込み、次にSIG_INTを書き込み、次に
DBに入力したデータは、実行中も保持されます。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/compose/issues/2127#issuecomment -254986952、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAa_RG_pJj0i-OSCfcBlG__8ToFDtGKMks5q1sWlgaJpZM4GHruC
。

うーん、これはDockerコンテナの私の理解に違反しています。 ホストにパスを提供せずにボリュームをマウントするにはどうすればよいですか？ 私の理解では、ボリュームを明示的にマウントしない限り、Dockerコンテナーは一時的なものですか？

ボリュームにはホストパスは必要ありません。 ボリュームには次の3種類があります。

• ホストバインドマウント（ -v /host:/container ）
• 名前付きボリューム（ -v name:/container 、 docker volume create ）
• 匿名ボリューム（ -v /container 、またはVOLUME内のDockerfile ）

mysqlイメージは匿名ボリュームを使用します。 実行時に、コンテナー内のそのパスに別のボリュームを使用するようにコンテナーに指示できますが、そうでない場合でも、匿名ボリュームはそこにあります。

匿名のボリュームは素晴らしいものではありません。 それらは3つの中で最も古いものであり、それらの動作の多くは、下位互換性の理由でのみ保持されるレガシーなものです。

「--recreate-volumes」というコマンドラインオプションがあればいいのですが...

OK、みんな、これが考えるべきケースです：

1）Railsパブリックディレクトリをnginxコンテナに再マウントして、静的なものをnginxから直接提供できるようにします。
2）「匿名」（ホストにマウントされていない、名前が付いていない）ボリュームを/ usr / local / app / app / publicに割り当て、「volumes_from」を介してnginxと共有します
3）「パブリック」コンテンツは、イメージビルドで変更されることがよくあります。トップレベルのファイルだけでなく、サブディレクトリ内の一部のファイル（これは重要です）

現在、コンテナを再作成すると、古いバージョンの「public」になってしまいます。イメージのコンテンツは単に無視されます。 はい、Dockerは不足しているファイルを匿名ボリュームにコピーすることに

そのため、「stop-rm-up」シーケンスを実行するか（本番環境ではそれほど便利ではありません）、別のディレクトリを共有ボリュームとして使用し、アプリケーションコンテナの開始時に明示的に「rsync」を呼び出してデータを入力/更新する必要があります。

匿名ボリュームを親コンテナと一緒に移動させる方法があれば、それは大きな改善になるでしょう。

コード（または静的アセット）にボリュームを使用しないでください。 ボリュームは、デプロイメント間で保持するデータ用です。これは、ここで必要なものとは逆です。 静的アセットを使用してnginxイメージを構築するか、静的アセットを含むWebサーバーコンテナーをプロキシします。

視点をありがとう！ 私はまだこの観点から考えていませんでした。

これは、（まだ進化している）Dockerアーキテクチャの概念的な問題の1つであるようです。 これまでのところ、データボリュームの概念の進化（たとえば、「データコンテナ」から「名前付きボリューム」へ）が見られましたが、おそらくまだ完成していません。

https://docs.docker.com/engine/tutorials/dockervolumes/#/data -volumesを見ると、説明されているほとんどの利点（AUFSのバイパス、共有）が必ずしもデータの永続性に関連しているとは限らないことがわかります（どのボリュームが元々設計されていたか）。

したがって、（私を含む）人々が本来の目的を超えてさまざまな方法でボリュームを使用しようとしているのは当然のことです。 たとえば、多くの明示的なコピーを行わずに、一時的または画像制御されたデータを1つのコンテナから別のコンテナに共有します。

多分いつか私達はそれをするための一貫した標準的な方法を理解するでしょう。 :)これまでのところ、上記のかなり単純な回避策を使用することが可能です。 理想的ではありませんが、アーキテクチャ上の期待が適切に設定されている限り、許容できます。

もう一度、あなたの応答、説明、そしてあなたがしている素晴らしい仕事に感謝します！

私は今日この問題に遭遇しました、ここでの素晴らしい説明のおかげで、私は間違いなく問題を理解するのに役立ちました。

私にとって大きな混乱のポイントは、dockerfileのVOLUMEタグによって、一貫性のある匿名ボリュームが作成されることを理解していたことです。 ドキュメントでそれを見逃したかもしれませんが、それについての言及を見つけることができませんでした。

@dnephin

述べたように@ hleb-rubanau。 RailsとNginxで単一のコンテナーを実行することが解決策ですか？ （このように：https：//docs.docker.com/engine/admin/multi-service_container/？）

ベストプラクティスに違反する必要があります（「各コンテナには1つの懸念事項のみが必要です
"）資産を提供するためだけですか？:(

興味のある人のために、私は次のようになりました：

1）セットアップでは、常にバインドマウント（別名ホストマウント）ボリュームを使用しています。 匿名ボリュームと名前付きボリュームには、考慮に入れるにはあまりにも多くの特別/明白/条件付き/一貫性のない/暗黙のロジックがあります。 はい、それぞれのタイプのライフサイクルと管理の詳細を理解するのは簡単ですが、これらの無関係な違いをすべて気にしないと、アーキテクチャについて考える方が簡単であることがわかりました。 分散FSの場合、Glusterは正常に機能します（Dockerの観点からはバインドマウントされています）。

2）共有ボリュームはバインドマウントされたものであり、アセットがイメージに保存されているディレクトリではありません。 開始時（エントリポイント）でローカルrsyncを実行しているので、イメージのディレクトリのアセットがバインドマウントされた共有ストレージパスにコピー/ rsyncされます。

ありがとう@ hleb-rubanau

とにかく、RancherOSのようないくつかのオーケストレーションツールがそれらのボリューム構成をサポートしているかどうか、またはスケーリングするための正しい方法であるかどうかはわかりません。 最後に、dockerを使用してデプロイするのはより困難です...

私は匿名のボリュームを使用して、ある時点で孤立したものをクリーンアップすることを好みます。

これは私のプロダクションレールスタックです： https ：

これはまた、jenkins / jenkinsイメージをテストしているときに、かなりの混乱を引き起こし、/ usr / share / jenkins / ref内のファイルからの変更が既にコピーされているため、それらを尊重していませんでした。

これはかなり予想外のユーザーエクスペリエンスです。dockercomposeは、すべての目的と目的のために「隠された」ボリュームを作成しています。 通常のdocker runを使用すると、毎回新しいボリュームを取得します。 docker-compose upは何も書かれていないという意味で隠されたボリュームなので、画像が何をしているのかを詳しく知らない限り、掘り下げなければなりません。

少なくとも_非常に_、「ボリュームxを再作成しない」というメッセージを出力して、将来他の人が何が起こっているのか疑問に思って時間を無駄にする必要がないようにする必要があります。

こんにちは@dnephin 、

sudo rm -rf /var/lib/docker/volumes/aa_dbdatavolに電話しましたが、postgres docker-composeをdocker-compose upできなくなりました。

このエラーが発生する

デフォルトのドライバを使用してネットワーク「aa_default」を作成する
aa_postgres_1を作成しています
エラー：postgresの場合サービスpostgresのコンテナを作成できません：そのようなファイルまたはディレクトリはありません
エラー：プロジェクトの起動中にエラーが発生しました。
デーモンからのエラー応答：そのようなコンテナはありません：aa_postgres_1

それを回避するためのアイデアがあるかもしれませんので、共有してください。 ありがとうございました！

https://github.com/docker/compose/issues/2127#issuecomment -347152650

フォルダを再作成するだけで問題が解決します。
/var/lib/docker/volumes/aa_dbdatavol/_data

@dnephinに感謝しあなたの答えは初めて完璧に機能しました。 ムチョスグラシアス。

@dnephinは言った：

ボリュームを使用する唯一の理由は、実行間でデータを永続化することです。 永続化されたデータが必要ない場合、なぜそれをボリュームに入れるのですか？

コンテナ間でファイルを共有します。 ボリュームを使用せずにそれを行うためのより良い方法はありますか？

「ファイル共有」とはどういう意味ですか？

一方のコンテナーがファイルに書き込み、もう一方のコンテナーがそれらの書き込みを確認することを期待していますか？ ファイルシステムは通常、2つのサービス間の適切なインターフェイスではありませんが、その場合は、ボリュームに更新を書き込むことで、サービスの1つにファイルシステムを「管理」させることができます。

「共有」とは、2つのコンテナがたまたま同じファイルの一部を読み取ることである場合、ボリュームは必要ありません。 COPY使用して両方のコンテナにファイルを追加します。

Docker version 18.06.1-ce, build e68fc7aを使用しており、次のコマンドを使用して匿名ボリュームを再作成できます。

docker-compose up -d --build --force-recreate --renew-anon-volumes db

フラグ--renew-anon-volumesが最近追加されたようです

Docker version 18.06.1-ce, build e68fc7aを使用しており、次のコマンドを使用して匿名ボリュームを再作成できます。

docker-compose up -d --build --force-recreate --renew-anon-volumes db

フラグ--renew-anon-volumesが最近追加されたようです

このオプションを許可していただきありがとうございます。