More than 3 years have passed since last update.

Ruby on Railsの環境構築をElastic Beanstalkで行う

Last updated at 2021-09-15Posted at 2017-01-09

この記事について

最近は、主にTipsのところを更新しており、Elastic Beanstalkに関する私的メモのような感じになっております。
2019-04-03 assets:precompileについてを追加
2021-01-21 PlantoformにAmazonLinux2をを利用する場合、eb-activitiy.logがeb-engine.logになる旨を追記
2021-03-23 PlantoformにAmazonLinux2をを利用する場合の環境変数読み込みについて追記

Elastic Beanstalkとは

アプリケーションのインフラ周りをよしなにやってくれるAWSが提供するPaaS
もう少し説明すると、Webアプリを公開する場合、Webサーバ、アプリケーションサーバ、DBサーバを立てて、それぞれを連携させる必要があります。場合によってはロードバランサ(ELB)でリクエストを分散させる仕組みを構築したり、サーバーを監視(CloudWatch)したりするインフラを整備する必要があります。Auto Scalingも考えなければいけません。Elastic Beanstalkは、そうしたインフラ周りの構築をよしなにやってくれます。詳しくはAWS Elastic Beanstalk とは?をご覧ください。
Ruby on Railsだと、たとえばWebサーバにnginx、アプリケーションサーバにunicorn、データベースサーバにはAWSのRDSを使うといったことが多いかと思いますが、Elastic Beanstalkでは、Webサーバーにnginx、アプリケーションサーバーにはPumaまたはPassengerが用意されています。データベースサーバは現状ではRDSは手で作ってあげる必要がある模様です。詳しくはサポートされているプラットフォーム Rubyをご覧ください。
Elastic Benastalkにはcliツールが用意されており、ebコマンドを使用することで、簡単に初期設定やdeployなどを行うことができます。
Elastic Beanstalkを使うための料金は基本的に無料です。ただし、構築されたEC2インスタンスやRDS等には(無料枠外であれば)課金されます。
(余談)Elasticとは「柔軟な」、Beanstalkとは「豆の木」という意味です。そう「ジャックと豆の木」の「豆の木」です。(詳細)

今回作成する構成

Webサーバにnginx、アプリケーションサーバにPuma、RDSはPostgresql 9.5で構成しようと思います。
この記事は、Elastic Beanstalkで環境構築した際につまづいたことなどを逐次追記しています。
ELB（Elastic Load Balancing）に関しては、1回目に構築した時は、Classic Load Balancerを用いています。2回目に構築した時はApplication Load Balancerを用いており、記述が併記されている箇所があります。

手順

GUIでも出来るかと思いますが、ebコマンドを使ってcliで行います。
作業しているマシンはmacOS Sierraです。

IAMユーザーの作成

AWSのアカウントは作っているという前提で進めます。Elastic Beanstalkを使うには、IAMユーザーを作成する必要があります。
AWSマネジメントコンソールから、IAMをクリックし、ユーザーを追加から追加してください。
アクセスの種類は、今回はcliで作業するので、プログラムによるアクセスにチェック。マネジメントコンソールからも作業したくなるでしょうからAWS マネジメントコンソールへのアクセスにもチェックしておけば良いかと思います。お好みで。
アクセス権限は既存のポリシーを直接アタッチでも良いですし、今後Elastic Beanstalkでデプロイするユーザーが増えることを想定するのであれば、グループを作成してそこにユーザーを追加する形でも良いかと思います。私はグループを作成しました。
- グループ名はeb-deployなどわかりやすい名前をつけます。お好みで。
- ポリシーフィルターはAWSElasticBeanstalkFullAccessを入れておけば良いかと思います。
確認、ユーザーの作成を行うとAccess Key IDやSecret Access Key、マネジメントコンソールにアクセス許可した場合はパスワードも表示されるかと思います。Access Key IDやSecret Access Keyはとても大事なので慎重に保管しておいてください。

コマンドラインでAccess Key IDやSecret Access Keyの設定

作成したIAMユーザーで操作するためにAccess Key IDとSecret Access Keyの設定を行います。
(注意) awscliをインストールしていない方はインストールしておいてください。（詳細）
aws configureと打つと、対話形式で聞いてくるのでIAMユーザー作成の際に表示されたAccess Key IDとSecret Access Keyを入力します。Default region nameはap-northeast-1、Default output formatはjsonあたりを指定しておけば良いかと思います。

