【AWS】EC2を利用してRailsアプリをAWSにデプロイしたい!準備編

f:id:kisokoji:20180401152046p:plain
AWS

AWSにまず慣れる

AWSのCloud9でこの2ヶ月Railsをやっていたのだけど、まだまだ他のことはわからず。

とりあえず、Herokuじゃなくてデプロイするにはどうしたらいいのか。試行錯誤の日々をまとめた。詳しい説明は参考にしたサイトを参照していただきたい。

慣れるためにまず順序を覚えるために必要な最低限。

参考:(デプロイ編①)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで - Qiita



最初の準備

数ヶ月で画面構成が変わる気がするのは気のせいか?

参考にしたサイトの公開日が2016年8月。1年半前。若干変わっていた。

AWSコンソール

AWS マネジメントコンソール | AWS

コンソールへログインをクリック。

アカウントの作成をしてない場合はここで新規でユーザーアカウントを作成する。

まぁそこは割愛。

AWSサービスの検索画面が表示されるので「VPC」を検索し、クリック。

VPCダッシュボード画面へ遷移する。

リージョン

ヘッダーのアカウントの右側でリージョンの選択が出来る。ここで注意したいのが、Cloud9ではまだ「アジアパシフィック(東京)」が選択できない。

でも、VPCでは選択できる。

ずっとCloud9でやっているとそのままやろうとしてしまうので、必ず変更する。

f:id:kisokoji:20180401134954p:plain:h500



VPCの作成

VPCダッシュボードメニュー:VPCの画面から作成する。

f:id:kisokoji:20180401135833p:plain:w500

名前タグ:VPC_for_TEST
IPv4 CIDR ブロック:10.0.0.0/16
IPv6 CIDR ブロック:IPv6 CIDRブロックなし
テナンシー:デフォルト



サブネットの作成

  VPCダッシュボードメニュー:サブネットの画面から作成する。

f:id:kisokoji:20180401140614p:plain:w500

名前タグ:TEST_Subnet
VPC:VPC_for_TEST

アベイラビリティーゾーン:ap-northeast-1a
IPv4 CIDR ブロック:10.0.0.0/24



インターネットゲートウェイの作成

  VPCダッシュボードメニュー:インターネットゲートウェイの画面から作成する。
 

f:id:kisokoji:20180401141000p:plain:w500

f:id:kisokoji:20180401141108p:plain:w500


Nameタグ:Geteway_for_TEST


f:id:kisokoji:20180401141212p:plain:w400

状態はまだ「dettached」

作成したGatewayを選択し、アクションVPCにアタッチ

f:id:kisokoji:20180401141450p:plain:w400f:id:kisokoji:20180401141527p:plain:w400


VPCを選択し、アタッチ

f:id:kisokoji:20180401141634p:plain:w500

状態が「attached」に変更される。



ルートテーブルの作成

VPCダッシュボードメニュー:ルートテーブルの画面から作成する。

  f:id:kisokoji:20180401142525p:plain:w500

名前タグ:Table_for_TEST
VPC:VPC_for_TEST


作成したルートテーブルにルールを追加する。

f:id:kisokoji:20180401142854p:plain:w400

  • 作成したルートテーブルを選択
  • ルートタブを選択
  • 編集をクリックする


f:id:kisokoji:20180401143111p:plain:w400

f:id:kisokoji:20180401143537p:plain:w400

送信先:0.0.0.0/0
ターゲット:作成したゲートウェイを選択(プルダウンが表示される)

保存をすると保存完了が表示される。

サブネットとルートテーブルの紐づけ

VPCダッシュボードメニュー:サブネットの画面で行う。

f:id:kisokoji:20180401144143p:plain:w500

保存をすると保存完了が表示される。

セキュリティーグループの作成

VPCダッシュボードメニュー:セキュリティーグループの画面から作成する。

f:id:kisokoji:20180401144529p:plain:w500


名前タグ:TEST-SecurityGroup
グループ名:TEST-SecurityGroup
説明:TEST-SecurityGroup
VPC:VPC_for_TEST


説明はそのままでいいのか?って感じだけど。

作成したら、「ルール」を付与する。

f:id:kisokoji:20180401145007p:plain:w400


  • 作成したセキュリティーグループを選択
  • インバウンドのルールを選択
  • 編集をクリック


f:id:kisokoji:20180401145631p:plain:w400

別のルールを作成をクリックし、新しく行を表示し、追加する。


タイプ:SSH(22)
プロトコル:TCP(6) デフォルト
ソース:自分のPCのグローバルIPアドレス/32
 

タイプ:HTTP(80)
プロトコル:TCP(6) デフォルト
ソース:0.0.0.0/0


ここまでが準備ということ。

しかも今、ふつーにSSHを設定したのだけど、私はこの段階では何も疑問を持たなかった。

が、この段階で意識しておいた方がいいのではないか?

自分のパソコンに22番ポートは開放されているのか?

疑問に思ったこともなかった。

が、しかし。意識しないといけないものだったようだ。



Mac22番ポート

いざ接続って段階で

「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」って・・・まぁその前段階でも言われる。

って言われましても・・・って感じでした。

そもそも私のMacはリモートログインを許可しているのか?ってことでした。

f:id:kisokoji:20180401150555p:plain:w200


アップルマーク - システム環境設定


f:id:kisokoji:20180401150715p:plain:w300


共有をクリック


f:id:kisokoji:20180401150922p:plain:w400


何も共有の許可出してませんでした。

これでは絶対にアクセスできない。

こういうことってどうやって知るの?

ってことで、

  • リモートログインにチェック
  • 次のユーザーのみに今の自分を追加


すべてのユーザにしてもいいのだろうけど、念の為ね。

これで後々困らない。