まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:domain

2019年4月1日午前11時40分ごろ、新しい元号の発表がありました:
gengou_happyou_reiwa_kakageru


30年ちょっと続いた「平成」は4月30日の「退位の日」を持って終わり、5月からは「令和」となります。自分自身は昭和から平成と変わる時も物心がついていたのですが、昭和天皇崩御の直後だったこともあってお祝いというよりは静粛な雰囲気で行われた記憶があります。改元自体はおめでたいことだと思うので、本来はこうあるべきなんじゃないかな、、と思っています。

さて、この新元号発表の瞬間、僕は Abema TV にへばりついて生中継を見ていました。一刻も早く新元号を知りたかった理由、それは「新元号のドメインをとりたかった」に他なりません(笑)。

ドメインというのはインターネットのネームスペースのドメインのことです。メールアドレス xxx@abc.co.jp でいう "abc.co.jp" の部分です。ドメインは原則早いもの勝ちで取得ができるもので、おそらく同じことを考えていた人は少なくないと思います。そんな中で新しい元号が発表されたら、その元号にちなんだドメイン ○○○.jp を後で高く転売してやろうとか考えて取りたかったのでした。

ちなみに、自分はいくつかのドメインを所有しています。ドメインの申請や登録業者には GoDaddy.com を使っています。特別な理由はなく「ずっと昔からここを使っていたから」です。今回の新元号ドメイン取得は多くのライバルがいることを想定していたので、事前にシミュレーションを行って購入のリハーサルを行ったり、最短スピードで購入できるような手順を確認した上で臨みました。

(1)購入まで
そして当日、Abema TV を聴きながら(視てません。画面は GoDaddy.com にして、音声だけ聞いて、発表直後にドメイン検索できるように待ち構えてました)その瞬間を待ちます。そして発表!

・・「レイワ? レイワって言ったな?」 直後に reiwa.jp を検索(体感的にはこの間 0.1 秒)! 結果は・・・がーん、まさかの取得済み! 


後で調べてわかったのですが、千葉県柏市の「株式会社 冷和」様が 2007 年に登録済みのドメインでした:
2019041801


が、reiwa.jp が取得済みなのは(まさか一般企業が取得しているとは思ってなかったけど)想定済み、プランB発動! .jp 以外でどこか空いてないかな・・・ と探していたら reiwa.world が空いていました。

「ワールド!? うーん、ワールドか・・・ でもまあ『世界にアピールするには悪くない』よな。あと .world なら値段もそんなに高くないはず」と体感的には1秒ほど考えた後、脊髄反射的に購入プロセスへ(というわけでスクリーンショット撮ってません、ごめんなさい)。もしかしたら同じ処理をしている人が他にいるかもしれない、その場合は早いもの勝ち! でもこのあたりは直前に何度もリハーサルしてるので(苦笑)迷うことなくサクサク進めることができました。そして、、、
2019041802


取ったー!!