$ aws configure
AWS Access Key ID [None]: *********
AWS Secret Access Key [None]: **********************
Default region name [None]: ap-northeast-1
Default output format [None]: json

設定した値は

$ cat ~/.aws/config
$ cat ~/.aws/credentials

で確認できます。
なお、profile名を指定したい場合は、aws configure --profile your-profile-nameとします。

Elastic Beanstalkのセットアップ

まず、ebコマンドをインストールします。homebrewでインストールします。（詳細）

$ brew install awsebcli
$ eb --version
EB CLI 3.9.0 (Python 2.7.1)

eb initコマンドで初期化します。
- 対象となるリポジトリで作業して下さい。
- こちらも対話形式で聞いてきますので、以下に私の場合の例を載せます。#以下はコメントになります。

$ eb init
Select a default region
1) us-east-1 : US East (N. Virginia)
・・・(中略)
9) ap-northeast-1 : Asia Pacific (Tokyo)
・・・(中略)
15) eu-west-2 : EU (London)
(default is 3): 9

Enter Application Name
(default is "sample-app"): sample-app　# デフォルトはリポジトリ名になると思われる

It appears you are using Ruby. Is this correct?
(y/n): y

Select a platform version.
1) Ruby 2.3 (Puma)
・・・(中略)
8) Ruby 2.0 (Passenger Standalone)
9) Ruby 1.9.3
(default is 1): 1 # バージョンは各アプリで違うと思うのでお好みで。
Do you want to set up SSH for your instances?
(y/n): y

Select a keypair.
1) sample-app
2) [ Create new KeyPair ]
(default is 2): 1 # すでにあるkeypairを使う場合はそれを選択。keypairがない場合や新たなkeypairを使用する場合は、[ Create new KeyPair ]の番号を選ぶ。

設定はcat .elasticbeanstalk/config.ymlで確認できます。

$ cat .elasticbeanstalk/config.yml

このあたりで、.gitignoreにElastic Beanstalk用のファイルは無視する設定が追加されるかと思います。リポジトリの.gitignoreで管理したい場合は、commitしておきましょう。

git add .gitignore
git commit -m "add elastic beanstalk files to .gitignore"

これで初期化が終わりました。

アプリケーションの環境の作成

これまでの作業でマネジメントコンソールからElastic Benastalkの管理画面に行くと、以下のような形になっているかと思います。
- 今すぐ作成しましょう。と書いてあるので作成しましょう。
eb createで作成します。こちらも対話形式で設定が可能です。
まず触ってみるだけならば、defaultのままで大丈夫かと思います。タイプしなくてもEnterで可能です。

$ eb create
Enter Environment Name
(default is sample-app-dev): sample-app-dev
Enter DNS CNAME prefix
(default is sample-app): sample-app # eb openコマンドで見れるときのURL。http://sample-app.ap-northeast-1.elasticbeanstalk.com/などとなる。

Select a load balancer type
1) classic
2) application
(default is 1): 1

しばらく時間がかかるので、みかんでも食べて(冬場の場合)しばしお待ちください。コマンドラインにあるように(safe to Ctrl+C)なのでCtrl+Cしても大丈夫です。経過はマネジメントコンソールから確認できます。

RDSの作成

しばらく待っていると、おそらく失敗すると思います。こういう場合は基本中の基本、ログを見ます。
eb logsコマンドでログが見れます。eb logsコマンドを実行すると/var/log/nginx/error.logなど、複数のログが表示されます。今回のログはElastic Beanstalkに関するログなので、/var/log/eb-activity.logのとこ
ろを見ます。（AmazonLinux2では、/var/log/eb-engine.logになります）

$ eb logs
# lessで表示される。
-------------------------------------
/var/log/eb-activity.log
-------------------------------------
  ++ /opt/elasticbeanstalk/bin/get-config container -k app_user
  + EB_APP_USER=webapp
  ・・・(中略)
  + su -s /bin/bash -c 'leader_only bundle exec rake db:migrate' webapp
  rake aborted!
  PG::ConnectionBad: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

