DS3 12ヶ月点検
DS3 を 12 ヶ月点検に出しました。先に冷却水周りを整備してもらったとことは別の、ネットで結構見かけるショップへ。
指摘されたのは、 * 右のタイロットエンドの交換が必要（確かにタイヤがグラグラ） * ブレーキディスクとパッドの交換（ディスクがだいぶ削れて凹んだ感じに）
これに加えて、右パワーウィンドウ不調の話をすると、レギュレーターを交換ですねというお話に。
すべて見積もりを依頼すると…
タイロットエンドは国内在庫なしということで、輸入の見積もりが 40,000 円。しかも納期 3〜5 ヶ月。マジ!? ネット検索すると 4,000 円台で社外品引っかかるよ。他にブログとか検索すると、純正でも 8,000 円台という感じなので、「こういう社外品はダメなん？」と質問すると、1 万程度で社外品で安心のモノが見つかりました、即納です、とのことなので、それでお願いしました。それでもネットで見つかる適当なやつよりは高いし、工賃も…
レギュレーターは、純正でそれなりのお値段。それでお願いしますと言った（部品発注）あと、ネット調べるとリビルド品（中古品）が結構安くで売ってるので、走りに影響ない部分やし、そういうので頼んでみても良かったのかなと。しらんけど。
というわけで、まだ中古車価格を超えてないけど、もうすぐ超えそうなくらいの費用をかけて😂、無事整備されました。
令和 3 年秋期応用情報技術者試験のコンテナ型仮想化に関する問題からコンテナを考える
今さらの話なのですが、「コンテナとは」というお話です。厳密には「コンテナ型仮想化とは」です。
まあ、ほとんどネタなので、細かなところへのツッコミはなしでお願いします😂
X を見てると、徳丸さん（@ockeghem）の気になるポストを見つけました。
この応用情報技術者試験の問題、正答は消去法で答えられるのだけど、「コンテナ型仮想化の説明として、適切」かと言われると、違う、そうじゃないと言いたくなりますね。https://t.co/DIwYo5zm3t
— 徳丸 浩 (@ockeghem) 2025年8月12日
情報処理試験に出た「コンテナ型仮想化」に関する問題です。令和 3 年秋期という結構前の問題なので、IPA さんも「今ならこんな問題出さないよ」という話かもしれませんが。
なんで令和 3 年の問題が今取り上げられていたのかは知りません。
問題は次のような問題です。
正解は「ア」です。うーん、これはとても微妙でモヤモヤする解答ですね。徳丸さんのおっしゃるように消去法で答えられるかもしれませんが、答えられないような気もします。
設問を見ていきましょう。
そもそも、コンテナとは何か? ですが、これは次の記事に説明があります。
プロセスの一部をグループ化し、他のグループやグループに属していないプロセスから隔離した空間で動作させる
つまりプロセスから見えている OS リソースを、他のプロセスから隔離するのがコンテナです。
ア
アを分解すると
- アプリケーションの起動に必要なプログラムやライブラリなどをまとめ、ホスト OS で動作させる
- 独立性を保ちながら複数のアプリケーションを稼働できる
さて、ここで「コンテナ技術って何？」に立ち返ってみましょう。コンテナは OS リソースを他のプロセスから隔離することが本質です。
1 の「アプリケーションの起動に必要なプログラムやライブラリなどをまとめ、ホスト OS で動作させる」はコンテナ技術とはまったく関係ありません。この文章だけだと、rpm や deb などのパッケージ管理システムも当てはまるでしょう。もちろん、コンテナイメージにも当てはまりますが。
2 の「独立性を保ちながら複数のアプリケーションを稼働できる」はコンテナの特徴といえるでしょう。しかし、これだけだと仮想マシンでも同じことができますし、徳丸さんがおっしゃるように、
そう言われてみると、スマホのアプリがぴったり当てはまりますね。アプリごとに必要なライブラリを持っていて、アプリごとにユーザーが別れているので独立しています
— 徳丸 浩 (@ockeghem) 2025年8月12日
のようなスマホアプリでも実現できますし、古くからの chroot でもできますし、snap や Flatpak でも、ホスト OS とは独立した環境でアプリケーションを実行できます（これらも全部簡易的なコンテナと言えるでしょう）。
では、1 と 2 を組み合わせたときにコンテナならではの特徴・機能になるのかというと、そうではありません。特定のコンテナマネージャの実装には当てはまる説明にはなるでしょう。特に今一般的な Docker などのコンテナマネージャ。
2013 年にリリースされた Docker が爆発的に流行し、今、コンテナ技術が一般的になった理由のひとつは、ホスト OS とは独立したプログラムやライブラリをまとめたイメージを展開し、お手軽にホスト OS とは独立した環境で動作させるというものでしょう。イメージの取得と展開も高速になる工夫がありましたし、仮想マシンとは違い、プロセスが起動するだけですので、それが高速に起動できるというところがポイントです。でも、これは Docker の特徴ですし、この Docker の特徴でコンテナならではというのは「高速に起動できる」というところくらいでしょう（あくまで仮想マシンと比べてのお話です）。
このような特徴は、コンテナのファイルシステムがホストのファイルシステムと独立しているところがポイントです。
しかし、Linux で起動するコンテナにおいては、この独立は OS リソースごとに独立（隔離）できます。コンテナのファイルシステムをホストと独立させなくても、その他のリソースを独立させれば立派なコンテナです。
もうひとつ、「アプリケーションの起動に必要なプログラムやライブラリなどをまとめ、ホスト OS で動作させるので、独立性を保」てると書いてるのですが、プログラムやライブラリなどをまとめることは独立性とは関係ありません。先に書いた通り、rpm などのパッケージ管理システムも「プログラムやライブラリなどをまとめてホスト OS 上で動かすための仕組み」です。
ここは、この選択肢を正解としたいなら、「プログラムやライブラリなどをまとめ、ホスト OS とは独立したファイルシステムで動作させるので、独立性を保ちながらアプリケーションを稼働できる」と書くべきでしょう。
まとめると、
- プログラムやライブラリをまとめてホスト OS 上で動作させるのは、コンテナ独自の特徴ではない
- プログラムやライブラリをまとめることはコンテナ技術とは関係ない
- プログラムやライブラリをまとめなくても（コンテナのファイルシステムをホストと独立させなくても）コンテナは稼働できる
- 独立性を保ちながら複数のアプリケーションを稼働するのは、コンテナ独自の特徴ではない
- プログラムやライブラリをまとめただけで独立性が保てるわけではない
となります。
この選択肢は、コンテナならではの特徴ではないけど、コンテナでは（特にメジャーな特定のコンテナマネージャの）特徴となりえることを書いているので、すぐに正解！と飛びつけるかというと微妙な文章であるといえます。また、独立性の根拠が根拠になってない部分も気になるところでしょう。プログラムやライブラリをまとめなくてもコンテナですし、プログラムやライブラリをまとめることと独立性は関係ないのですから、「もしかしたら不正解？」と思っても仕方ないですね。
イ
「イ」の選択肢を見ていきましょう。
- サーバで仮想化ソフトウェアを動かし、
- その上で複数のゲスト OS を稼働させるので、サーバの OS とは異なる OS も稼働できる。
ここでポイントになるのは、
- 仮想化ソフトウェア
- 異なる OS
でしょう。
「仮想化ソフトウェア」は、仮想マシンを動かすための仮想化ソフトウェアを指しており、仮想化ソフトウェアが不要なコンテナは当てはまらないから不正解、とさせたい選択肢にも思えます。
しかし、待ってください。仮想マシンを起動させるための機能は Linux カーネルに標準的に実装されており、別に仮想化ソフトウェアを準備しなくても仮想マシンは起動します。そして、コンテナも同様に Linux カーネルに標準的に実装されており、別にコンテナ用ソフトウェアを準備しなくてもコンテナは起動しますので、Linux カーネル自身が「サーバ仮想化ソフトウェア」と言えるでしょう。
そして、イマドキのコンテナは「アプリケーションコンテナ」と言って、コンテナ内ではアプリケーションを実行するだけなのが普通ですが、コンテナ内で init（systemd）を起動させると、システムとしてコンテナが起動しますので、普通に Linux をインストールした環境や、仮想マシンに Linux をインストールしたのと同じことが実現できます。
このようなコンテナをシステムコンテナといい、Docker 登場以前はシステムコンテナが普通でした。今でも OpenVZ や Incus、LXD といったシステムコンテナ用のコンテナマネージャーはあります。
ここで Linux カーネルの上では「Windows コンテナ」は動かないじゃないか、という反論もあるかと思います。しかし、問題では「異なる OS」と書かれています。例えば Ubuntu の上で Debian や Rocky のシステムコンテナを動かせば「異なる OS」と言えそうですし、Ubuntu の上で Ubuntu を動かしてもシステムとしては別の環境なので「異なる OS」と言うことができるでしょう。
いや、Linux の上で Linux を動かしても「異なる OS」とは言えない、というのも別に間違いではありません。
コンテナのプロセスとしてエミュレーターを動かして別の OS…とか言い出すとキリがないでしょうか。
まとめると、
- コンテナ機能を実装したカーネルはコンテナを動作させるための「仮想化ソフトウェア」であると言える
- 仮想マシンを起動する際も、特別なカーネル・システム・ソフトウェアは不要で、通常の OS を起動するだけで仮想マシンが起動するので、コンテナと変わらない
- システムコンテナを起動すれば、ホスト OS の上で、別のシステムが起動するので「サーバの OS とは異なる OS も稼働できる」と言えなくもない
この選択肢は、「異なる OS も稼働できる」を素直に考えると、間違いとなりますが、システムコンテナの存在を考えると「もしかしたら正解？」と思ってしまう選択肢ですね。特に「ア」の選択肢が微妙なところを考えると、「いや、やっぱりこっちが正解かも？」と、解答者が混乱しても仕方がありません。
ウ
これは情報だけを転送する「リモートデスクトップ」を指す話ですので、明らかに何の迷いもなくコンテナ型仮想化の話ではありません。
確信を持って正解の選択肢の候補から外せます。
エ
この選択肢の文章がとても曖昧で微妙なので難しいところです。この選択肢は日本語としてどう理解するか？が一番難しかったです。
- ホスト OS で仮想化ソフトウェアを動かし、その上で複数のゲスト OS を稼働させる
- 物理サーバへアクセスするにはホスト OS を経由する必要がある
イで説明したとおり、「ホスト OS で仮想化ソフトウェアを動かす」はコンテナでもそう言えるでしょうから、この選択肢もコンテナの説明である可能性があります。
そして、この選択肢の一番の問題（困惑するところ）は「物理サーバへアクセスする」というのがどういう操作なのかが書かれていないことです。物理サーバのデバイスなどの物理的なモノをソフトウェア的に操作すること、という前提だと、次のようなことが考えられます（まあ、まさか物理的なサーバのケーブルを抜き差しするとかが、アクセスするという意味ではないでしょうけど）。
- 普通のシステムコンテナ（= ゲストOS）を複数起動しても、コンテナからは物理サーバへアクセスできないので、物理サーバへはホスト OS を経由する必要がある→コンテナの説明として成立
- ただし、システムコンテナを特権コンテナとして複数起動すると、ホスト OS と同じ操作がコンテナ内でできるため、物理サーバへはホスト OS を経由する必要はない→コンテナの説明としては間違い
- もちろん、仮想マシンとしてゲスト OS を複数稼働しても、ゲスト OS からは物理サーバへはアクセスできないので、物理サーバへはホスト OS を経由する必要がある→仮想マシンの説明としても成立
a、b、c いずれも考えてしまって、これが正解なのか間違いなのかはかなり迷いそうです。特に、a であるようなコンテナ環境が普通でしょうから、「これは正解」と思っても仕方ないですね。（いずれも「複数」起動してもしなくても関係ないですが、問題がそうだったのでそう書いてます）
選択肢を見てみましたが、明らかに適切でないのは「ウ」のみで、「イ」「エ」は適切と言えるケースもある、「ア」は適切だけどコンテナならではの特徴を書いてなし、コンテナで一番重要なポイントである独立性の根拠の説明が不適切ですので正解なのか微妙と思ってしまう可能性がある、と思いました。
まあ、普通の人であれば、徳丸さんがおっしゃるように「消去法で行くと『ア』になる」のでしょうけど、コンテナ技術に精通してる人がこの問題の選択肢を見ると、「イ」「エ」も正解と言えなくもない（もしくは正解がない）と思うはずです。
この問題、「コンテナ技術そのものを説明する選択肢を設けてくれ」と思います。コンテナ型仮想化を理解しているかどうかを問う問題としては、コンテナ技術そのものを書いた選択肢がなく、不適切な問題と言えるでしょう。
作問者には、ぜひ（通称「コンテナ本」である） "Linux Container Book" を一度読んで、設問の問題点を考えてほしいところですね😂。
コンテナ本こと、Linux Container Book シリーズは、技術書典サイトで購入できます。現時点で全 5 巻です。特に第 1 巻を見てほしいところです。
また、上記とまったく同じ内容のインプレス「技術の泉」シリーズから出ている電子書籍（とオンデマンド印刷本）がアマゾンをはじめとする各種オンラインブックサイトから購入できます。
Amazon.co.jp: Linux Container Book (技術の泉シリーズ（NextPublishing）) eBook : 加藤 泰文: 本
インプレス版 "Linux Container Book" は、技術書典版の第 1 巻と同じ内容ですが、技術書典版第 1 巻は新しい章を含む「第2版」が出ていますので、今なら技術書典版がオススメです。
結局自分の本の宣伝がしかったんかい！（はい、そうです😛）
（2025-08-14 追記）
もしかして、コンテナってこんな理解してる人が結構一般的なん?
以前ある人が、「コンテナは要するにtarみたいなものと考えるといいです」と言っていて、要しすぎだろと思ったことを思い出しました。 https://t.co/dYV03qq05M
— 徳丸 浩 (@ockeghem) 2025年8月12日
技術書典 18 で Linux Container Book (5) cgroup v2 コア編を出しました
技術書典 18 で、Linux でコンテナを起動・実行するときに使う Linux カーネルの機能を紹介する第 5 巻を出しました。
第 1 巻は第 2 版を出しているので、技術書典 13 以来 6 冊目の新刊です。
既刊もサークルページで売っていますので、よろしくお願いいたします。
正誤表
誤字脱字などを修正した場合、ここで案内します。
2025-06-14: 細かい修正や調整を行った ver1.0.1 にしました
| 場所（電子版） | 誤 | 正 | 備考 | 修正バージョン |
|---|---|---|---|---|
| P.47, P.82 | エントリ | エントリー | 用語の統一を行うための調整です | v1.0.1 |
| P.57 | 4.5 | 表5.5の"populated"の「実装されたバージョン」が空欄になっていました | v1.0.1 | |
| P.96 | このオプションは、 | （削除） | 7.2の最初から3段落目の冒頭を削除。表現が重複してるようだったので | v1.0.1 |
| P.111 | この操作により、書き込んだcgroupとその子孫のcgroupは次のような状態になります。 | この操作により、書き込んだcgroupとその親、子孫のcgroupは次のような状態になります。 | v1.0.1 | |
| 全体的 | 全体的に細かな表現を調整しています。意味や内容には変化はありません | v1.0.1 | ||
| P.23 | cgruop v1の階層構造 | cgroup v1の階層構造 | 図3.1のキャプション |
技術書典18では、物理本は受注生産としていました。v1.0.1の状態で印刷しますので、お手元に届くのは修正済みのバージョンです。
オフライン当日
6/1 のオフライン会場当日は、たくさんの方に本を手に取っていただきました。（オンラインでも反応を頂いたりしています）
以前からお買い上げいただいていた方が、新刊の見本誌を見ることもなく買っていただけたり、ふらっと通りすがりに寄っていただいて、見本誌を手渡すとじっくり見ていただいたり、私が席を外していないのに見本誌をじっくり見ていただいていたりと、色々な方に来ていただきましたし、見本誌を見ながら色々お話をした方もいて、楽しい時間を過ごせました。
おかげさまで、最後の方まで人が途切れることもなく、お昼を食べる暇もないくらいでした。
ありがとうございました。
第 5 巻について
第 5 巻はついに cgroup v2 です。最近の distro では v2 がデフォルトであることが多く、これまでは v1 の本を「これで学べば v2 でも役立ちます」と案内していたのが、ついに「これからは v2 ですからこちらで」と言えるようになりました。でも、コア機能だけで、コントローラーによるリソース制御の話は全くないので、少し微妙な位置づけではありました。引き続きコントローラー編も出せるように連載記事もがんばって書きます。
v1 は 130 ページほどではあったものの、1 冊ですべて書けました（一部書けてない機能がありますが）。しかし、v2 はコアが大幅に整理され、きちんと規約を決めた上で実装されたので、コアの機能のみ説明するだけで v1 と同様の 130 ページほどに達してしまいました。
コントローラーの説明がまだ書けてないというのもありますが、上記のような理由でコア編だけで第 5 巻を出すことにしました。
正直、cgroup v2 のコア機能の動きや設定について直接ユーザーが触ることはないでしょうし、リソース制限にも関係ない部分の解説ですから、「機能がどうしても知りたい」という方以外に、実用的にこの本を活かせるという方は想定しづらいと思っています。コンテナエンジンを書いたり、systemd を開発したりという方以外の実用性はないのでは？と思います（これらの方はすでにご存知の知識のはずです）。😂
それでも、機能オタクが細かく機能を説明する本というのは、技術書典のような場に出す同人本にはぴったりのタイプの本ではないでしょうか。
役に立つかわからない cgroup v2 コアの機能を本書で学び、私が調べる前に私に新機能を教えてくださったり、一緒に機能を調べたりできる方が現れることを期待しています。
このブログ記事を書いている時点では、まだ技術書典 18 は開催中です。引き続き Linux Container Book シリーズをお願いいたします。
6.14 カーネルで cgroup に追加された dmem コントローラー
6.14 カーネルで、cgroup に久々に新しいコントローラーが追加されました。
追加されたのはデバイスメモリーコントローラー = "dmem" コントローラーです。
デバイスのメモリー領域を cgroup で管理するためのコントローラーです。現時点では（?）、GPU のメモリーと、GPU ドライバーが割り当てた CPU メモリーが cgroup に計上されて、制限がかかるようです。
将来的に GPU 以外でも使うかも? ってことで汎用的な名前になってるのでしょうか?（しらんけど）
6.14 カーネルで dmem コントローラーを有効にしてカーネルをビルドすると、次のように cgroup.controllers ファイルに dmem という文字列が現れます。そして、root cgroup には、dmem.capacity と dmem.current という 2 つのファイルが現れます。
$ cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma misc dmem $ ( cd /sys/fs/cgroup && ls dmem.* ) dmem.capacity dmem.current
cgroup を作成し、子 cgroup で dmem コントローラーを使えるようにすると、子 cgroup にも dmem. で始まるファイルが出現します。
$ sudo mkdir /sys/fs/cgroup/test01 $ echo "+dmem" | sudo tee /sys/fs/cgroup/cgroup.subtree_control +dmem $ cat /sys/fs/cgroup/cgroup.subtree_control dmem $ cat /sys/fs/cgroup/test01/cgroup.controllers dmem $ ( cd /sys/fs/cgroup/test01/ && ls dmem.* ) dmem.current dmem.low dmem.max dmem.min
表. dmem コントローラーのインターフェースファイル
| ファイル名 | 機能 | 操作 |
|---|---|---|
dmem.capacity |
デバイスメモリーの最大容量が記載される。root cgroup のみに存在 | 読み取り専用 |
dmem.current |
現在のリソース利用状況が記載される | 読み取り専用 |
dmem.max |
memory.max と同じ |
読み書き |
dmem.min |
memory.min と同じ |
読み書き |
dmem.low |
memory.low と同じ |
読み書き |
dmem.current はカーネル付属文書では「root 以外のすべての cgroup」と書いてあるけど、root cgroup にもいますね。
パッチ
私の手元には dmem コントローラーを使える環境がない（出現したファイルすべての中身が空）ので、パッチを見てみましょう。ここからは素人の考察ですので、間違えてる可能性大です。
7 つのパッチから構成されており、"0/7" はこちらです。
こちらのパッチが、dmem コントローラーそのものでしょうか。これらの関数を使うと、dmem コントローラーの制限が効くようになるようですね。
dmm コントローラー用のヘルパーが、次のパッチで drm に追加されています。
リソース制御は TTM で処理するため、TTM に色々処理が追加されています。TTM は、専用メモリーを備えたアクセラレーターデバイス用のメモリーマネージャーらしいです。ここで実際のリソース制限とかがかかるんでしょうかね。
現時点では Intel の Xe ドライバーでのみ実装されているようです。そのパッチを見ると、ドライバーへの変更は少ししかありません。ここで実際のメモリーを登録する感じですかね。
drm と ttm でリソース制御の部分は吸収されて、各ドライバーは登録だけすれば良い感じでしょうか。今後、他のドライバーにも実装されていくのでしょうね。
また、手元で試せるようになったら試してみたいですね。どうやって試すのかしらんけどw
参考
DS3冷却水漏れ修理とそれに伴う整備
昨年、2012 年式のシトロエン DS3 スポーツシックを中古で買ってしばらく経ちます。快調には走っていましたが、気になるところもありました。
この時期の DS3 に搭載されているエンジンで、よくあるトラブルが冷却水の漏れです。ネットで検索しても多数出てきます。
冷却水系の配管が樹脂製で、耐久性がイマイチで劣化し、水漏れが起こるようです。部品交換のために連結部分を外すと、外した先の樹脂部品も割れたりして、結局そう取っ替えになることもあるようで、今回の私の愛車も同じような感じでした。
最初に持っていったときは、ボンネットを開けて上から時間をかけて見てもらい、見積もりをもらいました。リザーバタンクからラジエターにつながる配管からの水漏れが確認されたのと、それ以外にカムカバーからのオイル漏れ、ウォーターポンプのプーリーに亀裂が入ってるのが見えたので、それも合わせて整備をお願いしていました。
入庫は 12 月中旬、その後リフトアップして細かく調べると、さらに様々な箇所からの水漏れが確認されたとのことで、見積額が x2 くらいになりました（中古で買った価格の半額くらい）。整備しない理由はないので、すべて部品交換をお願いしました。
結局、すべて交換が済んで連絡があったのが 1 月中旬。その後もいくつかの部品に傷みがあるとのことで +2 万ほど。
今回で冷却水周りの配管は 95% 程度交換したとのことでした。
交換箇所はこんな感じ。
交換した部品たち。