もうドメインを取ることだけを考えて手を動かしていたので値段見ずに買ってました(良い子は真似しちゃいけません)。ぶっちゃけ思っていたよりも高い。(^^; しかもよくわからない "Private Domain Registration" まで付けて買ってるし(苦笑)。でもいい! reiwa.world ドメイン取ったどーー!!


(2)謎のメール
上記の購入お知らせメールを受信した直後に GoDaddy.com からもう一通のメールを受信しました:
2019041803


"reiwa.world" を登録できない!? エラー!? 登録できなかったら返金する、って、いやいやいや。どういうこと??

後でわかったのですが、どうやら GoDaddy.com の受付処理が間に合わないレベルでほんの僅かに先客がいたようで、このドメインを取ることができませんでした:
2019041804


この先客の登録は日本時間で 11:42:43 、僕の登録(正確には登録メールを受信したタイミング)は 11:43:04。20秒差もあったということは、この相手はほぼ自動的にドメインを登録する処理をしていたのだと思われます。やられた・・・

そしてその先客とは・・・グーグル様でした。 凸(▼▼
2019041805


残念ですが、「個人でグーグルと張り合った」と解釈して満足することにします。


(3)返金
後日、GoDaddy.com から返金処理が行われてきました:
aeon201905


ちょっと待って!

支払額が 23558 円で、返金額が 18063 円。なんで差があるの? しかもこの 18063 円ってドメイン登録費用のみの額で、(調べずに付けて買った)プライバシー登録費用の 5495 円ぶんが返金されてないじゃん!

というわけで GoDaddy.com のカスタマーサポートに電話。ここ、いつの間にか日本語で電話できるようになったんだよね。助かります。

で、事情を伝えると「忘れてたみたい、今から返金します」的な感じで対応していただきました。 まだ入金は確認できませんが、とりあえず手続き処理は完了した模様です。


最後までドタバタしましたが、令和の前に令和の騒動を解決できたっぽいのでまとめておきました。 令和の次まで生きてたら、次回は自分も API とか探して自動化で参戦したいです。

今月(2018年5月)から GitHub ページがカスタムドメインでも HTTPS 対応された、という発表がありました:
Custom domains on GitHub Pages gain support for HTTPS

2018051001


というわけで、自分が取得しているドメインを使って試してみました。以下、GitHub ページの紹介と、その手順を含めた報告です。


GitHub ページとは?

GitHub ページとは GitHub の仕組みを使った静的ウェブサイトのホスティングサービスです。GitHub アカウントを持っていれば、誰でも簡単にウェブサイトを作って公開することができるので、非常に便利です。


GitHub ページの作り方

index.html 一枚だけの非常にシンプルな例で紹介します。まずは普通に Github でリポジトリを作成し、GitHub ページ(ウェブサイト)に含めたい HTML ファイルその他をまとめてプッシュし、公開します:
2018051002


この時点で、同リポジトリが GitHub で普通に公開されている状態になりました:
https://github.com/dotnsf/githubpagessample


(今回、公開する index.html ファイルの中身)
https://raw.githubusercontent.com/dotnsf/githubpagessample/master/index.html


次にこのリポジトリを GitHub ページとして公開します。リポジトリのページから "Settings" メニューを選択します:
2018051003


少しスクロールして GitHub Pages の設定欄を表示し、Source が None になっている所を "master branch" に変更して "Save" します。これでこのリポジトリのマスターブランチが Github Pages として公開されることになります:
2018051004


"Save" が成功すると画面内に GitHub Pages として参照する場合の URL が表示されます。一般的にはここは https://(ログイン名).github.io/(リポジトリ名)/ となります:
2018051005


この URL にアクセスしてみると、先程のリポジトリのマスターブランチが HTTP サーバーのドキュメントルートとして扱われる感じになり、index.html ファイルが表示されます。またこの画面からもわかるように、このページは HTTPS 対応しています:
2018051102


以上、ここまでが GitHub ページの説明です。


カスタムドメインで GitHub ページを使ってみる

今回の更新で、上記の GitHub ページがカスタムドメインでも HTTPS 対応されるようになりました。この点を確認したいので、まずは GitHub ページをカスタムドメイン対応してみます。

そのためには GoDaddyお名前.comなどのドメイン業者でドメインを取得しておく必要があります。ここはどうしても無料というわけにはいかず、ドメインの種類にもよりますが、1年間 $10 程度かかってしまうことを理解した上で取得してください。ちなみに自分は(B'z ファンでもないのに) welove.bz というドメインを GoDaddy で取得しているので、このドメインを使って GitHub ページをカスタムドメイン対応する手順を以下に紹介します。

最初に、対象ドメインの DNS 設定を変更する必要があります。このページの "Configuring A records with your DNS provider" という項目によると、ホスト名の A レコードの IP アドレスを以下のように設定する必要があるようです:
2018051103


A レコードの IP アドレスを複数設定できる場合はこの4つの IP アドレスを設定します。僕が使っている GoDaddy では1つしか設定できないようだったので、一番上のアドレスに指定しました:
2018051104


この部分は同様の作業をドメイン業者の用意したツールを使って設定してください。 なおこの作業について、詳しくは GitHub のドキュメントも参照ください:
https://help.github.com/articles/setting-up-an-apex-domain/


この作業の後で、GitHub の該当リポジトリに CNAME という名前のファイルを1つ追加します。CNAME ファイルの中身にはカスタムドメイン名だけを記載します:
2018051105


このファイルをリポジトリに add して commit して push します:
2018051106

2018051107


最後に再びリポジトリの settings 画面を確認して、GitHub ページのカスタムドメインが設定されている(されていない場合は、ドメイン名を入力して "Save")ことを確認します。これで GitHub ページのカスタムドメイン設定ができました:
2018051108


この状態で http://(カスタムドメイン名) にアクセスすると、先程まで ***.github.io ドメインで動いていた GitHub ページが表示されます:
2018051101


これで GitHub ページのカスタムドメイン化が完了しました。



カスタムドメイン GitHub ページの HTTPS 対応

やっと本題です(苦笑)。ここまでの作業で GitHub ページがカスタムドメインで利用できるようになりました。今回の目的は「このページを HTTPS 対応にする」ことです。

そのための設定はリポジトリの settings で、カスタムドメインを指定した下に "Enforce HTTPS" というフィールドがあるので、ここにチェックを入れるだけ・・・
2018051101



・・・なのですが、まだ証明書が有効になっていないようです(チェックできない)。こうなると作業としてできることはないので、ひたすら待つ必要があります。

ちなみに、この状態で無理やり HTTPS を指定して https://(カスタムドメイン名)/ にアクセスすると「安全な接続ではない」と言われます。ここから例外を承認して・・・ということもできないわけではないですが、せっかくなのでしばらく待ちましょう:
2018051102


しばらく待つとこの部分のメッセージが変わり、"Enforce HTTPS" がチェック可能になります:
2018051103


チェックするとこのような画面になり、このリポジトリの GitHub ページは強制的に(HTTP でリクエストしても)HTTPS でアクセスされるようになります:
2018051104


実際にアクセスしてみました。ちゃんと HTTPS に転送されています:
スクリーンショット 2018-05-11 15.38.40


HTTPS のインフォメーションを確認しても(オレオレ証明書とかではなく)"Secure Connection" になっていることが確認できます:
スクリーンショット 2018-05-11 15.39.12



(おまけ)
ではこの証明書は誰がどうやって発行しているのだろう? と疑問に思ったのですが、"Verified by: Let's Encrypt" だそうです。なるほどね・・・:
スクリーンショット 2018-05-11 15.38.58


めでたし、めでたし。
ところでこの welove.bz ドメイン、なんかいい使いみちないかな? (^^;


以前に IBM Bluemix を独自ドメインで利用する方法について紹介しました:
IBM Bluemix を独自ドメインで運用する


本エントリでは、特に SSL を使って IBM Bluemix を独自ドメイン運用するための注意点と手順を紹介します。


まず独自ドメインを使わない場合、IBM Bluemix 上のウェブアプリケーションには米国リージョンの場合で****.mybluemix.net(英国リージョンであれば ****.eu-gb.mybluemix.net)というホスト名が割り当てられます。**** 部分はアプリケーション作成時に指定したものが使われます。 以下、説明をシンプルにするため、米国リージョンでの利用を前提として説明を続けます)。

このホスト名を SSL で利用する場合の SSL 証明書は mybluemix.net 側で(つまり IBM 側で)用意されていることになります。特に **** 部分にどのような文字列が来るか想定できない前提で SSL を使うので、その証明書はワイルドカード対応のものが用意されている、ということになります。


さて、独自ドメインで IBM Bluemix を使う場合の注意点として、そのドメインの SSL 証明書は利用者が用意する必要があり、加えて上記の理由からその証明書はワイルドカード対応のものを用意する必要がある、ということになります。

現在、SSL 証明書を発行してくれるサービスは国内外でいくつかあります。ただ IBM Bluemix で利用するドメインの SSL 証明書を発行してもらうためには、ワイルドカード対応のものを発行してもらう必要があるのですが、全ての業者がワイルドカード対応の証明書を発行してくれるわけではありませんワイルドカード対応の SSL 証明書を発行してくれる業者の中から選んで注文する、という点に注意が必要です。


ただ、特定の限られた用途での利用など、いわゆる「オレオレ証明書」でもいい、という場合は、自分でワイルドカードに対応した SSL 証明書を用意することでも対応は可能です。ワイルドカードに対応した SSL 証明書を自分で発行する場合の手順はこちらを参照してください:
ワイルドなオレの証明

以下はこの方法で用意した SSL 鍵および証明書を使った前提で紹介を続けます(手順そのものは正式な証明書を使った場合も同様です)。

まず冒頭で紹介した「IBM Bluemix を独自ドメインで運用する」の手順を進めて、「組織の管理」メニューからドメインの追加を行います:
2015030601


追加する独自ドメイン(この例では "yellomix.net")を指定して「保存」します:
2015030602


保存後、「SSL 証明書」と書かれた列に証明書アップロードのためのボタンが表示されるので、ここをクリックします:
2015030603


証明書ファイルと秘密鍵ファイルを指定してアップロードします。もし中間証明書ファイルをお持ちで、追加したい場合は中間証明書ファイルも指定します。最後に「アップロード」ボタンをクリックします:
2015030604


先ほどのボタンがグリーンに変わっていれば証明書ファイルのアップロードは完了です:
2015030605


では独自ドメインでアプリケーション・サーバーを1つ作成して、SSL でアクセスする、という動作確認を行ってみます。まずは Bluemix 上に(動作確認なので中身はあってもなくてもいいと思いますが)ランタイムまたはボイラープレートから作成したランタイムを作ります。その際にドメイン情報として、追加した独自ドメインを指定するようにします:
2015030606


ランタイムアプリケーションを作成すると、経路の情報としてホスト名が表示されます。先ほど独自ドメインを指定したので独自ドメインにアプリ名が付与されたホスト名になっているはずです:
2015030607


DNS 側でもこのホスト名の名前解決ができるような設定をしておきます。このランタイムに付けた名前(dotnsf-ibm-wordpress)の CNAME として、元々デフォルトで割り振られるはずだった名前(dotnsf-ibm-wordpress.mybluemix.net)を参照するように指定します。この部分は各々でお使いの DNS ツールの方法に従ってください:
2015030608


これで設定は完了しています。確認のため実際にブラウザを使って、作成したランタイムのホスト名に対して https:// でアクセスしてみましょう。オレオレ証明書を使った場合は、ブラウザの種類にもよりますが、「接続の安全性を確認できない」云々、といった確認画面になると思います。ある意味、正しく SSL が動いている証拠と言えます:
2015030609


理解した上で許可すれば SSL で(httpsで)見れるようになります。このホスト名を直接指定した形では SSL 証明書を作っていませんでしたが、ワイルドカード指定で作成した SSL 証明書が IBM Bluemix に正しくインポートされて動いていることが確認できました:
2015030610





















 

IBM Bluemix を使ってアプリケーションサーバーを立ち上げると、そのアプリケーションの URL は
 http://(アプリケーション名).ng.mybluemix.net/ (USリージョンの場合)
 http://(アプリケーション名).eu-gb.mybluemix.net/ (EUリージョンの場合)
となります(アプリケーション名の部分は作成時に付けた一意の名前)。

自分でドメインを管理しなくても、このようなサブドメインが用意されていて、すぐに公開できる、ということになります。これはこれで便利ですが、実際の運用時になると会社などで取得した独自のドメインを使って、
 http://(アプリケーション名).yourdomainname.jp/
のような URL で運用したい、ということもあると思います。

もちろんホスト名と IP アドレスの関係だけであれば DNS 側の設定で済むのですが、アプリケーションサーバー自身に自分のホスト名が変わったことを理解させる必要があるケースもあります。 IBM Bluemix はそのような設定もできるようになっているので、その手順を紹介します。

例として、僕が個人で取得している yellowmix.net というドメインを使って Bluemix 上のアプリケーションを稼働させてみます。


まず、Bluemix 上で追加したい独自ドメインをシステムに知らせる必要があります。ダッシュボード画面の左上で組織アイコンをクリックし、「組織の管理」を選択します:
2015020201


組織の管理画面が表示されたら「ドメイン」タブを選択します。現在システムで管理しているドメイン(この例では eu-gb.mybluemix.net)が表示されるので、「ドメインの追加」ボタンをクリックして新しいドメインを追加します:
2015020202


ここで自分が取得しているドメイン(この例では "yellowmix.net")をキーボード入力で指定して追加します。最後に「保存」ボタンをクリックします:
2015020203


"yellomix.net" ドメインがシステムドメインとして追加されました:
2015020204


続いて、Bluemix 上のアプリケーションサーバーにこのドメインを使ったホスト名によるルーティングを指定します。アプリケーションを1つ選択し、現在の経路が書かれている右側の鉛筆アイコンをクリックします:
2015020205


経路の編集ダイアログが表示されます。今回は新たな経路を追加したいので「経路の追加」をクリックします:
2015020206


新しい行が追加されるので、新しい経路のホスト名を入力し、続いてドメインを選択肢から選びます。先程 "yellowmix.net" ドメインを追加しているので、選択肢の1つとして表示されるはずです。最後に「保存」ボタンで保存します:
2015020207


1つ前の画面に戻り、新しい経路が追加されたことが確認できます:
2015020208


ここまでの作業で Bluemix サーバー側の設定は完了しました。最後に DNS 側に cname 値を追加します。ここでの作業はドメインを取得した際の DNS 業者によって設定方法は異なりますが、以下は GoDaddy.com での例です。CNAME 値として先程設定したホスト名を追加し、その接続先を元の ****.eu-ng.mybluemix.net に指定して保存しています:
2015020209


これで全ての作業が完了しました。独自ドメインを使った URL で元のアプリケーションにアクセスできるようになりました:
2015020210









 

このページのトップヘ