PowerShell ワークフロー アクティビティでは、InlineScript を使用してネイティブ PowerShell スクリプトを呼び出すことができます。
workflow test
{
InlineScript
{
.\script.ps1
}
}
しかし、Azure Automation では、ドット パス (少なくとも私のテストでは) が返さc:\windows\system32れ、Azure Automation の script-as-runbook はそこに存在しませんでした (または、スクリプトが見つからなかったため、実行に失敗しました)。
- このように AAuto に保存されているネイティブ PS ランブックを実行することは可能ですか?
- その場合、ファイルへのパスを指定するにはどうすればよいですか?
- これは、Azure Automation のワークフロー Runbook と InlineScript アクティビティの解析/コンパイル プロセスのバグ/見落としであり、依存する Runbook がワーカーにコピーされませんか?
少し調べてみたところ、ネイティブの PS Runbook が実行されると、次のことがわかりました。
- 最初に、他の Runbook 参照がないか検査されます。
- 実行のためのワーカーへのデプロイの一環として、ランダムな名前のフォルダーが下に作成されます。
C:\Temp\ - 参照された Runbook は、最終的にこのフォルダーにコピーされます。
- Runbook が参照されていない場合、それらは一時ディレクトリにコピーされません。
- ルート Runbook がフォルダーにコピーされていないようです。
- ワークフロー runbook の実行時に、動的に名前が付けられたフォルダーは (c:\Temp の下に) 作成されません。
- 標準のワークフロー コンパイルの一部として、InlineScript アクティビティの内容が自動生成された xaml にコピーされます。ランタイムの問題と思われる動作に基づいていますが、リンクされたファイルについてはわかりません。私の推測では、ワークフローが実行されるたびにコンパイルが行われ (したがって、開始が遅れます)、ワーカーで行われ、ローカルと同じように標準の PS ワークフロー コンパイルが使用されます。
このスクリプトを (簡単に) ワークフローに変換することはできず、他のワークフロー アクティビティ内から使用されます。現在、この「機能」を実現できる唯一の方法は、スクリプトをコピーして、それを必要とするワークフロー内の最初の InlineScript に貼り付けることです。これは、メンテナンスの観点から明らかに退屈で面倒です。
おそらく、回避策として、Hybrid Worker を使用できますが、それには、子 Runbook がそこに公開されていることを確認し、それらを個別に維持する必要がある、または AAuto が Automation アカウントからカスタム モジュールを自動的にプッシュしないなど、他の多くの問題が伴います。労働者（これは計画されていますが）など。