最近は Azure WebJobs をよく使っているのですが、Visual Studio からスケジュールされた WebJobs をデプロイしようとすると、新しくジョブコレクションを作ろうとするので残念な感じです。
なので、手動で WebJobs をキックするジョブを作ろうとするんですが、SCM 側への認証周りで毎回躓くのでまとめておきます。
Kudu (SCM) へのログイン
基本的にブラウザで Kudu にアクセスする時には Microsoft アカウントを使ったフェデレーション認証になりますが、昔はデプロイ資格情報を使った基本認証だった頃もあります。
実はまだ基本認証は生きていて、認証ヘッダを付けると REST API を叩けるようになってます。しかも、その資格情報はユーザーレベルとサイトレベルの 2 種類が存在していたりします。
Deployment credentials · projectkudu/kudu Wiki · GitHub
このあたりに資格情報の話が書いてありました。ページ名は Deployment になってますが、デプロイ以外にもいろんな場面で使われているので紹介しておきます。
ユーザーレベル
ユーザーレベルの資格情報はつまるところデプロイ資格情報のことになります。
案外知られていないかもしれないですが、これはユーザーごとに紐づいてるのでサイト作る度に再設定とか要らないようになってます。
新ポータルの設定画面にもそのように書いてあります。
Microsoft アカウントに紐づいているサイト全てにアクセス出来るという、割と凶悪な権限を持っているので扱いには注意しましょう。*1
サイトレベル
サイトレベルの資格情報は馴染みなさそうですが、発行プロファイルなど MSDeploy に絡む部分で使われているので誰もが 1 度は使ったことがあるはずです。
パスワードが自動生成かつ、ユーザー名がサイト名から一意に決まるのが特徴ですね。
実際に発行プロファイルをダウンロードしてきて開いてみると、userName と userPWD という属性に設定されていることが分かります。
全く関係ないけど、controlPanelLink が今は亡き Silverlight 版ポータルの URL になっているのが気になる。*2
サイトレベルの資格情報は Azure PowerShell の Get-AzureWebsite を使っても取得することが出来ます。
ポータル開くのがめんどくさい時には、こっちを使ったりします。
スケジューラーからキック
REST API を使って WebJobs を実行するためには、以下の API を基本認証経由で叩く必要があります。
https://{sitename}.scm.azurewebsites.net/api/triggeredwebjobs/{webjobsname}/runKudu の REST API を管理ポータルも使っているので、覚えておいて損はないかと。
Visual Studio からスケジュールされた WebJobs を追加すると、サイトレベルの資格情報を使ってジョブを作ってくれますが、手動の場合は当然ながら手動で資格情報を設定します。
と言っても、現行ポータルには基本認証の資格情報を簡単に設定できるようになっているので安心です。
これで既存のジョブコレクションを使って WebJobs を実行出来るようになりました。理想としては WebJobs を追加する時にジョブコレクションを選択できるようになることなんですけどね。
