Как использовать модули PowerShell и PowerShell на предприятии - PullRequest
Новая
       10

Как использовать модули PowerShell и PowerShell на предприятии

8 голосов
/ 17 марта 2011

Недавно я присоединился к команде Windows на своем предприятии и, имея опыт работы с разработчиками (Java, .NET и Web в целом), довольно быстро заинтересовался PowerShell. Я вижу его значение по сравнению с простыми старыми пакетными файлами, VB, ... вот почему я хотел бы продвигать его использование и постепенно подталкивать людей отдавать предпочтение его остальным, если нет причин не делать этого.

Развертывание PowerShell кажется довольно простым, поскольку мы можем легко утвердить соответствующие исправления в WSUS и настроить политику выполнения через GPO для интегрированных серверов AD.

На самом деле мои вопросы касаются распространения и использования модулей PowerShell и PowerShell (например, PCSX, PowerShellPack, home made, ...).

Для тех из вас, кто уже развернул PowerShell на своем предприятии:

  1. Есть ли у вас какой-то стандартный пакет для PowerShell с набором модулей, которые вы развертываете на каждом сервере? Если да, то как развернуть новые версии установленных модулей?

  2. Вы разместили центральный репозиторий PowerShell, где хранятся все ваши модули PowerShell? Если да, доступен ли этот репозиторий глобально или вы также вторичные репозитории, которые вы синхронизируете?

    Я довольно привык к таким инструментам, как Maven, Ivy и другим программам управления зависимостями, поэтому я немного разочарован тем, что PowerShell может предложить в этом отношении.

    Я нашел очень хорошую статью на эту тему и, вероятно, пойдет по тому же пути, что и соответствует моим требованиям.

  3. Вы используете WinRM? Вы подключаетесь напрямую с рабочих станций или у вас есть центральные серверы управления? Вы ограничивали доступ к WinRM для этих серверов управления?

  4. Используете ли вы WinRM в неуправляемой среде (серверы не в домене AD)? Как вы настраиваете WinRM?

    У нас есть сетевая зона, в которой серверы не являются частью домена AD, поэтому я не могу полагаться на аутентификацию Kerberos для WinRM.

  5. Во всем мире, каков ваш опыт, довольны ли вы результатами?

Edit: Что касается вопроса 2, мы решили создать центральное хранилище.

Идея будет состоять в том, чтобы иметь основной репозиторий, который будет находиться под контролем версий (GIT) и к которому мы будем единственными, кто будет иметь доступ для записи.

Из этого репозитория мы будем копировать модули, используя rsync-подобный инструмент (в нашем случае это будет robocopy), в другие вторичные репозитории (которые будут только для чтения). Клиентам будут доступны только эти репозитории (нам просто нужно обновить PSModulePath на этих клиентах, чтобы они могли получить доступ к репозиторию).

Мы также подготовим наши выпуски, поэтому в репозитории будет доступно несколько версий: Разработка, Интеграция и Производство.

1 Ответ

9 голосов
/ 17 марта 2011

Давайте рассмотрим каждый вопрос по категориям.

Евангелизация

Чтобы заинтересовать PowerShell для ваших коллег, я бы предложил начать с хлеба с масломавтоматизации.Найдите общую болевую точку, которую относительно легко реализовать (чтобы быстро что-то выложить перед коллегами), и автоматизируйте ее с помощью PowerShell.Затем развернитесь оттуда.

Еще одна хорошая идея - открыть «Клуб сценариев» в своем офисе, где вы проводите обучение и делитесь идеями или проблемами в области сценариев в PowerShell.Вы можете начать с одного раза в несколько недель и посмотреть, как это происходит.На моей работе у нас есть книжный клуб, где мы проходим различные технические книги по тестированию, дизайну и программированию, это хорошо работает.

Упаковка

  • Модули - Модули PowerShell - лучшая форма упаковки.Они довольно просты в использовании и предлагают некоторые приятные функции, такие как простое развертывание и частные переменные / функции.
  • Сценарии - Сценарии - хорошая идея для незавершенного производства или для началапоскольку вашим коллегам наверняка будут удобны сценарии.

Развертывание

В настоящее время существует несколько вариантов развертывания.

  • Развертывание на каждой машине - Это может избежать некоторых проблем с сетью и дает вам больше гибкости на каждой машине, но недостатком является то, что обновление модулей может быть более болезненным.
  • Centralрепозиторий (он же сетевой ресурс) - вы также можете хранить все свои модули в общем сетевом ресурсе.Это позволит избежать проблем с развертыванием на каждой машине, и вы можете сделать модули доступными только для чтения, если хотите контролировать изменения.Но вам все равно придется развернуть профиль на каждой машине, чтобы добавить сетевой ресурс в переменную $ env: PSModulePath .Было бы лучше установить это в профиле all-users-all-hosts.С этого момента вам не нужно обновлять его, пока путь не изменится.
  • NuGet - NuGet - проект с открытым исходным кодом, который переносит управление пакетами в .NETразвитие.Что приятно, так это возможность иметь публичные репозитории и локальные / частные репозитории.Уже существует начальная версия модуля PowerShell , которая будет использовать NuGet для развертывания модуля PowerShell.

Удаленный доступ

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

...