db:migrateができないよと言っているわけです。この辺りは、Railsのconfig/database.ymlにどのように書かれているかにもよるのですが、defaultでlocalhostが指定されていてそれをproductionにも<<: *defaultのまま指定してあったりすると当然Elastic Beanstalkで作成されたEC2上にはデータベースサーバはありませんので、接続できないというわけです。
これまで見てきた方法では、環境変数に本番環境のデータベースの情報を入れておいて、config/database.ymlでhost: <%= ENV['DB_HOSTNAME'] %>のようにしてある形も多かったです。そのような場合ですでにデータベースが作成されている場合は、Elastic Benastalkで作成したEC2からそのデータベースサーバに接続できるようにセキュリティーグループを設定してあげる必要があります。
今回の場合は新たにRDSを作成し、そこに接続するようにします。
Elastic BeanstalkではRDSは作成してくれませんので、自分で作成します。
Elastic Beanstalkの該当のアプリケーションのダッシュボードへ行き、左側にある設定をクリック。下の方にあるデータ層というところから、新しい RDS データベースを作成します。
- （画像は一部省略してあります)
作成するDBはお好みでいいのですが、無料枠だけでおさめたい場合はインスタンスクラスはdb.t2.microにしておく必要があるのでご注意ください。
- (画像は私の場合)
RDSを作成すると、エンドポイントなどが表示されると思います。また、マネジメントコンソールのRDSからも作成されているのが確認できるかと思います。そこでもエンドポイントやポートなどを確認できるかと思います。
RDSへの接続は、AWSのDocumentにもあるように、config/database.ymlに設定しておかなければいけません。

default: &default
  adapter: postgresql
  encoding: unicode
・・・(中略)
production:
  <<: *default
  database: <%= ENV['RDS_DB_NAME'] %>
  username: <%= ENV['RDS_USERNAME'] %>
  password: <%= ENV['RDS_PASSWORD'] %>
  host: <%= ENV['RDS_HOSTNAME'] %>
  port: <%= ENV['RDS_PORT'] %>

そして環境変数は、eb setenvコマンドで行います。

eb setenv RDS_DB_NAME=ebdb RDS_USERNAME=*********** RDS_PASSWORD=*********** RDS_HOSTNAME=***********.rds.amazonaws.com RDS_PORT=****

設定されている環境変数は、eb printenvコマンドで確認できます。

$ eb printenv
 Environment Variables:
     RDS_PORT = ****
     SECRET_KEY_BASE = ***************
     RAILS_SKIP_ASSET_COMPILATION = false
     RDS_DB_NAME = ebdb
     RACK_ENV = production
     RDS_PASSWD = *************
     RDS_USERNAME = *******
     BUNDLE_WITHOUT = test:development
     RAILS_SKIP_MIGRATIONS = false
     RDS_HOSTNAME = ************rds.amazonaws.com

デプロイ

この状態でもう一度デプロイして見ます。今回は２回目なのでeb deployコマンドを使います。

eb deploy

しばらく待ちます。
これで、正しくdeployが行われれば、eb openでサイトが見れるはずです。

eb open

うまくできない場合は、eb logsでエラーを確認してGoogle先生等に聞いてエラーを解消してあげてください。
以上で、初期セットアップは終わりです。以下は開発上のTips的な記述ですので、必要に応じて参考にしていただければと思います。

Tips

Application Versionが規定数を超えていてデプロイできない場合

ERROR: You cannot have more than 500 Application Versions. Either remove some Application Versions or request a limit increase.

AWSコンソールから作業することもできますが、CLIで行う場合、eb appversionコマンドの--deleteオプションで削除できますが、version-label（VersionLabel）を知らなければいけません。

aws elasticbeanstalk describe-application-versions --application-name your-application-name

上記コマンドを実行すると以下のようなJSONが得られます。（値は適当なものを入れています）

    [
        {
            "ApplicationName": "your-application-name",
            "Status": "UNPROCESSED",
            "VersionLabel": "app-000f-191111_112017",
            "Description": "hogefuga",
            "DateCreated": "2017-03-27T07:20:16.892Z",
            "DateUpdated": "2017-03-27T07:20:16.892Z",
            "SourceBundle": {
                "S3Bucket": "elasticbeanstalk-ap-northeast-1-100000000001",
                "S3Key": "your-application-name/app-000f-191111_112017.zip"
            }
        }
    ]

