BloggerからJekyllにブログを引っ越し

Updated: / Reading time: 5 minutes

ブログ引っ越し検討、およびブログサービスに求める要件で検討していた引っ越しについて、2017年1月から4月にかけて、BloggerからJekyll、つまり静的サイトに引っ越しをしました。この記事では、Jekyll検討過程、引っ越しの手順、ブログ構成を説明します。

振り返り - Bloggerで辛いところ

  • Markdownで書けない。
  • スマホから書けない。
  • ガジェットがスマホ向けに表示されない。
  • コードブロックが整形表示されず、ただのpreブロックになってしまう。

Jekyll検討

Jekyllについては、以下を参照。

Markdownで書ける!

何と言っても、Markdown文書をそのまま公開することができます。テーマによりますが、コードブロックやガジェットもキレイに表示できます。Bloggerの場合、ローカルでMarkdown文書を作成→StackEditにコピペしてパブリッシュ、という手順が鬱陶しいです。

後の公開ワークフローで説明しますが、GitHubのmasterブランチにpushすれば、自動的にブログが更新されるようなワークフローを作ることも可能です。

サーバーの用意

Bloggerはホスティング・サービスなのでサーバーについて何も考えなくて良かったですが、Jekyllは静的サイトなので自分でサーバーを用意する必要があります。この点、もともと自宅サーバーを運用しているので、悩む必要がありませんでした。自分でサーバーを一から用意できない場合でも、以下の手段でホスティングすることができます。

現在は自宅サーバーで公開していますが、何らかの都合でそれが使えなくなっても、簡単にAWS S3などに移行することができます。

引っ越しの手順

もともと、記事をMarkdown文書で管理していたため、記事本文の移行はほぼ作業無しでした。以下に、必要だった作業を説明します。

ドメイン名

Blogger時代のblog.u6k.meというドメイン名を変えるつもりはなかったので、ドメイン名はそのままです。DNS設定とBlogger設定を変更しました。

Jekyll用ファイル構成

単にMarkdown文書を格納していたので、これをJekyll用ファイル構成に整理しました。Jekyllで初期サイト構成を生成して、そこに既存ファイルを移動しました。この時、テーマもいろいろいじりました。

Dockerを使い、生成した静的サイトをnginxコンテナに格納して公開したかったので、そのためのDockerfileなども作成しました。

ヘッダー

Markdown文書のヘッダー部分(メタ情報部分)を変更・追加する必要がありました。基本的にStackEdit向けに書いていたので、これをJekyll向けに変更しました。

旧URLからのリダイレクト

Bloggerのパス体系とJekyllのパス体系が異なったので、過去にシェアしたURLからリダイレクトする必要がありました。jekyll-redirect-fromプラグインを使用すると、あるパスにアクセスされたときに実際の記事パスにリダイレクトすることができます。このプラグインを適用して、必要な記事のヘッダー部にredirect_fromパラメータを追加しました。

画像

Blogger時代にいろいろなサービスで画像を生成・格納していたため、これを整理して同一リポジトリに格納しました。というか2017/8/8時点では移動中です。

UML図

jekyll-plantumlプラグインを使用することで、Markdown文書中にPlantUML文書を直接埋め込むことができます。静的サイトを生成すると、UML画像に変換され、記事に埋め込まれます。 超便利!!!

ブログ構成

以下の構成でブログの記事を執筆し、公開しています。ややこしいですが、Author(執筆者)がエディターで記事を書きgit pushした後は、blogコンテナが再起動されるまで自動です。

PlantUML SVG diagram

以下に、これらを使用したブログの公開ワークフローを説明します。

Local PC

ローカルPCで記事を執筆し、gitで管理します。執筆中の記事を表示確認したい場合、blog-devコンテナでblogイメージをビルドして、これを起動して表示確認します。単純なMarkdown文書であれば普通にAtomなどでプレビューできるので、blogコンテナで表示確認もほとんどしていません。

Android端末でブログを書くで書いた通り、短い文章であれば、Android端末のJotterPadでMarkdown文書を書き、MGitでgit pushするという方法も可能です。

GitHub

記事を管理しています。GitHubにgit pushすると、WebHookによりCircleCIのビルドが実行されます。

CircleCI

静的サイトをビルドします。具体的にはblog-devコンテナでblogイメージをビルドします。masterブランチであれば、Docker Hubにdocker pushしてJenkinsのWebHookに通知します。

Docker Hub

ビルドしたblogイメージを管理しています。Automated Buildではなく、CircleCIからdocker pushしています。ですので、Dockerイメージを管理しているだけです。

macOS

自宅サーバーで、ブログを公開しています。ここではJenkinsとblogが動作しており、CircleCIからWebHook通知を受けると、JenkinsがDocker Hubから最新のblogイメージをdocker pullして、blogコンテナを再起動します。これにより、最新の記事が公開されます。

ちなみに、_config.ymlを見ると分かりますがs3_websiteプラグインを追加しており、実は一時的にAWS S3で公開していました。

おわりに

ブログにしては複雑なワークフローになってしまいましたが、普通にサービスのビルドフローと同じ程度ですし、まぁいいかと思っています。今はテーマを適用して少しカスタマイズした程度なので、いろいろ試したいと思います。