Docker

モダンオペレーティングシステム 第5版 上 第3章中盤（3.3後半〜3.5）。ページテーブルの実装とTLB、ページ置き換えアルゴリズム。 3.3後半 ページテーブルの実装 多段ページテーブル 仮想アドレス空間が64bitの場合、単純なページテーブルは現実的じゃない。 理論上の最大：2^64 = 18,446,744,073,709,551,616 バイト 1ページ = 4KB = 4096バイト ページ数 = 2^64 / 2^12 = 2^52 個 1エントリ = 8バイトとして ページテーブルのサイズ = 2^52 × 8 = 32ペタバイト プロセス1個のページテーブルだけで32PB。話にならない。 実際のx86_64は64bitフルを使わず48bitに妥協している（一部の最新CPUは57bit）。64bitフルを使うと6〜7段の階層が必要になりメモリアクセスのオーバーヘッドが耐えられなくなるから。「理論上の最大は64bitだけど、現実のCPUは48bitに妥協している」という設計判断。 Linuxはこれを多段ページテーブルで解決してる。x86_64では4段構成。 仮想アドレス（48bit有効） ┌──────┬──────┬──────┬──────┬────────────┐ │ PGD │ PUD │ PMD │ PTE │ offset │ │ 9bit │ 9bit │ 9bit │ 9bit │ 12bit │ └──────┴──────┴──────┴──────┴────────────┘ 名前は覚えなくていい。住所の階層構造だと思えばいい。 東京都 → PGD（一番大きい区分） 渋谷区 → PUD 代々木1丁目 → PMD 1番地 → PTE 101号室 → offset（ページ内の位置） ポイントは使っていない部分のテーブルを作らないこと。 ...

モダンオペレーティングシステム 第5版 上 第3章後半（3.6〜3.8）。実装上の課題、セグメンテーション、そしてCPU脆弱性とOSの関係。 3.6 実装上の課題 OSがページングに関わるタイミング ページング処理はいつ動くか。 【プロセス生成時】 → 新しいページテーブルを作る → ディスクからプログラムをロードする準備 【プロセス実行時】 → TLBミス → ページテーブルをたどる → ページフォルト → ページを物理メモリに載せる 【プロセス終了時】 → ページテーブルを解放 → 物理フレームを解放 → ディスク上のスワップ領域を解放 【コンテキストスイッチ時】 → ページテーブルの切り替え → TLBフラッシュ or ASID切り替え k3sでPodが終了した時： コンテナプロセス終了 → カーネルがページテーブル解放 → 物理フレーム解放 → 次のPodがそのフレームを使える 命令の再実行問題 ページフォルトが起きた時、フォルトした命令を再実行する。でもここに厄介な問題がある。 メモリのコピー命令（100番地→200番地にコピー） 実行途中の150番地でページフォルト ↓ 100〜149はすでにコピー済み ↓ 命令を再実行 ↓ 100〜149を二重にコピー → 壊れる 対処法 方法1: 命令実行前に全ページが存在するか先読みチェック → なければ先にページフォルトを起こしておく → 全部揃ってから命令実行（x86寄りの方式） 方法2: CPUが内部状態を保存 → どこまで実行したか記録 → 再開時はその続きから（一部のRISCの方式） ページのロック（ピン留め） I/O処理中のページは絶対に追い出せない。 DMA転送中 → デバイスが直接メモリに書き込んでる → このページを追い出したら → デバイスが存在しないメモリに書き込む → 最悪システムクラッシュ だからI/O中のページには**ロック（ピン留め）**をかける。置き換えアルゴリズムの対象外になり、I/O完了後にロック解除。 ...

