LoginSignup
12
11

More than 5 years have passed since last update.

@HitomiHoshisaki(ひとみ ほしさき)

【AWSでサイト制作3】Cloud9×RailsでHello World！

Last updated at Posted at 2018-08-27

★ AWSでサイト制作シリーズ

  1. レンタルサーバーを選択
  2. IAMを設定
  3. Cloud9×RailsでHello World！ ←今ココ
  4. CodeStar×Railsで自動デプロイ
  5. 独自ドメイン設定
  6. 無料SSL化

※ 「Railsでサイト制作」シリーズから「AWSでサイト制作」シリーズに改名しました😌

■ 今回のゴール

前回は、こちらの参考記事を元にAWSにIAM設定をしてみました。
【参考記事】https://qiita.com/katatemadesuga/items/1db2aad5205450c659c7
引き続き同記事を元に作業を進めていきます。
AWS Cloud9を使って、RailsでHello World！をするところまでがゴールです。

■ nginxって何？

参考記事によると「まず、EC2にnginx+railsの環境を作成するため、CodeStarを使用します」とのこと。
うん、nginxってなんでしょ？

nginx（「エンジンエックス」のように発音[3]）は、フリーかつオープンソースなWebサーバである。処理性能・高い並行性・メモリ使用量の小ささに焦点を当てて開発されており、HTTP, HTTPS, SMTP, POP3, IMAPのリバースプロキシの機能や、ロードバランサ、HTTPキャッシュの機能も持つ。
https://ja.wikipedia.org/wiki/Nginx

Nginxは、Apache（アパッチ）の代替となり得るWebサーバーです。成り得るというより、成り得ちゃってるといってもいいと思います。アクティブWebサイトの上位1000の41%はNginxで動いているという調査結果もあるみたいですね。
...略...
たとえばNginxにはphpの処理機能がないので、動的コンテンツを処理できなかったりするんですね。Apacheにはもちろんphpの処理機能はついています。なので、Nginxの下に複数台のApacheをぶら下げておけば、Nginxが自分で処理できないものはApacheへなげて、処理できるものは自分で処理するというような使い方もできますね。
https://academy.gmocloud.com/qa/20160616/2761

なるほど、参考記事と同じく「nginx+rails」の環境を作っておけば間違いなさそうです。

■ キーペアの作成

以前キーペアは作成済みなので、それを使いましょ。
キーペアがない場合は、下記を参考に作成して下さい。
【参考】Amazon EC2 を使用してキーペアを作成する

■ CodeStar

▽ サービス > CodeStar
サービス > CodeStar

▽ CodeStarのトップページ > プロジェクトを開始する
※リージョンを東京にしたのは失敗でした。結局シンガポールで作り直しました。詳細は後述します。
CodeStarのトップページ

▽ おっとと。「ロールを作成します」にしました。
サービスロールの作成

◆ プロジェクトのテンプレートを選択

テンプレートがいっぱい並んでます。
ウェブアプリケーションとRubyで絞り込みをかけると2つになります。

▽ ウェブアプリケーションとRubyで絞り込み
image.png

Elastic Beanstalk(EB)かEC2か？という選択になります。
参考記事によると、

今回は、簡易的な動作確認ですので、EC2版を選択します。
おそらく、Sqlite3を使った1インスタンスの最小構成で作成されるはずです。
mysqlなどのRDBを使ったり、ロードバランサを置いたりしたい場合は、
AWS Elastic Beanstalk版を選択すると良いと思います。
https://qiita.com/katatemadesuga/items/1db2aad5205450c659c7

とのこと。
できるだけ参考記事と同じ設定で進めたい気持ちと、
SQLも触りたいからEBにしたい気持ちとで悩みます。。。
また寄り道して、EBとEC2の違いについて調べることにします。

AWS Elastic Beanstalk とは?
Elastic Beanstalk を使用すると、アプリケーションを実行しているインフラストラクチャについて心配することなく、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。 AWS Elastic Beanstalk は、選択肢を狭めたり制御を制限したりすることなく、管理の複雑さを軽減します。アプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、拡張、およびアプリケーションの状態のモニタリングといった詳細を処理します。Elastic Beanstalk は、AWS 無料利用枠で利用できる信頼性が高くスケーラブルなサービスを使用しています。
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/Welcome.html

