🐈

Gatsbyで管理しているブログをJAMStack構成にアップデート

2022/04/03に公開

AWS

はじめに

Gatsbyにマークダウンファイルをアップロードすることで記事を公開していたブログを、執筆作業をすべてWordpressに統一し、表示のみGatsbyを使うようにするというPJがあり、その流れを記録します。

※　公式はじめ各所に情報が落ちていたのでその詰合せのような記事になりました。

実現したいこと

Wordpress(以後WP)をヘッドレスCMSとして使用しWPにて記事を執筆し、Gatsbyで記事のテキストをgraphqlを用いて取得し、静的サイトを生成する

(おおよそのイメージ)

やったこと

1. Amazon LightsailでWordpressインスタンスを設定し、アクセス可能に。
2. SSL化
3. Wordpress側設定
4. gatsby-source-wordpressを導入
5. コンテンツ移行し表示などGatsby側で調整
6. 運用可能な状態への調整

以下、順に詳細記載していきます。

1. Amazon LightsailでWordpressインスタンスを設定し、アクセス可能に。

既存のインフラがAWSであるため、Lightsailを使うことを選択しました。
LightsailにはWPインスタンスがあるのでそれを選択し、諸々設定していきます。

基本的に公式が出している以下の流れのとおりに実施すれば問題なく設定できました。

次に、Route53にLightsailの静的IPアドレスをAレコードとして作成します。

作成したURLにアクセスすることで、WPにアクセスできればOKです。
※ 今回はもともとドメインは取得済みであったが未済の場合はもちろん取得する必要があります。

2.SSL化

基本的に以下記事のとおりに行いました。

3. Wordpress側設定

WPのプラグインとして、WPGatsuby・WPGraphQLをインストールします。

メーラー

メール周りはAWS SESに一任。
以下公式通りに実施すれば問題なくできます。

※ ちなみにメーラーの設定をしないとユーザ追加の際の招待メールも飛ばないため注意が必要です。

4. gatsby-source-wordpressを導入

Gatsbyが提供しているライブラリです。

ここで自分は若干ハマりました。
上記ライブラリをインストールして設定ファイル更新し、gatsby developしたところ、以下エラーが出力されました。

gatsby-source-wordpress  Your remote version of WPGatsby is not within the accepted range
(>=0.9.0 <2.0.0)
    
This is not a bug and it means one of two things:
  you either need to upgrade WPGatsby or gatsby-source-wordpress.
    
  1. If the version of WPGatsby in your WordPress instance is higher than 2.0.0
  it means you need to upgrade your version of gatsby-source-wordpress.
    
  2. If the version of WPGatsby in your WordPress instance is lower than 0.9.0
  it means you need to upgrade your version of WPGatsby.
    
Download a matching version at https://github.com/gatsbyjs/wp-gatsby/releases
or update via https://xxxxxxxx/wp-admin/plugins.php

調べてみると、gatsby-source-wordpressの最新バージョンは6.7.0でしたが、
今回対象プロジェクトのpackage.jsonだと4.0.8が限界のようでした。
4.0.8だとWPGatsby側のバージョンが2.0.0未満である必要があるため、こちらの手順でWPGatsbyをダウングレードしました。

※ 本来、Gatsby側をUpdateすべきだと思いますが、影響範囲やスピード感を考慮し、今回はWP側のダウングレードでの対応としました。

上記対応の結果、gatsby developし、http://localhost:8000/___graphqlにアクセスできるようになりました。

5. コンテンツ表示するためのGatsby側での調整

本PJにおいて行った調整について下記します。

アンカーリンク

既存の構成ではgatsby-remark-autolink-headersを使っていました。
執筆者がこれまでの運用と変えなくていいようにするために、以下構成にしました。

WP側にプラグインでEasy Table of Contentsを導入
Gatsby側で上記プラグインのデフォルトのid, classに対してこれまでと同様のスタイルを適用するcss当てる

（ハマり）

WP側では適切に動作するアンカーリンクがGatsby側で適切に動作しない事象に出くわしました。
→ position:fixedを使ってヘッダを固定していたことが原因でした。以下の対応を入れてFIXしました。
https://www.tam-tam.co.jp/tipsnote/html_css/post4776.html

6. 運用可能な状態への調整

記事取得

WPで記事作成/更新するだけだとGatsby側には反映されず、ビルドが必要となります。

現状の構成がS3 + Cloudfrontのため、WPで更新があった際にGithubActionsを作動させるように設定。（Netlifyとかvercelとかだとそれ用のプラグインみたいなのがあります）

WPにはアクションフックが設けられているため、それを使って、期待するアクション時にwebhookでGithub ActionsにリクエストするようにWP側に実装することで対応しました。
ex) 記事公開時・記事更新時・記事削除時にwebhook飛ばす、など

GithubActionsが提供しているrepository_dispatchを使うことで外部からのリクエストを受けて発火させることができます。

以下のようなイメージで実装します。

name: deploy s3 triggered by wp action

on:
  workflow_dispatch:
  repository_dispatch:
    types:
      - [xxxxxx]
      # ここのtypesをWP側で指定してwebhookを飛ばすことでこのactions起動のトリガーとなる

jobs:
  build:
  .
  .

おわりに

構築は若干面倒なものの、WPで記事を更新できるようになることはリソース配分の観点から非常にGOODだなと思いました。
また、各公式が出している情報が非常に充実していたのでそれを参照しながら手を動かせばそこまで大きくハマることなく構築できると思います。
本件に取り組むに当たり、細かいことでやったことは他にも多々あったので時間を見つけて追記していきたいと思います。
例によって誤りなどあればコメントお寄せいただけると嬉しいです！