Windows Server でも使える Elastic Beanstalk のデプロイフックについて調べた

Elastic Beanstalk のデプロイフックに関しては Amazon Linux に関しては割と記事を見るのですが、Windows Server の場合を見なかったのと利用できる場面がありそうだったので実際に試しました。

Amazon Linux の場合は、この記事が分かりやすくまとまっていると思います。

appdeploy を使っていろいろとやっていますが、実際にはもっと多くのフックポイントが用意されているので、実行タイミングを正しく把握しておけば、後々便利に使えるのではないかと思います。

Windows Server の場合は C:\Program Files\Amazon\ElasticBeanstalk の中に hooks があります。

f:id:shiba-yan:20170113001945p:plain

最近は Go を使ってプラットフォームの壁を超えることが出来てるのが喜ばしいですね。

実行タイミングと順序を把握するために、簡単な ebextensions を作成してみました。1 つのファイルにログを追記していくだけの、簡単なコマンドを実行するようにしています。

commands:
  test:
    command: echo commands executed >> C:/hooks.log

container_commands:
  test:
    command: echo container_commands executed >> C:/hooks.log

files:
  "C:/Program Files/Amazon/ElasticBeanstalk/hooks/appdeploy/pre/99test.bat":
    content: |
      echo appdeploy_pre executed >> C:/hooks.log

  "C:/Program Files/Amazon/ElasticBeanstalk/hooks/appdeploy/post/99test.bat":
    content: |
      echo appdeploy_post executed >> C:/hooks.log

files を使うと Program Files などにも簡単にファイルを作成できます。hooks の中には Elastic Beanstalk が利用しているスクリプトがあるので、実行を邪魔しないように 99 とか大きな数字を付けました。

あまり関係ないですが ebextensions は CloudFormation によって実行されているみたいで、その時の実行ユーザーは SYSTEM になるので少し注意が必要でした。

とりあえず Elastic Beanstalk でフックが呼ばれそうな処理を行って試してみました。

アプリケーションのデプロイ
アプリサーバーの再起動
環境の再構築
設定の変更

いくつか実行が確認できないフックがありましたが、それは時間のある時にもう少し調べようと思います。

アプリケーションのデプロイ

MSDeploy パッケージを Elastic Beanstalk にデプロイした時は、ebextensions と大体タイミングが被っていますがデプロイ完了後のフックがある点が大きく異なっています。

commands (ebextension)
appdeploy/pre
container_commands (ebextension)
(MSDeploy)
appdeploy/post

正直なところ、デプロイ前のフックはあまり使わない気がします。デプロイが完了した後には ASP.NET の場合は、アプリケーション URL をキックして IIS を起こしたりしたいかもしれません。

アプリサーバーの再起動

Windows Server の場合はアプリサーバーの再起動を実行すると IIS のみが再起動されます。実体は iisreset を呼び出しているだけのようです。

restartappserver/pre
restartappserver/post

フックの実行はまあ予想通りという感じです。

環境の再構築

EC2 インスタンスを作り直して、アプリケーションをデプロイし直す処理なので殆どはアプリケーションのデプロイと同じフックが実行されています。

commands (ebextension)
appdeploy/pre
container_commands (ebextension)
(MSDeploy)
appdeploy/post
postinit

最後に postinit が実行されているのが異なります。preinit は恐らく ebextensions を使ってフックを設定しているので、実行タイミングに間に合わないのだと思います。

カスタム AMI を作成して、予め仕込んでおけば preinit もこのタイミングで呼び出されると思います。

設定の変更

32bit アプリケーションの有効化など、インスタンスの再構築を伴わない設定を変更した場合は configdeploy だけが実行されました。

configdeploy/pre
configdeploy/post

インスタンスサイズの変更など、インスタンスの再構築が必要な場合は環境の再構築と同じになります。

補足: インスタンスのライフサイクルとフック

最後にインスタンスのライフサイクルから見て、フックについて思ったことを書いておきます。

必ず 1 回だけ実行される
- preinit (未確認)
- postinit
複数回実行される
- appdeploy
- restartappserver
- configdeploy
タイミング未確認
- preinitreboot
- postinitreboot

preinitreboot と postinitreboot は Windows Server を再起動しても実行されていなかったので、Elastic Beanstalk が内部的に何かして再起動が必要になったときに実行される気がします。

しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