Q: AWS Elastic Beanstalk はどのような人に適していますか?
アプリケーションを短時間で AWS クラウド内にデプロイして管理したいという方です。クラウドコンピューティングの経験がなくても利用を開始できます。AWS Elastic Beanstalk では Java、.NET、PHP、Node.js、Python、Ruby、Go、Docker のウェブアプリケーションがサポートされます。
https://aws.amazon.com/jp/elasticbeanstalk/faqs/

AWSの各種サービスを組み合わせたPaaSです。 環境作成時に、ロードバランサ、オートスケーリング、ローリングアップデートなどの機能が自動設定され、Elastic Beanstalkから一括管理できるようになります。
https://tech.misoca.jp/entry/2018/02/16/110000

ん？PaaSってどこかで聞きましたね。
当シリーズの1 で「代表的なPaaSはHeroku」ってメモしてました。
ざっくりいうと、HerokuとAWSのいいとこどりって思ってていいのかしら。

ElasticBeanstalkは、EC2などのAWSのサービスを「組み合わせて、1つのシステムとして運用する」ためのサービスです。RailsやPHPといったアプリケーションを、「あとはコードを反映するだけ」という状態になるまで自動でサーバを構築してくれます。なお、ElasticBeanstalk自体の料金は無料ですが、ElasticBeanstalkで構築されたEC2やRDSなどの料金は通常通り発生します（まとめ買いの分を割り当てることも可能です）。
https://teratail.com/questions/53786

ははぁ、EBとEC2は並列で比較するものではないんですね。
EC2その他のサービスを組み合わせた楽々パックがEBなのか。
自分で構成するEC2に比べて料金が倍かかるという話もあるけれど、
個人利用だしそんなに高額にはならないことでしょう。
(ほとんど使ってないヘテムルを解約したほうがたぶんお得)

よし、今回はEBを使うことに決めました。
(後になって、Hello WorldだけならEC2でも良かったじゃん… と思った)

▽ EB版テンプレートを選択
EB版テンプレートを選択

◆ プロジェクト詳細

▽ プロジェクト名・レポジトリ設定
プロジェクト名・レポジトリ設定

参考記事ではレポジトリに「AWS CodeCommit」を選択していましたが、
私は使い慣れてる(し今後も使うつもりの)GitHubを選択してみました。

▽ GitHubに接続
GitHubに接続

▽ 確認画面
確認画面

▽ GitHubに接続成功
リポジトリ名や説明も自動で入ってくれるのね😁
GitHubに接続成功

▽ プロジェクト詳細の確認
プロジェクト詳細の確認

▽ EC2のキーペアの選択
EC2のキーペアの選択

▽ ユーザー設定のセットアップ
ユーザー設定のセットアップ

◆ ツールのセットアップ

▽ ソースレポジトリへの接続
ソースレポジトリへの接続

◆ プロジェクトのセットアップ

あれれ。ツールのセットアップのところでIDEの選択画面が出ると思ったのに、終わってしまいました。
参考記事みたいにCloud9の選択にたどり着かない…

▽ ダッシュボード
プロジェクトのセットアップ

■ Cloud9

先にAWS Cloud9の利用開始とか設定とか必要だったのかしら？と思った。とりあえず行ってみよ。

▽ サービス > Cloud9
サービス > Cloud9

▽ リージョンを適当に選択(東京じゃCloud9は動かないらしい)
リージョンを適当に選択

…はっ！(ﾟдﾟ)
東京のリージョンじゃ動かないから、
さっきツールのセットアップのところでCloud9が出てこなかったんじゃないか！？
シンガポールリージョンでCodeStarを設定すればよかったのか？
CodeStarは東京リージョンのままで、Cloud9だけシンガポールリージョンとかできるのか？
また寄り道して、リージョンとかそれ関連のことを調べてみます。

製品およびサービス一覧（リージョン別）
https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/

us-east-1(ヴァージニア)か、us-west-2(オレゴン)を使うのがコスト優位のようです。
ap-northeast-1(東京)は約1.5倍かつ、円安(124.1円/$ ※)の影響でお財布には優しくないです。
※2015/07/20 現在
https://qiita.com/koshilife/items/d0b9d978e2f6ed03b785

使うリージョンによってコストも違ってくるんですね…！👀

海外サーバを使った時に、どれだけ遅延が出るのか、その遅延はサービス的に「使える」レベルなのか、ということが気になるところです。「使える」なら、少しでも安くなるリージョンのサーバを使いたいですよね。ということで、全リージョンでHTTPレスポンスを調べてみました。
http://www.denet.ad.jp/technology/2014/01/vol9-aws.html

