プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

ディズニーのくるくる回るおもちゃの電池交換

ずいぶん前に子供をディズニーのイベントに連れてってた時に、欲しい!と言われて買った、くるくる光って回るおもちゃですが、電池が切れました。

f:id:junichim:20170923220721j:plain

これ、裏側のフタを空ければ電池交換できるんですが、これが開けにくいのってなんの。

必要なもの

  • マイナスドライバー(少し大きめのほうがいいかも)
  • 交換用電池(単4 3本)

開け方

  1. 電池フタの下部の隙間にマイナスドライバーを入れます。 f:id:junichim:20170924145346j:plain
  2. ドライバーを隙間の奥に押し込みながら、おもちゃの端(黒いところ)側を支点にして、てこの要領で少し前側(電池が入っている部分側)に押します
  3. 力をよしなに調整すると、フタが、パカッと取れます

力のかけ具合が難しいところですが、少しづつ力を入れていくとうまくできると思います。 (動画撮ればよかったですね、すいません)

ちなみに電池ケース上部にある、ネジは無関係のようで、外さなくてもフタ取れます。

フタがとれた後はこんな感じです。

f:id:junichim:20170923221135j:plain

フタ(表)

f:id:junichim:20170923221157j:plain

フタ(裏)

f:id:junichim:20170923221213j:plain

フタの画像を見ると分かるように、フタの下側(画像で下側)部分のツメで引っ掛けている感じです。

取り付けるときも逆の要領でつけます(ドライバーを使ったほうがスムーズに取り付けられると思います)。

最悪、ツメが折れたりしても責任取れませんので、自己責任でお願いします。

小さいお子さんのいる方、怪我しないように、頑張って電池交換にチャレンジしてみてください。

参考

hirokiman.way-nifty.com

独自ドメインで、メールとhttps化したWebサイトを別サーバーで運用する (2/2)

blog.mori-soft.com

の続きです。 ここから、https でアクセス可能なWebサイトの公開のための作業になります。

Amazon Certificate Manager によるSSL証明書の取得

ドメイン所有者宛てに送られるメールを受け取れるようになったので、SSL証明書の申請を行います。 SSL証明書は、リージョン毎に作成されるようです。

ただし、CloudFront で使用できる証明書は us-east-1 のリージョンのもののみなので、このリージョンに対して証明書の申請をすることに注意してください。

詳しくは、

よくある質問 - AWS Certificate Manager | AWS

にある『Q: 複数の AWS リージョンで同じ証明書を使用できますか?』に記載されています。

AWSのコンソールにログインして、Certificate Manager を開きます。 リージョンとして、us-east-1 (米国東部(バージニア北部))を選択します。 『証明書のリクエスト』を押します。

f:id:junichim:20170915102906p:plain

ドメイン名を入力する欄があるので、今回使用する独自ドメイン名を入力します(Zone Apexとして入力します)。 ワイルドカード証明書も取ることができるので、『この証明書に別の名前を追加』ボタンを押して、サブドメインのワイルドカード証明書も申請しておきます(今回の目的には不要なのですが、別件で使うかもしれないので)。

f:id:junichim:20170915103130p:plain

ちなみに、ワイルドカード証明書だけでは、Zone Apex はカバーされないのでご注意ください。

次に進むと確認画面が表示されます。

f:id:junichim:20170915103547p:plain

ここで、『確定とリクエスト』を押すと、ドメイン所有者に対してメールによる確認が行われます。

f:id:junichim:20170915104222p:plain

メール記載のリンクをクリックして、表示される確認内容に問題がなければ、承認します。 承認後、コンソールの画面に戻り『続行』と押すと、問題なければ、証明書一覧の画面が表示され、ステータスが『発行済み』となります。

f:id:junichim:20170915104848p:plain

こんな感じになってれば、証明書が発行できてます。

S3のホスティング

さて、いよいよホスティングするS3の設定をします。

まずは、バケットを作成します。S3で独自ドメインを割り当てる場合は、サブドメインでもZone Apexでもバケット名をそのドメインの形式にする必要があります。

例えば、独自ドメイン名が example.com なら、バケット名も example.com になります。

また、S3でホスティングする場合、誰でも見れる必要があるため、アクセス許可(アクセスコントロールリストやバケットポリシー)を追加しますが、今回は、CloudFront経由でのアクセスのみに制限するので、現時点では、アクセス許可はデフォルトのままとします(パブリックアクセス許可を与えません)。

なので、この時点ではブラウザで確認できないのでご注意ください。

表示するためのファイルをindex.htmlとしてアップロードしておきます。

Hello WOrld!

公開するバケットの『プロパティ』『Static website hosting』を選択して

f:id:junichim:20170915110643p:plain

設定画面で、

f:id:junichim:20170915110934p:plain

『このバケットを使用してウェブサイトをホストする』を選んでおきます。

CloudFront の設定

S3の設定ができたら、CloudFrontでディストリビューションを作成します。

設定内容としては、httpsでのアクセス(httpはhttpsにリダイレクト)とし、必ずCloudFront経由でS3にアクセスするようにしています。

