У меня есть несколько сценариев 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'"
Итак, теперь я хочу, чтобы каждый сценарий содержал только один редактируемый файл конфигурации, в котором администраторы могли изменять параметры. Я мог бы также упростить организацию параметров - иметь "глобальный" файл конфигурации параметров, который используют все сценарии, а затем файлы конфигурации для конкретных сценариев.
Я думал, что буду использовать 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)
Таким образом, в запланированной задаче мне нужно передать только один аргумент (путь к файлу конфигурации). Кажется, это работает, но я хотел спросить, есть ли лучший и более разумный способ достичь моих целей. Есть ли что-то глупое в этом подходе, которого я не вижу?
То, что вы делаете, имеет смысл; никому не нужно возиться со сценарием (что может вызвать проблемы с кодом) или с запланированной задачей (для чего может потребоваться, чтобы они знали учетные данные «запускать от имени», а также неудобно, особенно для тех, кто не знаком).
Также имеет смысл передать путь к файлу конфигурации в качестве параметра; таким образом вы можете легко повторно использовать свой скрипт с различными конфигурациями; поэтому вы не ограничены одним «набором параметров» в любой момент времени, но можете иметь набор параметров (файл конфигурации) для каждой запланированной задачи.
Возможная проблема
Ваш JSON включает тип данных; например"folder1": ["string","C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"]. Зачем? Вы все равно определите типы в своем файле PS (при необходимости); в вашей конфигурации вы просто хотите хранить данные, не требуя, чтобы ваши администраторы знали, что «строка» означает «текст» /, не задумываясь об этом. т.е. просто иметь "folder1": "C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\".
Есть некоторые дополнительные соображения:
JSON против XML против INI против Database по сравнению с другими. С какими типами файлов / технологий ваши администраторы знакомы больше всего / чем им легче всего манипулировать? Лично я бы использовал для этого XML; PS так же комфортно с ним, но преимущество в том, что ваши администраторы могут открыть его в браузере и сразу увидеть, действителен ли он XML или нет (т.е. если они пропустили закрывающий тег / что-то неправильно написали). Тем не менее, это во многом зависит от способностей / предпочтений / инструментов вашей команды.
Проверка. Что произойдет, если кто-то введет неверные данные или испортит формат файла (например, пропустит скобку) или повредит файл (например, сохранит в ANSI вместо UTF8 и т.д.)? Убедитесь, что в вашем сценарии есть что-то для решения этой проблемы; а также подумайте, как вы узнаете; то есть, а также «не запускать, если в конфигурации есть проблемы», вы хотите «сообщить о проблеме, чтобы я мог исследовать и исправить ее, если в конфигурации есть проблемы».
Персонаж убегает. В приведенном выше примере вам нужно было избежать пути к файлу: C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\ вместо того C:\sldks\dsf\sdf\sdf\sd\fsdf\. Знают ли администраторы, как это сделать / какие символы нужно избегать для формата файла конфигурации? Если у вас есть (общий) инструмент для редактирования таких файлов, который избавит вас от некоторых проблем; в противном случае см. пункт выше о валидации.
Безопасность. Надежно ли защищены папки, содержащие ваши сценарии и файлы конфигурации; в противном случае люди могут манипулировать вашим кодом, чтобы делать то, что им нравится, при выполнении задачи под учетной записью «Запуск от имени». Если люди, редактирующие конфигурацию, отличаются от тех, кто редактирует скрипты, лучше всего хранить их в отдельных каталогах, чтобы ограничить возможности каждого человека.
Большинство из этих вещей все равно нужно учитывать при передаче параметров; так что ваш путь определенно будет шагом вперед, независимо от вышеупомянутых соображений; но если вы хотите создать что-то действительно дружелюбное и надежное, вам поможет учет вышеперечисленных пунктов.