なるほど、海外サーバーだと物理的な距離の問題で遅延も出るんですね…！👀

今回はアジアパシフィック (シンガポール)でAWS Cloud9を使ってみます。 新規ではなく、現在私が使用している東京リージョンでAWS Cloud9を利用します。 (リージョンは違いますが、問題なく動作しました。)
https://techblog.timers-inc.com/entry/2018/04/02/100310

シンガポールリージョンでCloud9を使う？けど、既存の東京リージョンでCloud9を利用する…？
Cloud9自体はシンガポールリージョンだけど、コードは東京リージョンに置いてるって意味かしら？
だとしたらありがたい。

CodeCommitは、シンガポールリージョンにも、東京リージョンにも用意されています。近い将来、Cloud9が東京リージョンに来たときのことを考えて、リポジトリは東京リージョンに作りました。
https://qiita.com/isamusuzuki/items/e985c908231eca150e7f

そうよね。近い将来、Cloud9が東京リージョンにくる！という可能性はあるのよね！😊

というわけで、
シンガポールリージョンでCloud9環境を作っても東京リージョンのコードと連携できる？っぽいので
ためしにシンガポールリージョンでCloud9環境を作ってみます。

▽ AWS Cloud9 TOPページ > Create environment
AWS Cloud9 TOPページ > Create environment

▽ Name environment
Name environment

▽ Configure settings(とりあえずデフォルトのままで行きました)
Configure settings

▽ Review
Review

▽ くるくる〜(1分くらいかな)
くるくる〜

▽ できまちた
できまちた

■ やりなおし

ここまできて、また　( ﾟдﾟ)ﾊｯ! と気づきました。
参考記事ではリポジトリに「AWS CodeCommit」を選んでたけど
私がGitHubを選んでしまったからIDEの選択肢にCloud9がなかったのでは？？？

…ビンゴでした。

今回、プロジェクト名、リポジトリ名を「test-cloud9」とし、管理リポジトリを「CodeCommit」としています。コード管理をGitHubにするとIDEを選択する画面がでてこないので注意ください。
https://dev.classmethod.jp/cloud/aws/aws-cloud9-codestar/

そして、CodeStarとCloud9でリージョンを超えて連携させることはできないみたいです。

早速CodeStarとCloud9の連携を試すぞ！と思ったのですが、よくよく考えればCloud9が東京リージョンに来ていませんでした。今回はシンガポールリージョンで検証した内容でお伝えします。。。
https://qiita.com/hayao_k/items/743be4d8f5e21844ed51

つまり、CodeStarとCloud9を使うためには、

  • Cloud9が提供されているリージョンでCodeStarを設定
  • リポジトリ管理は「AWS CodeCommit」を選択する

という必要があったわけですね。くぅぅ。これも勉強。
用意したCodeStarとCloud9とGitHubを全削除して、シンガポールリージョンで作りなおすことにします。
Cloud9を使う選択肢を諦めようかと思ったけど、とりあえずHello Worldまではやったろうじゃん。

◆ Cloud9の削除

▽ Delete
Delete

▽ Deleteって入力してDelete
Deleteって入力してDelete

▽ 消えまちた
image.png

◆ CodeStarプロジェクト削除

▽ プロジェクト
プロジェクト

▽ プロジェクトを削除する
プロジェクトを削除する

▽ 消えまちた
消えまちた

プロジェクトを削除してもEC2とかあちこちになんか残ってるんじゃないかな？
と思ったら案の定残ってました。

AWS CodeStar プロジェクトを削除しても、そのプロジェクト用に作成されたリソースがまだ存在します。デフォルトでは、プロジェクトを削除すると、AWS CodeStar によりプロジェクトリソースも削除されます。バケットにデータが含まれている可能性があるため、ユーザーが [Delete associated resources along with AWS CodeStar project] チェックボックスを選択しても、Amazon S3 バケットなどの一部のリソースは保持されます。
https://docs.aws.amazon.com/ja_jp/codestar/latest/userguide/troubleshooting.html#troubleshooting-pd1

上記トラブルシューティングのリンクを上から順に開いて、ポチポチDeleteしていきました(スクショ割愛)。

◆ GitHubリポジトリ削除

割愛。

