正月休みのせいかどうか知らないが、Amazonのサポートからは何も返事がこない。とか言っている間に「お名前.com」のサポートから連絡がくる。すいません。返答を待っている間にキレてGoogle Domainsに引っ越してしまいました。えへへへ。

というわけで、S3が使用可能になった時の予習に余念がない。しかしあらためて手順を見ると（Amazonの人が講演した「Amazon S3による静的Webサイトホスティング」というスライドが存在しているのだ）結構面倒なことに気がつく。ただS3におくだけではだめで、Route53と連携し、CloudFrontと連携し。それらのサービスについて学ぶにはいい機会だが、私はできるだけ楽をしたい。

問題はもう一つある。この手順に従うとGoogle domainsのDNSを諦めAmazonのDNSを使用しなくてはならない。結果としてまたmail転送がうまくいかない問題に逆戻りである。

なんとかその問題を回避する方法はないか、とあれこれ検索する。こういう時たよりになるのはStackoverflowである。それはなんだ、と問われれば「プログラミング関係で困ったときには大抵の答えが載っているサイト」と答える。実のところ私は学生に「英語を勉強すべきですか？」と問われれば「ソフトウェアの仕事をするのなら、Stackoverflowを読み書きできる英語力は最低限必要だ」と答えることにしている。それぐらいにStackoverflowにはありとあらゆる問題の答えが載っている。もしStackoverflowに答えがないとすれば、自分がなにかとんでもなく初歩的に間違ったことをしているのだ。

話を戻そう。Stackoverflow様のお告げに従い、AmazonのDNSを利用した状態で、Googleで管理しているドメインでメール転送をする目処が立つ。しかしそれはAmazonとかGoogleが推奨している方法ではない。ということはある日突然その方法が使えなくなり、かつ文句を言う相手がどこにもいない、という可能性が存在するということである。

なんとかもう少しまともな方法はないか、と探しているうちにGoogleにもS3のようなCloud Storageというものが存在することを知る。そうだよ。GoogleがAmazonの独走を指を加えて見ているわけがないじゃないか。おまけにこちらはGoogleのサービスだからきっとGoogle Domainsと相性もいいに違いない。よし、これにしよう。

そう思ってあれこれ調べる。しかしどうにもこうにも細かいところが気になる。最近のWebサイトはhttp://ではなくhttps://で始まるものが多い。なんだか知らないがとにかくhttpsなのだ。ところがGoogle Cloud Storageでは、独自ドメインを使った場合それが使えないと書いてある。そして「もし使いたい場合にはFirebaseを使ってね」とも書いてある。

左様か。ではそのFirebaseというものを使おう。そう考えアクセスしてみると自分がすでにアクセス解析で利用していることを思い出す。スマートフォン上で動くアプリを作るなら、Firebaseを利用しないと損だよ、とどこかで読んで使ったことをかすかに思い出す。ここにはサイトの面倒をみてくれる機能もあるらしい。

よし。こちらもGoogleのサービスだからGoogle Domainと組み合わせた時もちゃんと動いてくれるに違いない。そう信じ込んであれこれ設定を始める。使うためにはあれこれのツールをPCにインストールする必要がある。大抵こういうのはどこかでつまづくことになっているが、珍しくすんなりインストールできる。えいやとテストページを設定するとちゃんと表示される。ああなんて簡単。ありがとうFirebase。

ところが「さあ全体を移行しちゃうぞ」と考えたところでいやなことに思い当たる。パソコン側であれこれファイルを更新した後サーバー側に転送するのだが、そのコマンドが一種類しかない。deloyという呪文だ。単純でいいのだが、ふと気がつく。

「これってたくさんあるファイルの中の更新したものだけ転送してくれるんだろうか？」

当サイトにはファイルがたくさんある。毎日いじるのは、せいぜい二つから５つのファイルだけ。そのたびに全部転送してもらうのは困る。そしてこうした場合はどこでも同じだが「こういうことができます」とは書いてあるが、「これはできません」はなかなか見つからない。結局またもやStackoverflowのお世話になる。結論として

