eyecatch
Fri, Jul 1, 2016

CloudFlareでブログをHTTPS化

最近GitHub PagesがHTTPSに正式対応したというニュースを見たことをきっかけに、このブログをCloudFlareで常時HTTPS化した話。 このブログ このブログはGitHub Pagesでホストされている。 GitHub Pages上のWebサイトはデフォルトでは<GitHubユーザ名>.github.ioというドメインで公開されるが、ちょっとかっこつけたかったのでカスタムドメイン(www.kaitoy.xyz)にした。 GitHub Pagesは2014年3月から非公式にHTTPSをサポートしていて、2016年6月8日に正式サポートを表明したが、これは<GitHubユーザ名>.github.ioドメインだけが対象であり、カスタムドメインはHTTPSサポートされていない。 要するにこのブログにはHTTP接続しかできない状態だった。 これをなんとかHTTPSに対応させたかった。 なぜHTTPS HTTPS化(常時SSL化)が世界的な流行りな雰囲気を感じていたのと、なにより、Googleに優遇してもらえるから。 Googleの検索結果の2,3ページ目までに出てこないなら、そのサイトはこの世に存在しないのとあまり変わらない。 昔はHTTPSにするとSSLプロトコルのオーバーヘッドや暗号化/復号化処理によりHTTPに比べて遅くなると言われていたが、最近ではサーバ/クライアントマシンの性能が上がり、このデメリットは気にするほどのものではなくなった。 逆に、常時SSL化するとSPDYやHTTP/2といった高速なプロトコルの恩恵を受けることができるようになり、HTTPより速くなることもあるらしい。 カスタムドメインなGitHub PagesサイトをHTTPS対応する方法 上記の通りこのブログはカスタムドメインでGitHub Pagesのサポートがなく直接にはHTTPS対応できない。 よって間接的に対応することになるので、リバースプロキシを使うことになる。 リバースプロキシサーバを自分で運用するのは大変なので、CDNサービスを利用する。 CDNサービスでまず思い当たったのはAWSのCloudFrontだけど、なんだか大げさで面倒そう。 あとはCloudFlareが有名なので調べたところ、手軽で無料でよさそうだったのでこれにした。 因みに、ごく最近始まったサービスのKloudsecというのも見つけたけど、まだベータが付いているし、遅いだのそもそもつながらないだの評判が悪かったのでこれは無し。 CloudFlareを利用すると、もともとだいたいこんな感じ↓だったのが、 こんな感じ↓になる。多分。 上のスライド中のリバースプロキシは実際にはいくつもあり、エニーキャストによってブラウザから一番近いものが使われる。 CloudFlare事始め CloudFlareの始め方はQiitaの記事を参考にした。 CloudFlareのアカウント作成 CloudFlareのサイトに行ってSign upのリンクからメアドとパスワードを渡してアカウントを作成。 CloudFlareにサイトを登録 アカウント作成後に開くページに従い、4つのステップをこなすとサービス利用開始できる。 まずはサイトの登録。 サブドメインを除いたkaitoy.xyzを入力してBegin Scanをクリック。 何かのスキャンが始まるので1分ほど待つ。何をしているのかはよくわからない。 CloudFlareのDNSの設定 次のステップでCloudFlareのDNSにレコードを登録する。 ブラウザからのトラフィックの誘導にはAかAAAAかCNAMEを登録できる。 トラフィックはkaitoy.github.ioに送りたいけど、IPアドレスは自分でコントロールできないのでAとAAAAは使えない。 CNAMEを登録した。 適当に入力してAdd Recordを押すとレコードを登録できるが、StatusのところがデフォルトでDNS only(灰色のクラウドのアイコン)になっているので、アイコンをクリックしてDNS and HTTP proxy (CDN)(オレンジ色のクラウドのアイコン)にしておく。 こうしないとブラウザからのトラフィックがCloudFlareを経由せず、HTTPS化できないはず。 プランの選択 サービスプランは無料のFree Websiteを選択。常時SSL化するだけならこれで十分なはず。 レジストラのネームサーバの変更 最後にレジストラのサイトに行ってネームサーバを変更するように指示される。 CloudFlareからは二つのネームサーバが割り当てられたようだ。 指示されたとおりに変更する。 CloudFlareの設定 サインアップが終わるとCloudFlareのダッシュボードが開く。 ダッシュボードのOverviewのStatusは最初はPendingになっていて、これはネームサーバの変更を反映中ということらしかった。 ネームサーバの変更は数時間くらいかかったが、変更中もhttp://www.kaitoy.xyz/にはアクセスできた。 ダッシュボードからやった設定は以下。 これもQiitaの記事を参考にした。 SSL ダッシュボードのCryptoのSSLの設定はデフォルトでFull (strict)になっている。 これはブラウザ-CloudFlare間とCloudFlare-GitHub Pages間両方をSSL化する設定。
eyecatch
Fri, Aug 28, 2015