デフォルトの設定値と異なる箇所を以下に示します。

  • Origin Domain Name : S3のバケット名を選択
  • Restrict Bucket Access : Yes
  • Origin Access Identity : Create a New Identity
  • Grant Read Permissions on Bucket : Yes, Update Bucket Policy
  • Viewer Protocol Policy : Redirect HTTP to HTTPS
  • Alternate Domain Names : 独自ドメイン名
  • Default Root Object : index.html

なぜか、この時点で SSL Certificate として Custom SSL Certificate を選択できなかったので、一旦このままディストリビューションを作成します。

なお、CloudFront経由でS3にアクセスする方法については

blog.mori-soft.com

に記載があるので、ご参考にしてください。

Route53 の設定

独自ドメインに対して Alias レコードを設定します。

f:id:junichim:20170915111507p:plain

レコードタイプとして Aレコードを選択して、AliasをYesにします。

Alias Target として、CloudFront のアドレスを選択します。

CloudFront で証明書を指定

最後に、CloudFrontのディストリビューションを再度開き、『General』タブで『Edit』を行います。

f:id:junichim:20170915111932p:plain

SSL Certificate として Custom SSL Certificate を選択し、その下のドロップダウンリストからACMで取得した証明書を選択します。

これで設定完了です。

確認

さて、ブラウザでアクセスしてみましょう。

f:id:junichim:20170915112319p:plain

httpsでアクセスしてもちゃんと表示されています。 ちなみに、http//独自ドメイン/ でアクセスしても表示されます。

さいごに

設定は非常に楽しかったのですが、実際の料金がどれぐらいになるかはちょっと気になるところです。

Route53, CloudFront, S3

でそれぞれ費用が発生するので、アクセス数次第では結構いいお値段になるかもしれません(まあ、そうなったらうれしくもあるんですが)。

これについては、載せたい内容が固まって、本格的にリリースできてから改めて検証したいと思います。

参考

メールの部分以外はこちらを参考にしました。

qiita.com

独自ドメインで、メールとhttps化したWebサイトを別サーバーで運用する (1/2)

独自ドメインで運用するけれども、更新が頻繁にない静的サイトなら、S3でホスティングして費用を抑えられないかな?と考えています。

おまけに、AWSの場合、無料でSSLを利用することができるとのことです(Amazon Certificate Manager (ACM))。もっとも、AWSのサービスで使う用途に限られますけどね。 これをS3で使う場合は、CloudFront経由で設定することで、SSLを無料で利用することができます。

で、Webサイトはこれでいいとしても、独自ドメインのメールサーバーどうしようかというところが悩ましいところです。 個人的には、メールサーバーの運用なんてしたくないので、 メールはさくらインターネットのメールボックスを利用したらいいんじゃないのか?と思い立ちました。 値段も、月額約86円(年1029円)で、比較的お安く運用できそうですしね。

ちなみに、最初は、そんなにアクセス数がない静的サイトであれば、同じくさくらインターネットのレンタルサーバーのライトプラン(月額129円)でもいいかと考えました。 でも、SSLに対応しようとすると、自分でSSL証明書を用意して云々で費用的にもかさむし、RapidSSLがChromeで対応されなくなるという話も気になるので、AWSを使おうと思った次第です。

今回設定した作業をメモ書きとしてまとめておきます。

構成

さて、今回試した構成をまとめると、

  • ドメイン取得:さくらインターネット
  • ネームサーバー:Route53
  • メールサーバー:さくらのメールボックス
  • Webサイト:CloudFront+S3のホスティング
  • SSL証明書:ACM

という感じになりました。

設定の流れとしては、ACM での SSL証明書の発行には独自ドメインのメールアドレスが必要なので、

  1. ドメインを取得する
  2. メールサーバーで独自ドメインのメールの送受信ができるようにする
  3. S3でホスティングする
  4. CloudFront を設定する
  5. ACM で取得したSSL証明書を設定する
  6. https でアクセスできることを確認する

という流れです。Route53は適宜設定していきます。

ドメインの取得

独自ドメインは、どこでとってもいいかと思います。 今回は、たまたま既にさくらインターネットで取得したものがあったのでそれを使いました。

なお、試しで使った際に、ネームサーバー(さくらのネームサーバー)を設定していたので、一旦削除しておきます。

f:id:junichim:20170915090618p:plain

削除方法は、『会員メニュー』にログインして、ドメインメニューを開いて、対象とするドメインの『ゾーン編集』ボタンを押すと現在の設定内容が出てくるので、 左側のカラムにある『削除』ボタンから設定内容を削除しておきます。

さくらのメールボックスの契約

次に、さくらインターネットのメールボックスを契約します。 月額約86円(年額1029円)で運用できるのはありがたいですね。

とりあえず、取得したドメイン名(さくらインターネットのサブドメイン名、xxxx.sakura.ne.jp のやつです)でメールの送受信ができることを確認しておきます。

独自ドメインを Route53 で管理

S3でのホスティング時に、Zone Apex(サブドメインのないドメイン、 example.com のようなやつ。ネイキッドドメインなどとも呼ばれるようです)でのアクセスを行う場合、ドメインは Route53 で管理されている必要があります。

