Tag: root

Dockerのむずかしいところ

未だに思想がわからない.

 

Dockerまわり

コンテナのライフサイクル

コンテナには,存在しない/停止中/起動中の3パターンの状態があり,この状態に依ってコマンドの挙動がかわる.ややこしい.

run
指定した名前のコンテナが存在しない場合,イメージからコンテナを作成する.
指定した名前のコンテナが存在する場合,古いイメージのまま起動する.
指定した名前のコンテナが起動中の場合,なにもしない.

start
指定した名前のコンテナが存在しない場合,起動できない.
指定した名前のコンテナが存在する場合,起動する.
指定した名前のコンテナが起動中の場合,なにもしない.

起動中のコンテナを新しいイメージで立ち上げ直したい場合,
停止(kill or stop)→削除(rm)→立ち上げ(run)を行う必要があるので注意する.

https://fa-works.com/blog/visualizing-docker-containers-and-images

exec

コンテナが出すメッセージが読みたい場合,-itを付ける.ホストのSTDIN,STDOUTと接続する.
読みたくない場合,何もつけない.
バックグラウンドで実行したい場合,-dをつける.

http://qiita.com/RyoMa_0923/items/9b5d2c4a97205692a560

 

パーミッション

結論として,完全自動のバッチ処理を行うコンテナを作りたい場合,dockerの中では一般ユーザーを作らないほうがいい.
理由はdocker cpによってコピーしたファイルのオーナーがrootになるため.
ホストから与えた入力ファイルはオーナーがrootのため一般ユーザーが触ることができない.
触りたい場合一般ユーザーでchownすることになるが,root権限を要求され,パスワード入力が必要となり自動化できない.
sshの暗号鍵などもchmodする必要があるが同様の理由で大変.
回避方法として,①Docker buildした後ある程度手作業をしてcommitしたイメージを使う②一般ユーザーにroot権限を与える
の二つがあるが,どちらも非常に面倒臭いので全てrootで実行する方が楽.

ネットワーク

コンテナ郡は仮想ブリッジdocker0を介してホストとつながる.
ホストから見て,コンテナは172.17.x.xとかにいる.
コンテナから見ると,ホストは192.168.x.xとかにいる.
ホストのローカル127.0.0.1で立ち上げたファイルサーバーとかは,コンテナから192.168.x.xでアクセスする.

http://qiita.com/Arturias/items/b538e6bbf05dd3364397

その他のTips

docker execとコンテナ内でのバックグラウンド実行

docker exec nohup cmd1 &
docker exec nohup cmd2

のようなケースを考える.cmd2の実行時にcmd1がバックグラウンドで動作していることを期待するが,そうはならない.
期待した動作を実現するためには,

docker exec bash –c ‘cmd1 & cmd2’

のようにする.どうやらexecが終了すると,サービスなどは全て終了すると考えて良さそう.
環境変数の設定も同様で,逐一実行時に与えるか,dockerfileのENVで記述してしまうのが良い.

なお,docker exec –d でどういう結果になるかは未調査.