久しぶりのセルフホストな記事。
このブログはまだWordPressなんですが、サブブログをWordPressからHugoに移行しました。理由は主に昨今のサイバー攻撃の激化のためです。WordPressが悪いというわけではないのですが、アタックサーフェスの大きさやPHPの特性を考えると、正直これからの時代厳しいように思われました。毎日のように「プラグインの更新してないぞ」「このIPアドレスから阿呆みたいなブルートフォースアタックきてるぞ」という通知がくるのも疲れましたし。
なので、昔に戻ってスタティックなコンテンツ配信に徹しよう、というような感じです。
WordPressからHugoへ
今回手始めに移行したのは、AIに記事を書かせている邪悪なサイトです。こんな感じに変わりました。
なんだかんだで移行まで3日くらいかな。正直AIなかったらしんどすぎて無理ってなったと思います。でも移行を決めたのはAIによるサイバー攻撃の激化のためなので、AIのおかげで言っていいのかどうかは微妙なところです。
ここからまた色々と手を加えつつ運用をして、課題を洗い出しながら、本ブログであるこのサイトの移行の準備を進めます。このサイトは14年続いているだけあって色々な歴史が不思議なHTMLタグとなって残っているため、すんなりとはいかないでしょう。AIにめっちゃ調査させながら進めていくことになるでしょうね。かなり時間がかかると思います。仕方無い。来月中にできるといいな。
全体の構成
さて、構成ですが、元々の構成は極めてシンプルでした。
これが今回、ちょっと複雑になりました。というのも、私は自作の管理アプリケーションがあり、そこで記事の執筆などもしたいためです。こんな感じのアプリでやってます。
記事執筆と管理系のがずらずらと。ちなみにサイトトップの古のアクセスカウンタもこのアプリケーション上でウィジェットを作っています（アクセス解析自体はOSSのUmamiを使わせていただいております）。ウィジェットのみグローバルに公開して、内部のアプリケーションはLAN内限定です。
執筆機能は重要です。そもそもWordPressを使っていたのも、ぶっちゃけWYSIWYGで編集してその場で公開できなきゃいやだいという運用上の理由が大きかったです。デザインはどうでもよい。なので、Hugoに移行するとしてもエディタを用意できることはマストでした。このへんはAIのおかげでやれるようになったと言っていいでしょう。
ただこういうややこしいことをする以上、Hugo側の管理と衝突するために、アーキテクチャはどうしても考えるところが生じます。今回は以下の構成に行き着きました。
Hugo環境はコンテナに隔離して、cloudflaredよりトンネル経由で外からアクセスする感じです。Cloudflare依存になってるやんと見えますが、まぁそうなんですが、別に使えなくなったらVPSからfrpなりなんなり使った構成に切り替えればいいだけなので、まぁいいかなと。さらに言えばサイト公開するマシンはそれ専用にする予定です（まだ徹底はできていない）。
そんで、記事の生成とかビルドの実行とかは、全部管理アプリケーション上でやる構成ですね。一言で言えば管理アプリケーションが正本となる構成です。Hugoリポジトリは中継地点ないしバックアップの役割になります。なのでCI/CDによるホスティングではないです。これによる制約はいくつかあります。主に運用上の制約は以下になるでしょうか。
- 管理アプリケーションとHugoのホスティング環境が同一のマシン上にあること（変えてもいいんだがややこしくなり思想から外れる）
- 普段は管理アプリケーションからHugoリポジトリのpush/pullを実行するが、Hugo側のデザイン変更時（特に記事データに特殊な記法を挿入する時）はローカルのHugoリポジトリでpushする、2つのワークフローが存在すること
- CI/CDでブランチごとにホスティングしてステージング環境作るとかはできない（できないことはないが構成と運用がややこしくなり、設計思想から外れる）
この制約は受け入れることになります。
別の考え方としてリポジトリを正本とする考え方もあり、まぁそちらのほうがアーキテクチャは綺麗になると思うんですが、なんか無駄に複雑な運用になりそうだったのでやめました。どうせ運用者も僕だし。
再び個人サイト激動の時代に…
とまぁこんな感じでやっていて思ったんですが、AIで楽になったと言っていいんですかねぇ…。25年前は専門じゃなくてもやる気があれば頑張ってサイトを持つことができたと思うんですけれど、今はこれちょっとどうなんでしょう…。
トンネル技術とコンテナが揃った時には、個人サイトやセルフホストがまたやりやすい時代になった！と思ったのですけれど、サイバー攻撃がヤバいから守備を固めよう、WordPressはよくない、でも運用が不便になって更新しなくなったら元も子もないから利便性も高めよう、みたいなことを考え始めると、AIによる効率化以上に、トータルの難易度自体は上がり続けているような気がします…。
いやまぁ、僕がややこしくしているだけか。
これはまぁ結局、何をどこまで信じるか、という話です。少し前までだとVPSやクラウド基盤そのものを疑うのはキチガイ扱いだったかもしれないのですが、最近お名前.comデスクトップクラウドが基盤ごとやられて顧客の資産がハッカーの攻撃により消失し、さらにGMOが顧客の端末を回収するため物理的に全国を駆けずり回ったという事件は、クラウドは絶対安全ではないという当たり前の技術的な真実を曝け出しました。ま…それでAWSをはじめメガクラウドが陥落するかと言えば別にそういうわけではないですけれど、でもメガクラウドだから安全だ、は技術ではなく信仰でしょう。
結局個人サイトって自分の城です。城をどこにたてますか、どうなったらその城はぶち壊れますか、あなたはそれに納得できますかと、そういう話なんだと思います。絶対防御は無理なので、そのうえで何を賭けるのか。それを考え始めると、やりたいことに対して、本気でぶち壊そうとする勢力、さらにその被害が大きくなりすぎて、それが多分根本的な問題なのだと思います。
僕の構成がややこしくなっているのは、それだけ僕が納得するのに必要になってしまったということはあります。別にもっとシンプルな構成は可能です。元々のようにCloudflareトンネルでWordPressコンテナ直通でも良いといえばそうなので。ちゃんと更新し続けて、今回のPHP事件みたいなのがあったらキャッチアップして…ってやっても、基本は大丈夫でしょう。心配なら物理的にサイト専用のマシン作って切り離すくらいで、ほぼほぼ問題ないと言って思います（まぁそれも普通からするとややこしいわけですが…）。
まぁ結局どうしたいかは人それぞれということになるんですが、その構成に至る道筋や、またその構成における必要な運用はなにか、普通の人がそれを理解して辿り着くのが難しくなっているのかなぁと、そんな風に思いました。
<関連記事>
コメント