DNSとかネームサーバとかRoute53とかAレコードとかCNAMEとかがわからない人のためのまとめ

表題の通り。

いくら調べてもわかるようにまとめてる人がいなくてさすがにムカついたのでまとめた。

この記事の対象読者

  • ドメインの設定わかりづらすぎるよお死ぬう」
  • DNSサーバとかネームサーバってなんなのマジで・・・」
  • 「AレコードとかCNAMEとかよくわからないしよくわからない理由で設定が拒否された」
  • 「よくわかってないのに動いちゃったしヤバイ気がしてるしこわい」
  • 「Route53に移管っていう単語が死ぬほど出てくるけどそもそもなんなのこれ」

webサーバを公開してから、取得したドメインでそのサーバにアクセスできるようにするまでの流れ

さて、まずは全体の大まかな流れを見てみよう。

  1. webサーバでwebサイトを公開する
  2. webサーバのIPアドレスを確認する
  3. ドメインを取得する
  4. ドメインを取得したサービスで、使用するDNSサーバ(ネームサーバ)を設定する
  5. DNSサーバでドメインIPアドレスを紐づける設定をする
  6. 設定が反映されるのを待つ
  7. できた!

たったこれだけなんだけど、DNSサーバってなんなんだとか、紐付けってどうするんだ、ってなって仕組みがどんどんわけわからなくなるので整理する。

あと、ネームサーバって単語があちこちで出てくるわりにどこにあるかわかりづらくてAWSなんかが独自サービス出したりしたせいで余計わかりづらくなってる気がするのでそのあたりも含めて整理したい。

IPアドレスドメイン名について

とりあえずこれだけは理解してないと先の話がわからなくなるので整理。

IPアドレス

webを通じて何かを見るためには、その見たいものが置いてある場所をPCに対して指定する必要がある。

荷物を送るには住所がわからないといけない、みたいな話。

その住所のことをIPアドレスという。

IPアドレスの具体例

一番下の数字の羅列をURLバーに入れるとgoogleのページが表示されるはず(2015年9月14日現在)。

これは、この数字がgoogleのサイトの住所を表しているからなのだ。

ドメイン

でもgoogleだったらふつうgoogle.comでサイトにアクセスする。

このときに使うものがドメインと呼ばれている。

これは数字だと使う人がわかりづらいから文字でIPアドレスを伝えましょうということ。

なぜドメイン名を使うのか

国立競技場に行きたい人は「今から東京都新宿区霞ヶ丘町10番2号に行くんだー」と言わない、みたいな話。どう考えても「今から国立競技場行くんだー」の方が伝わるしわかりやすい。

それと同じで、173.194.117.128よりgoogle.comの方がわかりやすいので、ドメイン名というものを使う。

DNSって何?

DNSドメインネームシステムというもので、住所と場所の名前をつなぐ対照表みたいな感じ。

  • 国立競技場の住所 = 東京都新宿区霞ヶ丘町10番2号
  • google.com = 173.194.117.128

みたいな感じで、それぞれをちゃんと一致させてくれるもの。

こんな表があれば、国立競技場に行きたい、と言ったときに具体的な住所がわかるので、たどり着くことができる。

現実世界では地図などがそれにあたるわけだけど、webにおいては、DNSというものを使って台帳管理をしているわけだ。

DNSサーバまたはドメインネームサーバについて

さて、こうやって住所と名前をつなぐ台帳があるわけだが、どこに台帳を見に行くか、という問題がある(世界中の情報を手元に置いておくわけにもいかないので)。

インターネットがない頃は、地図屋に地図を買いに行ったり、役所に戸籍謄本をあげに行ったりしてたけど、それに近い。

で、これらの台帳はDNSサーバというところで管理されている。ドメインネームサーバとかネームサーバとか呼ばれたりもする。

DNSサーバ自体も、それぞれの住所を持っている。まさに役所みたいな感じ。

ドメインを取ったときのネームサーバ設定云々というのは、この「住所を確かめるための役所を指定する」というのに近い。

例えばお名前ドットコムでドメインを取った場合のネームサーバ

例えばお名前ドットコムでドメインを取った場合、管理画面のネームサーバの変更、というところからネームサーバを指定できる。

