Способ интеграции сценариев Powershell с рабочим процессом, отличным от Windows?

16

Я люблю запах новых машин по утрам.

Я автоматизирую рабочий процесс создания машины, который включает несколько отдельных систем в моей инфраструктуре, некоторые из которых включают 15-летние сценарии perl на хостах Solaris, системы PXE Booting Linux и Powershell на Windows Server 2008.

Я могу написать сценарий для каждой отдельной части, и интеграция автоматизации Linux и Unix довольно проста, но я не знаю, как надежно связать сценарии Powershell с остальными процессами.

Я бы предпочел, чтобы процесс начался на хосте Linux, так как я представляю, что он в конечном итоге станет веб-приложением, работающим на сервере Apache, но если он должен начаться в Windows, я не решаюсь с этим.

В идеале мне бы хотелось, чтобы что-то вроде psexec для Linux работало против Windows, но ответ в этом направлении, похоже, на Cygwin , и, насколько я ценю всю тяжелую работу, которую они вложили, это никогда не казалось правильным , если вы понимаете, о чем я. Это отлично подходит для настольных компьютеров и дает много функциональных возможностей, но я чувствую, что серверы Windows должны рассматриваться как серверы Windows, а не как подконтрольные Unix-машины (что, кстати, является и моим аргументом против серверов OSX, и на самом деле они Unix) , Во всяком случае, я не хочу идти с Cygwin, если это не последний и единственный вариант.

Поэтому я думаю, что я спрашиваю, есть ли способ выполнять задания на компьютерах с Windows из Linux. Без Cygwin. Я открыт для идей и предложений, в том числе «Смотри, идиот, все используют Cygwin, так что смирись с этим и разберись с ним». Заранее спасибо!

Мэтт Симмонс
источник

Ответы:

5

Я потратил часы на решение этой самой проблемы, и в итоге дело дошло до двух жизнеспособных вариантов (существует множество нежизнеспособных вариантов):

  1. Создайте коробку Windows со службой IIS, на которой размещен WebAPI, который и создан, и настроен таким образом, чтобы сессия WinRM из него работала.
  2. Cygwin

Со вторым вариантом вы застряли, пробираясь сквозь слой абстракции GNU / Posix, чтобы получить реальные биты окон. Что ограничивает то, что вы можете сделать с этим.

Первый вариант в значительной степени создает веб-слой абстракции, который вы пишете самостоятельно поверх полной установки Windows из собственного стека. Если вы готовы приступить к работе, мастер-сервер Linux должен сделать только несколько вызовов curl, чтобы выполнить то, что нужно. Это работает лучше всего, когда скрипты запускаются и забываются, так как создание системы обратного вызова требует гораздо больших усилий.

sysadmin1138
источник
Я боялся этого первого варианта :-) Там большой акульный аквариум, полный проблем, просто ждущий, чтобы укусить меня, если я тоже сделаю это неправильно. Аутентификация, анализ ошибок, общая безопасность приложения ... и т. Д. И т. Д. И т. Д. Но спасибо за ввод. Я рад, что я не единственный человек, который был одержим этим.
Мэтт Симмонс
2
@MattSimmons Я сделал нечто подобное на $ Job-1. IIS IP ограничения делают многое из этого легче; если вызовы API могут поступать только с одного хоста, это значительно уменьшает поверхность атаки.
sysadmin1138
Я не использовал его, но из того, что я прочитал, WinRM может работать самостоятельно (без IIS или специального API). Используйте ограниченную маршрутизацию и аутентификацию Kerberos, и это звучит (ЗВУКИ), как будто это может быть довольно безопасно. Мысли?
смеющийся
@laughingbovine Проблема всегда заключалась в поддержке WinRM. Предлагаемый мною метод IIS позволяет использовать PowerShell с REST API, который поддерживается практически всем. Поддержка WinRM едва поддерживается в нескольких местах. За почти три года с тех пор, как я написал это, эта поддержка, вероятно, улучшилась по сравнению с несуществующим состоянием, которое было в 2012 году.
sysadmin1138
3

Вы также можете приобрести кроссплатформенное программное обеспечение для планирования или автоматизации рабочих процессов, которое может запускать собственные сценарии на многих хостах в зависимости от предыдущих действий или даже их возвращенных результатов. Крупные предприятия используют программное обеспечение, такое как Tivoli, UC4, Espresso (CA dSeries, сейчас), которое делает это, и я использовал его на крупных предприятиях, которым нужно было делать подобные вещи. К вашему сведению, они часто имеют встроенную поддержку таких вещей, как задания Oracle, чтобы дать вам представление о ценнике, на который вы могли бы обратить внимание.

(В моей прошлой работе они в любом случае также использовали Cygwin , чтобы они могли использовать те же сценарии Perl без изменений, когда рабочие нагрузки перемещались между платформами. Очень весело.)

