お首が長いのよお首が長いのよ

チラシの裏よりお届けするソフトウェアエンジニアとして成長したい人のためのブログ

2020-01-05

ブログをGatsbyJS製の静的サイトに移行した

個人ブログ開発

JavaScript

GatsbyJS

Netlify

元構成

AWS上にLightsailでサーバーを借りて、その上にDockerでWordPressを構築していました

問題と動機

  • Docker(compose)単体での管理は一見シンプルだけど裏が大変
  • WPプラグインのアップデートが面倒
  • 運用が大体1年〜2年ぐらいになるので、単純に新しい構成にしてみたかった

元構成の通り、DockerComposeを使ってWordPress + MariaDBの２コンテナに加え、 SSL/TLSを手軽に実現するつもりで用意したnginx-proxyコンテナの管理もあるので、 いろいろと見るものは多かったです。

これはDockerやLet'sEncryptの勉強だと思って割り切って構築した感じだった。

学び始めてから移行までの流れ

いきなり本チャンの環境を作ってもよかったですが、チュートリアルも手軽そうだったので、 段階を踏んで学習するアプローチを取りました。

後から感じた事ですが、GatsbyJSも手軽に出来るとはいえ、 特定の項目を自分用にカスタマイズして使おうとするとWhyを理解して設定しなければならず、チュートリアルを踏んで良かったなと思います。

GatsbyJSのチュートリアルを進める

Gatsby.js Tutorials

8章構成のうち、1〜7までを触りました。 英語ソースですが、英語中級者レベルであれば難なく読めるレベルだったため、抵抗はありませんでした。

このチュートリアルを終える頃にはきっとあなたもパンダのファンになっているはず。

WordPressをソースにデータの抽出

WordPress Source Plugin Tutorial

チュートリアルでやった範囲＋WordPress用の追加チュートリアルを参考に現行のWordPressブログから構築を試しました。

WordPressの記事をMarkdownへ移行

WordPress の Markdown 移行補助ツールを開発してみた wpxml2md - npm

本来であればWordPressを裏において運用でもよかったんですが、Syntax Highlightのように装飾された所と親和性がよくなかった為、ソースをWordPressではなくMarkdownなどの他の形式にする必要がありました。

それにあたって上記記事を参考にxmlデータからMarkdownファイルへの変換を行いました。

大変有益なツールありがとうございます。この後でも書くんですが、ちょこちょこソース読んで勉強にさせてもらいました。

後になって気がついたんですが、既に私のブログってMarkdownでgithubに格納されてたはずなのにそれを使おうと思わなかったのが泣ける。

Markdownをソースに本チャン作成

現行のWordPressを使わずに高速でビルドが出来るようになった為、ここからサイトのレイアウトや表示させるデータを本格的に決めていきました。

デザインはテーマから選んで使っても良かったんですが、せっかくなのでBootStrap4を使ってさくっと用意しました。

サイズが変わるとグリッドの段組みが変わる程度のなんちゃってレスポンシブなのでまだ改善点はありますが、ほとんどの内容は半日かからずに出来上がったと思います。

ホスティングサーバーへデプロイ

今回はNetlifyを使ってデプロイしました。

Netlify、アカウントも作りはじめレベルの初心者なのにここに選定してからデプロイ&SSL/TLS化完了の確認までは大体30分程度。 噂には聞いてたけど本当にすげープロダクトだわこれ・・・。

ハマったポイント

年末年始休暇で空いた時間を使ってちょこちょこやってたんですが、いくつかハマったポイントがありました。

date(formatString: "XXX")が使えない

sh
1GraphQL error: unknown argument "formatString"
2

個別記事のMarkdownファイルに投稿日時として日付を書いておく事で、GatsbyではGraphqlを使って取得・表示形式のフォーマットが自由に変更出来るんですが、 date要素は取得できるのにformatStringを使って表示形式の変更が出来ませんでした。

いろいろ試行錯誤して、WordPressからMarkdownファイルに変換する際に出力した日付の書式がうまく噛み合わず、ただの文字列として認識されていたのが原因でした。

  • うまくハマらなかった書式：date: "2019-01-15T14:15:56Z"
  • 修正後：date: "2019-01-15"

70記事あるのでフォルダ内でgrepとsedコマンドによる置換で上記のようにT...Z部分を取り除くように修正。

正しくGraphqlのスキーマが取り込まれて日付のフォーマットが効くようになりました。

この部分はwpxml2md側のソースをもうちょっと読んで直すべきなのか、そもそも出力したxmlの書式がイケてなかったのか、そもそも他にベストプラクティスかを調べる余力はなかったのでゴリ押し。

記事内のソースコード部分が一行になって出力される

wpxml2mdが想定しているSyntaxHighlightと私が使ってたSyntaxHighlightプラグインがうまくかち合わないのが理由だろうなと思いました。

うまく取り込めるようにできないものかと思い、１日半ぐらいツールのソースコードをいじって試みましたがエクスポートした元データがイケてなさすぎたので断念。

そもそもSyntaxHighlightを使ってソースコードを記載する記事を書くようになったのはここ1、2年になってだったので、なんとか手修正でゴリ押せた・・・

静的ホスティングサーバーの選定

候補は３つありましたが、結局Netlifyにした理由は以下の通りです。

surge.sh

  • GatsbyJSのチュートリアルで出てきたのでそのまま使うつもりだった。
  • コマンドだけで完結できるのでほぼこれで決まりかけてた
  • surge.shによて払い出されるドメインではなく、カスタムドメインblog.killinsun.comを使うのとSSL/TLS対応の両方を実現する場合、有料プラン（結構高い）が必要だった為断念

github pages

  • エンジニア御用達のgithubなので最悪これでいいだろ感があった
  • FQDN配下の先頭ディレクトリがGithubリポジトリ名になる為、相対パスが崩れて面倒くさい事になる
  • ちゃんと設定すればドキュメントがたくさんあるので安心安全だったはず
  • とりあえず年末年始休暇中に一旦デプロイさせたかったので納期優先で断念

Netlify

  • 最近人気が爆発してるのでドキュメントも多くありそう
  • surge.shの欠点をカバー
  • コマンドもWebもいける

上から順に触って試して、結果的にはNetlifyになりました。 上述の通り、Netlifyは触り始めて30分程度までデプロイ出来たのでびっくらこいた

移行してみて

噂通り鬼速いです。　また、速いのはもちろんなんですが、お作法が決まっているので誰が書いても同じ作り、構成になるだろうなと思いました。 これの有利な点で言うならば初学者が有識者の成果物（テーマテンプレなど）を参考にして作りやすい事でしょうか。

また、アップデートペースの早いサイトでは不向きという意見もいくつかあります。 個人的には画像の扱いが鬼門なように感じたので、この辺りのドキュメントが増えるといいなと感じました。（それなら自分でやれよという話ですが）

残課題

みての通り、まだやることがいくつかあるので、順を追ってアップデートしていきたいと思います。

  • 記事一覧のタグ、カテゴリの区切り
  • SEO向けの設定
  • 日英の多言語化
  • ページネーション
  • 記事内にメタデータの表示

よかったらシェアしてください！