モダンオペレーティングシステム 第5版 上 第3章前半（3.1〜3.3）。メモリ管理の基本。 第3章前半 メモリ管理の基礎 ベースレジスタとリミットレジスタ CPUのハードウェアレジスタを使ったシンプルなメモリ保護の仕組み。 プログラムがメモリにロードされる ↓ ベースレジスタ ← プログラムの開始物理アドレス リミットレジスタ ← プログラムの長さ ↓ プロセスがメモリにアクセスするたびに ↓ CPUがアクセスアドレス + ベース値を自動加算 ↓ リミットを超えてないか同時チェック ↓ 超えてたらフォールト（アクセス中断） これによってプロセスAはプロセスBのメモリに触れない。CPUレベルで物理的にブロックしてる。 ProxmoxのVM（KVM）との絡み KVMの場合はベース/リミットだけじゃなく、**EPT（Extended Page Table）**というIntel VT-xの機能でさらに一段上の分離をしてる。 ゲストの仮想アドレス ↓ ゲストのページテーブル ↓ ゲストの物理アドレス（実はまだ仮想） ↓ EPT（ここがKVMの追加レイヤー） ↓ 本当の物理アドレス これをネストされたページングと呼ぶ。ゲストOSごとに完全に別の物理アドレス空間にマッピングされるので、VM同士はお互いのメモリに絶対アクセスできない。 EPTはソフトウェアじゃなくてCPUがハードウェアで変換するので速い。 KVMに必要なCPU機能 KVMは以下のCPU機能が必須： CPU 仮想化支援機能 Intel VT-x AMD AMD-V（SVM） ARM（ラズパイ4等） ARMv8 Virtualization Extensions BIOSでVT-xが無効になってるとKVMが動かない。ProxmoxでVM作れないエラーの原因の大半がこれ。 MacのDockerが遅かった理由もここ Intel Mac時代 → HyperKitでソフトウェア仮想化 → 遅い・重い Apple Silicon（M1〜） → ARMのVirtualization Extensions使える → ハードウェア仮想化 → 速い M1でDockerが速くなったのはApple SiliconがARMの仮想化支援機能をちゃんと使えるようになったから。ただしARMなのでx86イメージは--platform=linux/amd64でエミュレーションになり遅い。 ...

モダンオペレーティングシステム 第5版 上 読んでる。 読み進めた記事というよりは範囲の中でわからんとこを生成AIと相談しながら文章課題とか出してもらいつつ進めたものをまとめた記事。 第1章 序論 OSの2つの役割 OSには2つの顔がある。 1. 拡張マシン（Extended Machine） ハードウェアの複雑さを隠蔽する。アプリ開発者はディスクの物理構造を知らなくてもファイルを読み書きできる。Docker APIがLinuxの複雑さを隠すのと同じ発想。 2. リソースマネージャー（Resource Manager） CPU・メモリ・ディスク・ネットワークを複数プロセスに割り当てる。k3s schedulerがNodeのリソースをPodに割り当てるのと同じ役割。 k3s scheduler → OSのリソースマネージャーと同じ役割 Docker API → OSの拡張マシンと同じ役割 OSがやってることをk3sやDockerが上位レイヤーで再現している。 ユーザー空間とカーネル空間 ┌─────────────────────────────┐ │ ユーザー空間 │ │ Docker、アプリ、k3s、etc... │ │ → 直接ハードウェアは触れない │ └──────────┬──────────────────┘ │ システムコール（唯一の通路） ┌──────────▼──────────────────┐ │ カーネル空間 │ │ スケジューラ │ │ メモリ管理 │ │ ファイルシステム │ │ デバイスドライバ │ │ → ハードウェアを直接触れる │ └─────────────────────────────┘ アプリが直接ハードウェアを触れたら危険。カーネルが仲介することで安全性を保証する。 システムコール docker runした時の実際の流れ： docker run ubuntu ↓ Dockerデーモン ↓ clone() ← プロセス生成 unshare() ← namespaceを作る mount() ← ファイルシステムをマウント ↓ Linuxカーネル Dockerはシステムコールの集合体。魔法じゃなくてLinuxのシステムコールをうまく組み合わせてるだけ。 ...

