最近は App Service on Linux を使った仕事もしていたので、本番環境で使う場合の注意点を簡単にまとめておきます。地味にはまるポイントが多くて忘れそうなので、ほぼ自分用のメモですね。
2 コア以上のインスタンスを選ぶ
1 core 1.75GB の B1 / S1 インスタンスから選べますが、明らかにコンテナの起動時間が遅いので最低でも B2 / S2 を選ぶべきです。これは本番環境だけではなく、テスト用でも同じです。
CPU リソースというよりもメモリが足りていない気もするので、Premium V2 が App Service on Linux でも使えるようになれば幸せになれそうです。
Docker Image のタグを必ず指定する
App Service on Linux はホスト側のメンテナンスなど、様々な事情で実行中のコンテナが再起動されることがあります。なので、タグを指定せずに latest のまま使うと、再起動時に pull が走って意図せずバージョンアップしてしまいます。
ACR はタグを指定しないと設定できないので良いですが、Docker Hub を使っている場合には注意です。
当然ながら CI で Docker Image を作る場合にもビルド番号などでタグを指定します。
Always On は有効化する
App Service on Linux の仕組みとして、最初にリクエストがあったタイミングでコンテナが起動されるので、初回アクセス時に割と時間がかかってしまいます。
なので、Always On を有効にして、出来るだけコンテナを常に立ち上げた状態にしておきます。
このあたりは Windows と同じですね。設定することで意図しない再起動の影響を最小限に出来ます。
Staging Slot を使って Swap でリリースする
軽量な Alpine ベースの Docker Image を使っている場合には気にならないぐらいの時間でしょうが、ASP.NET Core アプリケーションの Docker Image は 100MB を超えてしまうので、pull で時間がかかります。
Image 自体は App Service on Linux 側にキャッシュされるので、Staging Slot を使って時間のかかる pull を回避しつつ、リリースする方法を取る必要があります。
Swap を行うと、今の実装では Production / Staging Slot 共に新しいコンテナが起動されて、起動完了後に入れ替わるという仕組みみたいなので、両方で同じバージョンになるタイミングが発生します。
両方の Slot 設定をキッチリと合わせていても、新しいコンテナが必ず起動されるみたいなので、暖めて出すという使い方が出来ないのが少し残念ではあります。
ACR を利用した CD を使わない
Azure Container Registry の Webhook を使った CD 機能は非常に便利そうに思うのですが、Webhook の実装がコンテナを再起動するだけという、非常に残念なものになっています。
なので、CI では常に同じタグを push せざるを得ず、Swap のタイミングで再起動されるという実装と相まって、Swap を実行すると両方の Slot が最新になるという致命的欠点があります。
ACR 連携の CD は Webhook が push された Docker Image とタグの情報を読み込んで、その通りに Docker Image を更新するようになるまで使い物にならないと考えた方が良いでしょう。
Azure CLI を使った更新や、VSTS のタスクでは Docker Image 名を変更するので、こういった問題は発生しません。Docker Image の情報は ARM 側に持っているっぽいので、Webhook での対応は望み薄です。
