0

Add-Type を使用してカスタム C# コードを追加するワークフロー Runbook をテストしています。

突然、新しい PSSession が作成されていないかのように、後続のテスト ジョブで「type already exists」エラーが発生し始めました。

つまり、新しいジョブが同じ実行コンテキストを共有しているように見えます。これは、PS インスタンスごとに同じコマンドを 2 回実行しようとした場合にのみ、ローカルで取得されます。

問題の型は、いくつかの拡張メソッドを持つ静的クラスです。ソースブロックで宣言された最初の型でもあるため、他の非静的型も同様にエラーをスローすることは間違いありません。

私はこれを数回実行したので、「最終的に」これが起こらなくなることを完全に期待していますが、強制することはできないようです。また、この状況に陥るために何ができたのかわかりません、 また。

このようなジョブ間で実行コンテキストが共有されている証拠を見ると (特に?) 一時的なものであっても - 変更を加えて展開し、その後のテストを実行するときに過去に見た一般的な実行の不一致の一部またはすべてがすぐに実行されるのではないかと思います。以降はこれに関連します。

これは単なるテスト ジョブと「実際の」ジョブの違いの一部であると考えたくなりますが、テスト ジョブ自体の WRT がパブリッシュ ジョブを模倣することの有効性について疑問が生じます。

すべての Azure Automation ジョブは分離して実行する必要がありますか? これは開発者によって制御/悪用される可能性がありますか?

4

1 に答える 1

1

各 Automation アカウントには、そのジョブが実行される独自の分離されたサンドボックスがあります。これらのサンドボックスは、多数のワーカー マシンに分散されています。テスト ジョブの場合、[コードを変更して再テスト] が何度も繰り返されるため、ジョブの開始時間を改善しようとします。サンドボックスがまだクリーンアップされていない場合、オートメーションは、このランブックの以前のテスト ジョブで使用されたのと同じサンドボックスを再利用します。これにより、一意のテスト ジョブごとにサンドボックスをスピンアップする必要がなくなります (サンドボックスの作成は、ジョブの開始時間が必要以上に長くなる 1 つの理由です)。この動作により、同じ Runbook のテスト ジョブを短時間で実行すると、上記の動作が得られます。

ただし、運用ジョブの場合でも、同じ Automation アカウントのジョブ (Runbook 全体) は同じサンドボックスを共有できます。ワーカー マシン間でジョブをランダムに分散するため、可能なジョブ A が実行のためにキューに入れられ、ワーカー W に配置されます。5 分後、ジョブ B が実行のためにキューに入れられ、ワーカー W にも配置されます。ジョブ A とジョブ B が同じオートメーション アカウントであり、モジュール/モジュール バージョンに関して同じ "要求" がある場合、ジョブ A のサンドボックスがまだ存在する場合、それらは同じサンドボックスに配置されます。「モジュール/モジュール バージョンの要求」は、Runbook で使用されるモジュールを意味するものではなく、

特定の問題を解決するという点では、Add-Type を try、catch ステートメントで囲むか、使用することができます。Add-Type -IgnoreWarnings

于 2016-03-01T19:37:13.830 に答える