🚤

コンテナ時代にLinux知識はレガシー化するの?~トレンドに「Linux」が入った日に思ったこと~

2025/02/17に公開

今日(2025年2月16日)、
XでLinuxがトレンドに入っていた。コンテナが普及してきた中で、Linux自体の学習をどうするか、という話とかが中心の模様。議論の中で出てきたアイデアを自分なりに解釈して書いてみた。

結論

  • Linuxを学習する重要度・優先度は 一部の役割の人達にとって下がっている
    • 背景:コンテナなどの発達によりサーバー構築作業が必要な場面が 減った から

また、これはLinuxに限らず、あらゆる場面で、
技術の優先度や位置づけの変化が、(もともとあったが加速しているという意味で)起きている

コンテナの普及

VMがあったのになぜ、さらにコンテナが普及した?
 → コンテナの技術的な特性は当然ながら
 → 次項「同じ」の単位としてぴったりだったという面はありそう
   当初から狙ったわけじゃ無いかもしれないけど。世に出したらそうだった

「同じ」は便利。だけど、作るもの

システムを作るフローの中で、「同じ」環境をつくることは重要
「同じ」であることを求めるのは、環境差異によるトラブルや追加作業を避けたいから で効率に大きく影響する
 → ローカルではちゃんと動いているのに、開発サーバーに置くと動かない。これは面倒だし嫌。

無限に「同じ」がいいか

そうはいっても、じゃあ、CPUまで同じにすべき、とは思わない
ドライバ類ならまだしも、Webサーバーが
「Intel Core Ultra 5 245KFでしか動きませんCore Ultra 7 265KFは非対応です」
これは、使い物にならない。性能不足ならしょうがないが
OS?それも、Ununtuで動くならDebianでもRHELでもAmazon Linuxでも動いて欲しいし、開発効率考えるならMacでも動いて欲しい
言語のバージョン?
まあ、Node 18で動くけど Node 22では動かない。これはしょうがないと思える
でも、Node 22同士なら動いて欲しい
どうも、この辺りが「同じ」のラインとしてよさそう

※これはアプリ側の感覚。ただし、インフラとアプリは対になっているもの。相互に独立するものでもない

そしてこう思う
(あれ?コンテナイメージを選ぶ粒度に似ているような)

コンテナの粒度のちょうどよさ

この変わっても動いて欲しいラインとコンテナの抽象化のラインを比べると、
コンテナがちょうどいいラインで抽象化をしていることが分かる
従来のVMは、粒度がマシンと似すぎていたのかも知れない
コンテナは、そこから先は変わっても影響されたくない、ってラインをきれいに抽象化した

「Problem of 24 hours per day」

アプリエンジニアだってLinux勉強したい。シェルは心落ち着く。
CTOだって、エンジニアが勉強する内容をとやかく言いたくない。
でも、仕事だから、限られた時間の中で、セキュリティも安定性も、ユーザビリティもコンバージョンレートも何もかも一定の水準を満たしたサービスを作らねば。

Linuxは難しい、フロントは難しい、全部難しい

汎用OSであるUbuntuやRHELは、サーバー向けエディションであっても、
妥当にセットアップするのは極めて難しい
汎用故にいろいろなものが入って動いている
UbuntuやRHELの全てを把握している人なんてどれほどいるんだろうか
現実に影響がある範囲をコントロールしている、というのが実情だと思う

アプリ側はアプリ側で、フロントエンドはものすごい速さで変化する技術への追従や、直接ユーザーの目に触れることから来る難しさと対峙している
バックエンドも多要素認証がふつうになり、スパム対策関連のメール対応・変化が早くなった税制や取引関連の規則・キャッシュレス、LLMなど四方八方から考慮すべきことが増えている

我々は「マッシュ達」や「デク達」だ

かつて、サービスの技術要素を全て把握するというのは、「当たり前」だった
しかし、今は、一人が全てやるには、すべきことが多すぎる


ヒロアカの「デク」は仲間の力を借りながら、なんとかやり遂げる
マッシュルの「マッシュ」ですら、中盤以降、仲間の力なしには対応できなくなっている
ワンパンマンの「サイタマ」のように、全て自分で対応できるというのは非現実的で、だからこそワンパンマンという設定の面白みが生まれている


そんなことを思いながら、コンテナは必要に迫られた分業をかなりの部分サポートしてくれる存在に見えている

つまりLinuxの知識の価値はあるのないの?

もちろん、価値がある。
ただし、 過去に比べ、その価値が業務に紐付きやすい人とそうでない人が、エンジニアの中でも分かれて きている。


一旦、一定水準までは、コンテナ移行の部分をコントロールするだけでできる、ここまでできるだけでも価値があるし、分業の中での自分の仕事を進められる

もちろん、本番サーバーで動くコンテナに入ってトラブルシュートするしかない自体は起きうる
そういう場合はコンテナの場合、IaCを含めたコードを作り直して再デプロイするのが通常だが、
それでも、中に入ってLinuxの知識を総動員しないと対応できない自体は起きうる

そもそも、コンテナにはボトルネックがあるし、コンテナを使うにしても、
詳細にコントロールするためにはLinuxを知らないとできない

セキュリティの領域になるともはや、Linuxに習熟し、かつセキュリティにも高い知見を持つものでないと対応できない


つまり、Linuxを深く知るエンジニアは必要であり続ける

分業といっても、実際は、
このような人が、ある程度汎用に使えるデプロイ用イメージを作り、その上にアプリを構築するということ
そもそも Alpine LinuxもRHCOSもBottlerocketもVoid LinuxもnixOSも、当然、Linuxに対する深い知識を持つエンジニアが作っている
だから、Linuxの知識は、役割によっては優先順位が下がり、
役割によっては変わらない、そして上がった人もいる

Linuxを深く知るエンジニアは必要であり、
でも、その数は減る

それ以上でもそれ以下でもない

ポエム

あらゆる技術は何かのためにあり、
何かを解決する技術は、何かの作業の意味を変える
それは、エンジニアの営為であり、良いも悪いもない
経験と知識に基づいて適切に位置づければ良いと思う

Discussion