1
0
hugo/content/blog/2020-03-28-blog.md
2024-12-21 21:03:10 +09:00

6.9 KiB
Raw Blame History

+++ date = "2020-03-28" tags = ["blog"] title = "ブログをはじめるならGitHub Pagesがおすすめ" slug = "blog" +++

ブログをやるならGitHub PagesGitLab Pagesがおすすめです。

私は、少し前にGitLabでブログをやっていましたが、その後、GitHubに移行したというか、戻りました。経緯としてはGitHub -> GitLab -> GitHubという流れです。

syui.github.io

割と長くGitHub PagesやGitLab Pagesでブログをやってきたので、今回は、両者の違いをまとめてみます。

  • GitLabはプライベートリポジトリが無制限で、HTMLソースを公開しなくていい

  • Web Serverは、GitHubのほうが安定していて速い

  • GitLabのほうがドキュメントが充実しており、公式テンプレートがわかりやすい

  • どちらもCIを回せるけど、GitLabはGitLab CIを回して、public/にビルドするという形態を採用するため、CIが成功しないとページが公開、更新されない。ユーザーが.gitlab-ci.ymlを書く必要がある

  • GitHub PagesはデフォルトでJekyll Buildを実行しページが公開される仕組み。ただし、リポジトリルートに.nojekyllを置くことでJekyll Buildを実行しないオプションも存在する。よって、HTMLを直に置いてページを作ることもできる。何らかの原因でJekyll Buildが失敗する場合、この手段を用いることができる

  • GitHubは、${USER}.github.ioというリポジトリ名を作成することで、当該ドメインが与えられる。branch:masterにHTMLをpushすると更新される。複数のページを用意したい場合は、リポジトリを作ったうえでbranch:gh-pagesjekyll buildが通るソースコードを置くことでページを公開する

  • GitLabも同じく${USER}.gitlab.ioというリポジトリ名を作る。ただし、ブランチは基本的にはmasterを使用する。なお、.gitlab-ci.ymlでソースを置くブランチは制御、変更できる

  • 現在、GitHub Pagesには、GitLab CIに相当するGitHub Actionsがあるのでページの自動ビルド、デプロイに関しての不便はない

  • GitLab Pagesは複数のドメインを登録できる。GitHubは無理。なので必要なときはGitLab Pagesのドメイン設定を使ってGitHub Pagesにリダイレクトさせるなどのハックに利用させてもらってる

まとめ

以下、サービス別に特徴をまとめます。一応、GitHub Pagesをおすすめしておきます。GitLab Pagesはweb serverが不安定なことが多かった記憶があります。とはいえ、好みの問題ですね。

GitHub Pages

  • web serverが速くて安定している

  • デフォルトではjekyll buildが回る、オプションで切ることもできる

GitLab Pages

  • ドキュメントや公式テンプレートがわかりやすい

  • 必ずGitLab CIを通す必要がある

  • 複数のドメインを指定できる

  • プライベートリポジトリが無制限に使えるため、HTMLソース(リポジトリ)を非公開にできる

GitLabからGitHubに移行した経緯

私は、GitLab Pagesを2年くらい使っていましたし、特に不満もなかったのですが(たまに不安定で遅かったというのはある)、あるとき突然にページが非公開になってしまうことがありました。

で、運営に連絡してみたのですが、返事がなかったので、GitHub Pagesに同じソースでデプロイしました。つまり、ここで移行という形になります。

その後、GitLabの方で非公開が解除されたのですが、なんだったのかよくわからなかったので、その後、GitLabに戻ることはありませんでした。そのような経緯で、それ以降は、GitHub Pagesを使っています。

ただ、GitHubはCI連携がデフォルトではなかったため、通常は、ビルドしたものをリポジトリにpushしなければ更新できません。したがって、Travis CIを回してページのビルド、デプロイを自動化してましたが、GitHub Actionsが登場したので、今はそちらに移行しています。

GitLab Pagesを使った複数ドメインを利用するハック

例えば、blog.syui.ailog.syui.aiというドメインをsyui.github.io/blogに飛ばしたいとしましょう。この場合、GitHub Pagesは一つのページに一つしかドメインを指定することができないので難しい。

そこで、GitLab Pagesでつのドメインを登録した上で、CloudFlareなどのリダイレクトをGitHub Pagesへ走らせることで、blog.syui.ailog.syui.aiを目的の場所に飛ばすことができます。

CNAME : gitlab pages

↓

リダイレクト : github pages

とはいえ、これはあくまでリダイレクトという形なので、アクセスは、トップドメインにとどまります。このような形を実現したい場合のみ利用できるハックです。

簡単にブログを立ててみる手順

GitLab Pages

https://gitlab.com/pages

まず、リポジトリを作りましょう。リポジトリ名は${user}.gitlab.ioです。例えば、私の場合、syui.gitlab.ioですね。

そして、以下のリポジトリをpushしましょう。

$ git clone https://gitlab.com/pages/jekyll

$ cd jekyll

# ${USER}に注意
$ git remote add origin git@gitlab.com:${USER}/${USER}.gitlab.io.git

$ git push -u origin master

GitLab CIが通ったのを確認したら、ページが表示されているはずです。(GitLabの場合、成功しても公開まで少し時間がかかります)

ビルド出力はpublicディレクトリでないといけません。このへんは注意です。それぞれのジェネレーター(静的サイトジェネレーターなど)の実行にオプションから指定しないといけない場合があるかもしれません。publicがデフォルトでない場合はそうですね。

複数のページを作りたい場合は、同じような手順に加えて、.gitlab-ci.ymlを調整しましょう。

GitHub Pages

まず、リポジトリを作りましょう。リポジトリ名は${user}.github.ioです。例えば、私の場合、syui.github.ioです。

$ git clone https://gitlab.com/pages/jekyll

$ cd jekyll

# ${USER}に注意
$ git remote add origin git@github.com:${USER}/${USER}.github.io.git

$ git push -u origin master

複数のページを作りたい場合は、同じような手順に加えて、ブランチをgh-pagesにしてpushしましょう。アクセスは、https://${USER}.github.io/リポジトリ名となります。

# リポジトリを作った上で
$ git remote add origin git@github.com:${リポジトリ名}.git
$ git branch -b gh-pages
$ git push -u origin gh-pages