Translate

2015年3月5日木曜日

The Docker User Guide: Managing Data in Containers を翻訳してみた



The Docker User Guideの1セクションである

 Managing Data in Containers
 https://docs.docker.com/userguide/dockervolumes/


の範囲だけ翻訳してみました。
もちろん参照する際はAt Your Own Riskでお願いします。

----------

コンテナ内データの管理


いくつかの基本的なDockerコンテナについて紹介し、Dockerイメージがいかにして動作するかだけでなくコンテナ間のネットワーキングやリンクについて見てきました。このセクションでは、内部そしてDockerコンテナ間のデータをいかにして管理することができるかを議論します。

Docker内のデータ管理方法として主に2つの手段に着目します。

  • データボリューム
  • データボリュームコンテナ

データボリューム


データボリュームは、(永続化もしくは共有されたデータのためにいくつかの有用な機能を提供する)ユニオンファイルシステムをバイパスする1つ以上のコンテナの範囲内で特別に設計されたディレクトリです:

  • ボリュームはコンテナが生成されると初期化される
  • データボリュームはコンテナ間で共有や再利用が可能
  • データボリュームへの変更によりディレクトリが作成される
  • データボリュームへの変更にはイメージの更新時は含まれない
  • データボリュームはそのコンテナ自身が削除されても永続している

データボリュームは、コンテナのライフサイクルに独立して、データを永続させるために設計されています。Dockerはそれゆえコンテナを削除した時でも決して自動的にボリュームを削除しません。コンテナによって参照されない"ガーベージコレクト"ボリュームも削除しません。

データボリュームの追加


docker createコマンドやdocker runコマンドに「-v」フラグを使うことで、コンテナにデータボリュームを追加することができます。複数のデータボリュームをマウントするために複数の「-v」フラグを使用することができます。Webアプリケーションコンテナに1つのデータボリュームをマウントしてみましょう。


 $ sudo docker run -d -P --name web -v /webapp training/webapp python app.py

このコマンドは /webappのコンテナ内部に新規ボリュームを生成します。

 注意:
 イメージから生成されたコンテナに対して1つ以上のボリュームを追加するために
 Dockerfile内のVOLUMEインストラクションもまた使用可能です。

データボリュームとしてホストディレクトリをマウント


-v」フラグを使用したボリュームの新規作成に加えて、コンテナ内のDockerデーモンのホストからディレクトリをマウントすることも可能です。

注意:
もしBoot2Dockerを使用するのであれば、Dockerデーモンだけは OSX/Windows ファイルシステムへのアクセスが制限されます。Boot2Dockerは /Users(OSX) もしくは C:\Users(Windows) ディレクトリへの自動共有を試行します。-「docker run -v /Users/:/ ... 」(OSX)もしくは「 docker run -v /c/Users/:/ 」することができます。他のすべての経路はBoot2Docker仮想マシンのファイルシステムからとなります。


 $ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp training/webapp python app.py

上記のコマンドは、ホストのディレクトリ/src/webapp をコンテナの/opt/webappへマウントします。
 

注意:
もし /opt/webapp がコンテナイメージの内部ですでに存在していた場合、コンテナは期待されるマウント動作と一致し続けるために、ホスト上の/src/webappのコンテンツに置き換えられます。

これはテストの際にはとても有効です、例えばコンテナ内へソースコードをマウントして、ソースコードを変更した際のアプリケーションの動作を確認することができます。ホスト上のディレクトリは絶対パスで指定しなくてはなりません。もしディレクトリが存在しないと、Dockerは自動的に作成します。
 

注意:
これはビルドされたイメージのポータビリティや共有を目的としたDockerfileからは有効ではありません。ホストディレクトリはもともとホスト依存であるため、おそらくDockerfile内で指定したホストディレクトリはすべてのホスト上ではおそらく動作しないでしょう。

Dockerはデフォルトでは読み書きボリュームですが、読み込みのみのディレクトリをマウントすることもできます。

 $ sudo docker run -d -P --name web -v /src/webapp:/opt/webapp:ro training/webapp python app.py

ここでは同一の /src/webapp ディレクトリをマウントしていましたが、ro オプションを追加することで読み込みのみでマウント
指定できます。

データボリュームとしてホストファイルをマウント


「-v」フラグで、ホストマシンからディレクトリの代わりに、単一のファイルをマウントすることもできます。

 $ sudo docker run --rm -it -v ~/.bash_history:/.bash_history ubuntu /bin/bash

