Scribble at 2023-07-10 14:13:32 Last modified: 2023-07-12 08:31:45

某巨大駅ビルでクーポンを発行している一部のサイトだけを別のサーバで運用し続けることになり、さくらインターネットの VPS で僕がサーバ構築と httpd などの設定を行うことになった。ウェブ制作会社の甘い収益構造として相変わらずの話だが、セキュリティやサーバのメンテナンスには全く予算がないらしいので、初期設定で10万円ていどを請求できるのが限界のようだ。もちろん僕の工数見積もりだと２人日にすらならない費用だが、サービスとして２人日は使ってサーバを構築してあげようというわけである。そしてメンテナンスを要するソフトウェアのアップデートなどは、別に予算をもらって作業するというわけである（こういう作業とか日々の工数を「エンジニアの矜持」だの「運用責任」だのと、たかが数百万の予算でわれわれ技術者が自分の子供を面倒見るように当たり前にやる「べき」だと言い放つような、クライアントの傲慢や思い込みや無知無教養を許すからこそ、ウェブの制作会社なんてどこもまともな粗利が残らないのだ）。

さて VPS に採用する OS なのだが、もちろん SAKURA（冒頭では、名詞の直前に読点あるので「さくらインターネット」と表記したが、他の品詞と区別がつきにくい場合は、やはり "SAKURA" と書いて膠着語独特の読み辛さを軽減する）では複数の OS イメージを用意していて、僕が大好きな FreeBSD もちゃんと用意されている。でも、今回は UNIX ではなく Linux としておく。このところ Amazon Linux2 ばかり使っていて、他の Linux のディストリビューションも使っておきたいし、CentOS の開発が終了してから RedHat 系の（Amazon Linux ではない）OS を触っていないというのも一つの理由である。ちなみに、Amazon Linux のベースになっている OS がなんなのかを調べると、株式会社アクロビジョンという会社が「結局はわかりませんでした」という、芸能人の個人情報について書いていると称して「わかりませんでした」と書いてはアクセスを稼ぐクソみたいなブログと同じ事をやって、検索の上位に上がっているのは残念なことである。いくら儲かっていないからといって、ベンダーがこんな記事をばら撒いたり放置するのは、どんなものだろうか。ていうか、ちゃんと調べたら RHEL だと分かるはずだけどねぇ（なお、次期バージョンの Amazon Linux 2023 では RHEL から Fedora にベースが代わるらしい）。

さて、そういうことで CentOS 以降の RedHat 系の OS を選ぶことにしたのだが、ご存じのように CentOS Stream、AlmaLinux、そして Rocky Linux という三つの選択肢がある。もう最近の広告代理店案件では、大手企業や上場企業でも、RHEL を選ぶ予算なんてないからね。そして、調べてみると呆れてしまうのだが、馬鹿が何の条件も書かずに、「やってみた」式に CentOS Stream を公開サーバヘ投入したりする。こういう馬鹿の真似はしないようにしよう（どうでもいいが、ATOK はやたらと漢語をひらがなで変換しようとするが、小学生に最適化された IME なのか？）。OS 開発・メンテナンスの「ストリーム」という概念を理解していない連中というのは、まさしく PHP という処理系を開発している人々の仕事を理解しないで WordPress のテンプレート・タグをいじくり回しているデザイナーとかと同じで、本当は他人様からお金をいただいて OS を構築したり運用する能力なんてない。さくらインターネットがステージング環境に使うものと想定して CentOS Stream を提供するのは勝手だが、こんなアップ・ストリームで使う OS を、しっかりした運用体制もなしに、ましてや個人でサーバをメンテナンスするような状況で、プロダクション・サーバの OS として採用するものではない。

ということで、まともなサーバ・エンジニアなら AlmaLinux か Rocky Linux のどちらかを選ぶのが妥当なところだろう。だが、これらのどちらを選ぶかは、正直なところ難しい。明らかな優劣や、優劣とまではいかなくても運用上の特徴というものがないからだ。もう少し調べてから決めることにするが（もちろんスキルとしては僕はどちらでも使える。RedHat 系の Linux にしたって、もう20年は使っている）、その工数そのものが無駄であるという可能性も高い。

[追記：2023-07-12] ウェブの制作では残念ながらよくあることだし、特に僕らのような大手の企業を相手にしている場合は頻繁にあることなのだが、見積もりまでクライアントに提出していたにもかかわらず、いまになって相手から「内規によって他のサーバ会社を使えない」という回答がやってきた。よって、CPI で別のプランを借り直すという選択しかできなくなった。レンタル・サーバの契約と設定だけなので、本来なら「ウェブ」ディレクターを名乗る彼らでも、本来はできるような作業だ。われわれのようなエンジニアが手を動かすまでのことでもないが、残念ながら日本のウェブ・ディレクターは実質的には「営業」＋「プランナー」＋「進捗係」という、販売寄りの悪魔合・・・もとい、ジェネラリストであるため、制作の実務なんて殆ど分かっていなかったりする。元デザイナーとかコーダという人は多いけれど、その大半はサーバやネットワークやコンピュータの知識なんて（コーダですら）ないし、雑に言えばベンダーの「SE」と似たようなものだ。なので、CPI のような技術的な知識はもちろん、「魔宮」あるいは「ダンジョン」と言っていいような、無駄に複雑で、どう考えても違う会社や部署が実装したとしか思えないバラバラなデザインと使い勝手の管理画面を何層にも使い分けなくてはいけないという、下らない経験が必要なサービスを相手にする場合は、僕らのような技術的に突出した人間というだけではなく、それなりに CPI を使った経験がある人しか扱えないわけである。