===== 2022年8月22日 =====
結論から書きます。
- 日本国内での Linuxサーバー導入は RedHat一択
- クライアントは殆ど Windowsで Linuxの考慮は必要なし
- snapは生き残る
当ホームページでは、サーバーのお勉強に Ubuntu Server 22.04を多用しておりますが、環境構築作業を重ね、いくつもの OSSの導入を進めるうち、薄っすらと疑問を持ち始めていることがあります。
Ubuntuでは snapパッケージでのソフト導入を推進、かつそれにシフトしている一方で、個人的に snapが扱い辛いと感じているからで、仕事として Ubuntu Serverを導入することを顧客に勧められるか迷っているのです。
日経系の雑誌が Ubuntuの導入記事を多く載せていますし、Linux界隈では比較的情報が入りやすいこともあって、Linux初心者は Ubuntuから入って「心の Linux」といえば Ubuntuという方が多いのではないかと思います。
私はこれまで特段の問題も感じず、新しいカーネルや OSSの新しいバージョンが RedHat系(主に CentOS)に比べて早く提供されるのが魅力で Ubuntuを愛用してきたのですが、22.04から Firefoxは snap版のみの提供となるなど、snap利用へのムーヴが強くなってきたためか、若干の違和感を感じ始めています。
ところで Ubuntuを作っているのはどんな人達なのでしょうか。
Canonical(カノニカル)という集団なんですが、Wikiによれば英国に本拠を置く世界に支社を持つ営利企業で、Ubuntuを導入している企業へのサポートやエンジニアのトレーニングを収益元としているようです。
RedHatを除く他の Linuxディストリビューションの多くが有志の集まり(コミュニティ)に拠っているのとちょっと違いますね。
次に snapについて。
Linux界では、プログラムの配布形式が debパッケージ・rpmパッケージに二分されていて、前者が利用されているのが Debian系ディストリビューション、後者が RedHat系ディストリビューションと呼ばれていると認識しています。
Ubuntuは aptコマンドで debパッケージを利用する Debian系ディストリです。
ただ数年前より Canonicalはこれに代わるパッケージングシステムとして snapを開発して Ubuntuへの導入を進めており、特に最新版の 22.04からその色合いを濃くしています。
snapは Flatpackという、やはり別のパッケージングシステムと共に、サンドボックス型と呼ばれる新しい観念のパッケージングをしています。
サンドボックス型とは何かというと、対象のアプリケーション以外の所に影響を与えないよう閉じられた環境でしか動かないようにするもので、一部ではソフトの仮想化と呼んでいるようです。
Dockerを使った事がある方は、コンテナと似たような分離環境になっていると考えれば分かりやすいかと思います。
なぜ今サンドボックスなのかというと、一応は従来の deb/rpmが持っている課題の解決を求めている模様です。
- 開発者は依存する共有ライブラリのバージョンとの兼ね合いを調整するのが大変。
必要なものを全て同梱すれば開発者は楽になる＝ソフト提供の垣根が下がってソフトも増える＝皆ハッピー。 - 他のソフトのファイルを読み書きできてしまう懸念を払拭するため、利用できるディレクトリを制限してしまえば良い。
- (必要なものを全部自前で持ってるから)ディストリビューションに関係なく動くよ。
- Ubuntuでは Canonicalに配布元を一元化して信用あるパッケージしか置かないから怪しげなパッケージないし。
こんな感じで、コンセプトは素晴らしいのです。
snapについて、米国の掲示板(?)の Reddit にこんなスレがあったので、一通り読んでみました。
Why do Linux users tend to hate Snaps?
様々な意見が交わされています。
タイトルから snapを嫌っている人の書き込みに偏っていることを考慮しても、有用な意見が多く拾えました。
厭われる理由を箇条書きにするとこんな感じでしょうか。
- ソフト起動時に圧縮されたデータを展開するのでシット遅い。
- 共通ライブラリであるはずのものを各パッケージが自前で持つのでディスクを喰い過ぎるアース。(gimpは1GB)
- 動作がアースなブラックボックス化していて、Linuxの思想とは相反する。
- 配布をCanonicalが牛耳ってるのは Linuxの思想とは相反する。市場を独占したいシットだろ。
- まるでマイクロソフトを Linuxに持ち込まれたようなもので、アースでシットだ。
- Canonicalは新しいもので古いものを駆逐するが、いつも途中で投げ出す。(例：Ubuntu Touch) ブルシットだろ？
- ソフトのアップデートが強制で、しない選択肢がない。ノーウェイだ。
概ね趣味ユースのデスクトップユーザー、自由を良し(束縛は悪)とし、営利企業が嫌いな Linux民の意見が多いと思われ、当HPでやろうとしているサーバーとしての利用を目的とすると問題にはならない点が多いのですが、大体はアースとシットの応酬でした。
但し最後の「強制アップデート」は確かにサーバー運用では致命的です。
強制アップデートは、Lubuntu 22.04を使っていて私も実際にこの目で見ているのですが「Firefoxのアップデートまであと13日」なんてメッセージが出てきて「いいえ」ボタンもないんですね。
放っておくといつの間にかアップデートしています。
Firefoxならまだ良いですが、サービスを提供するサーバープログラムを勝手にアップデートされて、いざの時のバージョン戻しがやや不安定ともなると、Ubuntu Serverを業務で使うわけにはいかなくなってしまいます。
企業が使うサーバーの運用保守の世界では(少なくとも日本では)、保守を受けられないハード・ソフトの利用を許す企業は少ないのではないでしょうか。
OSサポートを行うことで Canonicalが収益を上げられるのは、海外でも同じと言うことかも知れません。
日本の Linuxサーバーの殆どが RedHat Enterprise Linux(RHEL)なのも、サポートがあるよとサーバーベンダーと一緒になって売り込んでいるからだと思います。
一方 Canonicalは日本で日本語サービスを強力に展開していないように感じますね。
こちらの企業のようにサポートを請け負っているところもありはしますが。
株式会社SRA Ubuntuサポートサービス
Redditでは、Ubuntuデスクトップユーザー相手には「snapの仕組み自体を削除すれば良い」とアドバイスする向きがあるも、企業のサーバーを運用する者は OSSの本家サイトのリポジトリならいざ知らず、サポート外のリポジトリからパッケージを入れる訳にも行きません。
その一方で Canonicalが OSSの最新バージョン提供を段々と snap版に寄せてきているのには歯がゆいところがあります。
勉強してsnapに精通せい！
と言われてしまえばそれまでなのですが、Canonicalが提供する snapパッケージが特殊なのか分かりませんが、OSSの元の動作にちょっと追加があるんですね。
癖があると言いますか。
そしてその情報が無いか、私が見つけられていないかで、導入までとにかく時間と手間がかかる。
ここは業務でやってるわけではないので「いずれ解決するかも知れない」と構えていられますが、納期のある業務でこれでは辛いです。
また、癖があるということは覚えることが増えるのでして、設計・運用要員の教育コストが大きくなりますし、市場からエンジニアを引っ張ってくるのも難しくなります。
そこまでして、RHELではなく Ubuntuを使う理由はどこにありや？
という顧客や上司の質問に対して、中々明確な回答をできるようには思えませんで、「じゃ RHEL9にしようか。」と安易な結論に至るケースがしばらく続きそうです。
ただ Ubuntuの回りを俯瞰してみれば「Firefoxを Chromeや Edgeから覗き見られるのを防ぐため snap版で提供したい」と言っているのは開発元の Mozillaらしいですし、マイクロソフトは Canonical経由で(snapではなくdebだが) .NETの提供をしましたよね。
Azureの収益がメインとなってしまっているマイクロソフトは、WSL2にも見えるように Ubuntuを足がかりに Linux界への進出を目論んでいるように見えますし、今はこの業界の勢力図が変わりつつあり、その中心に Canonicalの snap問題があるようにも思えます。
Redditではそこそこの人数が「Canonicalはデスクトップより企業向けのサーバー用途に力を入れようとしている」と論じていて、Canonicalとマイクロソフトの動き次第で、日本の Linuxサーバーといえば Ubuntuという日が来るのかも知れません。
最後に、クライアントPCは…Windowsで良いんじゃないですかね。
無理にLinuxを使わなくても。
Redditでお勧めされてたのは、Linux Mintでした。
Ubuntuから snapを抜いたものだからだそうです。
いやはや、嫌われてますね、snap。
不幸な子。
===== 2023年6月28日 =====
先日 RedHatがちょっと気になる方針を発表して、RHEL界隈に動揺が走っている気がします。
このリンク先が問題のブログポストです。
Furthering the evolution of CentOS Stream
更に追加されたブログポストです。
Red Hat’s commitment to open source: A response to the git.centos.org changes
Publickeyさんでも取り上げておられて、日本語で上手に纏めておられます。
Red HatがクローンOSベンダを非難、「付加価値もなくコードをリビルドするだけなら、それはオープンソースに対する脅威だ」と
結果として、RHELのそのまんまとは言えなくなってしまった CentOS Streamを唯一のソース開示対象にしたがっていると認識しています。
私は RHELのお勉強環境として Rocky Linuxを愛用しているのですが、こういった RHELのクローンOSにとっては大打撃だと思います。
RHELの本音は「REHLは手間暇かけて安定させているのにフリーライドするな」ということなんだと思いますので仕方ない処置と思いますけど、クローンOSを使っている立場としては困った事になってきました。
現時点ではクローンOS側は「大丈夫!」と沈静化を図っていますが、CentOS Streamの話が出たのがそもそもの RHELブチギレ案件だったのだと思いました。
このキレっぷりからはクローンOSで儲ける輩を一掃したい意図が見え、タダで RHELモドキを使いたい勢に対して、①金を払って RHELを使うか、②他の OSへ去るか の選択を迫ってくるのであろうか？ と思う所であります。
RHEL周りの勢力図が変わるかも知れず、それが Ubuntu Serverに流れてくるかも知れないと期待をしております。
===== 2024年1月18日 =====
その後大きな動きがあった訳ではないのですが、半年近く経ちましたので。
Ubuntuに関しては、今度の春に出る 24.04で、Canonicalが「snapを外す事を考えてる」とか、オール snapの「Desktop」「も」引き続き出るよって話が聞こえてきています。
これは何を意味するのか。
snapが外れた Desktop/Serverがリリースされる一方で、全てのパッケージが snapで提供される Desktopも出るってことなんでしょうか。
Desktopの方は好きにしてもらうとして、私としては Serverが気になります。
「今だって debパッケージをインストールすれば良いじゃん」って話ではないんですね。
もし仕事で使うなら Canonicalが提供しているリポジトリのパッケージを使いたく、Debianのリポジトリは避けたい。
Canonicalは snapと aptのリポジトリを持っていますが、以前は snapにしか最新版が提供されなかったものが結構ありました。
これが 24.04では aptリポジトリにも常に snapと同じ最新版のパッケージが提供されるかどうか、ここが大事だと思います。
ただそこが解決されるとしても、国内で Ubuntu Serverを使おうって企業が増えなさそうではあります。
これは相変わらずですね。
インターネットでは Ubuntu Serverを利用している事例は多く出るようになってきていますが、あくまで個人の話で法人でってことではありません。
そこで気になるのは RHELの方の動向なんですが、RHEL(IBM)は OSのソースコードを一般に公開しないようにし、保守を受けているユーザーだけに限定すること、そのソースコードを使って別OSを作ることを禁止する方向に進もうとしているとどこかで読みました。
ちょっと前に Oracleと SuSEが RHEL互換OSを出すとか、そこに Rockyも参画するとか言われましたね。
今はそれぞれに策を巡らして CentOSの代替を狙ってるようですが、一部はバイナリ互換を目指すなどとトーンダウンしてしまっています。
CentOSを使っていた(RHELの金は払いたくない)法人は
- 諦めて RHELを買う
- 完全互換ではないがフリーの OSを使う
- Ubuntuに鞍替えする
- 古いまま CentOSを使い続ける
これらのどれかになるんでしょうが、今時点では全く先が見えません。
サーバーをやる人は、引き続き動向を見守る必要がありますね。
私は春に Ubuntu 24.04がどうなるのか、それを待っていますが、お勉強のベースにする OSをはっきりできないのは困りますね。
===== 2024年5月7日 =====
2024年4月25日に待ちに待った Ubuntu 24.04がリリースされ、これを使ってサーバー構築などしています。
一番気になっていた snapの行方ですが、今の所 22.04の頃と余り変わらないように感じています。
今年に入ってからは aptリポジトリのパッケージのバージョンも新しいものが入っているのが分かってきて、24.04用の aptリポジトリでも同様とは思います。
結局 24.04においても snap版パッケージと apt版バッケージの選択の呪縛からは逃れられないようです。
ですが 2024年5月6日に上げた「Jenkinsインストール」では、snap版の Jenkinsで待ち受けるポート番号の変更に四苦八苦した挙句に完遂できないという結果に終わってしまいました。
snap版パッケージの特異性とその仕様に対する情報量の少なさが利用者を減らし、また情報が少なくなるという悪循環に陥っているのではないかと思います。
Desktop版で Canonicalが想定する使い方に固定されるのには利があるように思いますが、サーバーでカスタマイズが困難になるのは結構痛いです。
今後 Ubuntu Serverを使い続ける上での回避策としては「Server版では aptリポジトリに絞る」という方法を採用する線もありますが、Canonicalが必ずしもユーザーが欲しい OSSの aptバッケージを用意してくれるかは不明です。
Debianのリポジトリを利用する事もできますが、多分 Canonicalのサポートは受けられないのだろうと思います。
それなら最初から Debianを使えば良い訳です。
24.04 Serverはこれからも使うつもりですが、企業ユースにおいては余りオススメできないかなぁ…というのが本音ですね。
一方で対抗馬たる RHELですが、CentOSのすったもんだの落とし所がまだ決まっておらず、Ver.9.4がリリースされたものの、状況は以前と変わらないカオスのままです。
RHELを擁する IBMは先日 Terraform(HashiCorp)を買収しました。
これで IBMは IaCのツールとして、Ansible・Terraformを持つこととなり、これらツールと RHELとの関わりも強くなるんだと思います。
サーバーエンジニアとして RHEL周りに関わるには、今後ここら辺は何かあるかも知れませんね。
現時点での結論として「日本の企業ユースでは RHEL一択」という考えは変わってないのですが、互換 OSを謳った連中は早く大同団結してよって思っています。
困ったものですね。
===== 2024年5月12日 =====
Ubuntuでの snapパッケージの扱いに大きな変化が出ない限り、これから 2年弱は基本的に、Serverには aptパッケージ、 クライアントには snapパッケージ、こういうスタイルで行こうと思います。
例外として、Canonicalまたはソフトウェア開発側が snapパッケージを優先しているものはそちらに従うことにしようかと。
Canonicalが開発元になっている microk8s、開発元が snapを良しとしている Firefoxなんかです。
ただどうしても snapの問題が大きくて、導入や運用に苦労しか無いと思われるものは aptに逃げようと思います。
こちらの例は Selenium Gridで使う Firefoxなんかですかね。
引き続き状況の見定めは必要でしょう。