Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Dockerの裏側を攻める
Search
SuperHotDog
September 09, 2025
0
4
Dockerの裏側を攻める
SuperHotDog
September 09, 2025
Tweet
Share
More Decks by SuperHotDog
See All by SuperHotDog
SigLIP
superhotdogcat
1
91
post-training
superhotdogcat
3
590
研究室紹介用スライド: Unified Memoryを活⽤した効率的な計算⽅法を考えよう
superhotdogcat
0
94
大規模モデル計算の裏に潜む 並列分散処理について
superhotdogcat
1
57
オンプレソロプレイ
superhotdogcat
0
78
CUDAを触ろう
superhotdogcat
0
110
GemmaでRAG を作ろう
superhotdogcat
1
620
Featured
See All Featured
Done Done
chrislema
185
16k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Designing Experiences People Love
moore
142
24k
Music & Morning Musume
bryan
46
6.9k
Typedesign – Prime Four
hannesfritz
42
2.8k
The Language of Interfaces
destraynor
162
25k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
4 Signs Your Business is Dying
shpigford
185
22k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Code Reviewing Like a Champion
maltzj
526
40k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Transcript
Docker Desktop の裏側に迫る ~最後にDocker Container外からContainerをいじる~
$whoami 名前: 犬 何してる人 →本業は学生(修士一年), 今はOSとGPU をしている人なはず X: @takanas0517 最近は研究でPyTorchのソースコードをビ
ルドしている。
今日のお題: Dockerを深く学ぼう 経緯: Job huntingで海外のOS Software Engineerを申し込もうとしたところOSについ ての経験を求められ, 普段の研究以外に仮想化技術のアピールするかってことで, Dockerそのものをいじっていた,
調べていた時の記録をLTにしようと思った 毎度のことで, 間違ってたらすまん, あと可搬性とかオーケストレーションとかみたいなベ ストプラクティスの話はしないです 参考資料: LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術 工学基礎シリーズ オペレーティングシステム Binary Hacks Rebooted ―低レイヤの世界を探検するテクニック89選 Docker実践ガイド 第3版
目次 ・概説 ・Container仮想化の構成要素(not 全て) ・Namespace ・chroot ・cgroup ・MacでのDocker Desktopの構成 ・Containerの外部からContainer内部を破壊してみた
概説: DockerとはLinuxの機能を活かしたプロセス単位の仮想化である ・Dockerの実態はHost OS上で動くプロセス である ・Linuxの機能を使って資源を分離, OSを直接 持たずにあたかも他のLinux Distributionが動 くように動いている
・Linux NamespaceというLinuxの機能 ・プロセスの名前空間を分離する ・どういうことかというと, プロセスから見えるProcess ID, Network, Mount Pointなどを 隔離する
・話していると無限に時間が使えちゃうのでコマンドを実行してさっと見せる Container仮想化の構成要素: Namespace
Container仮想化の構成要素: Namespace デフォルトのLinuxでは/procという擬似ファイルで今起動しているプロセスの情報を見る ことができる。なんかデフォルトだとたくさんある
Container仮想化の構成要素: Namespace 例えば, PID Namespaceを分離させてみる。unshare –fork –pid –mount-procで新し い/procを見てみると...(unshareについては大体こちら) なんと,
あれだけたくさんあったProcess IDが2つに減ってしまった‼ →Docker container内部ではDocker外部のHostのPIDが見えないのはこういうこと 他にもNetworkなどは同じようにLinux Namespaceで分離する
Container仮想化の構成要素: chroot ・Containerの中身は全く別のシステムのファイルシ ステムが見える ・実はこれはHost fileの一部を隔離したものを chrootでrootの位置を変更している ・Linux distributionはkernelは共通でpackage管 理システムやinit
systemなどが違うという違いがあ るので, distributionのfile構成をこぴってくれば良い ・ここまでのunshare + chrootで簡単なcontainer 構成は作れる 工学基礎シリーズ オペレーティングシステム
Container仮想化の構成要素: chroot じゃあalpineを例に中身を見てみましょう wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x8 6_64/alpine-minirootfs-3.15.3-x86_64.tar.gz tar -xvzf alpine-minirootfs-3.15.3-x86_64.tar.gz ls
alpine/ みたことある/以下のファイル構成が見える-> alpineコンテナの際はここをrootにしている
Container仮想化の構成要素: cgroup ・コンテナが暴れすぎないようにプロセスにハードウェアの利用制限をかけるもの ・実はデフォルトのプロセスも何かしらのcgroupに所属している CPU 制御: 割り当てコア数や時間配分の制限 メモリ制御: 最大使用メモリ量の制限、 OOM
キル I/O 制御: ディスクやネットワーク帯域の制御 プロセス数制御 : fork できるプロセス数を制限 ・Containerのハードウェア制限もこのcgroupでかけています
Container仮想化の構成要素: cgroup 大体こんなの, cpuの最大使用率, memory最大使用率などはここに書き込めば設定で きます。→まあ, 直接いじるのは怖いのでDockerはWrapper APIを提供
MacでのDocker Desktopの構成 ・ここまでの話でDockerがLinuxで実装されているのはわかったがあれWindowsとMac は?と思った人もいると思う ・実は, Docker DesktopはLinuxKitの軽量VM上で立ち上がっている。つまるところ, VM 経由
Containerの外部からContainer内部を操作してみた ・Hackしていきます。今回はこのfileをコンテナの外側からいじります。
Containerの外部からContainer内部を操作してみた ・実際のMacの上で立ち上がっているLinuxKit VMにはDocker経由で入る方法が提供 されています。docker run -it --privileged --pid=host justincormack/nsenter1で入りま しょう
・dockerのファイルの実態は/var/lib/docker/volumes/<container name>/_dataにあり ます
実際のデータの置き場所に書き込んでみる
破壊の衝動が抑えられないので実験する 数ヶ月前のLT用のollama volumeが残っていたのでrm -rfで直接削除する すると, データの実態は消えたが, metadata.dbにollama-servers_ollamaのエントリが 残っているのか, Docker Desktop,
Docker CLIでは消えていなかった
つまりどういうこと? ・多分Docker CLIとかはmetadataだけをみているんじゃないかと思う(実際のところ metricsを取るためだけに何回もcontainer file実態の中身をみに行くのは非効率なよう に感じる) ・SSDの故障でContainerデータだけ破壊されて, metadata.dbは無事な場合, Containerのvolumeが無事じゃないことはおそらくDockerの監視だけではわからない場 合がある。metadataが無事だからおそらく無事だろうという障害原因の切り分けができ
ないことがこのことから予測できる。(インフラって難しいね) ・Dockerから提供されているAPI以外でそもそも動かすんじゃない ・みんなも今日の内容を完全理解してOS Software Engineerになろう