Dockerコンテナーは、意図的に分離された環境です。各コンテナには独自のファイルシステムがあり、他のコンテナやホストから直接アクセスすることはできません。
コンテナがデータを共有する必要がある場合があります。コンテナは自給自足を目指すべきですが、データ共有が避けられないシナリオもあります。これは、2番目のコンテナーが結合されたキャッシュにアクセスしたり、ファイルでバックアップされたデータベースを使用したり、バックアップを作成したり、別のWebサーバーコンテナーを介してアップロードされたプロファイル写真を処理するイメージオプティマイザーコンテナーなどのユーザー生成データに対して操作を実行したりできるようにするためです。 。
このガイドでは、Dockerコンテナ間でデータを渡すためのいくつかの方法について説明します。 Dockerが既にセットアップされており、コンテナー、イメージ、ボリューム、ネットワークなどの基本的な概念に精通していることを前提としています。
ボリュームは、データ共有を設定するための事実上の方法です。これらは、個々のコンテナの外部にデータを保存する独立したファイルシステムです。コンテナ内のファイルシステムパスにボリュームをマウントすると、ボリュームのデータへの読み取り/書き込みアクセスが提供されます。
ボリュームは、複数のコンテナに同時に接続できます。これにより、Dockerによって管理されるシームレスなデータ共有と永続性が促進されます。
開始するボリュームを作成します：
docker volume create --name shared-data
次に、コンテナを作成し、各イメージで予期されるファイルシステムパスにボリュームをマウントします。
docker run -d -v shared-data:/data --name example example-image:latest docker run -d -v shared-data:/backup-source --name backup backup-image:latest
この例では、backup コンテナはexampleに効果的にアクセスできます コンテナの/data ディレクトリ。 /backup-sourceとしてマウントされます;どちらかのコンテナで行われた変更は、もう一方のコンテナに反映されます。
上記の例は、docker runを使用して簡略化できます。 コマンドの--volumes-from 国旗。これにより、既存のコンテナですでに使用されているボリュームを自動的にマウントするメカニズムが提供されます。
docker run -d --volumes-from example --name backup backup-image:latest
今回はbackup コンテナはshared-dataを受け取ります /dataにマウントされたボリューム ディレクトリ。 --volumes-from フラグは、exampleに添付されているすべてのボリューム定義をプルします 容器。これは、メインサービスの補助コンポーネントとして機能するバックアップジョブやその他の短期間のコンテナに特に理想的です。
デフォルトでは、ボリュームは常に読み取り/書き込みモードでマウントされます。ボリュームにアクセスできるすべてのコンテナは、その内容を変更することが許可されており、意図しないデータ損失を引き起こす可能性があります。
コンテナが変更を行うことが予想されない場合は、共有ボリュームを読み取り専用モードでマウントすることをお勧めします。上記の例では、backup コンテナはshared-dataのコンテンツを読み取るだけで済みます 音量。マウントを読み取り専用モードに設定すると、この期待が強制され、イメージ内のバグや悪意のあるバイナリがexampleで使用されるデータを削除するのを防ぎます。 コンテナ。
docker run -d -v shared-data:/backup-source:ro --name backup backup-image:latest
roを追加する -vの3番目のコロン区切りパラメータとして フラグは、ボリュームを読み取り専用モードでマウントする必要があることを示します。 readonlyと書くこともできます roの代わりに より明確な代替手段として。
ファイルシステムボリュームを介したデータ共有の代替アプローチとして、ネットワーク交換を使用できます。 2つのコンテナを同じDockerネットワークに参加させると、自動割り当てされたホスト名を使用してシームレスに通信できます。
docker network create demo-network docker run -d --net demo-network --name first example-image:latest docker run -d --net demo-network --name second another-image:latest
ここでfirst secondにpingを実行できるようになります およびその逆。コンテナはHTTPAPIサービスを実行して、コンテナが相互にやり取りできるようにすることができます。
バックアップの例を続けて、今度はbackup コンテナはhttp://example:8080/backup-dataにネットワークリクエストを行うことができます バックアップするデータを取得します。 example コンテナは、保存する必要のあるすべてのデータを含むアーカイブで応答する必要があります。バックアップコンテナは、アーカイブを適切な保存場所に保持する責任があります。
ネットワーク上でデータ共有が行われるようにすることは、多くの場合、デカップリングの取り組みに役立ちます。最終的には、サービス間に強い依存関係を作成しない、明確に定義されたインターフェイスになります。すべてのコンテナにボリュームへの完全なアクセスを許可するのではなく、データタイプごとにAPIを公開することで、データアクセスをより正確に制御できます。
このアプローチを使用する場合は、セキュリティを考慮することが重要です。他のDockerコンテナによる内部アクセス用に設計されたHTTPAPIには、Dockerホストのブリッジネットワークで公開されているポートがないことを確認してください。これは、上記のネットワークオプションを使用する場合のデフォルトの動作です。 -p 8080:8080でポートをバインドする ホストのネットワークインターフェースを介したバックアップAPIへのアクセスを許可します。これはセキュリティの問題になります。
Dockerコンテナーは、互いのファイルシステムにアクセスできない分離された環境です。それでも、参加しているすべてのコンテナにマウントされるボリュームを作成することで、データを共有できます。共有Dockerネットワークを使用することは、ファイルシステムを直接操作する必要がないシナリオでより強力な分離を提供する代替オプションです。
コンテナ間の相互作用を可能な限り制限することをお勧めします。データ共有が必要な場合は、サービスが緊密に結合されないように明確に定義する必要があります。 別のからのデータに厳密に依存しているコンテナ コンテナは、長期にわたって展開および保守するのが難しい場合があり、コンテナ化と分離の幅広いメリットを損ないます。