ネームサーバは、お名前ドットコムなどのドメイン取得サービスがそのまま用意していたりするし、AWSを使う人にはAmazon

Amazon Route 53(ドメインネームサーバー – DNS サービス) | アマゾン ウェブ サービス(AWS 日本語)

というサービスを用意している。

今回はおれが使うのでRoute53について少し見ていきます。

Route53の使い方

とりあえず最低限動くまでのやるべき手順だけ書くと以下の通りになる。

  1. まずはつなぎたいサーバのIPアドレスを確認する
  2. マネジメントコンソールでRoute53に移動
  3. Create Hosted Zoneを選択
  4. 右に出てくるところに、使いたいドメイン名を入れる(www.とかは入れない。xxxxx.jpとかxxxxx.com、という部分だけ)
  5. 作ったら出てくるNSレコードを全て記録しておく
  6. Create Record Setを選択
  7. 右に出てくるところのNameにwwwを、TypeはA - IPv4 Addressを、ValueにつなぎたいサーバのIPアドレスを入れてCreate
  8. ドメインを取得したサイトに行って、ネームサーバを設定するページに行く
  9. アドレスを入れろと言われるので、先ほど記録したNSレコードを貼り付けて保存(※ 最後のピリオドを取らないとエラーになる)
  10. 設定が反映されるまで待つ

何をやったのか

Route53はDNSサーバを作れるサービスなので、まずは使いたい名前でDNSサーバを立てる。

そうするとそのURLが発行されるので、これをDNSサーバとして使うよ、とドメイン取得サービスの方に伝える。

立てたDNSサーバに、自分に対するアクセスをどこに振り分けるかを指定してやる(IPアドレスを教える)

こうすることで、ドメインから自分が立てたRoute53のDNSサーバにアクセスが行き、Route53のDNSサーバから指定したIPアドレスにアクセスが行く、という流れになるので、指定したドメイン名で指定したサーバが表示されるようになる、という感じ。

Route53に移管とはなんだったのか

アクセスがあったときにどのIPアドレスを見に行くかを決める場所を、ドメイン取得サービスが提供しているものからRoute53に切り替えましょう、という話だったので実はもうあまり解説することがない。上述の手順が移管にあたります。

AとかCNAMEとかって何

ちゃんと調べきれてないけど、ざっくりこんな感じみたい。

Aレコードは、ドメインにアクセスしてきた人がどのIPアドレスを見るか、というのを指定するもの。 Aレコードは一つしか指定できないが、IPアドレス複数指定できるらしい。

CNAMEは、Canonical Nameのことで、「この名前できたら実際にはここを見てね」というもの。 CNAMEで設定したURLにアクセスすると、指定したURLに飛ばしたりする。

こっちの方がわかりやすいかも。

qiita.com

ApacheとNginxとPassengerとUnicornの違い【すごい初心者向け】

Amazon EC2の上でRailsアプリケーションを動かそうとして、サーバーを構築しようとしているのだけれど、Apache, Nginx, Passenger, Unicornなど色々な名前が出てくるものの、それぞれの役割がどう分担されているのかが分かりづらいのでメモすることにした。

自分も初心者に毛が生えた程度なので正確性はあんまり保証できないけど分かりやすさ重視でがんばってまとめたよ。

単純にサーバーを立ち上げて動きさえすればよいのであれば、

qiita.com

qiita.com

あたりを参考にすると良さそう。

この記事の対象読者

  • Webサーバってなにそれ?おいしいの?
  • さくらVPSとかEC2とかで泣きながらApacheの設定したことあるけど全く理解してない
  • ぐぐればぐぐるほど意味がわからなくなったのであきらめてる
  • Ruby on Railsをやろうとしているかherokuとかではすでにアプリを公開している

という感じのレベルの人。

すごく当たり前っぽいことも解説したりするし、正確性よりも比喩での分かりやすさを優先したりしているので、わかってる人には冗長かつ曖昧に感じる記述も多いかも。

とはいえ自分も勉強しながら書いているので、明らかに不適切なたとえだったりしたらご教示いただけると嬉しいです。

ことば

サーバ (Server)

プログラムとかファイルを保存しておいたり実行したりできるもの。

お手持ちのMacWindowsそれ自体もサーバとして動かすことができたりする。さくらVPSやEC2は、仮想空間で作ったサーバを外部に向けて貸し出している。