少し横道にそれますが、この理由について考えてみます。この理由の直接的な記述を見つけることができなかったのですが、『例: 独自ドメインを使用して静的ウェブサイトをセットアップする』にあるように、S3での公開名に対して独自ドメインでアクセスするためにCNAMEレコードが必要になり、Zone Apex に対してはCNAMEレコードを追加できないため、Route53独自のレコードであるAliasレコードを使う必要がある、ということだと思います。 いやはや、DNSまわりはややこしいですねー。

S3でのホスティングをサブドメインで行うなら、このステップはなくても大丈夫です。 (上記の理由の裏返しで、サブドメインにならCNAMEレコードを設定が可能なので、ドメインを取得した会社のネームサーバーでCNAMEレコードの編集ができるなら、Route53でなくてもOKです)

具体的な移行方法は次の記事を参考にしました。

Amazon Route 53 を既存ドメインの DNS サービスにする - Amazon Route 53

ホストゾーンの作成

AWSのコンソールにログインし、Route53を選んで、Create Hosted Zone を選択します。

f:id:junichim:20170915093948p:plain

管理するドメイン名を入力します。

f:id:junichim:20170915094120p:plain

コメント欄は空欄で大丈夫です。

問題なければ、このようにNSレコードとSOAレコードが登録された状態になります。

f:id:junichim:20170915094214p:plain

レコードセットの作成

次に、Route53にレコードを追加します。追加するのは、MXレコードとTXT(SPF)レコードです。

Create Record Set ボタンを押して、レコードセットを作成します。

まずはMXレコード

f:id:junichim:20170915094411p:plain

MXレコードが指すメールサーバーは、さくらのメールボックスのサーバー名です(xxxx.sakura.ne.jp のやつ)。

次に、TXT(SPFレコード)です。

f:id:junichim:20170915094457p:plain

SPFレコードの内容は

v=spf1 a:wwwxxxx.sakura.ne.jp ~all

としています。ここで、a: のうしろのホスト名としては、さくらインターネットのメールボックスのサーバー名を指定します。 コントロールパネルから『サーバー情報』を表示させると

f:id:junichim:20170915094841p:plain

のようにホスト名が表示されるので、これを使います。

参考

なお、ホストゾーンへのMXレコードとSPFレコードの追加は、以下のサイトを参考にしました。

他社で取得したドメインでさくらのメールボックスを利用する

独自ドメインのメールアドレスをさくらレンタルサーバーのメールボックスで取得しました。 - estomo Blog

メールボックスに独自ドメインを割り当て

契約したメールボックスのコントロールパネルにログインして作業を行います。

コントロールパネルの『ドメイン設定』を開き、『新しいドメインの追加』を選択します。 いくつか選択肢が表示されますので、 『5. 他社で取得したドメインを移管せずに使う』を選びます。

f:id:junichim:20170915095228p:plain

表示された画面で、ドメイン名を入力します。

f:id:junichim:20170915095333p:plain

問題なく、追加できていれば、下記の様な画面になります。

f:id:junichim:20170915114811p:plain

参考

なお、『詳細設定にすすむ』は行わなくても問題ありませんが、仮にリンクをクリックすると

f:id:junichim:20170915114937p:plain

のようにSPFレコードの設定確認がでてきます。 ここまで行うと、(さくらインターネット側で)追加したドメインのゾーン情報が作成され、 そのDNSレコードが

f:id:junichim:20170915100240p:plain

のように設定されます。 これらは、次のネームサーバーの切り替えにより、参照されなくなるのですがご参考までに。

あと、今回は試さなかったのですが独自ドメインの割り当ての際『2. さくらインターネットで取得したドメインを使う』を選んでも同じだったかなと思ってます。

f:id:junichim:20170915100839p:plain

次に類似の設定を行う機会があれば、試そうと思います。

ネームサーバーを Route53 に切り替え

今回の独自ドメインは、さくらインターネットで取得しているので、ネームサーバーをRoute53に切り替えます。

『会員メニュー』の『ドメインメニュー』から対象とする独自ドメインの『WHOIS情報』のボタンを押します。

f:id:junichim:20170915101238p:plain

画面の下のほうに、ネームサーバー1~4を記入しているところがあるので、

f:id:junichim:20170915101323p:plain

『変更』ボタンを押します。

編集状態になったら、Route53でホストゾーンを作成した際のNSレコードに記載されているサーバー名を4つとも入力します。

f:id:junichim:20170915101535p:plain

この値ですね。

参考

ここの作業では、下記を参考にさせていただきました。

Amazon Route 53と独自ドメインでさくらのレンタルサーバを利用する方法

Amazon Route 53 を既存ドメインの DNS サービスにする - Amazon Route 53

メールの送受信テスト

さて、しばらく待ってから、まずはSPFレコードが正しく設定されているか確認します。

SPF Query Tool

上記のサイトを利用して確認します。問題なければ、独自ドメインを使って、メールの送受信ができるかテストしておきます。

問題なければ、ここまでで一段落です。 次は、S3によるホスティングとhttpsでのアクセスのための設定になります。