はじめに
- Azure App Service に関して 見落としがち、あまり知られていないのでは? …な内容を細々~とまとめます
- App Service の OS は Windows 前提で書きます
お金 系
- 何に対してどれくらいお金かかるの?
- はじめのうちはふわっと理解したつもりになりがちなのでまとめます
App Service Plan に対してお金がかかる
- 実際の内部アーキテクチャや概念を無視し、誤解を恐れず「お金」という観点だけから見ると、以下の関係がしっくり来るかもです
- App Service Plan = 物理サーバ:買うのにお金がかかる
- 増やす(スケールアウトする)と、よりお金がかかる
- 性能上げる(スケールアップする)と、よりお金がかかる
- App Service = アプリケーションサーバ:ソフトウェアサーバなので立ち上げ放題
- App Service Plan = 物理サーバ:買うのにお金がかかる
- つまり 1つの App Service Plan 上に いくら App Service を載せても、かかるお金は同じ
- ただし Plan ごとに 載せられる App Service の上限はある
- 上記の関係のため、同一 Plan 上 マシンリソース(CPU, メモリ等)は 山分け となる
- Azure ダッシュボード上で 新規に App Service を作成するとき、
- 料金プランを選ぶと、それに応じた App Service Plan というリソース(黒いサーバのアイコン)がさりげなく作られる( 見落としがち! )
- App Service を削除するとき App Service だけ消しても App Service Plan が残っているとその分の料金がかかる!
- 削除する際にきちんと警告が出ています
- スケール操作は App Service に対してではなく App Service Plan に対して行っているのがポイントです(ダッシュボード上では App Service からもスケール操作できてしまうので紛らわしいですが…)
公開 系
- アップロード、デプロイに関すること
とにかくさっさと公開したい!
-
/site/wwwroot/
以下が 公開ディレクトリとなっているので、そこにファイルを ドロップします
Git 使いたい
- デプロイセンターを選択し、下へスクロール
-
App Service Kudu ビルドサーバを選択し [続行]
-
すると Git リポジトリが作成され、デプロイセンターに Clone URL が表示されます
- あとは各自ローカルのGitを使ってデプロイできます
- 各言語向けの初期テンプレートも公開されています
- 例:NodeJSの場合
- [Azure で Node.js Web アプリを作成する
] (https://docs.microsoft.com/ja-jp/azure/app-service/app-service-web-get-started-nodejs)
-
資格情報は [展開の資格情報] から表示・設定ができます
資格情報について
アプリの資格情報
- App Service ごとに設定可能な資格情報
- ユーザ名もパスワードも、ユーザが自由に決められず、自動生成される
- ランダムパスワードは再生成(リセット)可能
ユーザの資格情報
- ユーザが自由に設定可能な資格情報
- App Service、サブスクリプションの垣根を超えてアクセス可能
- [Configure deployment credentials for Azure App Service] (https://docs.microsoft.com/ja-jp/azure/app-service/deploy-configure-credentials)
- 特別な理由がない限り「アプリの資格情報」を使ったほうが良さそうです
がっつり CI/CD(DevOps)やってみたい
- Azure DevOps を使いましょう
- 詳細はここでは言及できません(膨大すぎるので・・・)
- 本家:Azure DevOps
- Azure とは別ドメインですが、Azure のサブスクリプションを共用し連携できます
- 基本的には以下のような使い方になると思います
- ソースコードの管理、ビルドの設定 等を DevOps 側で定義 し
- デプロイ先として Azure App Service を指定 する
- コンテナにデプロイして・・・等もできますがここでは割愛
デプロイスロット 系
- App Service には スロットを複数持たせ、切り替えて公開することができる機能「デプロイスロット」があります(ブルーグリーンデプロイメント)
スワップって何がスワップされるの?
- 以下にまとめて記載あります。
- [Set up staging environments in Azure App Service] (https://docs.microsoft.com/ja-jp/azure/app-service/deploy-staging-slots#which-settings-are-swapped)
- 補足すると、App Serivce でないリソースに関してはスワップされません
- 例えば スケール設定(レベル等)に関して、ダッシュボード上では App Service から設定できるように見えますが、実体は App Service Plan の設定ですので、スワップの対象ではないです(当たり前かもですが・・・)
Webジョブ系
ジョブの定義はどこに保存される?
- App Service 高度なツールでファイルとして保存されている定義を見ることができます
- D:\home\site\wwwroot\App_Data\jobs 以下がWebジョブが保存される保存ディレクトリです
- この記事では JOB_HOME と称します。
ジョブの種類
トリガー
- 保存先:
JOB_HOME/triggered
以下 - 以下の方法で実行できます
- ダッシュボード上から実行
- WEBHOOK URL を叩く
- CRON式を設定してスケジュール実行
継続
- 保存先:
JOB_HOME/continuous
以下 - 継続的にエンドレスに実行されます(以下のようなログが保存されているのを見ると60秒毎?)
[12/21/2018 10:15:45 > 0de3df: SYS INFO] Run script 'run.cmd' with script host - 'WindowsScriptHost'
[12/21/2018 10:15:45 > 0de3df: SYS INFO] Status changed to Running
[12/21/2018 10:15:45 > 0de3df: INFO]
[12/21/2018 10:15:45 > 0de3df: INFO] D:\local\Temp\jobs\continuous\test2\pwx4sqds.a31>echo "HELLO"
[12/21/2018 10:15:45 > 0de3df: INFO] "HELLO"
[12/21/2018 10:15:45 > 0de3df: SYS INFO] Status changed to Success
[12/21/2018 10:15:45 > 0de3df: SYS INFO] Process went down, waiting for 60 seconds
[12/21/2018 10:15:45 > 0de3df: SYS INFO] Status changed to PendingRestart
[12/21/2018 10:16:45 > 0de3df: SYS INFO] Run script 'run.cmd' with script host - 'WindowsScriptHost'
[12/21/2018 10:16:45 > 0de3df: SYS INFO] Status changed to Running
[12/21/2018 10:16:45 > 0de3df: INFO]
[12/21/2018 10:16:45 > 0de3df: INFO] D:\local\Temp\jobs\continuous\test2\pwx4sqds.a31>echo "HELLO"
[12/21/2018 10:16:45 > 0de3df: INFO] "HELLO"
[12/21/2018 10:16:45 > 0de3df: SYS INFO] Status changed to Success
[12/21/2018 10:16:45 > 0de3df: SYS INFO] Process went down, waiting for 60 seconds
[12/21/2018 10:16:45 > 0de3df: SYS INFO] Status changed to PendingRestart
ジョブディレクトリ内でジョブを実行させたい
- Webジョブを実行すると ジョブ格納場所とは別の場所に一時ディレクトリが作られ その中でジョブが実行されます
- つまり以下のようなディレクトリ構成であった場合、
- jobs
- triggered
- hello
- run.cmd
- hello2
- run.cmd
- hello
- continuous
- triggered
- bin
- hello.jar
- jobs
- hello や hello2 ディレクトリ内の run.cmd から hello.jar を叩く場合、
java -jar ../../../bin/hello.jar
と指定しても実行できません- hello(helloジョブのディレクトリ)以下が、システムの一時ディレクトリへコピーされて実行されてしまうためです
- その様な場合、以下のようにすることで実行可能です
- hello, hello2 ディレクトリ直下に jar を配置しておく
- 同一の jar である場合、同じものがあっちこっちに存在することになるのであまりおすすめできません。。。
- hello, hello2 ディレクトリ直下に
{ "is_in_place": true }
と記述したsettings.job
というファイルを置く- これでジョブを実行しても hello, hello2 ディレクトリ以下で直接実行されるようになります
- ただし ファイルロックされる問題があるとか…?
- [WebJobs - WebJob Working Directory] (https://github.com/projectkudu/kudu/wiki/WebJobs#webjob-working-directory)
- hello, hello2 ディレクトリ直下に jar を配置しておく
WebJobの実行ログを診断ログ(アプリケーションログ)として吐かせたい
- App Service のアプリケーション設定に以下を設定します
- 名前:WEBJOBS_LOG_TRIGGERED_JOBS_TO_APP_LOGS
- 値:true
- [WebJobs - Configuration Settings] (https://github.com/projectkudu/kudu/wiki/WebJobs#configuration-settings)
その他
システムディレクトリを覗く
- Debug console → CMD とたどり、下部のコンソール画面で
cd ../
と入力し Enter を押すとルートディレクトリに移れます - Windows, Program Files 等、Windows ユーザにとって見慣れたディレクトリが一覧表示されます
- が、基本的には 見るだけ にしておきましょう
- マネージドのサービスなので、直接このようなシステム変更を加えても
- その変更が恒久的に保証されない
- 予期しない動作が発生する
- 等、危険があるため「中身はこうなってるんだ~」と見るだけにしておきましょう。
- マネージドのサービスなので、直接このようなシステム変更を加えても
おわりに
- 書いている本人も見落としていたこと、知らなかったなど結構ありました。そしてまだまだありそうです。。。
- App Service 奥が深い。。。
- ネタができたら定期的に更新する・・・かもしれません