January 17, 2020

なぜHugoに移行したか

Share on:

概要

これまで静的HTMLによるトップページとWordpressによるブログ部分で分離していたものをHugoに移行して統合した。 この形態に至った経緯をメモしておく。

動機

そもそもは今までウェブサーバとして使っていたVPSインスタンスを削減することが目的だった。

VPSインスタンスはいくつか使い分けているが、ウェブサーバ用のインスタンスは外部向けの静的/動的ページの他、WordpressやNexus Repository Manager(Mavenのリポジトリサーバ)などを走らせていたもの。 ただ、最近あまりアクティブに活用しているとは言い難い状況であってダボついていた。 個人用途で使うこともあるからメモリは開けておきたいし、もしプランを下げれるほどメモリに余裕ができればコストを削減できる。

また、Wordpressは自分の目的には一致していないと感じることが多々合った。

  • ブロックエディタ等あまりに高機能。Web記者になるのが目的ではないので応用できない学習コストは本望でない。
  • 大したことをしているわけではなくてもやはり遅い。そしてメモリを食う。
  • DBが単一障害点となる構成の脆弱さ。
  • (人気ゆえの代償という事もあるが)セキュリティ的な懸念が大きい。しかもこれがプラグインなどの増加に比例してしまう。
  • バックアップ&メンテナンスが面倒。

これに対してHugo(やその他の静的サイトジェネレータ)では

  • 慣れたMarkdownで書ける(これがとにかく大きい)。
  • 静的サイトなのでとにかく速く、メモリもWebサーバ分しか食わない。ついでにHugoはビルドも速い(後者は自動化しているのでさしたる問題ではないが)。
  • 静的サイトなのでセキュリティ的懸念が小さい。また自分のような無学にも挙動が理解しやすい。
  • GitなどのVCSで管理が簡潔する。
  • そして拡張性、表現性にさほどの差異を感じない。

自分は備忘録的にこのサイトを使う。簡潔で保守がしやすいことが何よりである。

そもそも(今更自分が議論するようなことではないが、主観として)Wordpressは非エンジニア向けというか、フロントエンドとバックエンドは(意図して)隔絶されているように感じる。多人数で利用して、かつその理解のレベルが均質でないならその隔絶は必要かもしれない。 でもこのサイトのように一人しか編集者が居らず、フロントエンドとバックエンドの管理を両方しなければならない場合、その隔絶はただのリスクであると感じた。 だからWordpressはやめてHugoに移行することに決めた。

Hugoに移行することによるデメリットとしては

  • やはりWordpressの情報量は圧倒的。
  • 将来的にGitリポジトリの容量が問題となってくる、ということもあるかもしれない。

などがあったがどちらも差し当たっては問題にならないと考えた。 前者に関しては情報量が多いがゆえの雑多さ(有益とは言い難い情報も氾濫している)があり、それに対してHugoコミュニティも十分な規模があり、質が良い。 後者に関してはそうそう問題になりそうもないし、問題になるほど自分がこのサイトを活用するようになるならその時はある程度の投資が見合うだろう。

Jekyll? Gatsby?

静的サイトジェネレータとしてはJekyll,Hugo,Gatsbyを選択肢として考慮した。 JekyllとHugoについては自分がGoのほうが馴染みであること、またビルドなどが非常に高速であることからHugoを選択。 Gatsbyについて、その先進性には惹かれるものがあるが、

  • 自分にとって馴染みのないReact.jsに対する理解を要求されること
  • 動作が複雑であること

から自分の目的に合致しないと判断した。

S3? Netlify?

VPS上ではなく、Amazon S3Netlifyでサービスすることも考えた。

S3については従量制というところが気になる。 現状で転送量の心配をするような事は無いとは言え、不確定要素は少しでも減らしたいし、スケール等をするわけでもないのにS3上で運用するメリットがない。 定額VPSの安心感はやはり大きい。

NetlifyについてはNelify CMSの存在とCDNによる高速化、そして管理の省力化が魅力だった。
CMSはWordpressのエディタ様のツールを用いて記事を管理できるツールで、当然Hugoのプロジェクトの形式に沿ったものを出力してくれるため、上に挙げたHugo導入のメリットを損ねない。 ただ自分は現状でWeb GUIで記事が書けることに固執しないし、Netlify CMSはNetlifyと切り離しても動作するし、forestry.ioという類似のサービスもあるからNetlifyでホストする決め手にはならなかった。
CDNについては、現状で国外からのアクセスを考慮しなければ自分のVPSからの配信の方が速かった。

結局は他のサービスを自分のサーバ上で運用することになるので、サイトのみをNetlifyに追い出したところでWebサーバを止めれるわけではなく、であれば静的ファイルを配信するだけのHugo管理の煩雑さは大した問題にはならない。 それであればHugoの理解とチューニングの点でVPSのほうが自分の得るものが大きいと考えた。

実態

これについては後日別の記事を書ければと思っているが、Hugoビルド可能なCaddyのDockerコンテナを作っておき、 GitにサイトをPushすることでWebhookによってサーバ上のCaddyがサイトを自動でPull、Hugoビルドし公開という工程を自動化している。 Dockerコンテナ一つで完結し、Jenkinsなどの外部CIツールに依存しない。

Atomで記事を書いてローカルでプレビューしてCommit、Pushすれば数秒で記事が公開できる。 もしサーバのI/Oが問題となることがあってもクローンすればスケールできる。 何に置いてもGitで管理できるメリットは大きい。 非常に単純でありながら、高速かつ確実で、今後必要に迫られればスケールも簡単な気楽な構成になった。

Powered by Hugo & Kiss.