このコマンドは、ホスト上のbashヒストリを新規のコンテナのbashシェルへ投入します、そしてコンテナから出た際にコンテナ内でタイプしたコマンドのヒストリがホスト側にも反映しています。

 注意:
 viやsedを含むファイル編集のための多くのツールは結果としてinodeを変更します。Docker v1.1.0 以降、以下の様なエラーが発生します。
 "sed: cannot rename ./sedKdJ9Dy: Device or resource busy"
 マウントされたファイルを編集したい場合は、親ディレクトリをかわりにマウントする方法がおそらく最も簡単です。


データボリュームコンテナの新規作成とマウント


永続データを複数のコンテナ間で共有したい場合、もしくは非永続コンテナから使用したい場合、データボリュームコンテナ(Data Volume Container)と名付けられたものを作成してそこからデータをマウントする方法がベストです。

共有ボリュームを持つ新たな名前のコンテナを作成しましょう。このコンテナはアプリケーションが動作せず、「training/postgres」イメージとして再利用されます、このためすべてのコンテナは保存するためのディスクスペースのレイヤとして一般的に使用されます。

 $ sudo docker create -v /dbdata --name dbdata training/postgres

次に「--volumes-from」フラグを使って、別のコンテナの /dbdata ボリュームをマウントすることができます。

 $ sudo docker run -d --volumes-from dbdata --name db1 training/postgres

更に他のコンテナでは:

 $ sudo docker run -d --volumes-from dbdata --name db2 training/postgres

複数の「--volumes-from」パラメータを使って、複数のコンテナから複数のデータボリュームを持ち出すことができます。

db1もしくはdb2コンテナを経由して更に別のコンテナがdbdata コンテナのボリュームをマウントすることによってチェーンを延長することができます。

 $ sudo docker run -d --name db3 --volumes-from db1 training/postgres

もしもとのdbdataコンテナを含む、もしくは以降のコンテナdb1db2を含むマウントボリュームを削除したとしても、ボリュームは削除されません。ディスクからボリュームを削除するには、ボリュームを参照する最後のコンテナに対して「docker rm -v」と明記して実行しなくてはなりません。これを使って更新や、コンテナ間のデータボリュームを効果的に移すことができます。
 

注意:
ボリューム削除のために「-v」オプションを使わないでコンテナを削除する場合、Dockerは警告しません。もし「-v」オプションなしでコンテナを削除したなら、これ以上コンテナから参照できない"dangling(ぶらさがった)"ボリュームとなります。Danglingボリュームは削除が困難で、全体として大量のディスクスペース専有します。我々はボリューム管理の改善に取り組んでおり、リクエスト8484を調べることで進捗を確認することができます。


バックアップ、リストア、データボリュームの移動


ボリュームで実行できるもうひとつの役に立つ機能として、バックアップ、リストア、移動があります。次のような「--volumes-from」フラグを使って対象ボリュームをマウントした新規コンテナを作成することで操作します:

 $ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

ここでは、新規コンテナを用意して、dbdataコンテナのボリュームをマウントしています。そしてローカルホストのディレクトリを /backup としてマウントしています。最終的に、tar コマンドを使って dbdata ボリュームのコンテンツを backup.tar にアーカイブするコマンドを実行します。コマンドが完了すれば、コンテナがストップした場合でも、dbdata ボリュームのバックアップが残ります。

そして、同じコンテナや別に作成したコンテナへリストアすることができます。新規コンテナを作成します。

 $ sudo docker run -v /dbdata --name dbdata2 ubuntu /bin/bash

次に、バックアップファイルの tar をはずしてコンテナのデータボリュームへ格納します。


 $ sudo docker run --volumes-from dbdata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar

適当なツールを使い自動バックアップ、移動、リストアテストを上記の技術を用いることで可能になります。

次のステップ


Dockerの使い方についてより深く学習してきました、次に自動化したビルドや個人のリポジトリを含むDocker Hub上の有益なさービスをどうやって結びつけていくかを見て行きましょう。

Docker Hubの動作へ進む


----------

簡単にいえばマウント元専用のコンテナを作りなさいということらしい。

バックアップ先としてマウントしてデータをtarで集めさせて、コピりなさいよ..か。もうすこし考えて構成設計しないと足元すくわれそう..

0 件のコメント:

既存アプリケーションをK8s上でコンテナ化して動かす場合の設計注意事項メモ

既存アプリをK8sなどのコンテナにして動かすには、どこを注意すればいいか..ちょっと調べたときの注意事項をメモにした。   1. The Twelve Factors (日本語訳からの転記) コードベース   バージョン管理されている1つのコードベースと複数のデプロイ 依存関係 ...