AWS Elastic Beanstalk イメージがつかないのでやってみた

#■はじめに#

AWS ElasticBeanstalk とは、AWSにて提供されているアプリケーションを統合管理することができるプラットフォームです。

コードをアップロードするだけで、AWS Elastic Beanstalk が、キャパシティーのプロビジョニング、負荷分散、Auto Scaling からアプリケーションの状態モニタリングまで、デプロイを自動的に処理します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/03d59af7-5a4a-47c7-2ca6-c3382c35f3d7.png)

と言われてもよくわからないので、とりあえず触ってみる。

ウェブサーバーを作成し、このサービスを、例えば Python で記述した実際のケースについて検討しましょう。
では、ウェブサービスが世界中のあらゆる人に適切に表示されるようにするには、どうしたらいいか？
ElasticBeanstalk を実行すれば、極めて簡単に実現できます。



#■やってみた#
Elastic Beanstalk を開きます。

<br>

「ウェブサーバー環境」を「選択」
詳細は[ウェブサーバー環境](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts-webserver.html)
![スクリーンショット 2019-01-16 19.29.47.png](https://qiita-image-store.s3.amazonaws.com/0/280929/8ff8f7f8-8e42-224b-9fc3-f9fb285ef1a9.png)



[ドメイン]には手動で作成する場合には、空白にしておくこともできます。（今回は試しに空白にして起きました。）
[プラットフォーム]は、Python を利用します。
[アプリケーションコード] は、今回は特に用意していないので、サンプルアプリケーションを選択します。
![スクリーンショット 2019-01-16 19.33.47.png](https://qiita-image-store.s3.amazonaws.com/0/280929/60b72aed-1eb5-62dd-d73a-32c5443d1f4f.png)
![スクリーンショット 2019-01-16 19.40.15.png](https://qiita-image-store.s3.amazonaws.com/0/280929/a2fddd6f-670e-5f31-14ab-e80c4642416b.png)



現在、システムでは、環境全体、必要なすべてのインスタンス、すべてのネットワーキング環境の作成が行われています。
これには、5〜10分利用、場合によってはそれ以上かかります。
これをスピードアップするために、全く同じコードの環境を既に作成してあるため、これを利用できます。
![スクリーンショット 2019-01-16 19.42.06.png](https://qiita-image-store.s3.amazonaws.com/0/280929/3757843f-bd0b-c694-eaf2-65b710e491d1.png)



作成されました。作成されたら新しいバージョンのアップロードやデプロイが可能になります。
![スクリーンショット 2019-01-16 19.46.31.png](https://qiita-image-store.s3.amazonaws.com/0/280929/17dc15c6-dd33-d49e-ef6b-732ad6828425.png)



重要なのは、URL です。これはアプリケーションに対して作成された URLであるため、誰でもどこからでもこのURLにアクセスできます。
![スクリーンショット 2019-01-16 19.51.39.png](https://qiita-image-store.s3.amazonaws.com/0/280929/367c9560-36a9-f69d-9457-56c283ba0ca6.png)



「設定」を開くと、ソフトウェアやインスタンスの情報が表示されます。
![スクリーンショット 2019-01-16 19.53.58.png](https://qiita-image-store.s3.amazonaws.com/0/280929/43062d7d-239d-ec40-39fe-75f35d2f5f7d.png)



Beanstalkで、開発者様はアプリケーションの開発だけに集中できる。
自動でやってくれるのはわかった。

少し古いですが概念は変わっていないと思うので、↓の方のブログを見たほうがわかりやすかったです。
[sometimes I laugh 高専卒WEBエンジニアがいろいろ残しておくブログ](https://sil.hatenablog.com/entry/aws-elasticbeanstalk-settingcheck)
・Elastic Beanstalkとは
・まとめ


以降は学習のためのメモ


#■環境要素#
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/3ef77bf4-4e03-e9f1-934e-12c8e55195f3.png)


#■デプロイメント方式#

- 用語
 - In Place Deployment(Rolling Deploy):インスタンスは現行環境のものをそのまま利用し、新しいリビジョンのコードをその場で反映させる
 - Blue/Green Deployment(Red/Black Deployment):新しいリビジョンのコードを新しいインスタンスに反映させ、インスタンスごと入れ替える


- 方式

|デプロイメント方式|説明|方式|
|------|------|-----|
|1回にすべて(All at once)|同時に全ての既存インスタンスにデプロイをする。|In Place | 
|ローリング(Rolling)|まず**バッチサイズ**分のインスタンスがLBからデタッチされ、デプロイをする。<br>ヘルスチェックが通れば、そのバッチがLBに再アタッチされる。<br>全てのインスタンスにデプロイがされるまで LBからデタッチ⇒デプロイ⇒ヘルスチェックOKならLBに再アタッチ を繰り返す|In Place | 
|追加バッチとローリング(Rolling with additional batch)　|**バッチサイズ** 分のインスタンスを追加作成&そのインスタンスにデプロイ実行。<br>バッチサイズ 分のインスタンスがLBからデタッチされ、デプロイが実行される。<br>デプロイが終わりヘルスチェックが通れば、次のバッチサイズ分のインスタンスが同様にLBからデタッチされデプロイされ..を繰り返す<br>最後に追加作成分のインスタンスをshutdownする。(起動時刻が古いインスタンスからshutdownされている気がする)　|In Place 　　Blue/Green |
|変更不可(Immutable)|まず1台インスタンスを立ち上げ、デプロイをする。<br>ヘルスチェックが通れば 現在のインスタンス数-1 分新たにインスタンスを立ち上げ、デプロイする<br>全部のヘルスチェックが通れば、古いのをshutdownしていく　<br>※マネージドプラットフォーム更新→自動的に最新のバージョンに更新するよう設定可能|Blue/Green |
|URL Swap |参考[Elastic BeanstalkのCNAME Swapを試してみる](https://dev.classmethod.jp/cloud/aws/beanstalk-cname-swap/)　|Blue/Green　|
|Amazon Route 53 　|[[新機能]AWS Elastic BeanstalkがAmazon Route 53のALIASレコードの対象になりました](https://dev.classmethod.jp/cloud/aws/elastic-beanstalk-support-route53-alias/)　|Blue/Green　|

- デプロイ時間

1回にすべて(All at once) < ローリング(Rolling) < 追加バッチとローリング(Rolling with additional batch) < 変更不可(Immutable)
このようにAll at onceが一番早い。

詳しくはドキュメントを確認してデプロイ所要時間やダウンタイムの時間を確認し、デプロイメント方式を検討すること。
[AWS Elastic Beanstalk 環境へのアプリケーションのデプロイ](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html)


#■設定の保存#
ステージング環境で利用している環境を本番環境で利用したい場合などに、保存した設定からデプロイすることが可能。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/a21b2eaa-e372-7a01-9fe2-0e1aaa4410e4.png)


#■Docker Support#

##Single Container##
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/428d4e1f-29d6-3a9d-9f95-8217bc875039.png)

##Multi Container##
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/b59d233c-1617-9692-e141-092c42a2505b.png)


#■.ebextensions#
.ebextensionsはElastic Beanstalkの設定ファイル...ではなく設定ファイル群を格納するディレクトリです。
プロジェクトルートの直下に.ebextensionsディレクトリを作り、その中に拡張子が.configのyaml形式かjson形式のファイルを置くことで、自動的に読み取って設定してくれます。

例えば、HTTPS を復号するよう Elastic Beanstalk 環境のロードバランサーを設定するには、2通りの方法があります。
詳しくは↓。
[HTTPS を復号するよう Elastic Beanstalk 環境のロードバランサーを設定する](https://qiita.com/DeployCat/items/f7981cf82b4649247d55)

- コンソールから
- 設定ファイルを使用

後者の方法では、環境に Application Load Balancer がある場合、以下のような例を使用します。
この例では、aws:elbv2:listener 名前空間内のオプションを使用して、指定した証明書によりポート 443 上の HTTPS リスナーを設定しています。
リスナーは、デフォルトのプロセスにトラフィックをルーティングします。

```.ebextensions/securelistener-alb.config
option_settings:
  aws:elbv2:listener:443:
    ListenerEnabled: 'true'
    Protocol: HTTPS
    SSLCertificateArns: arn:aws:acm:us-east-2:1234567890123:certificate/####################################
```