OCHaCafe S11 #4 OSTreeで実現するイミュータブル・インフラ

Transcript

1. OSTree で実現する イミュータブル・インフラ Oracle Cloud Hangout Cafe S11 #4 Yuki Sogawa / Kyotaro Nonaka 日本オラクル株式会社
2. 本日のアジェンダ 1 2 3 4 5 はじめに OSTreeの仕組み OSTreeでOS＋パッケージ管理 (デモ) OSTreeのライフサイクル Kubernetes Adaption (デモ) Copyright © 2026, Oracle and/or its affiliates 2
3. はじめに
4. 自己紹介 Kyotaro Nonaka 野中恭大郎 Solutions Architect • Java EE/Messaging/NoSQL/Frontend • Oracle Cloud Hangout Café メンバー • Oracle Groundbreakers Advocate • 元ERPパッケージ開発者 • 月末久しぶりに野球するので焦ってトレーニングしてます 4 Copyright © 2026, Oracle and/or its affiliates @non_kyon
5. 自己紹介 曽川 宥輝 日本オラクル CloudNative/AI,ML ク ラウドエンジニア バックグラウンド 大阪大学でデータセンターの省電力化の研究をしていました 趣味 ギター、バイク、ゲームなど 5 Copyright © 2026, Oracle and/or its affiliates
6. インフラ運用の複雑化 変更の蓄積は、インフラ運用をより複雑で難しくする • 手動での設定変更やパッチ適用が積み重なる • 構成管理ツール利用環境であっても「例外対応」による差分 障害時の原因分析や環境再現に大きなコストがかかる Copyright © 2026, Oracle and/or its affiliates 6
7. 「ハンドメイド」から「工業製品」へ 個別に管理 (ハンドメイド) • 特定のサーバに名前を付ける • 手作業で管理 • 長期的に「育てる」 → 小さめの環境で有効 交換可能なリソース (工業製品) • prefixや自動採番で名称管理 • コードやツールで管理 • 「交換」を前提とした仕組み → 巨大クラスタなどで有効 Copyright © 2026, Oracle and/or its affiliates 7
8. イミュータブルという発想 既存の状態を変更せず再生成するアプローチで、状態の一貫性と再現性を維持 • 設定変更を既存サーバに適用しない • 新しい設定でイメージを作成して差し替える • パッケージ更新も新しいOSとして再構築する Kubernetes環境においても、 OS自体をイメージとして管理するメリットがある • OS差異によってコンテナの挙動が変わることを防ぐ • Node 間の差異をなくす • アップグレード、スケールなどのライフサイクルとの相性がいい Copyright © 2026, Oracle and/or its affiliates 8
9. 求められるOSの性質 現代のインフラでは再現性・原子性・ロールバック性を備えたOSが求められる 同一入力から同一状 態を生成できる再現 性が運用の前提 再現性 更新が途中状態を経 ずに切り替わる原子 的な適用 原子性 問題発生時に即座に 元の状態へ戻せる ロールバック機構 ロール バック性 Copyright © 2026, Oracle and/or its affiliates 9
10. OSTreeの仕組み
11. OSTreeとは OSのファイルツリーをバージョン管理する Gitのような仕組みでOSのファイルツリー全体をバージョン管理する 11 Copyright © 2026, Oracle and/or its affiliates 従来のOS管理の課題 • パッケージマネージャはファイル単位で上書き • 失敗時の状態が不確定 • ロールバックが難しい OSTreeのアプローチ • OSのファイルツリーをGitのようにバージョン管理 • 複数バージョンをディスク上に共存させて、ブート 時に切り替える オブジェクトストア （ローカル） リモートリポジトリ OSイメージを ダウンロード OSとして使える形 に組み立てる Deployment
12. OSTreeとは OSのファイルツリーをバージョン管理する Gitのような仕組みでOSのファイルツリー全体をバージョン管理する 12 Copyright © 2026, Oracle and/or its affiliates 従来のOS管理の課題 • パッケージマネージャはファイル単位で上書き • 失敗時の状態が不確定 • ロールバックが難しい OSTreeのアプローチ • OSのファイルツリーをGitのようにバージョン管理 • 複数バージョンをディスク上に共存させて、ブート 時に切り替える オブジェクトストア （ローカル） リモートリポジトリ OSイメージを ダウンロード OSとして使える形 に組み立てる Deployment このパートではローカルのオブジェク トストアに利用可能なコミットがある 前提で仕組みを説明します
13. （参考）Gitの仕組み ３種類のオブジェクトでファイルツリーの履歴を表現 • blob: ファイルの中身そのもの • tree: ディレクトリに相当 • commit: ある時点のスナップショット 13 Copyright © 2026, Oracle and/or its affiliates
14. OSTreeが持つオブジェクト • File • Gitのblobに相当 • ファイル自体を表す • Dirtree • Gitのtreeに相当 • ディレクトリの属性を表す • Dirmeta • Gitにはない独自オブジェクト • ディレクトリの中身を表す • Commit • Gitのcommitに相当 • OSのスナップショットを表す 14 Copyright © 2026, Oracle and/or its affiliates
15. OSTreeのオブジェクトストア SHA-256の先頭2文字でサブディレクトリ、残りをファイル名 15 Copyright © 2026, Oracle and/or its affiliates /ostree/repo/ ├── config ├── extensions/ │ └── rpmostree/ ├── objects/ │ ├── 00/ │ ├── 01/ │ │ └── 7b9c3a1f2e4d8f1a3b5c7e9d2f4a6b8c1e3d5f7a9b1c3e5d7f9a1b.file │ ├── 02/ │ ├── ... │ ├── a3/ │ │ └── f5b2c8d4e7c1a9b3d5e8f2a4c6b8d1e3f5a7c9b2d4e6f8a1c3.commit │ ├── ... │ ├── 7b/ │ │ ├── 9c3a1f2e4d8f1a3b5c7e9d2f4a6b8c1e3d5f7a9b1c3e5d7f.dirtree │ │ └── 9c3a1f2e4d8f1a3b5c7e9d2f4a6b8c1e3d5f7a9b1c3e5d7f.dirmeta │ ├── ... │ └── ff/ │ └── ... (256ディレクトリ × 多数のオブジェクト) ├── refs/ │ ├── heads/ │ │ └── fedora/x86_64/coreos/stable │ ├── mirrors/ │ └── remotes/ ├── state/ └── tmp/ └── cache/ 各オブジェクトが配置される Commitの名前（ref）とcommit ハッシュのマップが配置される
16. なぜハッシュ管理しているのか 重複排除のため OSは数万ファイルからなり、バージョンが上がっても変わらないファイルが多数存在 内容が変わらないファイルも重複して保持してしまうとディスク容量が膨れ上がってしまう ハッシュを使えば、同じ内容のファイルはオブジェクトストアに１つしか存在しないようにできる ただし、ディレクトリ構造がOS的な意味を持たないため、そのままでは使えない OSとして使える形に組み立てる必要がある 16 Copyright © 2026, Oracle and/or its affiliates オブジェクトストア （ローカル） OSとして使える形に組み立てる Deployment この処理が必要
17. OSとして使える形とは 普段使っているLinuxシステムで、ls / した時のファイルツリー 普通のLinuxでは、ディスクのルートにこれらのファイルがある OSTreeの場合、ファイルの実体は基本的にオブジェクトストアにあるので、結び付けが必要 17 Copyright © 2026, Oracle and/or its affiliates
18. Deployment OSファイルツリーとオブジェクトストアを結びつけたもの 大きく分けると３つのディレクトリに組み立てる 18 Copyright © 2026, Oracle and/or its affiliates 領域 役割 実体の場所 性質 /usr OS本体 オブジェクトストアへの ハードリンク Read-only, commit単位 /etc 設定 Deployment内に保存 書き換え可能、3-way マージ /var 永続データ Stateroot配下に一つ 書き換え可能、OS横断で 永続化
19. Deployment管理の全体像 19 Copyright © 2026, Oracle and/or its affiliates ホストマシン /var 永続データ（stateroot単位） /var Deployment A /usr : Read-only /etc : 3-way merge Deployment B /usr /etc • /usr, /etc はDeplolyment毎で固有 • /varはstateroot単位で固有（ディストリビューションが変わると別管理になる） ※１つのマシンに１つのstaterootになることがほとんど
20. Deploymentの全体像 20 Copyright © 2026, Oracle and/or its affiliates ディスクルート Deployment A（ここがルートとして起動する） オブジェクト ストア var Deploy ment B /usr /etc /var /sysroot バインドマウント バインドマウント ＋ ハードリンク バインドマウント 実体 マウントポイント
21. Deploymentのディレクトリ（/usr） OSの実態を配置するディレクトリ ここに配置されるファイルはOSのディストリビューションが提供するもので、ユーザーが作ったものではない 21 Copyright © 2026, Oracle and/or its affiliates /usr/ ├── bin/ 実行可能バイナリ（ls、cat、bash、systemctl等） ├── sbin/ 管理者用バイナリ（mount、ip、useradd等） ├── lib/ 共有ライブラリ（libc.so.6、libssl.so等） ├── lib64/ 64bit用共有ライブラリ ├── libexec/ 他のプログラムから呼ばれる補助バイナリ ├── share/ アーキテクチャ非依存リソース │ ├── doc/ マニュアルドキュメント │ ├── locale/ 各国語翻訳ファイル │ ├── icons/ アイコン │ └── fonts/ フォント ├── include/ ヘッダファイル（C/C++の.h） ├── etc/ ★ 設定ファイルのデフォルト値（重要） ├── lib/systemd/ systemd unit ファイル（OS提供分） └── lib/modules/ カーネルモジュール インストールしたソフトウェアな ども配置される
22. Deploymentのディレクトリ（/usr） 特徴 性質 • 容量が大きい • OSのバージョンに紐づく • ユーザーが書き換えるものではない • 同じ内容のファイルが多い（バージョン間で内容が変わらないものが多数） OSTreeでの扱い • Read-only（イミュータブル） • Content-addressed（容量が大きく、バージョン間で同じ内容のものが多いので効果大） • オブジェクトストアへのハードリンク + ブート時のバインドマウントで実現する 22 Copyright © 2026, Oracle and/or its affiliates
23. Deploymentのディレクトリ（/usr） 特徴 性質 • 容量が大きい • OSのバージョンに紐づく • ユーザーが書き換えるものではない • 同じ内容のファイルが多い（バージョン間で内容が変わらないものが多数） OSTreeでの扱い • Read-only（イミュータブル） • Content-addressed（容量が大きく、バージョン間で同じ内容のものが多いので効果大） • オブジェクトストアへのハードリンク + ブート時のバインドマウントで実現する 23 Copyright © 2026, Oracle and/or its affiliates なぜこのようなことをする必要があるか？
24. Deploymentのディレクトリ（/usr） なぜハードリンク + バインドマウントが必要か /usrには二つの性質が求められる 1. Deployment作成時には書き込める必要がある • 作成時には/usrにオブジェクトストアへのハードリンクを張る必要がある • Read-onlyだとハードリンクを張ることができない 2. OSとして起動してからはRead-onlyにしたい • イミュータブルにするため、起動後は/usrはRead-onlyにしたい つまり、作成時は書き込みができて、起動後は読み取り専用にしたい 簡単に実現できそうなのは、Deployment作成後にchmodでRead-onlyにすること しかしこれだと、root権限で解除できてしまう 24 Copyright © 2026, Oracle and/or its affiliates イミュータブルにならない！
25. Deploymentのディレクトリ（/usr） なぜハードリンク + バインドマウントが必要か そこで、ハードリンク + バインドマウントの２段階の構成を踏む ①Deployment作成時は書き込み可能な普通のディレクトリとする 作成時、/ostree/deploy/.../deploy/<commit>/usr/は書き込み可能な普通のディレクトリとする 中身はオブジェクトストアへのハードリンクで構成する この状態だと、起動後も書き込みができてしまう ②起動時にRead-onlyでバインドマウントする /ostree/deploy/.../deploy/<commit>/usr/は書き込み可能だが、/usrにRead-onlyでバインドマウントする これによって、/usr経由でアクセスした場合はRead-onlyになる ※ただし直接/ostree/deploy/…にアクセスすると書き込める場合がある 25 Copyright © 2026, Oracle and/or its affiliates /ostree/deploy/…/deploy/<commit>/usr /usr 実体 （オブジェクトストア） Read-only 最近のものはcomposefsで ルート全体をread-onlyにし、 /etcと/varだけ上書きでwrite できるようにマウントしてる
26. Deploymentのディレクトリ（/etc） 設定ファイルを配置するディレクトリ 26 Copyright © 2026, Oracle and/or its affiliates /etc/ ├── hostname マシン名 ├── passwd, shadow, group ユーザーアカウント ├── hosts 名前解決 ├── resolv.conf -> ../run/systemd/resolve/stub-resolv.conf ├── fstab (略) マウント設定 ├── locale.conf ロケール ├── machine-id マシン固有ID │ ├── ssh/ │ ├── sshd_config SSHサーバー設定 │ └── ssh_host_*_key ホスト鍵 │ ├── NetworkManager/ │ ├── NetworkManager.conf │ └── system-connections/ ネットワーク接続定義 │ ├── containers/ │ ├── registries.conf コンテナレジストリ設定 │ ├── policy.json コンテナ署名ポリシー │ └── systemd/ Quadlet │ ├── systemd/ │ ├── system/ ローカルsystemd unit │ └── user/ │ ├── selinux/config SELinux設定 ├── sudoers sudo権限 ├── sysctl.d/ カーネルパラメータ ├── ostree/remotes.d/ OSTreeリモート設定 ├── rpm-ostreed.conf rpm-ostree設定 └── zincati/config.d/ 自動更新設定（FCOS固有） HostnameやSSH設定、コンテナレ ジストリ設定など
27. Deploymentのディレクトリ（/etc） 特徴 性質 • ディストリビューション提供のデフォルト設定が存在する • ユーザー（管理者）が編集する必要がある • OSアップグレード時にデフォルトの設定とユーザー編集の両方を尊重する必要がある OSTreeでの扱い • Deployment内に実体を保存（オブジェクトストアの管理外） • OSアップグレード時に3-wayマージで新Deploymentの/etcを生成 27 Copyright © 2026, Oracle and/or its affiliates
28. Deploymentのディレクトリ（/etc） 3-wayマージ • 旧バージョンDeploymentのデフォルト設定 • 新バージョンDeploymentのデフォルト設定 • 今使っている/etcの内容 28 Copyright © 2026, Oracle and/or its affiliates 現在の設定（変更部分）が必ず残るようにマージする 古いデフォルトから変更して いない部分は新デフォルトに 置き換わる マージは再起動時に行われる
29. Deploymentのディレクトリ（/var） システムの動作によって生成・変化するデータが配置される 29 Copyright © 2026, Oracle and/or its affiliates /var/ ├── lib/ アプリケーションの永続データ │ ├── postgresql/ PostgreSQLのデータベース実体 │ ├── containers/ Podmanのコンテナイメージ・ストレージ │ ├── systemd/ systemdの永続状態 │ └── dpkg/ or rpm/ パッケージDB ├── log/ ログファイル │ ├── messages システムログ │ ├── journal/ systemd-journaldのログ │ ├── audit/ 監査ログ │ └── nginx/ アプリケーションログ ├── cache/ 再生成可能なキャッシュ │ ├── dnf/ or apt/ パッケージマネージャキャッシュ │ └── fontconfig/ フォントキャッシュ ├── spool/ 処理待ちデータ │ ├── cron/ cronジョブ │ └── mail/ メールスプール ├── tmp/ 長期間保持される一時ファイル ├── home/ ★ /home の実体（symlink先） ├── roothome/ ★ /root の実体 ├── opt/ ★ /opt の実体 └── srv/ ★ /srv の実体（Webコンテンツ等） ログやDBのデータ、コンテナイ メージなど ユーザーデータも/var配下
30. Deploymentのディレクトリ（/var） 特徴 性質 • OSバージョンを跨いで永続化する必要がある（DBのデータなど） • 頻繁に書き換わる（ログやDBのデータなど） OSTreeでの扱い • オブジェクトストアの管理外 • Stateroot（ディストリビューション）につき一つ • /sysroot/ostree/deploy/<stateroot>/var/に普通のディスク上のファイルとして管理し、/varにバインドマウント 30 Copyright © 2026, Oracle and/or its affiliates
31. Deploymentのディレクトリ（/var） 特徴 性質 • OSバージョンを跨いで永続化する必要がある（DBのデータなど） • 頻繁に書き換わる（ログやDBのデータなど） OSTreeでの扱い • オブジェクトストアの管理外 • Stateroot（ディストリビューション）につき一つ • /sysroot/ostree/deploy/<stateroot>/var/に普通のディスク上のファイルとして管理し、/varにバインドマウント 31 Copyright © 2026, Oracle and/or its affiliates なぜオブジェクトストアの管理外なのか
32. Deploymentのディレクトリ（/var） なぜオブジェクトストアの管理外なのか ①Deploymentを跨いで永続化する必要があるため /varがDeploymentに紐づいてしまうと、Deploymentを切り替えると/varの内容も切り替わってしまい、データの連続性が失われる ②頻繁な書き換えと、content-addressedの相性が悪いため Content-addressedを使う場合、ハッシュ計算が必要になる 毎秒単位で書き換わるログやDBのデータなどをハッシュ計算していたら、それだけでマシンリソースを使い切ってしまう 重複したデータがほとんど存在しないので、容量の削減にもならない 32 Copyright © 2026, Oracle and/or its affiliates
33. Deploymentの中身を見てみると ①Deployment内に実際に中身があるディレクトリ 33 Copyright © 2026, Oracle and/or its affiliates ├── 35bad5f19cba18082680012e01… │ ├── bin -> usr/bin │ ├── boot │ ├── dev │ ├── etc │ ├── home -> var/home │ ├── lib -> usr/lib │ ├── lib64 -> usr/lib64 │ ├── media -> run/media │ ├── mnt -> var/mnt │ ├── opt -> var/opt │ ├── ostree -> sysroot/ostree │ ├── proc │ ├── root -> var/roothome │ ├── run │ ├── sbin -> usr/sbin │ ├── srv -> var/srv │ ├── sys │ ├── sysroot │ ├── tmp │ ├── usr │ └── var オブジェクトストアへのハードリンク 基本的にはオブジェクトストアへのハードリンク ユーザーがファイルを編集した場合はそのファイルのみ実体が配置される • /bootがルートファイルシステムと同一パーティションならハードリンク • 違うパーティションなら実体をコピーして配置
34. （参考）/bootについて 実体はオブジェクトストアにある ハードリンクは、同一ファイルシステム内でしか機能しない Kernel, initramfsなどが配置されているパーティションによって扱いを変える必要がある 34 Copyright © 2026, Oracle and/or its affiliates ルートFSにKernel, initramfsが配置されている場合 /bootから実体のinodeへハードリンクを貼る 別ファイルシステムに配置されている場合 Kernel, initramfsなどを/bootにコピーする Kernelの実体 （inode） /boot/…/vmlinuz... /boot/…/initramfs... initramfsの実体 （inode） ルートFS /boot/…/vmlinuz... /boot/…/initramfs... /boot コピー オブジェクトストア LVMなどはGRUBが読めないので、 ルートFSがLVMの場合は別パー ティションにする必要がある
35. Deploymentの中身を見てみると ②ブート時にバインドマウントされるもの 35 Copyright © 2026, Oracle and/or its affiliates ├── 35bad5f19cba18082680012e01… │ ├── bin -> usr/bin │ ├── boot │ ├── dev │ ├── etc │ ├── home -> var/home │ ├── lib -> usr/lib │ ├── lib64 -> usr/lib64 │ ├── media -> run/media │ ├── mnt -> var/mnt │ ├── opt -> var/opt │ ├── ostree -> sysroot/ostree │ ├── proc │ ├── root -> var/roothome │ ├── run │ ├── sbin -> usr/sbin │ ├── srv -> var/srv │ ├── sys │ ├── sysroot │ ├── tmp │ ├── usr │ └── var ブート時にバインドマウントされる
36. Deploymentの中身を見てみると ③仮想ファイルシステム 36 Copyright © 2026, Oracle and/or its affiliates ├── 35bad5f19cba18082680012e01… │ ├── bin -> usr/bin │ ├── boot │ ├── dev │ ├── etc │ ├── home -> var/home │ ├── lib -> usr/lib │ ├── lib64 -> usr/lib64 │ ├── media -> run/media │ ├── mnt -> var/mnt │ ├── opt -> var/opt │ ├── ostree -> sysroot/ostree │ ├── proc │ ├── root -> var/roothome │ ├── run │ ├── sbin -> usr/sbin │ ├── srv -> var/srv │ ├── sys │ ├── sysroot │ ├── tmp │ ├── usr │ └── var 空ディレクトリ 仮想FSのマウントポイント
37. Deploymentの中身を見てみると ④他はシンボリックリンク 37 Copyright © 2026, Oracle and/or its affiliates ├── 35bad5f19cba18082680012e01… │ ├── bin -> usr/bin │ ├── boot │ ├── dev │ ├── etc │ ├── home -> var/home │ ├── lib -> usr/lib │ ├── lib64 -> usr/lib64 │ ├── media -> run/media │ ├── mnt -> var/mnt │ ├── opt -> var/opt │ ├── ostree -> sysroot/ostree │ ├── proc │ ├── root -> var/roothome │ ├── run │ ├── sbin -> usr/sbin │ ├── srv -> var/srv │ ├── sys │ ├── sysroot │ ├── tmp │ ├── usr │ └── var 残りはvar, usrへのシンボリックリンク
38. Deployment起動前と起動後の見え方の違い 実際に見てみると 38 Copyright © 2026, Oracle and/or its affiliates core@fcos-ch03:~$ sudo ls $DEPLOYMENT/usr bin etc games include lib lib64 libexec local sbin share src tmp core@fcos-ch03:~$ ls /usr bin etc games include lib lib64 libexec local sbin share src tmp core@fcos-ch03:~$ sudo ls $DEPLOYMENT/etc | head -5 DIR_COLORS DIR_COLORS.lightbgcolor GREP_COLORS NetworkManager X11 core@fcos-ch03:~$ ls /etc | head -5 DIR_COLORS DIR_COLORS.lightbgcolor GREP_COLORS NetworkManager X11 core@fcos-ch03:~$ sudo ls $DEPLOYMENT/var lib run core@fcos-ch03:~$ sudo ls /var adm cache crash db empty ftp games home kerberos lib local lock log mail mnt nis opt preserve roothome run spool srv tmp usrlocal yp /usr /etc /var 同じ内容 バインドマウントされて から中身が現れる
39. （参考）普通のLinuxがブートする仕組み 39 Copyright © 2026, Oracle and/or its affiliates OSTreeではこれらの処理が変わる OSTreeでは、rootFSに switch_rootせずに対象の Deploymentにswitch_root する必要がある
40. OSTreeシステムがブートする仕組み 40 Copyright © 2026, Oracle and/or its affiliates
41. GRUBとカーネル引数 起動するDeploymentを指定する OSTreeでは、Deployment作成時にGRUBの設定ファイルも書き換える GRUBの設定ファイルに • 次回起動時のカーネルとinitramfs • 起動するDeploymentの場所 を書いておく 41 Copyright © 2026, Oracle and/or its affiliates GRUB カーネル A Initramfs A Deployment A Deployment B GRUBの設定 ファイル カーネル B Initramfs B 設定ファイルに書かれた カーネル・initramfsを使 用 ostree= で起動する Deploymentを指定
42. ostree-prepare-root 適切なDeploymentにswitch_rootする initramfsの/sysrootに、ルートFSをマウント ostree=で与えられたDeploymentをそこから探して、最終的にswitch_rootする 42 Copyright © 2026, Oracle and/or its affiliates
43. OSTreeでOS＋パッケージ管理
44. OSTreeで管理すべきもの OSTreeはOSのバージョン管理ではあるが、OSのバージョンは同じでもパッケージを更新したり、新しいパッケージを入れたりする場合が 多くある OSTreeのイメージとしては純粋なOSのバージョンだけではなく、パッケージまで含めてイメージのバージョンとして管理しないとイミュータブ ルな管理とは言えない 44 Copyright © 2026, Oracle and/or its affiliates OS本体のみを管理する場合 パッケージまで管理する場合
45. rpm-ostreeとは OSTreeの仕組みを使って、新しいパッケージをインストールしたDeploymentに切り替えることでパッケージ導入・更新を実現する OSTreeの上に乗ったパッケージ管理システム Copyright © 2026, Oracle and/or its affiliates 45 従来 • 稼働中のシステムが直接書き換わる • ロールバックが難しい • 更新途中で電源断が起こるとシステムが中途半端な 状態になる rpm-ostree rpm-ostree install 新Deployment作成 再起動 新Deployment起動 dnf install 現在のOSに直接インス トールされる 何かあれば前の Deploymentに戻 すだけでOK
46. どのように新しいDeployment（コミット）を作るか 46 Copyright © 2026, Oracle and/or its affiliates ローカルでレイヤリング リモートレジストリで管理 ベースOS イメージ パッケージ 定義ファイル • treefile • containerfile リモートレポジトリ 各マシン ビルド ダウンロード
47. rpm-ostree installによるレイヤリング ベースイメージを各マシンで拡張する ベースとなるOSイメージをローカルレポジトリ（オブジェクトストア）にダウンロードした後、必要なパッケージを各マシンで追加する 47 Copyright © 2026, Oracle and/or its affiliates オブジェクトストア （ローカル） リモートリポジトリ OSイメージを ダウンロード OSとして使える形 に組み立てる Deployment 必要なパッケージを インストール オブジェクトストア （ローカル） rpm-ostree install
48. デモ：rpm-ostree installコマンド 新しいDeployment作成・ロールバック 48 Copyright © 2026, Oracle and/or its affiliates 稼働中の Deployment 新しい Deployment rpm-ostree install & reboot 稼働中の Deployment 前の Deployment rpm-ostree rollback & reboot 新規作成 ロールバック
49. rpm-ostree installによるレイヤリング ベースイメージを各マシンで拡張する ベースとなるOSイメージをローカルレポジトリ（オブジェクトストア）にダウンロードした後、必要なパッケージを各マシンで追加する 49 Copyright © 2026, Oracle and/or its affiliates オブジェクトストア （ローカル） リモートリポジトリ OSイメージを ダウンロード OSとして使える形 に組み立てる Deployment 必要なパッケージを インストール オブジェクトストア （ローカル） rpm-ostree install 各マシンで柔軟にパッケージが導入できるが、OSイメージの統合管理ができない
50. treefile インストールするパッケージまで含めてOSTreeイメージを作成し、配布 各マシンはOSTreeイメージをダウンロードし、そのコミットをDeploymentに変換して利用するだけ パッケージも含めたOSTreeイメージを作成するための定義ファイル Copyright © 2026, Oracle and/or its affiliates 50 リモートリポジトリ treefile イメージをビルドしてプッシュ 各マシン オブジェクトストア （ローカル） Deployment ref: example/x86_64/server repos: - fedora - fedora-updates packages: - kernel - systemd - bash - openssh-server この方法では、OSTree専用のリモート リポジトリが必要になる
51. containerfile コンテナイメージとしてパッケージも含めたOSイメージを配布する お馴染みのcontainerfileを書いて、OSイメージを配布する 既存のコンテナレジストリをそのままOS管理のレジストリとして利用できる 51 Copyright © 2026, Oracle and/or its affiliates コンテナレジストリ containerfile イメージをビルドしてプッシュ 各マシン オブジェクトストア （ローカル） Deployment FROM quay.io/fedora/fedora-coreos:stable RUN rpm-ostree install vim nginx && \ ostree container commit
52. OSTreeのライフサイクル
53. ライフサイクルの全体像 OSTreeはライフサイクルで見ると、 • 宣言的プロビジョニング • 実行環境 • 自動更新 • OSコンテナ管理 が統合された構造を持つ Ignition Butane CoreOS Zincati rpm- ostree 宣言的プロビジョニング 実行環境 自動更新 OSコンテナ管理 Copyright © 2026, Oracle and/or its affiliates 53
54. 宣言的プロビジョニング Node 構成をコードとして定義し状態を再現するアプローチ • OSレベルの設定 • ミドルウェア構成 • パッケージ管理 新規 Node を同じ定義から何度でも同じ状態で作成でき、一貫性 / 再現性 / 冪等性 が保証される これらをコード(≒ 設定ファイル)で管理 Copyright © 2026, Oracle and/or its affiliates 54
55. Ignition/Butane : Node の初期状態を再現可能にする 概要 • initramfs実行中にディスクを操作するために作成された ユーティリティ - ファイル作成/配置 - systemd unit の登録・有効化 - ユーザー・SSH鍵管理 特徴 • 最初の起動時のみ作動 • リモートURLなどから設定を読み込み、その設定を適用 • 設定ファイルは、システムの状態を記述する宣言型 • 低レベル設定ファイルのため手書きで記述すべきでない - 高レベル記述にはButaneを利用 https://coreos.github.io/ignition/ Copyright © 2026, Oracle and/or its affiliates 55
56. Ignition / Butane で設定できるもの ファイル作成/配置 • 以下のようなファイルを作成/配置可能 - /etc/hostname - systemd unit file - アプリ設定ファイル - SSH鍵 - Kubernetes関連設定 • ファイルに対し以下の操作が可能 - ファイル内容設定 - パーミッション - owner/group - overwrite - append systemd unit の登録・有効化 • 独自サービス追加 • Docker/Podman自動起動 • kubelet起動 • one-shot初期化処理 • timer unit ユーザー・SSH鍵管理 • coreユーザーへ公開鍵投入 • 管理者ユーザー追加 • sudo権限付与 • group 追加 • shell 56 Copyright © 2026, Oracle and/or its affiliates
57. Ignition / Butane で設定できるもの ディスク・パーティション設定 • ディスク初期化 • GPT • partition作成 • RAID • filesystem作成 • mount設定 ネットワーク設定 ※クラウド利用時は、プロバイダ側の設定と競合し動作が不安 定になりがちなので注意 • static IP • bond • VLAN • bridge 57 Copyright © 2026, Oracle and/or its affiliates
58. Butane を書いてみるとこんな感じ variant: fcos version: 1.6.0 passwd: users: - name: core ssh_authorized_keys: - ssh-rsa AAAA... systemd: units: - name: install-k3s-agent.service enabled: true ・・・右に続く contents: | [Unit] Description=Install k3s agent Wants=network-online.target After=network-online.target [Service] Type=oneshot ExecStart=/usr/bin/bash -c '\ curl -sfL https://get.k3s.io | \ K3S_URL=https://10.0.232.72:6443 \ K3S_TOKEN=K... \ sh -s - agent' RemainAfterExit=yes [Install] WantedBy=multi-user.target 58 Copyright © 2026, Oracle and/or its affiliates core ユーザ SSH Key systemd systemd config
59. CoreOS コンテナ時代向けに設計された軽量 Linux OS • Node は交換可能なもの • 設定は宣言的かつImmutable • 極小化されたOS • 自動アップデート という思想のもとで設計、OSを「イメージとして管理するもの」とし て捉える 主要ディストリビューション • Fedora CoreOS - upstream寄り - コミュニティ主導 • RHEL CoreOS - 安定重視 - Enterprise / OpenShift Copyright © 2026, Oracle and/or its affiliates 59
60. Multicloud container services deployment for Kubernetes • Centralized Kubernetes management • Oracle Container Host for Kubernetes (OCK) – Immutable • Unique UI for centralized deployment, monitoring and observability, built on HeadLamp opensource project • 100% open-source CNCF Certified Kubernetes distribution • Container and Virtual Machine (KubeVirt) orchestration with multi cluster support • Application definition and image build • Cluster-API Support • Service mesh • Cloud native networking and Persistent storage support • IPv4 and IPv6 dual stack support • High availability and Load balancing • Oracle Cloud Native and Community Catalogs • GitHub Organization at https://github.com/oracle-cne Oracle Cloud Native Environment Copyright © 2026, Oracle and/or its affiliates 60
61. 自動アップデートモデル CoreOS系OSは Node が自律的に更新を取得する自動アップデートモデルを採用 • バックグラウンドで新しいOSイメージを取得し適用準備 • 以下のような概念や機能を組み合わせ、再起動時に安全に新しいバージョンへ切り替わる - update rollout : 更新を段階的に展開 - maintenance window : 更新可能時間帯 - reboot coordination : reboot 順序制御 / 同時 reboot 数制御 - drain : ワークロード退避 - quorum control : 分散システム保護(多数決可能な最小人数) ...つまり自動アップデートモデルの根底にある思想は 何も考えずに再起動して安全アップデート！ 仕組みはあるので、自動アップデートできる環境を頑張って作ろう！ Copyright © 2026, Oracle and/or its affiliates 61
62. Zincati : 更新制御 自動更新するOSを、クラスタ運用で破綻しないようにするためのコンポーネント 更新の流れ 1. Zincati が更新検知 2. rollout policy 確認 3. fleet lock 確認 4. reboot timing 調整 5. rpm-ostree deploy 6. reboot • rollout policy :更新を、どういった順番で、どのぐらいの速度で、広げるかのルール • fleet lock : 外部(クラスタ全体)に「今 reboot していいかどうか」を問い合わせる機能 • reboot timing :内部(自 Node )的に「今 reboot できるタイミングかどうか」を確認する機能 発音は ZIN-kah-tee でいいっぽい Copyright © 2026, Oracle and/or its affiliates 62
63. rpm-ostreeに代わる、bootcという選択肢 rpm-ostree は複数の方法でパッケージの追加が可能 • レイヤリングを使ったローカルでのパッケージ追加 • Treefileを使ったパッケージ込みでのOSTreeイメージの作成 • Containerfileを使ったパッケージ込みでのOSTreeイメージの作成 コンテナイメージとしてOSTreeイメージを配布する際に、 レイヤリングをさせたくない (=完全なイミュータブルを実現したい)場合には多機能すぎる 63 Copyright © 2026, Oracle and/or its affiliates
64. bootc : コンテナネイティブOS管理 Container-native な Immutable OS 管理 OS を完全なコンテナイメージとして管理 • Open Container Initiative 準拠のイメージを「bootable OS」として扱う仕組み • docker run するようなコンテナとは少し違うのがポイント - OCI image には、ファイルシステム・レイヤーが含まれる - ファイルシステムであればOSでも利用できるはず、という思想 rpm-ostree と bootc • rpm-ostree - Node 上での package layering や override が可能 • bootc - OS 全体を OCI image として一元管理するアプローチ 64 Copyright © 2026, Oracle and/or its affiliates OS を Container-like に扱え、 Dockerfile / Containerfile ベースの OS 運用を可能とする
65. Kubernetes Adaption
66. Kubernetes Node と Mutable OS Pod 挙動の差異 • Mutable OS は Kernel の状 態が異なる可能性がある • Pod (Container) は Kernel を共有する Node ごとにOS状態が異なると Podの挙動に差異が生じる スケジューリング • Kubernetes は Node を同一 前提でスケジューリング • Node ごとに OS 状態が異なる と、Pod挙動が変化 配置先NodeによってPodの成功/ 失敗が変化する 障害解析と再現性 • Node 差異が Pod 障害を引 き起こす可能性がある • 特定 Node でしか再現しない 問題が発生する 原因解析や再現環境構築の難易 度が高くなる Copyright © 2026, Oracle and/or its affiliates 66
67. Kubernetes Node と Immutable OS Pod 挙動の差異 • Immutable OS は Kernel の状態が同一になる • Pod (Container) は Kernel を共有する Node ごとにOS状態が異ならず、 Podの挙動に差異が生じない スケジューリング • Kubernetes は Node を同一 前提でスケジューリング • Node ごとに OS 状態が完全に 同一 配置先NodeによってPodの成功/ 失敗が変化しない 障害解析と再現性 • Node 差異がなくなり、 Pod 障害の原因になりにくい • 特定 Node でしか再現しない 問題が起きにくい 原因解析や再現環境構築の難易 度を抑えられる Immutable OS の 「再現性」 が Kubernetes 運用にフィットする最大のポイント Copyright © 2026, Oracle and/or its affiliates 67
68. Immutable OS が Kubernetes にもたらすもの Immutable OS の「同じ Node を何度でも作成可能」な 再現性は、Kubernetes の運用に様々なメリットをもたらす • 交換性 - 問題の起きた Node の交換を容易に • 一貫性 - 構成ドリフトを防ぐ • スケール性 - Node の動的な増減 • 管理性 - Node 管理のシンプル化 • 耐改ざん性 - 意図しない変更を防ぐ 68 Copyright © 2026, Oracle and/or its affiliates 再現性 交換性 一貫性 スケー ル性 管理性 耐改ざ ん性
69. Immutable OS による 「交換前提」の Node 運用 • 異常状態の Node は修復せず廃棄 • OSTree イメージから同一構成の Node を再生成 • SSH による個別修復を排除 • 構成ドリフトを防止 • Kubernetes の Self Healing と高い親和性 Copyright © 2026, Oracle and/or its affiliates 69
70. Immutable OS による「構成ドリフト」の防止 Mutable OS の場合 • Node ごとに手動変更や環境差異が発生 • 「なぜか特定 Node だけ動かない」 Immutable OS の場合 • 全 Node を統一のイメージから生成 • 同一の構成を強制する 70 Copyright © 2026, Oracle and/or its affiliates Node A • パッケージ更新済 • 設定変更あり • 独自ファイルあり Node B • パッケージ未更新 • 設定変更あり • 独自ファイルなし Node C • パッケージ更新済 • 設定変更なし • 独自ファイルあり 構成ドリフトがトラブルの原因と運用負荷に繋がる Node A 構成ドリフトを排除し、運用の安定化を目指す Node B Node C OSTree イメージ
71. Immutable OS による「スケールしやすい」 Node Immutable OS は スケールイン / スケールアウト 時に Node 一貫性を維持可能 • OSTree イメージから同一 Node を自動生成 • スケールアウト時も構成差異を最小化 • Node の追加/削除を安全に実施可能 • Cluster Autoscaler と高い親和性 • Kubernetes の宣言的・自動化運用に適合 71 Copyright © 2026, Oracle and/or its affiliates Cluster Autoscaler Deployment スケール 指示 OSTree イメージ イメージ v1.x.x OSTree イメージ v1.x.x OSTree イメージ v1.x.x OSTree イメージ v1.x.x OSTree イメージ v1.x.x
72. Immutable OS による Node 「管理のシンプル化」 Immutable OS は Node管理をイメージ単位へ集約できる = Single Source of Truth Copyright © 2026, Oracle and/or its affiliates 72 Node A • パッケージ更新済 • 設定変更あり • 独自ファイルあり Node B • パッケージ未更新 • 設定変更あり • 独自ファイルなし Node C • パッケージ更新済 • 設定変更なし • 独自ファイルあり Node A Node B Node C OSTree イメージ 全 Node を個別で管理 OS イメージのみを管理
73. Immutable OS は「改ざんを防ぐ」 • OS領域を read-only 化し、不正変更の永続化を抑止 • /usr など OSTree 管理下の OS 領域が Immutable なので以下を防げる - バイナリ改ざん - 不正 service 配置 - 任意 package の直接導入 - 意図しない OS 設定変更 - バックドア etc. • Node再生成によりクリーンな状態へ迅速に復旧 73 Copyright © 2026, Oracle and/or its affiliates
74. Demo : OSTree with Kubernetes Kubernetes (今回はk3s利用)の worker node を、 OSTree ベースの immutable OS node で構築する 構成: OCI VCN / Subnet ├── Ubuntu VM │ └── k3s server / control plane └── Fedora CoreOS VM └── k3s agent / worker node デモの流れ Butane ↓ Ignition ↓ Fedora CoreOS first boot ↓ SSH key injection ↓ k3s agent auto install ↓ Kubernetes worker node join 74 Copyright © 2026, Oracle and/or its affiliates 設定記述 クラウド上で起動 自動構成
75. 今回の手順 事前準備 • FCOS の OCI 向け image を取得する • qcow2.xz を展開する • OCI Object Storage に image を upload する • OCI Custom Image として import する • k3s server を任意の Compute にインストール 1. k3s server token を取得 2. k3s server の API endpoint を確認 3. Fedora CoreOS 用 Butane config を作る • core ユーザーに SSH public key を投入 • k3s agent を systemd unit で自動インストール • /etc/hostname は書かない - OCI 側が hostname を管理するため、衝突する可能 性がある 4. Butane から Ignition config を生成 5. Ignition config を base64 encode 6. OCI 上で任意の Compute を作成 7. 作成したインスタンスの Boot Volume を事前準備した Custom Image で置き換える • ここでメタデータとしてIgnitionを適用する 75 Copyright © 2026, Oracle and/or its affiliates podman run --rm -it \ -v "$(pwd)":/data \ quay.io/coreos/coreos-installer:release \ download \ -C /data \ -s stable \ -p oraclecloud \ -f qcow2.xz \ -a x86_64
76. 7. の手順がポイント • OCI では、明示的にインスタンスに Metadata としてuser_data を指定できるのは Boot Volume 置換のタイミング • OCI CLI 経由 Compute 作成の API でもおそらく可能だが、GUI的にわかりやすいのが BV 置換 76 Copyright © 2026, Oracle and/or its affiliates