Вы также можете попробовать создать свой собственный, как подсказывает @ sysadmin1138; это был бы забавный проект, и он мог бы даже оказаться достаточно надежным, чтобы его можно было использовать, и он не доставит вас в 2 часа ночи, когда финансовый экспорт потерпит неудачу с первой попытки.

mfinni
источник
1
К счастью, я больше не передаю финансовые данные :-) Это автоматизация для колледжа. Гораздо ниже фактор складки.
Мэтт Симмонс
3

Я бы использовал функцию веб-доступа Powershell, представленную в Powershell v3.0. Это позволяет вам использовать скрипты Powershell с хоста Linux.

Рой Калдунг
источник
2

Сервер PowerShell позволяет подключаться по SSH к серверу Windows и получать консоль PowerShell. Я не использовал его помимо бесплатной пробной версии, но мое неформальное использование доказало, что это довольно надежный продукт.

длинная шея
источник
Во-вторых, их цена такова, что они предназначены для использования на сервере развертывания, а не на «развертывании всего, что требует удаленного управления». Работоспособна, просто модель отличается от Linux.
sysadmin1138
2

Как сильно вы хотите чувствовать себя потом, потому что всегда есть telnet :)

Если серьезно, зачем вам сервер Linux для вызова скрипта PowerShell? Можете ли вы изменить дизайн своего рабочего процесса, чтобы сервер Linux просто доставлял правильный образ boot.wim через tftp на загрузочный хост PXE? В прошлом мне повезло: я держал образ Windows с разными файлами ответов на файловом сервере Windows и предоставлял собственный загрузочный образ WinPE с помощью tftpd с хоста Linux. Затем вы можете заставить файл ответов вызывать правильный сценарий PowerShell, и вам не придется иметь дело с кроссплатформенным хулиганством, таким как Cygwin.

MDMarra
источник
О, если бы это было так просто. Я не шутил о 15-летней части Perl. Я был здесь в течение 3 месяцев, и я не знаю, как все «соединения» еще «работают», но я знаю, что они многочисленны и разнообразны, с тонкостью, которая приводит людей, которые были здесь годами, к полному игнорировать документированные функции в существующих инструментах, разработанных собственными силами, потому что никто не уверен, отлажены ли они / когда / как. Это волосатое тело Это будет многолетний проект, чтобы все это исправить.
Мэтт Симмонс
@MattSimmons Полагаю, я не до конца понимаю требования :-) Почему серверу Linux нужно вызывать скрипт PowerShell? В прошлом я обходил это требование, сохраняя информацию о машинной подготовке в базе данных (которая может обновляться сервером * nix), а затем WinPE запрашивает эту базу данных при определении, какой файл ответов применить. Конечно, нечто подобное можно адаптировать практически к любой среде, верно? Это в основном просто восстановление MDT с нуля, хе-хе
MDMarra
Есть вещи, которые (в некоторых случаях) должны происходить на стороне Windows всякий раз, когда запускается скрипт новой машины. Я мог бы начать все со стороны Windows, но мне нужно было бы создать новый сервер веб-приложений для интерфейса интерфейса, когда придет время, и мне гораздо удобнее делать это с PHP на Linux, чем с C # (или чем-то еще) в Windows , Но, как я уже сказал, если мне нужно, я должен.
Мэтт Симмонс
2

Вы можете использовать что-то вроде nrpe для удаленного выполнения сценария powershell на хосте Windows. Возможно, вы захотите изменить свои скрипты powershell, чтобы они возвращали коды завершения, как ожидается от nrpe, но нет никаких причин, по которым вы не можете вызвать check_nrpe из ваших скриптов на вашем хосте linux.

rorr
источник
1
Это восхитительно нелогично. Мне это нравится. Это серьезный взлом, но все же, креатив! Благодарю.
Мэтт Симмонс
2

Что касается контринтуитивных взломов , рассматривали ли вы злоупотребление программным обеспечением Continuous Integration в качестве кросс-платформенного инструмента оркестровки?

Установите мастер CI там, где вам удобнее, установите агент на свой компьютер с Windows (или этот, или этот ), настройте задание для выполнения сценария powershell (либо непосредственно вызывая его с помощью конфигурации Windows Batch Command, либо, если хотите , с помощью плагина). написать / сохранить свой сценарий в приложении CI) на агенте Windows и запускать задание удаленно с помощью curl или подобного.

Грег Ворк
источник
0

Я работаю на крупном предприятии, где эта проблема встречается часто. Для процессов, которые мы в настоящее время поддерживаем, наш подход заключается в том, чтобы системы Unix выполняли веб-вызовы на «административном» сервере Windows, на котором запущен ColdFusion на IIS. У нас есть классы и функции, которые запускаются из GET-запросов, которые используют директиву cfexecute для запуска определенных скриптов powershell. Это некрасиво, но это работает. Мы смотрим на возможности веб-службы powershell v3, чтобы отказаться от использования ColdFusion в качестве посредника.

Райан Фишер
источник