Параметризация параметров PowerShell в запланированных задачах

У меня есть несколько скриптов 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)

Таким образом, в запланированном задании у меня есть только один аргумент для передачи (путь к файлу конфигурации). Кажется, это работает, но я хотел спросить, есть ли лучший и более разумный способ достижения моих целей. Есть ли что-то глупое в этом подходе, которого я не вижу?

Источник

1 ответ

То, что вы делаете, имеет смысл; никому не нужно возиться со сценарием (который может вызвать проблемы с кодом) или с запланированной задачей (которая может потребовать, чтобы они знали учетные данные учетной записи "запускать как", а также особенно незнакомым).

Передача пути к файлу конфигурации в качестве параметра также имеет смысл; таким образом, вы можете легко использовать свой скрипт с различными конфигурациями; поэтому вы не ограничены одним "набором параметров" в любой момент времени, но можете иметь набор параметров (файл конфигурации) для каждой запланированной задачи.

Возможная проблема

Ваш 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\, Знают ли администраторы для этого / знают, какие символы нужно экранировать для формата файла конфигурации? Если у вас есть (универсальный) инструмент для редактирования таких файлов, который избавит вас от боли, которая избавит вас от некоторых проблем; в противном случае см. пункт выше о проверке.

  • Безопасность. Надежно ли защищены папки, содержащие ваши скрипты и файлы конфигурации; в противном случае люди могут манипулировать вашим кодом, чтобы делать то, что им нравится, пока он выполняется под учетной записью "запуск от имени". Если люди, редактирующие конфигурацию, отличаются от этих сценариев редактирования, вероятно, лучше хранить их в отдельных каталогах, чтобы ограничить возможности каждого человека.

Большинство из этих вещей все еще будут соображениями, если передать параметры; так что ваш путь определенно является шагом вперед, независимо от вышеизложенных соображений; но если вы хотите сделать что-то по-настоящему дружелюбное и надежное, учтите вышеперечисленные моменты.

Источник
Другие вопросы по тегам