GitHub Pagesでブログ立ち上げ - Hugoを使う

GitHub Pagesでブログ立ち上げ - Jekyllのためのツールの続き。 前回は、GitHub Pagesで公開するブログサイトを構築するのに、JekyllとJekyll関連ツールを使おうと四苦八苦したが、結局Jekyllに見切りをつけ、Hugoを使うことに決めた。 Hugoとは Hugoは、国内では2014年末くらいから盛り上がってきているブログサイト構築ツール。 そのホームページによると、ウェブサイトフレームワークで、静的サイトジェネレータとのこと。 フレームワークと名乗ってはいるが、その正体は、Markdownで書かれた記事を元にブログサイトのソースを生成するコンテントビルド機能と、記事作成(など)を支援するユーティリティ機能を持ったコマンドラインツール。 また、静的サイトジェネレータというのは、静的なサイトを生成するという意味ではなく、静的にサイトを生成するという意味。もっと言えば、WordPressとかがアクセス時にビルドが走るのに対し、Hugoを使った場合は事前にビルド済みのものをサーバにアップロードすることになる、ということ。らしい。WordPressは使ったことがないのでよく知らないが、Hugoのホームページにそう書いてある。 つまり、Hugoは静的なサイトだけを扱うツールってわけではないので、JavaScriptとかを駆使して動的でインタラクティブなページを作ってもいいはず。 Hugoのインストール インストールガイドに従ってHugoをインストールする。 HugoのGitHub ReleasesからWindows用バイナリをダウンロード。このときはバージョン0.14が最新だったので、hugo_0.14_windows_amd64.zipをダウンロードした。 このzipの中身はhugo_0.14_windows_amd64.exeというバイナリ一つとLICENSE.mdとREADME.mdだけ。 このhugo_0.14_windows_amd64.exeがHugoのすべてなので、これを適当な場所において実行できるようにしとけばよい。 今回は、hugo.batというファイルに以下の内容を書き、PATHの通ったフォルダにいれた。 @echo off C:\Users\Kaito\Desktop\tool\hugo_0.14_windows_amd64\hugo_0.14_windows_amd64.exe %* これで、どこからでもhugo [arguments]と打てばHugoコマンドが実行できる。 Hugoのシンタックスハイライト ドキュメントによると、Hugoではシンタックスハイライトを実現する方法を以下の2つから選べる。 サーバサイド: Hugoでのブログサイト生成時にハイライトしておく方法。 クライアントサイド: クライアントがブログを読み込んだ時にJavaScriptでハイライトする方法。 前者の方が当然クライアントの負荷が軽くなるが、Pygmentsのインストールが必要だったりめんどくさそうなので後者にする。(PygmentsはJekyllのときにすでに入れたけど…) クライアントサイドでやるのもいくつかやり方があるが、例えばHighlight.jsを使うなら以下をHTMLヘッダに加えるだけでいい。 <link rel="stylesheet" href="https://yandex.st/highlightjs/8.0/styles/default.min.css"> <script src="https://yandex.st/highlightjs/8.0/highlight.min.js"></script> <script>hljs.initHighlightingOnLoad();</script> このdefault.min.cssの部分を変えると色々なスタイルが選べる。 このブログではZenburnを使うことにした。 Hugo味見 Hugoコマンドリファレンスを見つつ、Hugoの味見をする。 サイトのひな形を作るコマンドはhugo new site [path]。hugo new site blogを実行して、blogという名のフォルダにサイトの初期ソースを生成。blogの部分はファイルもフォルダも存在しないパスを指定する。 この時点で、blogフォルダ内には以下のものが入っている。 archetypes: 新規記事作成時に自動で挿入されるFront Matter (後述)のカスタマイズをするためのファイルを置くフォルダ。 content: ブログのコンテンツ(記事など)を置くフォルダ。 data: サイト生成時に使うデータを置くフォルダ。 layouts: サイトのレイアウトを定義するファイルを置くフォルダ。 static: CSSとかJavaScriptとか画像とかのファイルを置くフォルダ。 config.toml: 設定ファイル。これはTOMLだが、YAMLかJSONでもいい。 記事を作るコマンドはhugo new [path]。blogフォルダにcdして、二つ記事を作ってみる。 hugo new about.md hugo new post/first_post.md blog\content\about.mdとblog\content\post\first_post.mdが生成された。 これらには、Front Matterという、記事のメタ情報が自動で書き込まれる。 デフォルトで書き込まれるのは、日付 (date)、ドラフトフラグ (draft)、タイトル (title)だけだが、 Archetypesという機能でカスタマイズできる。 が、今はやらない。 about.mdとfirst_post.mdには適当に記事の内容を書いておく。 次にテーマを設定する。テーマを使えば、自分でレイアウトを書く必要がない。 テーマはHugo Themesにリストされていて、ひとつひとつ選んでインストールもできるけど、今回は全部いっぺんにインストールして色々見てみる。blogフォルダ内で以下を実行すると、blog\themesに全テーマがインストールされる。 git clone --recursive https://github.com/spf13/hugoThemes.git themes これで、以下のコマンドを実行すると、サイトがビルドされ、サーバが起動し、ブラウザで確認できる。 hugo server -t angels-ladder -D -w -tでテーマを指定している。指定するのはblog\themes内のフォルダ名。-Dはドラフト記事をビルドしたいときにつけるオプション。さっき作ったabout.mdとfirst_post.mdは、そのFront Matterのdraftがtrueになっていて、つまりドラフトなので、-Dを付けないとビルドされない。-wはLiveReloadを有効にするフラグで、付けておくとソースを修正したら自動でリビルドとブラウザのリロードが実行される。(変更を監視されるのはサブフォルダ内だけ。config.tomlの変更は無視される。) サーバにはhttp://localhost:1313/でアクセスできる。今回指定したテーマangels-ladderだと、トップページにfirst_post.mdの記事へのリンクがあり、その内容を確認できる。about.mdの方はリンクはなく、直接http://localhost:1313/about/アクセスしないと見れない。この辺りはテーマ(と設定?)によって異なるのかな。 まあabout.mdは試しに作ってみただけなので消しておく。 hugo serverの-tに与える値を変えれば簡単にテーマを切り替えられるので、いろいろ見てみる。 以上で味見終わり。 テーマの選定 - Robust Hugo Themesにあるテーマはどれもあまりしっくりこなかった。 もう自分で作ろうかと思っていたところ、Robustというテーマを見つけた。 こんな感じのページができる。いい。これを使うことにする。 blogフォルダ内で、いったんthemesを消してから以下を実行してRobustをインストール。 > git init .
eyecatch
Tue, Aug 25, 2015

