web-dev-qa-db-ja.com

再起動せずにポータルを使用してAzureアプリの設定を変更する

私は時々これに：

Azureポータルで、[アプリサービス]に移動し、Webアプリをクリックして、[アプリケーション設定]に移動します。

ここでは、「アプリの設定」リストから1つの値を変更します。

App Settings in Azure Portal

例えば。 「128」を「129」に変更します

最後に「保存」をクリックします。

これにより、Webアプリが再起動します。私はそれを望んでいません。

質問：再起動せずにこの値を手動で変更する方法はありますか？そうでない場合は、この値を別の方法で保存する必要がありますか？毎回アップロードできるweb.configの新しいセクションを使用しているのでしょうか？

新しいセクションを使用する場合、例：

<moreAppSettings configSource="moreSettings.config">
</moreAppSettings>

そして、このmoreSettings.configは次のようになります。

<?xml version="1.0" encoding="utf-8"?>
<moreSettings>
   <add key="ClientAppBuild" value="129" />
</moreSettings>

再起動せずに、その単一の.configファイルをアップロードして上書きできますか？

azureazure-web-sitesappsettings
10
sports

実行時に変更できるKey-Valueストアだけが必要な場合は、 テーブルストレージ や Redisキャッシュ など、そのために特別に設計されたものを使用してみませんか？

単にビルド番号を保存しようとしている場合は、静的なVERSIONファイルをプロジェクトとともにデプロイし（ソース管理によって追跡されない）、ビルド時にビルド番号を内部でインクリメントします。このファイルはwwwrootの外（およびd:\home\site\somethingElseの下）に保持して、次の展開でクリーンアップされないようにする必要があります。

継続的インテグレーションのためにソース管理をKuduに接続すると、現在/アクティブのコミットID（ロールバックしない場合は最新のビルドされたコミットも表します）を取得できます。 Kuduの/api/deploymentsを呼び出すことによる他のいくつかの興味深いこと：

httpはカールに似ていますが、異なります

$ http https://SiteUsername:[email protected]/api/deployments

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...

{
    "active": true,
    "author": "snobu",
    "deployer": "GitHub",
    "end_time": "2017-03-29T08:47:08.954981Z",
    "id": "5ada48724129c78b8a993b4a25f2144aec03cbd2",
    "message": "Changed bootstrap theme to Flatly",
    ...

そのAPIの詳細はこちら- https://github.com/projectkudu/kudu/wiki/REST-API#deployment

これは、人工的なビルド番号よりもはるかに意味があります。 サイトレベルの資格情報 をアプリケーション設定として安全に保存し、にシークレットをハードコーディングせずに/api/deploymentsURLを作成できます。

2
evilSnobu

Azure Portalを使用したアプリ設定の編集は、web.configファイルの編集と同じように機能します。その結果、これにより、WebアプリをホストしているIISアプリプールが再起動されます。これは、Azure AppServiceでもIIS =任意のWindowsServer上。

特定の設定を更新するときにアプリプールを再起動したくない場合は、それらを別の場所に保存する必要があります。単純なKey/Valueペアを保存する場合は、アプリとともにデプロイされたJSONまたはXMLファイルに保存するか、Azure StorageTablesやRedisCacheなどのKey/Valueストレージサービスを使用できます。キーと値のペアをアプリケーションデータベース内に保存することもできます。どこに保存する場合でも、何らかのキャッシュを実装して、アクセスするたびにストレージから値を読み取る必要がないようにする必要があります。

3
Chris Pietschmann

私が考えることができる別の解決策は、2つの展開スロットを持つことです、と言います：

  • 製造
  • プリプロダクション

プリプロダクションは、ダウンタイムをゼロにするための、プロダクションと同様の構成のスロットです。

したがって、ステップバイステップは次のとおりです。

  1. 実稼働前に新しい構成を追加する
  2. プリプロダクションが復活するのを待つ
  3. 100％のトラフィックを本番環境から本番環境前にルーティングする

本番環境で手順1と2を繰り返してから、トラフィックを本番環境に戻します。

0
user3579726