Ответ 1
Было несколько замечательных комментариев к этому вопросу, и я потратил некоторое время на изучение различных способов решения проблемы.
Начать с того, что я изначально просил, невозможно. Я имею в виду, если вы идете по пути модуля, то модуль должен физически присутствовать на целевой машине, чтобы можно было Import-Module
в удаленный сеанс.
Чтобы абстрагироваться от моего вопроса, я пытаюсь создать многократно используемую среду на основе PowerShell для развертываний продукта. Это будет принудительное развертывание, что означает, что мы рекомендуем людям запускать некоторые сценарии на локальном компьютере для развертывания на каком-либо удаленном сервере. Насколько я исследовал область, есть два возможных пути, которые являются дружественными для здравого смысла.
Модули подход
Процесс, которому нужно следовать:
- поместите каждый логически различный элемент функциональности в модуль PowerShell (
*.psm1
) - распространить модуль на удаленный компьютер и расширить переменную
PSModulePath
в нее местоположение новых модулей - на клиентском компьютере создайте новый сеанс на удаленном сервере и используйте
Invoke-Command -Session $s -ScriptBlock {...}
- в блоке скрипта запускайте из
Import-Module CustomModule
- он будет искатьCustomModule
на удаленной машине и, очевидно, найдет его
преимущества
Ниже приведены причины любить этот подход для:
- следствие традиционной роли модуля - облегчить создание многоразовых библиотек
- Согласно великой книге Windows PowerShell в действии, "модули могут использоваться для создания доменных приложений". Насколько я понимаю, это может быть достигнуто путем сочетания вложенности модулей и смешивания скриптовых/бинарных модулей для раскрытия интуитивно понятного интерфейса, характерного для определенного домена. По сути, это то, что я ценю больше всего для цели инфраструктуры развертывания на основе PowerShell.
Недостатки
Следующее важно принять во внимание:
- Вы должны найти способ доставки пользовательских модулей на удаленный компьютер. Я играл с NuGet, и я не уверен, что он подходит для этой задачи, но есть и другие варианты, например, установщик MSI или обычный
xcopy
из общей папки. Кроме того, механизм доставки должен поддерживать обновление/понижение и (предпочтительно) установку с несколькими экземплярами, но это больше связано с моей задачей, чем с проблемой в целом.
Скрипты подходят
Процесс, которому нужно следовать:
- поместите каждый логически различный фрагмент функциональности в отдельный скрипт PowerShell (*.ps1)
- на клиентском компьютере создайте новый сеанс на удаленном сервере и используйте
Invoke-Command -Session $s -FilePath.\myscript.ps1
для загрузки функций, определенных в сценарии, в удаленный сеанс - используйте другую
Invoke-Command -Session $s -ScriptBlock {...}
и обратитесь к своим пользовательским функциям - они будут присутствовать в сеансе
преимущества
Ниже приведены хорошие моменты этого подхода:
- это просто - вам не нужно знать об особенностях модуля. Просто напишите простые сценарии PowerShell и что это
- вам не нужно ничего доставлять на удаленную машину - это делает решение еще проще и менее подвержено ошибкам при обслуживании
Недостатки
Конечно, это не идеал:
- там меньше контроля над решением: например, если вы "импортируете" набор функций в сеанс, все они "импортированы" и видимы для пользователя, поэтому нет "инкапсуляции" и т.д. Я уверен, что многие решения может жить с этим, так что не решайте, основываясь только на этом
- функциональность каждого файла должна быть автономной - любой точечный источник или импорт модуля оттуда будет искать удаленную машину, а не локальную.
Наконец, я должен сказать, что удаленный компьютер все еще должен быть подготовлен к удаленному взаимодействию. Это то, что я имею в виду:
- Политика выполнения должна быть изменена на что-то, потому что она ограничена по умолчанию:
Set-ExecutionPolicy Unrestricted
- PowerShell remoting должен быть включен:
Enable-PSRemoting
- учетная запись, которую запускает скрипт, должна быть добавлена к локальным администраторам удаленного сервера
- если вы планируете получить доступ к общим файлам в удаленном сеансе, убедитесь, что вы знаете о многопользовательской аутентификации и предпримите соответствующие действия
- убедитесь, что ваш антивирус ваш друг и не отправляет вас в ад PowerShell