GitHub Pagesでブログ立ち上げ - Jekyllのためのツール

GitHub Pagesでブログ立ち上げ - GitHub PagesとJekyllの続き。 前回は、GitHub PagesとJekyllでブログを始めることにして、Jekyllのセットアップに四苦八苦した。 Jekyllがだいたいセットアップできたところで、どんなサイトデザインにしようか考え始めた。 調べたところ、生のJekyllを使うよりも簡単に見栄えのいいサイトを作れる方法がある模様。 Octopress もっとも有名なのはOctopress。 ホームページの説明によると、「Octopress is a framework designed for Jekyll, the static blogging engine powering Github Pages」とのこと。 フレームワークと呼ぶのはちょっと大げさな気がする。 まあ見たところ、Jekyllをサイト生成エンジンとした、ブログサイト構築、ブログエントリ作成、ブログサイトデプロイなどを簡易化するツール。 広く使われていて情報が豊富だし、テーマを選んでエントリの内容をMarkdownで書くだけでかっこいいサイトが作れる。バージョンは2系が主に使われているやつで、3系がβ状態。 血迷って3系に手を出してみる。GitHubにあるREADMEを見ながらWindows 7上にインストールして、適当なサイトを作ろうとするもjekyll buildでエラー。さすがにWindowsじゃだめかと思い、CentOS 7のVMを立ち上げてそこでやってみるもまたjekyll buildでエラー。 心折れかけながらドキュメントなど見ていたら、多くのプラグインがまだ開発中で、3系は基本的な機能しか動かなそうなことが発覚。素直に2系にすることに。 2系は成熟しているし情報が沢山あるので、順調にインストールとテストサイト作成に成功したあたりで、不審な情報を発見した。 Jekyllのドキュメントによると、GitHub Pagesではセキュリティ対策のためにJekyll をセーフモードで実行するため、カスタムプラグインが無効になるとのこと。 Octopressが生成したJekyllソースをGitHub Pagesに上げたらビルドして公開してくれると思っていたけど、OctopressはJekyllのプラグイン機能をもりもり利用しているようなので、上手くいかないようだ。 つまりOctopressをGitHub Pages上のサイトに使うとしたら、結局ビルド成果物をアップしないといけなくなる。JekyllのソースだけをGitHubで管理するように出来たらいいと思っていたが当てが外れた。 Jekyll-Bootstrap Octopressを使うモチベーションが下がり、他のを探したところ、Jekyll-Bootstrapというのを見つけた。 Jekyll-BootstrapはJekyllのソースそのもので、面倒な部分は既にできてるので、ユーザはテンプレートを使って記事の内容を書くだけでいいよ、というもの。テーマ機能と、記事作成作業をRakeで簡易化するためのRakefile付き。 すばらしいことに、「JekyllのソースだけをGitHubで管理するように出来たらいい」という需要に応えることを目指して作られていて、Jekyll-Bootstrapをベースに作ったJekyllソースはGitHub Pages上のJekyllでビルド可能。 まさに求めていたものと心躍った。 が、プロジェクトページを見るにあまり活発に開発が進んでない模様。 廃れ行きそうなツールを使うのもなぁ… 結論 Jekyll-Bootstrapを使うのは気が進まない。Octopressを使うとビルド成果物をアップしないといけない。 どうせビルド成果物を上げるのなら、Jekyllにこだわる必要はないか、ということで、去年末くらいから盛り上がってきているHugoにすることに。Hugoについてはまた別のエントリで書く。
eyecatch
Sat, Aug 15, 2015

