こんにちは、ロジカルアーツの井川です。
昨今は便利なアプリケーションやサービスが次々とリリースされますよね。
アプリケーションを動かすにはそれを実行するためのサーバやネットワークが必要になりますが、できるだけ早く用意してほしい！という急ぎの依頼を受ける時もあるかもしれません。
今回はアプリケーションを動かすために必要なAWSのサービスを素早く設定してくれるElastic Beanstalkをご紹介したいと思います。
Elastic Beanstalkとは
Elastic Beanstalkはアプリケーションが稼働するために必要なAWSのサービスをまるっと自動で設定してくれるサービスです。
例えば、アプリケーションを動かすためにEC2を設定しようとした場合で考えてみましょう。
以下のようなリソースの作成、設定作業が必要になります。
要件によっては負荷分散やAutoScaingの設定をする必要もあるかもしれません。
AWSは良く使ってるしサーバの設定には慣れてるよ、という方は大丈夫かもしれませんが、ここで躓いてしまい本来アプリケーションの開発に使うはずだった時間を削ってしまうようなことがあれば良くありません。
Elastic Beanstalkはこのようなアプリケーションを稼働させるために必要となるAWSのリソースや設定を自動で作成し、アプリケーションをAWSにデプロイするハードルを下げてくれます。
また、AWSマネジメントコンソール内のElastic Beanstalkメニューから、AWSサービスの設定を変更できるようになり、アプリケーションはソースコードをダッシュボード画面からアップロードするだけでデプロイできるようになります。
AWSのことはElastic Beanstalkに任せて、アプリケーションの開発に集中することができるサービスなのです。
ちなみにBeanstalkは「ビーン・ストーク」と読みます。
アプリケーション、環境の作成
Elastic Beanstalkを開始するにあたって、はじめに「アプリケーション」を作成します。
アプリケーションは、Elastic Beanstalkが作成する「環境」を管理するための入れ物になります。
「環境」は、実際にソースコードをアップロードするサーバやネットワークを組み合わたリソースの集まりで、アプリケーションは複数の環境を管理することができます。
まずはマネジメントコンソールにログインし、Elastic Beanstalkメニューに移動しましょう。
AWSマネジメントコンソールでElastic Beanstalkを選択します。
続いて新しいアプリケーションの作成を選択します。
アプリケーション名はigawa-appを入力し作成を選択します。
アプリケーションが作成できました。
続いて環境を作成します。
環境を作成するには、アクションメニューから環境の作成を選択します。
すると環境枠の選択画面に進みます。環境枠は用途に合わせて「ウェブサーバー環境」と「ワーカー環境」のどちらかを選択します。
| 環境 | 用途 |
|---|---|
| ウェブサーバー環境 | ウェブサイト、ウェブアプリケーション、または HTTP リクエストを処理する標準アプリケーション向け |
| ワーカー環境 | Amazon SQSキュー上のメッセージをリッスンするバックグラウンド処理を含む特殊なアプリケーション向け |
今回はサンプルアプリケーションを使った標準アプリケーションを作成するため、「ウェブサーバー環境」を選択している状態で選択を選択します。
環境を作成するために必要な情報を入力し、環境の作成を選択します。
| 項目 | 入力例 | 説明 |
|---|---|---|
| 環境名 | IgawaApp-env | 環境の名前 |
| ドメイン | igawaapp-env | 環境の一意なドメイン名 |
| 説明 | 省略 | 環境の説明 |
| プラットフォーム | Node.js | アプリケーションを実行するために使用するOS、ランタイム、Webサーバ、アプリケーションサーバの集まり |
| アプリケーションコード | サンプルアプリケーション | 環境にデプロイするコードを指定する |
Elastic BeanstalkがVPCやEC2インスタンス等のリソースの作成を開始します。作成が完了するまでしばらく時間がかかるので待ちます。
作成が完了すると環境のダッシュボードを表示できるようになり、環境の情報確認できるようになります。
画面上部にあるURLにアクセスしてみると、Webページを表示できました。
EC2のメニューを確認すると、Elastic Beanstalkによって作成されたEC2インスタンスが確認できます。
アプリケーションのデプロイ手順
Elastic BeanstalkはAWSマネジメントコンソール上からソースバンドル(ZIPファイルまたはWARファイル)をアップロードしてアプリケーションをデプロイすることができます。
そのため、必ずしもSSHやFTPでサーバに接続する必要はありません。
アップロードしたソースバンドルはElastic Beanstalk内でバージョン管理されており、以前のバージョンに戻すことが可能です。
新しいアプリケーションをデプロイしてみます。
まずはNode.jsのサンプルアプリケーションのソースバンドルを以下からダウンロードします。
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/samples/nodejs-v1.zip
ダウンロードしたZIPファイルを解凍し、index.htmlのCongratulationsをCongratulations Updateに変更します。
<body> <div class="textColumn"> <h1>Congratulations Update</h1> <p>Your first AWS Elastic Beanstalk Node.js application is now running on your own dedicated environment in the AWS Cloud</p> </div>
変更が完了したらZIP形式に圧縮します。
圧縮はプロジェクトフォルダ(親フォルダ)を含めずに、中のファイルとフォルダを選択した状態で行います。
環境のメニューを表示し、アップロードとデプロイを選択します。
アップロードするソースバンドルを選択し、バージョンラベルを入力後、デプロイを選択します。
しばらくするとアプリケーションの更新が完了し、実行バージョンが更新されました。
Webページにも追記した"Update"の文字が反映されました。
設定のカスタマイズ
Elastic Beanstalkでは環境の作成時、もしくは作成後に以下のオプションを指定することで環境の設定をカスタマイズすることができます。
| カテゴリ | 設定できる内容 |
|---|---|
| ソフトウェア | Webサーバの種類やログの設定を指定します。 |
| インスタンス | 作成するEC2インスタンスのインスタンスタイプやルートボリュームの種類、サイズ、使用するセキュリティグループを指定します。 |
| 容量 | AutoScalingの設定を指定します。EC2インスタンスの増減範囲や時間に基づくスケーリングのスケジュールを指定できます。 |
| ロードバランサー | ロードバランサーの待ち受けポートやセッション維持の設定、ヘルスチェックの設定を指定します。環境の作成時であればロードバランサーのタイプも指定することができます。 |
| ローリング更新とデプロイ | 設定変更によるEC2インスタンスの置き換え時のルールを指定します。これによりEC2インスタンスの置き換えが行われてもサービスのダウンタイムが発生しないようすることができます。 |
| セキュリティ | Elastic BeanstalkやEC2インスタンスのIAMロールとEC2インスタンスのキーペアを指定します。 |
| モニタリング | 環境のヘルスチェックに関わる設定やモニタリングするメトリクス(リソース)を指定します。 |
| マネージド更新 | 環境のパッチバージョンの更新を自動で行うよう設定できます。更新を有効にすると予め設定したスケジュールに沿って自動で実施します。 |
| 通知 | 環境からの重要なイベントに関する通知先となるメールアドレスを指定します。 |
| ネットワーク | 環境が使用するVPCやサブネットを指定します。環境の作成後は変更でません。 |
| データベース | 環境にRDSを追加してデータベースを作成します。 |
上記のカスタマイズはElastic Beanstalkメニューやコマンドラインで設定する方法と設定ファイル(.ebextentions)を使う方法があります。
それぞれの方法を使ってインスタンスタイプの設定を行ってみたいと思います。
Elastic Beanstalkメニューから設定する方法
ダッシュボードに移動し設定を選択します。
すると、設定できる項目がカテゴリごとに表示されるので、カスタマイズする項目を選択します。
今回はインスタンスタイプの変更を行うため、「インスタンス」の変更を選択します。
インスタンスタイプのプルダウンメニューでt2.microをt2.smallに変更し、適用を選択します。
確認画面が表示されました。既存のEC2インスタンスを置き換えて新しいインスタンスタイプのEC2インスタンスを作成する内容です。
問題ないため確認を選択します。
Elastic Beanstalkによってt2.microのEC2インスタンスが削除され、t2.smallのEC2インスタンスが新たに稼働しました。
設定ファイル(.ebextentions)を使う方法
アップロードするソースバンドル内に作成した設定ファイル(.ebextensions)を追加すると、環境の設定や環境に含まれるAWSリソースをカスタマイズできます。
設定ファイルを使う方法はサーバ内の細かな設定を指定することができるため、Elastic Beanstalkメニューで指定できない設定は、設定ファイルを使って対応します。
設定ファイルはYAML形式またJSON形式で記述します。
今回は以下のインスタンスタイプを変更する設定ファイルをYAML形式で作成しました。
option_settings: - namespace: aws:autoscaling:launchconfiguration option_name: InstanceType value: t2.small
この設定ファイルをソースバンドルの.ebextensionsフォルダ内に配置します。
このソースバンドルをデプロイすることで設定ファイルに記述した変更が同時に行われるようになります。
では、早速デプロイを試してみましょう！と進みたいところですが、Elastic Beanstalkは、環境に適用する設定に優先順位があり、設定ファイルで指定する方法は最も優先度が低いです。
Elastic Beanstalkメニューから指定した設定をコマンドラインを使って削除しない限り、設定ファイルで指定した設定を反映できません。
IgawaApp-envは先ほどElastic Beanstalkメニューから指定した設定が優先されるため、今回は新たに環境を作成して試すことにします。
※設定の優先順位については以下で詳細を確認できます docs.aws.amazon.com
アプリケーション、環境の作成の手順に従って新たにIgawaApp-env-ebexという環境を作成し、設定ファイルを含めたソースバンドルのデプロイ操作を行います。
アプリケーションの更新が完了するとイベント欄にEC2インスタンスを置き換えたことが分かります。
t2.microのEC2インスタンスが削除され、設定ファイルで指定したt2.smallのEC2インスタンスが新たに稼働しました。
まとめ
Elastic Beanstalkに対して何となく難しそうな印象を持っていましたが、一度使ってみると環境の作成を迷わず進められるようになりました。
これならサーバの設定や操作に慣れていなくても簡単に環境を準備できますね！
AWSの設定はElastic Beanstalkに任せてアプリケーションの開発に集中できそうです！
この記事がElastic Beanstalkに興味を持つきっかけとなれば幸いです。