「それは無理」

ということらしい。そもそもFirebaseは、サーバー側の機能を実現するために作られたものだから差分更新の機能は、、とかなんとか書いてある。

しかたない。というわけで、S3の代替をあれこれ調べたときにもう一つ候補にあがっていたNetlifyというものに頼ることとする。こちらは裏でAmazon S3を使っているらしいのだが、あれこれがんばることで、ユーザにはとても簡単に見せている。おまけに無料。不安といえばここはベンチャー企業なのでいつ

「すいません。サービス終了します」

になるかわからないところだが、まあそれは考えないことにしよう。仮にGoogleのサービスでもいつ「終了します」になるかわからないんだし。

というわけで設定を始める。Netlifyではパソコンから直接ファイルを転送することもできるのだが、GithubとかBitbucketというファイル管理サービスと連携することを推奨しているらしい。それはなんだと問われれば

「プログラムを書くとき、”前の状態に戻したい”と泣き喚かなくても済むようにしてくれるサービス」と答える。

それでもって最近作っているプログラムはBitbucketというサービスのお世話になっている。プログラムのソースコードも、サイトの文章も同じファイル。ならばお世話になっても問題なかろう。そう考えBitbucketにごっそりファイルを登録する。その際

「このファイル１０MB超えてるけどいい？」

とかいう警告文が出る。長年使っているサイトだから怪しげな巨大ファイルが点在している。まあいいや、とBitbucketに登録。でもってNetlifyに接続する。自動で展開されるはずだから待っていればいいはずだ。

そう思い箱根駅伝など横目で見ながら待つ。しかしいつまでたっても最初のファイルが見られるようにならない。どういうことか、と思いNetlifyの表示をみるとエラーがでて止まっている。どうやら先ほど警告がでた「巨大ファイル」が問題のようだ。不要なものなので削ってしまう。そのあともいくつか「これがひっかかります」というエラーがでたが、それらをモグラ叩き状態で消すことしばらく。とうとうサイトが表示されるようになる。これまでさくらのサーバー上で表示されていたものが、あっというまに他の場所に表示される。当たり前だがちょっとびっくりする。この時点で１月２日のお昼。

少し昼寝などして、再度作業を始める。言われるままにhttpsを有効にし、ついでにhttpsを強制するように設定する。これがどんな結果を招くか知ったのは後のことである。

最後は難関（のはず）のドメイン設定である。otsubo.infoというアドレスでアクセスできるようになってもらわなければならぬ。

調べてみると、さくらサーバーのようにNetlifyご推奨のDNSを使いなさい、という設定もあるがそれ以外の方法も記載されている。そちらを使えばMail Forwardingに使っているGoogle domainのDNSはそのままで行けそう。というわけで、えいやと切り替えてしまう。しばらく待ったか待たなかったか覚えていないがotsubo.infoでちゃんと表示がされるようになる。こうやってブラウザでアクセスするとなんの変化もないように見えるが、裏の仕組みは完全に変わっている。そのあっさりさ加減にちょっと驚く。

記録によると1月3日からはサイトの通常更新を、こちらで行なっている。長年使ってきたさくらサーバーもこれでさようなら（まだメールの後始末という”小さな”作業が残っているが）S3はそれなりにお金をとられるが、Netlifyだと私のサイトが大炎上でもしない限り無料で賄える。ああ、なんて素敵。

それとともに、自作して長年使ってきた「更新されたファイルだけをサーバーにFTPでアップロードしてくれる」アプリケーションも用済みとなる。考えてみれば最近そもそもFTPという言葉自体聞かないもんなあ。Gitという謎の仕組みを使うと、パソコン上で修正したファイルだけがBitbucketに送られる。そこから先は何か魔法がかけられotsubo.infoで見られるようになる。正月休みの間私は世の中の進歩のありように満足してほれほれと過ごしていた。そんなに話がうまくいくはずがないことを知っていたはずなのに。

前の章｜目次|　次の章