ホストファイルシステムにDockerコンテナーのコンテンツをマウントする

24

Dockerコンテナの内容を検査できるようにしたい（読み取り専用）。これを行うエレガントな方法は、コンテナのコンテンツをディレクトリにマウントすることです。私は、コンテナ内のホストにフォルダをマウントするのではなく、ホストにコンテナの内容をマウントすることについて話している。

現在、Dockerにはaufsとbtrfsの2つのストレージドライバーがあることがわかります。私自身のDockerインストールではbtrfsを使用しており、/ var / lib / docker / btrfs / subvolumesを参照すると、システム上のDockerコンテナーごとに1つのディレクトリが表示されます。ただし、これはDockerの実装の詳細であり、これらのディレクトリを別の場所にマウントしてバインドするのは間違っているように感じます。

これを行う適切な方法はありますか、またはこれらの種類のマウントをサポートするためにDockerにパッチを適用する必要がありますか？

— dflemstr
ソース

これらをどこか別の場所にバインドするのはなぜ間違っているのでしょうか？

— マイケルハンプトン

1

保管場所は実装の詳細であるためです。Day Dockerが別のストレージドライバーを追加すると、場所が移動します。私はこれを半自動にする必要があり、そのためにパブリックAPIを使用するとよいでしょう。

— dflemstr 14

2

nsenter（またはdocker-enter）を使用して目標を達成することを検討する価値があります。もちろん、コンテナ内の検査コード/ツールをrnuしなければならないという制約があります。

— VladFr 14

Linuxにコンテナの境界を越えてマウントするように指示する方法はありませんか？

— dflemstr 14

@dflemstrはい、あり、--volumes-からちょっとそれを行う、他のコンテナのベースイメージとボリュームからディレクトリの組合を取り付けるように見えますが、この動作は私の知る限り、文書化されていません

— Tarnayカールマン

10

を見てくださいdocker export。

コンテナ内のファイルをすばやくリストするには：

docker export CONTAINER|tar -t

輸出する：

docker export CONTAINER>snapshot.tar
docker export CONTAINER|tar x PATH-IN-CONTAINER

または、ファイルを見るには：

docker export CONTAINER|tar x --to-stdout PATH-IN-CONTAINER
# e.g. 
docker export consul|tar x --to-stdout etc/profile

Docker 1.8はcpをサポートしています：

https://docs.docker.com/reference/commandline/cp/

Usage:  docker cp [options] CONTAINER:PATH LOCALPATH|-
        docker cp [options] LOCALPATH|- CONTAINER:PATH

更新：これを実行するときに、Dockerマシンにsshする必要があります。

— ラクタック
ソース

2

私の画像はかなり大きい（数百MiB）ので、個々のファイルを取得するためにこれを行うとオーバーヘッドが大きくなります。それは毎回数百メガバイトのファイルを作成します。

— dflemstr

@dflemstrは、の行を使用し、tar x PATH-IN-CONTAINER必要なファイルのみを抽出します。

— ラクタク

...しかし、tarアーカイブ全体はまだDockerデーモンで作成され、作成には数分かかります

— ...-dflemstr

@dflemstrはセットアップが何であるかわかりませんが、たとえばdocker export ubuntu|tar -t|grep etc/network3秒かかります。

— ラクタク

おそらく、ドッカーデーモンと同じマシン上で使用すると、ネットワーク転送を行う必要はありませんので、実行している、とubuntu...画像は本当に小さいです

— dflemstr

3

docker commitを使用して、コンテナの現在の状態を新しいイメージに保持し、このイメージからインタラクティブコンテナを開始して内容を検査できます。

ドキュメントから：

コンテナのファイルの変更または設定を新しいイメージにコミットすると便利です。これにより、対話型シェルを実行してコンテナをデバッグしたり、作業データセットを別のサーバーにエクスポートしたりできます。

お役に立てれば。

— エリック・シテール
ソース

2

nsenterを使用して、コンテナー/ネームスペース内で検査プログラム（おそらくコンテナーに既に含まれている必要があります）を実行できます。ただし、コンテナファイルシステムを内部に表示されるようにマウントするには、元のイメージと、すべてのレイヤー（aufの場合）、またはデバイスマッパー、btrfs、および使用される他の（将来の）ストレージエンジンの同等のアクションをマウントする必要があります。おそらく、想定どおりにdockerが作業を行い、nsenterを使用してコンテナ内の検査を行う方が効率的です。

他のアプローチがあります。Docker diffは、元のイメージにあったものではなく、変更されたものを確認したい場合に、そのコンテナーで変更されたファイルを表示します。

永続的で検査可能なデータの場合、おそらくコンテナ内のボリュームに保存し、実際のファイルシステム、純粋なデータコンテナ、または同じコンテナにマウントする方が良いパターンになるでしょうが、それらのボリュームをマウントする検査プログラムで別のコンテナーを起動できること。

— グムスレラ
ソース

1

編集：以下の解決策を試してみましたが、残念ながら実際にはうまくいきませんでした。マウントされたファイルシステムは、コンテナのファイルシステムを正確に反映していませんでした（でもcache=no）。これが根本的な問題なのか、何か間違ったことをしているのかはわかりません。

sshdをdockerイメージにインストールし、それを使用してdockerコンテナーでdocker execsshサービス（/usr/sbin/sshd -D）を実行できます（dockerコンテナーのSSHポート22を公開する必要があることに注意してください）。

次に、docker cpssh公開キーを/root/.ssh/authorized_keysdockerコンテナのディレクトリにコピーします。

最後に、を使用docker inspectしてコンテナのIPアドレスを見つけ、コンテナのファイルシステムをマウントします

sudo sshfs -o allow_other,default_permissions,IdentityFile=/path/to/identityfile  root@xxx.xx.x.x:/ /mnt/my_container

この作業を実際に快適に行うには、スクリプトを作成する必要があります。

— Mnieber
ソース