■ CodeStarに再チャレンジ

▽ リージョンをシンガポールにして再挑戦
リージョンをシンガポールにして再挑戦

▽ キーペアがないって怒られました
キーペアがないって怒られました

▽ EC2管理コンソールでキーペアの作成
EC2管理コンソールでキーペアの作成

▽ 無事先に進めました
無事先に進めました

▽ ツールのセットアップに無事Cloudが登場しました！
ツールのセットアップに無事Cloudが登場しました

▽ Cloud9のインスタンスは無料枠対象のt2.microを選択しました
Cloud9のインスタンスは無料枠対象のt2.microを選択しました

▽ 数分待ち
数分待ち

▽ 成功！
image.png

▽ もうしばらく待つとデプロイも完了してアプリを表示できるようになります
アプリを表示

▽ Railsのサンプルアプリケーションかっこいい！
Railsのサンプルアプリケーション

■ Cloud9に再チャレンジ

▽ コーディングの開始
コーディングの開始

▽ 出た！Cloud9！
出た！Cloud9！

ここまでたどり着くのに苦労したぜ。。。
とりあえずサンプルが表示できるか見てみたい。

▽ Run > Run with > Ruby
Run > Run with > Ruby

▽ Preview > Preview Running Application > ブラウザで開く
Preview > Preview Running Application > ブラウザで開く

▽ うっぷす！
うっぷす！

Google翻訳するとこんな感じ
アプリケーションはここで実行されているようです！
AWS Cloud9では、要求された環境にアクセスできません。何が起こっているのか把握する方法に関するいくつかの提案があります：

● 環境にアクセスでき、AWS Cloud9に環境に合わせて署名されていることを確認してください。
● AWS Cloud9でサーバが正常に動作していることを確認します。
　　　　○ サーバーがエラーを起こした場合、出力ウィンドウにはそれが何であるかを示すメッセージが表示されます。
　　　　○ コードのデバッグの途中にいる場合は、サーバーが現在一時停止されている可能性があります。
　　　　○ サーバーが別のポートで実行されている可能性があります。それがポート8080上で実行されていることを確認してください。

CodeStarの方では何もしなくてもサンプルが表示されたから、
Cloud9もサンプル表示ができるところまでよしなにやってくれるかと思ったけど
やっぱり自分でもなにか設定しないとダメなのよね。。。

Railsチュートリアルを確認しながら、必要なことを調べていきます。

チュートリアルと見比べると、すでに

$ gem install rails -v バージョン
$ rails バージョン new アプリケーション名

ここまでは終わってる状態っぽいです。bundle installしてみます。

$ bundle install

足りてないgemがあったみたいで、続々追加されます。Railsを起動してみましょ。

$ rails server
Usage:
  rails new APP_PATH [options]

Options:
      [--skip-namespace], [--no-skip-namespace]            # Skip namespace (affects only isolated applications)
  -r, [--ruby=PATH]                                        # Path to the Ruby binary of your choice
                                                           # Default: 
...

参考記事の方と同じく、Usage(使い方)が出てしまいました😌
結局、参考記事さまと同じ呪文をやってみようか。
あるべきbinディレクトリがないのでrakeで作成します。

$ bundle exec rake app:update:bin
      create  bin
      create  bin/bundle
      create  bin/rails
      create  bin/rake
      create  bin/setup
      create  bin/update
      create  bin/yarn

Rails起動に再チャレンジ！

$ rails server
=> Booting Puma
=> Rails 5.2.0 application starting in development 
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.4.1-p111), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:8080
Use Ctrl-C to stop

なんかいい感じですね！

▽ 無事ブラウザでもサンプルが表示されました！Congratulations!
Congratulations!

■ Hello World

ではついに　Hello World　しましょ！！
やっとちょこっとだけ Rails 触りますよw

/rubysample/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception

  def hello
    render html: "Hello, World!"
  end
end
/rubysample/config/routes.rb
Rails.application.routes.draw do
  root 'application#hello'
end

■ 成功！

▽ Hello, World!
Hello, World!

でーきーーーたーーーーー！＼(^o^)／

★ AWSでサイト制作シリーズ

  1. レンタルサーバーを選択
  2. IAMを設定
  3. Cloud9×RailsでHello World！ ←今ココ
  4. CodeStar×Railsで自動デプロイ
  5. 独自ドメイン設定
  6. 無料SSL化
12
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
12
11