スケジュールされたタスクを介してさまざまな時間に開始されるPowerShellスクリプトがたくさんあります。
スクリプトは、異なる引数を使用して複数回実行されます。また、スクリプトに慣れていない管理者は、コードを編集せずにパラメーターを変更できる必要がありました。
この要件のため、スケジュールされたタスクのpowershell.exeに引数を介してパラメーターを渡しました。しかし、これはすぐに扱いにくくなりました。スクリプトのパラメーターを変更するには、タスクスケジューラに移動し、次のようになっているpowershell.exeの引数を編集する必要があるためです(実際にはさらに長くなります)。
-command "& 'C:\some\file\path\' -param1 'C:\some\file\path\' -param2 'C:\soawme\fawdile\pawawasth\' -param3 'C:\some\fisdfle\pasdfth\' -param4 'some arg'"
だから今私がしたいのは、各スクリプトに、管理者がパラメーターを変更できる1つの編集可能な構成ファイルを取り込むことです。また、パラメーターをより簡単に整理することもできます。すべてのスクリプトが使用する「グローバル」パラメーター構成ファイルと、スクリプト固有の構成ファイルを用意します。
構成ファイルで [〜#〜] json [〜#〜] を使用すると思い、次のようなことを考えていました。
{
"folder1": [
"string",
"C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"
],
"folder2": [
"string",
"C:\\jiji\\sfef\\igig\\igg\\"
],
"CSSFile": [
"string",
"\\\\some\\netqwork\\path\\"
],
"DBServer": [
"string",
"myserver"
],
"DB": [
"string",
"DB"
],
"SqlQuery": [
"string",
"SELECT * FROM myTable"
],
"UID": [
"string",
"root"
],
"PWD": [
"string",
"123456"
]
}
$jsonObject = ConvertFrom-Json (cat $PathToMyExternalJsonFilePassedInFromTaskShedualer)
function Set-ParamType ($jsonNode) {
switch ($jsonNode[0])
{
'string' {return [string]$jsonNode[1]}
'int' {return [int]$jsonNode[1]}
'switch' {return [switch]$jsonNode[1]}
default {"Debug: Unknown type"}
}
}
$folder1 = Set-ParamType($jsonObject.folder1)
$folder2 = Set-ParamType($jsonObject.folder2)
$CSSFile = Set-ParamType($jsonObject.CSSFile)
$DBServer = Set-ParamType($jsonObject.DBServer)
$DB = Set-ParamType($jsonObject.DB)
$SqlQuery = Set-ParamType($jsonObject.SqlQuery)
$UID = Set-ParamType($jsonObject.UID)
$PWD = Set-ParamType($jsonObject.PWD)
このように、スケジュールされたタスクでは、渡す引数は1つだけです(構成ファイルのパス)。これはうまくいくようですが、目標を達成するためのより良い、より賢明な方法があるかどうかを尋ねたかったのです。私が見ていないこのアプローチについて何か愚かなことはありますか?
あなたがしていることは理にかなっています。スクリプト(コードの問題が発生する可能性があります)やスケジュールされたタスク(「実行者」アカウントの資格情報を知っている必要がある場合があり、特に慣れていない人にとっては面倒です)をいじる必要はありません。
構成ファイルのパスをパラメーターとして渡すことも理にかなっています。そうすれば、さまざまな構成でスクリプトを簡単に再利用できます。したがって、一度に1つの「パラメーターのセット」に制限されることはありませんが、スケジュールされたタスクごとにパラメーターのセット(構成ファイル)を持つことができます。
考えられる問題
JSONにはデータ型が含まれています。例えば。"folder1": ["string","C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"]
。どうして?とにかく(必要に応じて)PSファイルでタイプを定義します。設定では、管理者が「文字列」が「テキスト」を意味することを知っている必要なしに、データを保持したいだけです。つまり、"folder1": "C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"
。
いくつかの追加の考慮事項があります:
JSON
vs XML
vs INI
vs Database
vsその他。管理者が最もよく知っているファイル/テクノロジーの種類/操作が最も簡単なものは何ですか?個人的には、これにはXMLを使用します。 PSも同様に快適ですが、管理者がブラウザで開いて、有効なXMLであるかどうかをすぐに確認できるという利点があります(つまり、終了タグを見逃したり、スペルを間違えたりした場合)。とはいえ、これはチームの能力/好み/ツールに大きく依存します。
検証。誰かが不正なデータを入力したり、ファイル形式を破損したり(たとえば、角かっこを見逃したり)、ファイルを破損した場合(たとえば、UTF8などではなくANSIに保存した場合)はどうなりますか?スクリプトにこれを処理するものがあることを確認してください。また、どのようにして見つけるかについても検討してください。つまり、「構成に問題がある場合は実行しない」だけでなく、「問題を報告して、構成に問題がある場合に調査して修正できるようにする」必要があります。
文字エスケープ。上記の例では、ファイルパスをエスケープする必要がありました:C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\
の代わりに C:\sldks\dsf\sdf\sdf\sd\fsdf\
。管理者はこれを行うことを知っていますか/設定ファイルの形式でエスケープする文字を知っていますか?あなたがそのようなファイルを編集するための(一般的な)ツールを持っていて、これから苦痛を取り除くなら、それはあなたにいくつかの懸念を救うでしょう。それ以外の場合は、検証に関する上記のポイントを参照してください。
セキュリティ。スクリプトと構成ファイルを含むフォルダーは適切に保護されていますか。そうしないと、タスクの「実行」アカウントで実行しているときに、コードを操作して好きなことを実行できます。構成を編集する人がそれらの編集スクリプトと異なる場合は、各人が実行できることを制限するために、それらを別々のディレクトリに保持するのが最善の方法です。
これらのことのほとんどは、パラメーターを渡す場合でも考慮事項になります。したがって、上記の考慮事項に関係なく、あなたのやり方は間違いなくステップアップです。しかし、本当にフレンドリーで堅牢なものを作りたい場合は、上記の点を考慮に入れると役立ちます。