#ljstudyのDocker勉強会に行ってきた
こんにちは。smallpalaceです。
docker勉強会にいってきたのでその備忘録です。
http://ljstudy.connpass.com/event/6318/
30分ちこく。。
電車で#ljstudyのTLを眺めていたところ、コンテナ走らせるsystemd入りの環境用意してきましたよね的な雰囲気を感じて戦慄しつつ到着しました。
最初はクイックツアーでやってみた系のところのお話の模様
めっちゃ途中からですがすみません。
事前資料：
http://www.slideshare.net/enakai/docker-34526343
http://www.slideshare.net/enakai/docker-34668707
つぶやきまとめ：http://togetter.com/li/682335
以下聞きながらのメモなので色々アレですがすみませんです。上記資料に細かいコマンドは全部書いてあります。
イメージ内にメタデータが埋め込まれる
裏ワザつかうとjson形式でイメージに埋め込まれたメタデータが見られる
コンテナの外でpsするとdockerのデーモンが親のプロセスとしてコンテナ内のプロセスが見れる
docker top コンテナ名でtopが見れる
Dockerfile
自動化の処理ファイル（chefでいうレシピ、Ansibleでいうplaybookみたいな感じか）
ビルドコマンドを叩くと書いた通りにコンテナが立ち上がっていく
完成品がこちらにと。
pid１のやつがいないとコンテナが落ちる。
なのでbashを無限ループで起動する。
手が滑ってexitしても無限ループなので助かる
ふしぎ。
アトミックホスト
ポータビリティについて
カーネルが同じ保障はない
カーネル依存するアプリが微妙な違いで落ちる可能性がある
みんながDocker専用のカーネル使えばいいじゃないという思想で
そういうのを作ろうとしてる
コアOSとかと近い？
本気で使うならそういう標準的なのを考える必要がある
dockerがないときの話
libvirtによるコンテナ作成
いろんな仮想化環境に対応してる
イメージを作る機能はどこにもないので手でやらないといけない
この時代はコンテナに必要なディレクトリだけ作るのが主流だった。
Dockerは丸ごと突っ込む感じに変わった
QA
・カーネルアップデートしたときに問題おきるかどうか
→オープンvzとか昔大変だったらしい。今dockerでつかってるコンテナはふつうのlinuxカーネルで、コンテナに必要な機能がカーネルに含まれてるので大丈夫
微妙な違いで今まで動いてたものが動かなくなる可能性は否定できない
Linuxカーネルの開発者は後方互換性にものすごく注意して開発している
リーナスがそれにすごい厳格で誰かが後方互換性を破壊するようなパッチを開発すると
激怒する。実際問題としてはほとんどないと思われる。
Dockerのtopコマンドが非常に見づらい
SYSTEMDとコンテナが連携する
systemctlでsystemdが管理している一覧がずらっと出るが、
このなかにコンテナIDを持った謎のユニットが作られている
dockerがコンテナを作ったタイミングで、コンテナ内で動かすプロセスをサービスとしてユニットとして管理されてる
後半のDockerをささえる技術
Openstack入門よろしくだそうです。
dockerのコンテナはLinuxカーネルで実現してるそうで
コンテナによって分離されるリソースがいくつかある
プロセステーブルの分離
さっき言ってた、コンテナの外からみると、Dockerの子プロセスだけど
コンテナ内ではinitプロセスに見えるという話
ふつうのリナックスの世界でいくとPID1の一番最初に起動するプロセスは、
他の親を失ったプロセスの親になる
pid1のプロセスが死ぬとシステムが落ちる
コンテナ内も同じなのでpid1相当のプロセスが死ぬとコンテナの存続はできない。
ファイルシステムの分離
chrootと同じこと。
コンテナ外でみると、謎のデバイスが長ったらしいディレクトリにマウントされて、
このディレクトリがコンテナに紐づけられる
コンテナの中は見えないけど外からはいろいろ丸見えである
なのでセキュリティ的にはどうかというのはある
VPSとかだとコンテナ貸出のやつはディレクトリ丸見えというのは知っておいたほうがいい
ネットワークの分離
一つのLinux上にネットワーク設定の空間を複数作る
vethという機能で仮想ニックで実現
ホストLinuxのIPマスカレードででコンテナ外に出ていける
外からダイレクトには来れないので、iptablesでポートフォワーディングが必要
CPUとメモリの分離
linuxのcgroupをふつうに使っている
コンテナに割り当てるグループを作ってなかのプロセスに割り当てる量を制限している
systemctl show コンテナユニット指定
CPUsharesとかMemoryLimitが確認できる
起動中のコンテナに対してsystemctl set-propertyとかで割り当てをダイナミックに変えることも可能
コンテナが使ってるリソース分割の仕組みはここまで
ここからが本番
まじか。ここからより詳細というかマニアックな解説が。
イメージ管理の部分
手元にダウンロードしたイメージをスナップショットとってぽこぽこコピれる
RHELとかFedora版は
devicemapperのThin-Provisioningという機能をつかってる
DeviceMapperとは？
物理デバイスの上にソフトウェアでモジュールかぶせて論理デバイスとして扱う機能
ミラーリングとか暗号化とかいろいろできる
DeviceMapperThin-Provisioningとは
論理デバイスをほぼ無限にいくらでも作れる機能。実態はない。
データを書き込んだ瞬間にデータ用デバイスがブロック割り当てられて消費してく
起動中のコンテナにスナップショットとると保存される
RHEL6からDMThin-Provisioningの機能は入ってる
LVMから使える
lvcreate2回する最初のやつはDMThin-Provisioningのブロックプールとメタデータデバイスつくる感じ
昔からあるやつは差分保存領域が要る感じでテンポラリにしか使えなかった
DockerはLVMは使ってない、ダイレクトにDMThin-Provisioningの機能を使ってる
/var/lib/dockerの下を消すとdockerが初期化される
2つのディスクイメージdevicemapperの下のdetaとmetadataというのをつかって
/dev/loop0と1でthinprovisioningの機能を実現してる
Dockerは独自に管理してる
/var/lib/docker/devicemapper/metadataの下にコンテナIDのファイルがあって
その中はjsonで管理情報が記録されてる
dmthinprovisioningのidとかわかっちゃう。
lsblkというコマンドでpoolの名まえが見える
dmsetupというコマンド、デバイスマッパーの機能をネイティブに呼び出すコマンド
そのコマンドでいろいろ指定して作ったデバイスをマウントすると、
イメージの中身がマウントして見えちゃう
イメージID名のなかにbaseという謎のやつがある
それはDeviceIDが0のやつ
一番最初このデバイスをext4でフォーマットしてる
この中にtarを展開してcentosのイメージを突っ込む
dockerのイメージはイニシャルで10Gなのでできるイメージが全部10Gなる
ほんとは気になってほしいやつ
dataとmetadata
スパースファイルで作ってる
100Gと2Gなくても作れる
パフォーマンスが必要な場合リアルなデバイスを使う必要がある
設定ファイルがないのでシンボリックリンクしないといけない
基本的なネットワーク設定
IPマスカレードで外にでるのでなく
外部と通信したいな
Linuxのコマンドを駆使すると自分で追加した物理nicに直結したオレオレ仮想nic追加できる
vethのゲストとホストを作る
/proc/pid/ns/net/noatarino
というやつがネットワークをいじるためのディスクリプタになってる
なんかすげー
pipeworkというコマンドが公開されてる
コンテナを起動したあとに自分でブリッジ直結するコマンドを打つ
Dockerってネットワーク回りは割り切った形になってる
なのでコンテナどうしを連携させるということはやりづらい（てことはHAの検証は不向きてことかな）
複数の物理サーバ同市のコンテナ連携させるやつでギアディーというんのがあるらしい
実際にプロダクションに投入する場合の運用監視、リソース監視みたいなん
→あんまりアイディアないかも
厳密にcgroupをやるのもできるかもしれないけどデフォだとCPUとメモリくらいしか指定できない
dockerがネイティブにたたいてるんじゃなくsystemd経由でリソースわりあててる？
→たぶんそう。dockderのライブラリの中にsysytemdのがあってそっちを読んでたきがする
コンテナが複数ある場合コンテナ同市で通信する場合どうするのがいいか
→どっかーのオプションでコンテナ間で見かけ上ダイレクトに通信するやつもある
やっつけに見えたのであえて説明しなかった
物理ニックつけて通信するんが今今としてはすなお
外部NWのIPを消費してくのでそこは注意
ツイッターで、VMでもゲストの中身見れるからセキュリティは変わらないのでは
というつぶやきが複数みられた
→VMでハイパーバイザー経由してみるのは結構大変なのでは
ゲストフィッシュとかつかうと簡単
ディスクはたしかに簡単かも
動いてるメモリ空間やプロセスの処理内容に関してはコンテナのが簡単
コンテナの中でプロセスの数が制限ができずLinuxの上限に達してホストが落ちるとか
昔は簡単だったが今はLinxuの開発者が頑張ってできなくなってる
ハイパーバイザーはエミュレーションして見せたいものだけ見せる
のでゲストの中でなんかしてホストに影響させるのはむずい
コンテナは内で変なことしてホストをおっことすのはVMに比べるとやりやすい
コンテナでリアルなマルチテナントするのは難しいと思う
勉強になってすっごい面白かったしお菓子もおいしゅうございました。ありがとうございました。ごちそうさまでした。
またの機会を楽しみにしてます。
では読んでいただいてありがとうございました。またそのうちに。
ていうか明日もあるんだな～。
