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
1
Dockerの裏側を攻める
SuperHotDog
September 09, 2025
Tweet
Share
More Decks by SuperHotDog
See All by SuperHotDog
SigLIP
superhotdogcat
1
88
post-training
superhotdogcat
3
580
研究室紹介用スライド: Unified Memoryを活⽤した効率的な計算⽅法を考えよう
superhotdogcat
0
92
大規模モデル計算の裏に潜む 並列分散処理について
superhotdogcat
1
55
オンプレソロプレイ
superhotdogcat
0
77
CUDAを触ろう
superhotdogcat
0
110
GemmaでRAG を作ろう
superhotdogcat
1
600
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
1
27
Unsuck your backbone
ammeep
671
58k
KATA
mclloyd
32
14k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Rails Girls Zürich Keynote
gr2m
95
14k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The Cult of Friendly URLs
andyhume
79
6.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
Producing Creativity
orderedlist
PRO
347
40k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
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になろう