Webサーバ (Web Server)

HTTPリクエストを受け取ったときに、なんらかの反応を返すプログラム。

例えば、localhost/index.htmlにアクセスされると、サーバー内のindex.htmlファイルの中身を返す、という感じ。 VPSやEC2などのサーバにWEBサーバを立てると、そのサーバで外部に向けてWebサイトを公開したりできる。

Rack

Rubyアプリケーションで、URLを生成するときに使われるしくみ。

PHPなどと違って直接ファイルを参照しない場合に、URLに合わせてどの順番でどのファイルを参照するか、などを管理してくれる。RailsではURLに沿って直接ファイルを参照したりしないので、routes.rbで指定された通りにファイルを経由してviewを表示するという経過をたどるわけですが、その裏ではRackの恩恵に与っているわけです。

もうちょっと詳しく知りたい人はこちらがよさそう。

5分でわかるRack - Route 477

Rack Webサーバ(Rack Web Server)

RubyアプリケーションとWebサーバをつなぐための中間サーバ、として扱われることが多い。

通常のWebサーバはRackのような機能をサポートしていないが、Rack Webサーバを挟むことで、RubyアプリケーションなどをWebサーバ上で動作させることができる。

Rack Webサーバ単体でも機能するにはするみたいだけど、Apacheなどの既存のWebサーバはレスポンスの処理がうまいので、それらと組み合わせて使うことが多いらしい。

モジュール (※Webサーバにおけるモジュール)

デフォルトのWebサーバの機能にはないものを、外部から取り込んで使えるようにするもの。

ApacheとNginxとPassengerとUnicornの違い

ApacheとNginxはWebサーバ

Apache

すごく有名で広く使われているオープンソースのWebサーバ。

ドキュメントがwebにいっぱい落ちている。デフォルトの設定だとRailsアプリは使えない。

Nginx

エンジンエックスと読むらしい。すごい優秀なWebサーバ。

以下のsion_cojp氏によるベンチマークを見る限り、Apacheよりかなり速そう。

qiita.com

Apacheと同じくデフォルトだとRailsアプリは使えない。

ApacheとNginxの共通点
ApacheとNginxの違い
  • Apacheは古くから使われていてドキュメントが多い
  • Nginxは比較的速くて高負荷に強い

PassengerはApacheやNginxで使えるモジュール

Passenger

Phusion Passenger(非公式にはmod_railsとmod_rackともいう)はApache HTTP Server及びnginx用のフリー・モジュールである。

引用元: wikipedia

すごくざっくりいうと、ApacheやNginxをちょっと改造してRackアプリ(Railsアプリ)にも対応できるようにしてしまうモジュール。

Apacheとは比較的組み合わせやすい。

Nginxと組み合わせる場合は、ソースコードを改造してコンパイルしなければいけないとのことで、ちょっとめんどくさそう。

UnicornはRack Webサーバ

UnicornはそもそもRackアプリに対応するために作られたRack Webサーバで、単体でも動作する模様。なんだけど、公式が

Designed for Rack, Unix, fast clients, and ease-of-debugging. We cut out everything that is better supported by the operating system, {nginx}http://nginx.org/ or {Rack}http://rack.github.io/.

(超絶意訳:RackとUnixと高速なクライアント向けに簡単にデバッグできるように作ったよ。nginxとかRackとかOSと相性が良くなるように調整したよ。)

defunkt/unicorn · GitHub

と言っているのもあり、nginxと組み合わせて使うことがほとんどのようだ。

Unicorn Workerというものを使ってリクエストに対応しているらしく、サーバのダウンタイムなしでデプロイできるのが強みらしい。

ThinやPumaなども含めてRackアプリの総合的な比較などをしている記事があったので、もっと詳しく知りたい方はどうぞ

www.engineyard.co.jp

ということでNginx + Unicornを使うことにした

なんか速そうなのと、ダウンタイムなしでのデプロイというのが魅力的なので、自分はNginx + Unicornを使うことにします。

標準的なAmazon EC2環境でのNginx + Unicorn環境構築も、既存記事などに過不足を感じれば作るかもしれません。

ということで、Railsアプリ関連のサーバ構築に関する悩みが少しでも解消されれば幸いです。