今、MacOS内で仮想サーバー（VirtualBox）を立て、仮想サーバーを使って開発したアプリケーションをAWSのEC2にデプロイするために、AWSの環境構築をしています。しかし、環境構築に際してクライアント/サーバーの理解が根本的に間違っていたので、復習の意味も込めて再度、整理したいと思います。
まずはこちらの記事を読んだ上で、読み進めていくと理解しやすくなると思います。
以前に書いた記事で紹介した図がこちら。
MacOSのローカル環境でRailsアプリを開発して、ブラウザ表示させるという普段当たり前にやっているこの操作。
|
1 2 3 4 5 6 7 8 9 |
MacBook-Pro-7:todo Chopesu$ rails s => Booting Puma => Rails 5.2.2 application starting in development => Run `rails server -h` for more startup options Puma starting in single mode... * Version 3.12.0 (ruby 2.3.1-p112), codename: Llamas in Pajamas * Min threads: 5, max threads: 5 * Environment: development * Listening on tcp://0.0.0.0:3000 |
「rails s」でRailsサーバー（puma）を起動し、development環境で、localホストサーバーの3000番ポートにリクエストを送り、レスポンスを得ているわけだが、私はここでのクライアントとサーバーの関係を勘違いしていた。つまり、上の図の通り、クライアントが自分のパソコンで、サーバーは別のどこかにあるものだと思っていたが違った。
development環境の場合は、クライアントとサーバーは別々ではなく、同一PC内にある。
なので、より正確に言うと、1つ目の図は、development環境ではなく、production環境でのクライアント/サーバーの関係図。2つ目の図は、development環境下でのクライアント/サーバーの関係図という位置付けになる。いつも参考書等に出ているクライアント/サーバーの図が1つ目だったので、development環境も同じだと思いこんでいた。
では、本題のAWSでは、どのような関係図になるのか？
ここで、EC2サーバー内に3つのサーバーを設定しているが、DBも使わずにシンプルに「Hello World」と表示させたいだけであれば、3つもいらない。アプリケーションサーバーだけで十分。VirtualBoxは本番環境と近い環境下で開発をすることができるというのがメリットの一つ。VirtualBoxでできることは、AWS（EC2）でも同じことができるということ。つまり、2つ目の図のVirtualBoxで開発したHello Worldが、rails sでちゃんと起動して、レスポンスをブラウザに返してくれるということは、EC2でもrails sでちゃんと起動して、レスポンスをブラウザに返してくれるということ。何が言いたいかというと、Hello Worldの例だけでいうと、AWS（EC2）にはWebサーバーやDBサーバーの設置、UnicornのインストールをしなくてもブラウザにHello Worldを返してくれるということ。
