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

So, what happened yesterday? Here's what went wrong and what we're doing to fix it: https://t.co/vWqs0TmrkL

— GitLab (@gitlab) 2017年2月1日

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

うーん、素敵です。

前回、 前々回と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の設定は先に行っておく必要があります。

参考ドキュメント：

• Netlify builds, deploys, and hosts your front end.
• 高機能ホスティングサービスNetlifyについて調べて使ってみた

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

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

前提

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

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

ざっくりとした流れ

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

• まずは https://username.gitlab.io/project/ のようなURLで所望のサイトが表示されるところまで持っていく。

• 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

簡単な説明

• image: alpine:3.4 軽量LinuxであるAlpine Linux上でCIを実行することを指定しています。
• before_script: Hugoをネットワーク越しに取得してインストールします。
• pages: GitLab PagesでCIの生成物を表示するには、pagesの記述が必要です。
• script: hugoコマンドを実行して、静的サイトを生成します。
• artifacts: hugoコマンドを実行すると、publicディレクトリに生成物ができるので、このディレクトリを指定します。
• only: masterにて、masterブランチにpushされたときだけpagesタスクが実行されることを指定します。

GitLabにpushすると、自動的にHugoが実行され、生成されるpublicディレクトリがPagesのページとして設定されます。 これでブラウザからサイトを表示することができるようになります。

もしpushしてもサイトが表示されない場合、プロジェクトの上部にあるPipelinesをクリックし、 Statusが"passed"にっていることを確認してください(下図参照)。“failed"になっているときは、CIが 失敗していますので、.gitlab-ci.ymlを中心にpushしたファイルの内容を確認してください。

また、Statusが"pending"になっているときは、CIの実行待ちです。システムの負荷によっては、 完了まで10分以上かかることもありました。

カスタムドメインの設定

DNSのAレコードはGitLab.com Settingsに記されているIPアドレスを設定します(apexドメインを使用する場合)。サブドメインを設定するときは、CNAMEでprojectname.gitlab.io.を設定します。

Let’s Encryptでの証明書の取得

こちらについてはいろいろ参考となるページがあるので、そちらを参照してください(すいません、サボってます。 またの機会に追加するかもしれません)。ただ、Hugoでサイトを作る上ではまったのは、 Let’s Encryptから指定されるファイル名で指定された文字列を取得できるようにする際に、 Markdownでは上手く生テキストファイルが生成できなかったため、 .gitlab-ci.ymlのscriptでecho “内容” » 指定ファイル名 のように追記することで対処しました。

証明書の設定

Pagesの設定ページで、右上の”+ New Domain"を押し、ドメイン名と取得した証明書を入力して"Create New Domain"を押します。

参考ページ

公式ドキュメント: GitLab Enterprise Edition documentation 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を使う上での具体的方法については、 また別途記事にしたいと思います。

次の記事はこちら。

2017/1/21追記: GitLabのセットアップはほぼできたのですが、どうもLet’s Encryptの証明書を設定するところで問題に遭遇しました。 カスタムドメインの証明書をGitLabに設定して、当該ドメイン名でアクセスしても、 何故だかgitlab.ioの証明書がブラウザに送られてきてしまいます。というわけで、当初の目的はNetlify にて達成できたので、そちらも参照してください。記事はこちら。