Blogging

GitLabが死んだので、BitBucketに一時?避難

以前、NetlifyとGitLabの組み合わせを推奨しましたが、 今日はGitLabが死んだというニュースが話題になってしまいました。

復旧まで待っても良いのですが、Netlifyだとこのような時でもサクッとBitBucketとの連携で解決できます。 今回、新しくBitBucketにリポジトリを作成し、そちらに記事データをgit pushするようにしました。 Netlifyの設定画面で"Link to Git"を編集してBitBucketの当該リポジトリを指定すれば、 そちらからfetch & buildしてくれます。

うーん、素敵です。

どうやら、GitLab & Netlifyが最強かも?

前回、 前々回とGitLab Pagesでのサイト作成について記載しましたが、 SSL証明書の設定で躓きました。色々調べているうちに、Netlifyというサービスを 使っても、静的サイトジェネレータ+カスタムドメイン+SSL証明書が実現できるということが分かりましたので、 その方法を簡単に説明したいと思います。

概要

今回も、サイトのソースはGitLabで管理します。NetlifyはCI, 証明書, ページのホスティング, の役割を担当してもらいます。

サイトのビルド時間もGitLab Pagesで回すより高速なように思われます。 (2017/2/1追記：サイトのビルド時間は明らかにGitLabよりも高速です。GitLabでは日本時間の夜の時間だと数時間かかってしまうこともありますが、 同じ時間帯でもNetlifyだと数十秒で完了しています。) ただ、生成物の最大サイズについては記述が見当たりませんでした。GitLab Pagesは1GBという制限がありましたが、 Netlifyではどうなのでしょう? もっと制限が緩いのか、きついのか。

Netlifyにログインしたら、GitLabのボタンを押して、GitLabとの連携を行います (アカウント作成時にGitLabのアカウントで行った場合は、最初から連携しているはずです)。 それから、Netlify側でホストしたいプロジェクトを選択します。

NetlifyでのCI

NetifyでCIをする際は、すでにHugoはインストール済みです。公式ドキュメントの Continuous Deploymentに記載があります。 そのため、プロジェクトの設定で、Build Cmd: hugo, Public folder: public と設定するだけで、 指定ブランチにpushすると、Hugoにてビルドされ、publicディレクトリがサイトとして設定されます。

GitLab Pages側でのビルドが不要であれば、.gitlab-ci.ymlは削除してしまいましょう。

ドメインの設定

プロジェクトのページで、Domain:欄に、カスタムドメイン名を入力します。apexドメインは非推奨なので、 www.などのサブドメインを付けたほうが良いようです。そしてDNSの設定で、カスタムドメイン名にCNAMEレコードとして (Name:欄に記載されている内容).netlify.com を設定します。

HTTPSの設定

これもNetlifyの秀逸なところです。プロジェクト > HTTPS のタブからボタンを押すだけで、 自動的にLet’s Encryptから証明書を取得し、設定してくれます。しかも、証明書の自動更新もしてくれるようです。 もちろん、DNSの設定は先に行っておく必要があります。

参考ドキュメント：

GitLab Pagesのセットアップ

前回の記事で、無料で個人サイトを作成するという 観点からGitLab Pagesがかなりイケてるサービスであるということを書きましたが、今回はもう少し具体的な方法を説明したいと思います。

2017/1/21追記: 下記では、最後のLet’s Encryptでの証明書が上手く設定できていません。 GitLabのシステムの問題では無いと思うのですが、下記"カスタムドメインの設定"、“証明書の設定"は 「こうすればできるはず」という意味での記載になります。 結局、Netlifyを使用することで所望の機能が実現できましたので、 そちらを記事にしています。–追記終わり–

前提

次のようなセットアップを考えます。

  • 静的サイトジェネレータとしてHugoを使用する。
  • GitLab Pagesにソースファイルをpushすると、CIでHugoを実行し、サイトを生成する。
  • DNSレジストラで取得したドメイン名をGitLab Pagesのページに結び付ける。
  • Let’s Encryptで取得した証明書をドメイン名に結び付ける。

ざっくりとした流れ

上記の構成をするための大まかな流れは次のようになります。

  • GitLab上でアカウントを取得、Pagesプロジェクトを作成する。
  • ローカル環境にHugoをインストールし、サイトが所望のように生成されることを確認する。
  • PagesプロジェクトでのCIの設定を行い、上記URLでのサイト確認を行う。
  • カスタムドメインの設定と証明書の設定
  • お名前.comなどのレジストラにてドメイン名を取得する。
  • DNSのCNAMEレコード(www.domain.comでアクセスするような場合)、 あるいはAレコード(domain.comでアクセスするような場合)の設定を行う。
  • Let’s Encryptから証明書を取得する。
  • 証明書をPagesのプロジェクト設定にて追加し、HTTPSでアクセスできることを確認する。

Hugoについて

まずは公式サイトからHugoを手元のマシンにインストールしましょう。 最後はCIでHTMLはGitLab Pages上で生成するとしても、手元で結果を確認することは必須でしょう。