上記JSONのVersionLabelを指定して削除します。古いのが一番下に出てくるので、古いのから削除していけばいいでしょう。

eb appversion --delete app-000f-191111_112017

注意

以下より、.ebextensionsディレクトリの利用が書かれておりますが、ElasticBeanstalkのPlatformにAL2を利用する場合、.ebextensionsは利用できません。.platform/hooksや.platform/confighooksを利用してください。詳細はこちらをご覧ください。
また、.platform/hooks配下のスクリプトは、eb deployコマンドでは実行されますが、環境変数の更新だけなどでは実行されません。その場合は、.platform/confighooksを利用してください。シンボリックリンクを貼っておくと良いでしょう。

cd .platform/confighooks/prebuild
ln -s ../../hooks/prebuild/01_hoge.sh 01_hoge.sh

yarnを利用する場合

yarnをinstallするためのコマンドを.ebextensionsディレクトリ配下に置きます。
webpackerのissueにconfigファイルを掲示してくれている方がいるので参考にしてください。
私の場合、deploy時に、yarnコマンドでトランスパイルを実行させています。
トランスパイル実行後にassets:precompileを走らせているので、RAILS_SKIP_ASSET_COMPILATIONの環境変数はtrueにしてassets:precompileを実行させないようにし、.ebextensions内で実行しています。

.ebextensions/10_yarn.config

# see https://gist.github.com/yuyasat/dcc2f2214f5087833aca2069e69f92fb

.ebextensions/11_container_commands.config

container_commands:
  11-npm_install_build:
    command: cd frontend && sudo yarn install && sudo yarn release
  23-assets_precompile:
    command: bundle exec rake assets:precompile

https接続する場合

流れとしては、
- ドメインの取得
- 証明書の発行（AWS Cetrificate Manager（ACM）、Let's encryptなどを利用する）
- 証明書のLoadBalancerやEC2への紐付け
Clasic Load Balancerの場合
- .ebextensions/loadbalancer-terminatehttps.configが参考になります。
Application Load Balancer の設定の場合
- .ebextensions/alb-secure-listener.configが参考になります。こちらの記事も大変参考になりました。
ネットワークロードバランサーの設定の場合
- .ebextensions/nlb-secure-listener.configが参考になります。ただし、NLBの場合、SSLの終端がEC2になります。2018/4/6現在、ACMはEC2に適応できないため、ほかの方法を利用する必要があります。
ACMでサブドメインのあり・なし共に利用できるワイルドカード証明書を作成する場合は、「ドメイン名の追加」において、*.hogehoge.comとhogehoge.comの二つを入力する必要があります。こちらが詳しいです。
httpをhttpsへリダイレクトする場合、ELBで80番ポートで受け取り、EC2（nginx）に81番ポートにフォワードし、nginx側で81番ポートにきた場合は、httpsにリダイレクトをする処理をかけるのがシンプルです。この手法は、Clasic Load BalancerとApplication Load Balancerで利用できます。
- 81番ポートの手法を使わなくてもGistに載せたように、/etc/nginx/conf.d/webapp_healthd.confをカスタマイズしても良さそうです。いろんなところでよく見るnginxのconfです。最終的に私のElasticBeanstalkの01_nginx.confと02_load-balancer.configはGistに載せたような形になりました。

EC2のタイムゾーンを変更する場合

初期はUTCになっています。

$ date
2018年  5月 23日 水曜日 01:22:22 UTC

.ebextensionsの中にJSTに変える処理を追加します。

.ebextensions/01_timezone.config

commands:
  timezone-change:
    command: sed -i -e "s/UTC/Japan/g" /etc/sysconfig/clock
    ignoreErrors: false
  localtime-change:
    command: ln -sf /usr/share/zoneinfo/Japan /etc/localtime
    ignoreErrors: false

`git`コマンドを入れる

例えばGemfileにgem 'elasticsearch-rails', github: 'elastic/elasticsearch-rails', branch: '6.x'のようにgitコマンドがないとbundle installができない場合、入れる必要があります。
.ebextensionsの中に以下のような設定を行います。

.ebextensions/00_packages.config

packages:
  yum:
    git: []

cronでrails runnerやrakeタスクを動かす

