8

バッチ ファイルに多数のスタートアップ タスクがあります。特に、IIS を呼び出して IISappcmd.exeを構成します。Azure のスタートアップ タスクは、何らかの理由でロールが再起動された場合に備えて、べき等 (つまり、同じ結果で繰り返し実行できる) であると想定されています。残念ながら、IIS 構成コマンドの多くは 2 回目に失敗します。たとえば、構成ノードが最初に削除され、その後の実行では存在しないためです。

私の質問は、これらのスタートアップ タスクを冪等にするにはどうすればよいかということです。appcmd.exe がエラーをスローしないようにする方法はありますか? シェルにエラーをキャッチさせる方法はありますか? Azure フレームワークにエラーを無視させる方法はありますか?

これが私のスタートアップタスクの例です。これはすべて、コマンド ファイルconfigiis.cmd.

@REM Enable IIS compression for application/json MIME type
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost

@REM Set IIS to automatically start AppPools
%windir%\system32\inetsrv\appcmd.exe set config -section:applicationPools -applicationPoolDefaults.startMode:AlwaysRunning /commit:apphost

@REM Set IIS to not shut down idle AppPools
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00 /commit:apphost

@REM But don't automatically start the AppPools that we don't use, and do shut them down when idle
%windir%\system32\inetsrv\appcmd.exe set config  -section:system.applicationHost/applicationPools "/[name='Classic .NET AppPool'].startMode:OnDemand" "/[name='Classic .NET AppPool'].autoStart:False" "/[name='Classic .NET AppPool'].processModel.idleTimeout:00:01:00" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe set config  -section:system.applicationHost/applicationPools "/[name='ASP.NET v4.0'].startMode:OnDemand" "/[name='ASP.NET v4.0'].autoStart:False" "/[name='ASP.NET v4.0'].processModel.idleTimeout:00:01:00" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe set config  -section:system.applicationHost/applicationPools "/[name='ASP.NET v4.0 Classic'].startMode:OnDemand" "/[name='ASP.NET v4.0 Classic'].autoStart:False" "/[name='ASP.NET v4.0 Classic'].processModel.idleTimeout:00:01:00" /commit:apphost


@REM remove IIS response headers
%windir%\system32\inetsrv\appcmd.exe set config /section:httpProtocol /-customHeaders.[name='X-Powered-By']
4

5 に答える 5

4

@ Syntaxc4の答えは別として：パンくずリスト（ファイル）をローカルで使用することを検討してください。スクリプトで、(作成した) 既知のファイルの存在を確認します。存在しない場合は、起動スクリプトを調べて、ブレッドクラム ファイルも作成します。次に vm が起動すると、ブレッドクラム ファイルの存在が再度チェックされ、存在する場合は cmd ファイルが終了します。ブレッドクラム ファイルが表示されない場合、これは通常、VM が別の場所で再構成されたことを意味し (新しいインスタンスまたは再生成されたインスタンスが別のハードウェア上にある可能性があります)、IIS 構成が必要になります。

于 2012-08-04T19:07:02.023 に答える
3

構成設定を削除する前に、構成設定が存在するかどうかを確認する必要があります (条件付きロジックを追加します)。これは、次の方法で実現できます。

「appcmd.exe リスト構成 - 詳細」

戻り値を取得すると、出力の長さであれ実際の値であれ、比較対象が得られます。

于 2012-08-04T18:10:02.437 に答える
3

MSDN には、APPCMD からのエラー コードを処理することでこれを行うための優れたガイドが含まれるようになりました。

http://msdn.microsoft.com/en-us/library/windowsazure/hh974418.aspx

基本的に、appcmd 操作の後、次の操作を実行できます。

IF %ERRORLEVEL% EQU 183 DO VERIFY > NUL

許容可能なエラー コードはすべて無視します。

于 2012-10-17T00:11:00.977 に答える
2

David Makogon の提案に基づいて、各 .cmd ファイルの先頭に以下を追加しました。これはトリックを行うようです。これは、実行中のスクリプトと同じディレクトリにフラグ ファイル (David がブレッドクラム ファイルと呼んだもの) を作成し、その後の実行でそれをチェックします。

@REM A file to flag that this script has already run
@REM because if we run it twice, it errors out and prevents the Azure role from starting properly
@REM %~n0 expands to the name of the currently executing file, without the extension
SET FLAGFILE=c:\%~n0-flag.txt

IF EXIST "%FLAGFILE%" (
  ECHO %FLAGFILE% exists, exiting startup script
  exit /B
) ELSE (
  date /t > %FLAGFILE%
)
于 2012-08-06T17:39:35.667 に答える
0

/config:* /xmlコマンドの最後にを使用することを強くお勧めしますlist。iis を冪等にする方法の詳細については、https ://github.com/opscode-cookbooks/iis を参照してください。

Chef は複数の構成管理プラットフォームの 1 つであり、現在の設定を一覧表示し、変更が要求されている設定と比較することでべき等を行うコード (Ruby で) を確認することをお勧めします。

于 2015-03-27T17:29:03.580 に答える