前回のハマり話の続編。 今回は実際にCI/CDパイプラインを動かすところまで進めた。結論から言うと、自動化は99%完成したが、最後の1%（Webhook）で詰んだ。 目標設定 理想は当然これ： GitHub push → Drone検知 → Hugo自動ビルド → Dockerイメージ作成 → k3sデプロイ更新 ただし、私の環境には致命的な制約がある。 制約：外部IP持ってない 自宅サーバーはTailscaleでVPN経由でのみアクセス可能。つまりGitHubからのWebhookが届かない。まあ、DuckDNSでドメインは取ってるけど、それでもTailscale依存の構成。 それでも「やれるとこまでやってみよう」精神で進めた。 .drone.yml 設定 最終的にはこんな感じになった： kind: pipeline type: kubernetes name: hugo-pipeline steps: - name: build-hugo image: klakegg/hugo:latest commands: - cd posts - hugo --minify - ls -la public/ - name: create-docker-context image: alpine:latest commands: - cp -r posts/public ./public - ls -la public/ - name: docker-build image: plugins/docker settings: registry: ghcr.io repo: ghcr.io/wasuken/tech_blog username: from_secret: github_username password: from_secret: github_token tags: - latest - "${DRONE_COMMIT_SHA:0:8}" - name: deploy-to-k3s image: bitnami/kubectl environment: KUBECONFIG: from_secret: kubeconfig commands: - kubectl set image deployment/hugo-site hugo=ghcr.io/wasuken/tech_blog:latest - kubectl rollout status deployment/hugo-site - name: deploy-complete image: alpine:latest commands: - echo "Hugo build complete!" - echo "Image pushed successfully" ポイントは、HugoビルドからDockerイメージ作成、GHCR（GitHub Container Registry）へのプッシュ、最終的なk3sデプロイまで全部自動化したこと。 ...

背景 日課でできる範囲の活動として、軽い記事から、疑問を生成AIに出してもらって、それに答えてもらって、深堀や補足、添削をしてもらった内容までを記事にするという習慣を続けていたが、公開するのはどうなのかなと思った。 しかし、後ほど止めるのはもったいないということで妥協案として、ローカルで動くブログには投稿することにした。 なので、ローカルブログを立ち上げることにした。 最初はGitHub Pagesでよく使われているJekyllを試した。しかし、ローカル環境とDocker環境でRubyのバージョン不一致が発生し、プロジェクト初期化の段階で躓いた。 ローカルのRuby 3.4に対してDockerの最新イメージがRuby 3.1で、この差分が原因でSCSS変換周りでエラーが頻発。Jekyllはプロジェクト作成をローカルで行う必要があるため、「Docker使えば環境差を吸収できる」という謳い文句が実質的に機能しなかった。 もっとうまくやればよかっただろうが、そのときは血が登っていて、Hugoにしてしまった。 要件整理 改めて自分の要件を整理した： Markdownファイルのマウントだけで完結 ローカル環境に一切依存しない プロジェクト初期化もDocker内で実行可能 検索機能とファイル一覧が欲しい これを満たすツールを探した結果、Hugoに行き着いた。 なぜHugoなのか Hugoを選んだ理由は明確： 1. バイナリ単体で動作 Go言語で書かれたHugoは単一バイナリで動作する。RubyやNode.js、Pythonのようなランタイム環境が不要。これにより依存関係地獄から解放される。 2. プロジェクト初期化もDocker内で完結 当初は生成AIの言うとおりに以下のコマンドでプロジェクトを作成した。 docker run --rm -v $(pwd)/posts:/src klakegg/hugo:alpine new site . この1コマンドでプロジェクト作成が完了する。ローカルに何もインストールする必要がない。 のだが、後ほどこれがトラブルを産んだ。 3. 高速なビルド Goの並列処理能力により、数千ページ規模のサイトでも秒単位でビルドが完了する。開発時のホットリロードも快適。 構築手順 1. docker-compose.yml作成 services: hugo: image: hugomods/hugo:base container_name: hugo-blog ports: - "7000:7000" volumes: - ./posts:/src command: server --bind 0.0.0.0 --port 7000 --buildDrafts --buildFuture restart: unless-stopped ポイント： hugomods/hugo:base を使用 ポートは7000にマッピング（後述のブラウザ制限回避） --buildDrafts --buildFuture で下書きと未来日付の記事も表示 2. プロジェクト初期化 docker run --rm -v $(pwd)/posts:/src klakegg/hugo:alpine new site . これで posts/ ディレクトリに必要なファイル群が生成される。 ...