Elastic Beanstalkへのデプロイ方法その3
先日の記事で、Elastic Beanstalkへのデプロイ方法には2通りあると言った。このたび、その2通りのちょうど中間に当たる方法が解ったのでメモ。前提として, awsebcliというpipパッケージを利用してコマンドラインベースでdeploy処理を走らせる場合のお話。
上記の2パターンをまとめると下記のようになる。
パターン1: 丸ごとzipアップロード方式
メリット:
簡単
.ebextensionsによるeb環境ホストの設定injectionが可能
デメリット:
- デプロイ所要時間が短い
eb deployコマンドのデフォルトの挙動で, ebプロジェクトルートディレクトリ内すべてをzip化し, ebプラットフォームにアップロードする。
eb環境ホストは上記zipを落としてきて, docker buildした後docker runし, アプリケーションが動き出す。
パターン2: dockerリポジトリpull方式
メリット:
- デプロイ所要時間が短い
デメリット:
- .ebextensionsによるeb環境ホストの設定injectionができない
どこかのdockerリポジトリに予めdocker buildしたimageをpushしておく。
Dockerrun.aws.jsonファイルにそのimageの所在（リポジトリ:タグ）を指定しておき, Dockerrun.aws.jsonファイルのみをebプラットフォームにアップロードする。
eb環境ホストはDockerrun.aws.jsonに指定されているdocker image情報をもとにリポジトリからimageをpullし、docker runすることでアプリケーションが動き出す。
中間手法: buildartifact.zip方式
メリット:
- デプロイ所要時間が短い
- .ebextensionsによるeb環境ホストへの設定injectionが可能
デメリット:
- デプロイの下準備が比較的面倒
eb deployによりzipアーカイブをアップロードし, それをもとにdocker runするのはパターン1と同じなのだが, zip生成過程を自前で準備するという点がパターン1と異なる。
zipアーカイブの中身に, 動かしたいdocker imageのリポジトリ:タグ情報を格納したDockerrun.aws.jsonと、.ebextensionsディレクトリのみを格納する。
これにより、パターン2と同様にeb環境ホスト側でのdocker build処理を回避しつつ、.ebextensionsによる設定injectionを可能にしている。
まあ、知っている人は知っているのかもしれないがいろいろと試行錯誤したのちにこの方法に落ち着いた。
