eyecatch
Tue, Feb 14, 2017

ブログアドレスを変更したときにやったこと

このブログの閲覧数がそこそこの規模になってきたので、Google AdSenseで小遣い稼ぎを始めようとしたら、最近サブドメインがwwwじゃないとできないようになったようだったので、サブドメインをtbdからwwwに変更した話。 変更自体はそんなに難しくなかったけど、Googleの検索順位を保つためにいろいろ気を使う必要があった。 (adsbygoogle = window.adsbygoogle || []).push({}); ブログアドレスの変更 以前にも書いたが、このブログはHugoで作ってGitHub Pagesでカスタムドメインで公開している。 コメント欄を設けるためにDisqusを使っている。 Cloudflareを使って全体をHTTPS化していて、その関係でkaitoy.xyzドメインの名前解決にはCloudflareのDNSを使っている。 アクセス解析などのためにGoogle AnalyticsとGoogle Search Consoleを使ってる。 この構成で、ブログアドレスの変更に必要だった修正を列挙する。(この順にやったわけではない。) 1. ブログソース修正 Hugoの設定ファイルであるconfig.tomlに書いてあるbaseurlの値をhttps://tbd.kaitoy.xyzからhttps://www.kaitoy.xyzに変え、また、各記事の内部リンクのURLもwwwのに変えた。 あとrobots.txtのSitemapのURLもhttps://www.kaitoy.xyz/sitemap.xmlに更新した。 2. GitHub Pagesの設定変更 ブログリポジトリに行って、SettingsのGitHub Pages欄のCustom domainの値をhttps://www.kaitoy.xyzに変えた。 ついでにブログリポジトリのトップに表示されるDescriptionのWebsiteの値も新しいURLに変更した。 この変更によりありがたい副作用もあった。 GitHub Pagesはwwwというサブドメインを特別扱いしていて、以下の恩恵を受けられるのだ。 wwwを省略したURL(apex domain)でアクセスすると、GitHub Pagesサーバがwww付きのURLにリダイレクトしてくれる。 安定していて速い。 3. CloudflareのDNS設定変更 CloudflareのDNSで、もともとCNAMEレコードでkaitoy.github.io(GitHub Pagesのデフォルトのドメイン)のエイリアスをtbdにしていたのをwwwに変更した。 また、上記の通りapex domainでGitHub Pagesにアクセスしても上手いことやってくれるようになったので、www.kaitoy.xyzのエイリアスをkaitoy.xyzとするCNAMEレコードを追加した。 CloudflareのDNSはapex domain(i.e. kaitoy.xyz)に対するCNAMEレコード設定をサポートしているので、これでwww.kaitoy.xyzでもkaitoy.xyzでもGitHub Pagesにルーティングされるようになった。 4. Disqusの設定変更 ホームの右上の歯車アイコンからAdminを開いて、ヘッダのSettingsからブログのURLを選んでその設定画面を開き、Website URLをhttps://www.kaitoy.xyzに変更した。 5. Google Analyticsの設定変更 管理タブのプロパティ設定のデフォルトの URLをhttps://www.kaitoy.xyzに変更しただけ。 Googleのページランクを保つためのあれこれ 以前もどこかに書いたが、どんなにすばらしい内容の記事を書いてもGoogle検索結果の2,3ページくらいまでに出てこないんであれば誰も読んでくれない。 このブログのいくつかの記事はそれなりにいいキーワードでいい検索順位になっていたので、サブドメイン変更によってページランクに悪影響が出るのはなるべく避けたかった。 調べたら、Google Search Consoleのヘルプにまさにその悪影響を防ぐ方法が載っていたので、これに従ってあれこれした。 1. 自身を参照する rel="canonical"リンクタグを付ける ブログの全てのページのヘッダに以下の様な移転先アドレスを指すlinkタグを付け、変更後のアドレスが正式なアドレスであることをGooglebotに教えてやる。 <link rel="canonical" href="https://www.kaitoy.xyz/2015/07/18/first-post/"> Hugoのソースでいうと以下の感じ。 <link rel="canonical" href="{{ .Permalink }}"> 2.
eyecatch
Fri, Jul 1, 2016

CloudflareでブログをHTTPS化

最近GitHub PagesがHTTPSに正式対応したというニュースを見たことをきっかけに、このブログをCloudflareで常時HTTPS化した話。 (adsbygoogle = window.adsbygoogle || []).push({}); このブログ このブログは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の記事を参考にした。
eyecatch
Fri, Aug 28, 2015

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

GitHub Pagesでブログ立ち上げ - Jekyllのためのツールの続き。 前回は、GitHub Pagesで公開するブログサイトを構築するのに、JekyllとJekyll関連ツールを使おうと四苦八苦したが、結局Jekyllに見切りをつけ、Hugoを使うことに決めた。 (adsbygoogle = window.adsbygoogle || []).push({}); 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を使うよりも簡単に見栄えのいいサイトを作れる方法がある模様。 (adsbygoogle = window.adsbygoogle || []).push({}); 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についてはまた別のエントリで書く。