配布されているHugoバイナリは依存ライブラリを必要としないので、手元の環境と対応した バイナリを展開すればインストール完了です。

Hugo Quickstart Guideなどを参考にして お好みに合わせたページが生成されるところまで持っていきます。

CIの設定

プロジェクトのルートディレクトリに.gitlab-ci.ymlという名前でファイルをgitで追加します。 私の場合、概ね次のような内容で動作しています。

image: alpine:3.4

before_script:
  - apk update && apk add openssl
  - wget https://github.com/spf13/hugo/releases/download/v0.18.1/hugo_0.18.1_Linux-64bit.tar.gz
  - tar xf hugo_0.18.1_Linux-64bit.tar.gz && cp ./hugo_0.18.1_linux_amd64/hugo_0.18.1_linux_amd64 /usr/bin/hugo
  - hugo version

pages:
  script:
  - hugo
  artifacts:
    paths:
    - public
  only:
  - master

簡単な説明

GitLab Pagesはもっと評価されてよいと思う

前書き

皆様個人でブログを作成するとしたら、どのような方法を取られるでしょうか? 昔からはてなやFC2などのブログサービスがありますね。 最近では、技術系情報を投稿するのにQiitaも良く使われているように感じます。 あるいはマニアックなところだと、Tumblrをカスタマイズしている方もいますね。 もちろん、ストイックにすべて自前サーバやVPSを用意してnginxやApacheでHTTPサーバを立てている方も いることでしょう。

GitHub Pagesの気になるところ

また、技術系の方々にはGitHub Pagesも良く知られている のではないかと思います。これはgh-pagesというブランチでファイルを保管すると、 それがそのまま__ユーザ名.github.io/(リポジトリ名)__の様な URLでアクセス可能になるというものですね。

ただ、個人的にはGitHub Pagesも、以下の点が気に入りませんでした。

  • フリーのレポジトリだと、gh-pagesは当然パブリックになる。
  • JekyllやHugoのような静的サイトジェネレータを 使用すると、1記事を追加するだけでも、Paginationのようないろいろのファイルが生成/変更されるため、 コミットを見ても、実際に追加されたMarkdownファイル以外が多数表示され、邪魔に感じる。

上記の2点目については皆さんはどう対処しているのでしょうね。単に無視すれば良いだけ、 と言われてしまえばそれまでなのですが。

また、上記1点目と関連して、masterブランチにMarkdownのソースファイルを保管するとして、 masterブランチはbitbucketのような、無料でもプライベートリポジトリを使用できるサービスを 使い、gh-pagesブランチだけGitHub Pagesにpushする、という運用をされている方もいるようです。

GitLab Pagesを見つけた!! (GitHubじゃないよ、GitLabだよ)

さらに調べているうちに、GitLab Pagesは 上記の2つの点も解消されており、かなり良いサービスではなかろうか、と思った次第です。

GitLab Pagesの利点を列挙します。

  • プライベートリポジトリも無料で作成できる。
  • CIも無料で使える。これを使うと、Markdownをpushしたときに、DockerコンテナでJekyllなどを走らせて、 その結果をWebページとする、といったことが可能。つまり、gitではMarkdown(ともちろんスタイル関連CSSなども必要ですが) のみを管理することになり、サイトジェネレータによる生成物自体はリポジトリで管理しなくてよくなる。
  • カスタムドメイン、SSL/TLSも対応可能。

3番目の点についてはGitHub Pagesも対応可能なので、GitLab Pagesのみの優位点ではないですが。

GitLab Pagesも完全無欠ではなかった!! でもフリーならたぶん最強でしょ!!

というわけで、パフォーマンスなどは別にして(こちらについてはまだ詳細に評価していません) 機能的にはほぼ欠点がなさそうに思えます。でも実際にはいくつか気になる点もあるにはあります。

  • 各レポジトリの最大容量は10GB。
  • CIでの生成物は最大1GB。 こちらはサイトが大きくなると後々問題になるかもしれませんね。これについては上記リンクの FAQ “Is all of this really free to use?“に書かれています。ただ、リポジトリサイズ10GBというのも 5GBから増量されたという経緯があるようですので、1GBの制限もいずれ緩和されるかもしれません。 それに、リポジトリが10GBで生成物が1GBというのは普通に考えてバランスが悪いですよね。 HTMLになるのですから、(Pagesでの利用法では)生成物の方が大きいのが普通ですからね。

この制限がありますので、現状サイト全体で1GBを超えてしまうのであれば、 VPSなどの他の方法を考えた方が良いのだと思います。

リポジトリサイズの制限については、GitHubも1GB以下が推奨されている ようですね(ただし、それ以上が絶対だめとは書かれていない)。それを考えると、 自前でサーバを管理しないのであれば、無料で使用できるサービスでは最強といえるのではないでしょうか?

記事は続くよ

だらだらと書いてしまいましたが、実際にGitLab Pagesを使う上での具体的方法については、 また別途記事にしたいと思います。