GitHub Pagesでブログ立ち上げ - GitHub PagesとJekyll

このブログを立ち上げたときの作業を、主に備忘録としていくつかのエントリに分けて書く。 このエントリでは主にGitHub PagesとJekyllについて書く。 今の構成 このブログは、Hugoで作って、GitHub Pagesで公開している。 Hugoについては別のエントリで書くとして、GitHub Pagesは、GitHubが提供しているウェブページのホスティングサービスで、GitHubに特定の名前のリポジトリ、または任意のリポジトリに特定の名前のブランチを作ってウェブサイトのソースを置くと、公開してくれるというサービス。PaaSにあたるのかな。 GitHub Pagesのサイトに利用方法が載っている。 以下、このブログ立ち上げに向けてやった作業について書く。 GitHub Pages味見 GitHub Pagesを利用するには、GitHubユーザ名.github.io という名前のリポジトリを作るか、任意のリポジトリにgh-pages という名前のブランチを作って、そこにサイトのソースを置けばいい。そのサイトには、前者の場合はhttp://GitHubユーザ名.github.ioで、後者の場合はhttp://GitHubユーザ名.github.io/リポジトリ名でアクセスできる。 (2016/8/18追記: 今はgh-pagesブランチは不要。) とりあえず前者をやってみる。 kaitoy.github.io という名前のリポジトリを作って、そのルートに「Hello World」とだけ書いた index.html を置く。 ブラウザでhttp://kaitoy.github.ioにアクセスすると、「Hello World」と表示された。 これだけ。 GitHub PagesとJekyll GitHub Pagesには、普通にHTML/CSS/Javascriptのソースを置いてもいいけど、Jekyllを利用することもできる。 Jekyllは、ブログ用の静的サイトジェネレータなるもので、Markdownで書いた記事を元にブログサイトのソースを生成するツール。GitHub Pages用のリポジトリにJekyllのソースをアップロードすると、Jekyllでビルドされ、その結果が公開される。 これはうれしい。 Jekyllのソースとビルド結果を別々に管理しなくてよくて楽だし、公開されるサイトが最新のソースに基づいていることが保証される。 結論から言うと、以下のような理由で結局Jekyllは使わなかったんだけど、Jekyllとの格闘の記録を残しておく。 Windowsを正式サポートしていない。 Rubyで書かれてるため、ビルドが遅い。ブログエントリが数百とかになると辛くなってくるらしい。 Jekyllを使っても、かっこいいサイトを手軽に作ろうと思ったら、結局ビルド成果物もGitHubに上げないといけなくなる。 Jekyllセットアップ GitHub PagesでJekyll使う場合は、GitHub Pagesと同じJekyll環境を手元に作ってプレビューできるようにしておくべきとのこと。なので、これに従って自分のPC (Windows 7) にJekyllをセットアップする。 1.Rubyインストール Jekyllは Ruby で書かれてるので、まずはRubyをインストールする。 WindowsなのでRubyInstaller (ver. 2.2.2)をダウンロードしてインストール。 Bundler (RubyのパッケージであるGemの依存をアプリケーションごとに管理するツール) もあるといいらしいので、gem install bundlerを実行してインストール。 2. Jekyllインストール さっき作ったリポジトリ kaitoy.github.io (の手元のクローン)のルートに、Bundlerの定義ファイルを Gemfile という名前で作り、以下の内容を書く。 source 'https://rubygems.org' gem 'github-pages' 依存するGemは jekyll じゃなくて github-pages。これはGitHub Pages環境のJekyllということだろう。 で、kaitoy.github.io のルートでbundle installを実行する。ここでエラー発生。 エラーメッセージによると、native gemをビルドするために DevKit なるものが要るとのこと。 再びRubyInstallerのページに行ってDevKitをダウンロードして、wikiに従ってインストール。 再度bundle installしたらJekyllのインストールに成功。 github-pages: ver.