cronでrails runnerやrakeタスクを実行したい場合、Elastic BeanstalkのWorker tierを用いれば良いのですが、そこまでするほどではない（orなるべく安く済ませたい）とき、.ebextensionsの中にcronの設定をしてあげる必要があります。
そのとき、単純にcd /var/app/current && rake -vTなどと書いたのでは動きません。Rails用の環境変数などが読み込まれていないからです。（参考）
- 環境変数を読み込む
- /var/app/currentにディレクトリを移動する
- bundleコマンドやrailsコマンドをフルパスで指定して実行する
コマンドが少し長くなってしまうので、下記ではAWSのドキュメントにならい、シェルスクリプトを実行させる形にしてあります。

.ebextensions/12_cronjob.config

files:
    "/etc/cron.d/mycron":
        mode: "000644"
        owner: root
        group: root
        content: |
            */2 * * * * root /usr/local/bin/my_rails_runner.sh

    "/usr/local/bin/my_rails_runner.sh":
        mode: "000755"
        owner: root
        group: root
        content: |
            #!/bin/bash

            . /opt/elasticbeanstalk/support/envvars
            cd /var/app/current

            # rails runnerの場合
            # 使っているrubyのversionに合わせる。eb sshして確認すること。
            /opt/rubies/ruby-2.5.0/bin/bundle exec /opt/rubies/ruby-2.5.0/bin/rails runner "puts MyModel.count" >> /var/log/cron-error.log 2>&1

            # rakeタスクの場合
            # /opt/rubies/ruby-2.5.0/bin/bundle exec /opt/rubies/ruby-2.5.0/bin/rake -vT >> /var/log/cron-error.log 2>&1

            exit 0

commands:
    remove_old_cron:
        command: "rm -f /etc/cron.d/*.bak"

CircleCIから`eb deploy`コマンドを利用する

CircleCIの PERMISSIONS > AWS PermissionsでAWS IAMユーザのAcces KEY IDとSecret Access Keyをセットします。CircleCI用に権限を絞ったIAMユーザを用意しておくと良いでしょう。
.elasticbeanstalk/config.global.yamlを用意する必要があるが、値を手動でセットするのは面倒なので、CircleCIにsshしてeb initコマンドを叩くと.elasticbeanstalk/config.yamlが吐き出されるので、それをコピーすると楽です。
.circleci/config.ymlにはebコマンドのインストールとDeployの実行を追加します。

.circleci/config.yml

 - run:
     name: Install eb Command
     command: |
       if [[ $CIRCLE_BRANCH = master && $CIRCLE_NODE_INDEX -eq 0 ]]; then
         sudo apt-get -y -qq update
         sudo apt-get install python-pip python-dev build-essential
         sudo pip install awsebcli --upgrade
       fi
 - run:
     name: Deploy Staging
     command: |
       if [[ $CIRCLE_BRANCH = master && $CIRCLE_NODE_INDEX -eq 0 ]]; then
         eb deploy your-envorinment-name
       fi

assets:precompileについて

ElasticBeanstalkを使っていると、assets:precompileが遅くなるという問題が生じることがあります。ローカルでassets:precompile実行したらすぐに終わるのに、ElasticBeanstalkのEC2上で実行するととても時間がかかってしまうということがあります。この原因は、t2やt3系を使っているとCPU負荷が上がってきたときにバーストしてくれますが、これは言い換えれば普段はCPU処理能力が低いということを意味します。assets:precompile実行時には多くのCPU処理能力が求められますから、CPU処理能力が低いとassets:precompileは非常に遅くなってしまいます。t2やt3系の場合バーストしてくれてCPU処理能力は上がっていきますが、少なくとも一つのコアはつねに100%を保ちながら処理を続けることになります。したがって、t2.smallなどのコア数が１のインスタンスを使っているとその状態でアクセスが来ると処理能力を超えサーバーが落ちてしまいます。（確か503 Service Temporarily Unavailableになります）
それを回避するには、バーストしない（通常からCPU処理能力が高い）EC2インスタンスタイプを利用するか、assets:precompileをEC2上で行わないようにします。
私の場合、CircleCIを利用しているので、CircleCI上でassets:precompileを走らせS3に上げ、それをデプロイ時にsyncするという方式をとっています。
まず、忘れずに環境変数RAILS_SKIP_ASSET_COMPILATIONにはtrueをセットしておきます。
以下のような形で.circleci/config.ymlにassets:precompileを行い、s3におきます。