Scribble at 2024-11-11 19:27:58 Last modified: unmodified

これまで WordPress でサイトを構築してきた何件かのプロジェクトで、主に SAKURA のクラウドで Kusanagi を OS イメージとして選択してきたのだけれど、ちょっとやめようかと思っている。最大の理由は、何か課題なりトラブルが生じたときに、Kusanagi はあらゆる設定ファイルが通常の WordPress や RedHat 系の OS とは違う場所にあって、しかも分散していたりするので、設定変更が非常にやりにくいということ。そして、そういうことを一元的に実行できるはずの kusanagi というコマンドがぜんぜん使い物にならないくらい貧弱な機能しかもっていないこと。加えて、こうした状況に対応するための Kusanagi に関するドキュメントが全く貧弱で使い物にならず、書かれている解説も不正確で意味不明なところが多いということだ（たとえば、コマンドのオプションだけ表記して説明していたりするが、そのオプションをどういうコマンドに付けるのかが分からない。"[--status]" とだけ書いてあるが、それは "kusanagi php --status" のことなのか、それとも "kusanagi --status php" のことなのか。これ、コマンドを打ち間違えるとプロセスが再起動したり、PHP のバージョンが変更されてしまうので、「試し打ち」ができないんだよね）。

さきほどは、WordPress でファイルのアップロードをしたいというクライアントから、最大サイズが 16MB なので、24MB のファイルをアップロードできるようにしたいと言われたのだが、Kusanagi のサーバにある PHP の設定ファイルは最低でも３個所くらいに分散してあり、更にはどれを変更しても設定が変わらないという困った状況に陥ったりする。そして、最後にウェブで検索してようやく見つけた、DocumentRoot の直下に ".user.ini" というファイルを作って、そこに php.ini で記述するような設定を書けば即座に反映されるという情報でなんとか対応できた。この ".user.ini" ファイルは、Kusanagi のドキュメントのどこにも書いてない（素人が解説してるページで ".user.ini" を知ったのだが、この人はサーバのエンジニアでもないのにどうやって知ったのだろう）。

と、こんな具合で、順調に動いているときはともかく、何かあったときに調査や対応にひどく時間がかかってしまう。僕らのように RedHat 8 の頃から Linux を使っているようなエンジニアですら、標準的な OS で PHP や Apache を使っていれば数分で終わってしまうような作業が、１時間以上もかかるのだ。これでは、もっと深刻な状況に見舞われたときの対応ができるかどうか不安がある。かといって、こんな特殊な仕様の OS にだけしか通用しない知識を習得するなんて無駄が多すぎる。殆ど日本人の書いたリソースしか当てにできないからだ。ということで、問題なく動いていれば堅牢で信頼できるのだとは思うし、実際によく出来た OS だとは思うが、やはりサーバ管理というものは通常運転だけで OS を選んではいけない。