1
0
hugo/content/blog/2020-03-28-blog.md
2024-04-23 22:21:26 +09:00

132 lines
6.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

+++
date = "2020-03-28JST"
tags = ["blog"]
title = "ブログをはじめるならGitHub Pagesがおすすめ"
slug = "blog"
+++
ブログをやるなら`GitHub Pages`か`GitLab Pages`がおすすめです。
私は、少し前にGitLabでブログをやっていましたが、その後、GitHubに移行したというか、戻りました。経緯としては`GitHub -> GitLab -> GitHub`という流れです。
[syui.github.io](https://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-pages`に`jekyll 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.cf`と`log.syui.cf`というドメインを`syui.github.io/blog`に飛ばしたいとしましょう。この場合、GitHub Pagesは一つのページに一つしかドメインを指定することができないので難しい。
そこで、GitLab Pagesでつのドメインを登録した上で、CloudFlareなどのリダイレクトをGitHub Pagesへ走らせることで、`blog.syui.cf`と`log.syui.cf`を目的の場所に飛ばすことができます。
```
CNAME : gitlab pages
リダイレクト : github pages
```
とはいえ、これはあくまでリダイレクトという形なので、アクセスは、トップドメインにとどまります。このような形を実現したい場合のみ利用できるハックです。
### 簡単にブログを立ててみる手順
#### GitLab Pages
https://gitlab.com/pages
まず、リポジトリを作りましょう。リポジトリ名は`${user}.gitlab.io`です。例えば、私の場合、`syui.gitlab.io`ですね。
そして、以下のリポジトリをpushしましょう。
```sh
$ 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`です。
```sh
$ 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/リポジトリ名`となります。
```sh
# リポジトリを作った上で
$ git remote add origin git@github.com:${リポジトリ名}.git
$ git branch -b gh-pages
$ git push -u origin gh-pages
```