8

最近、社内の Windows チームに参加し、開発者としてのバックグラウンド (Java、.NET、Web 全般) を持っていたため、すぐに PowerShell に興味を持ちました。単純な古いバッチ ファイルや VB よりも価値があることがわかります。そのため、私はその使用を促進し、そうしない理由がない限り、少しずつ他のものよりも優先するよう人々に働きかけたいと考えています。

WSUS で関連するパッチを簡単に承認し、AD 統合サーバーの GPO を介して実行ポリシーを構成できるため、PowerShell の展開は非常に簡単に思えます。

実際、私の質問は、PowerShell および PowerShell モジュール (例: PCSX、PowerShellPack、自家製など) の配布と使用に関するものです。

社内に PowerShell を既に展開している場合:

  1. 各サーバーに展開する一連のモジュールを含む PowerShell 用の標準パッケージはありますか? その場合、インストールされたモジュールの新しいバージョンをどのようにデプロイしますか?

  2. すべての PowerShell モジュールを格納する中央の PowerShell リポジトリを配置しましたか? もしそうなら、そのリポジトリはグローバルにアクセスできますか、それとも同期するセカンダリ リポジトリもありますか?

    私は Maven、Ivy、およびその他の依存関係管理ソフトウェアなどのツールにかなり慣れているため、この点で PowerShell が提供するものには少しがっかりしています。

    このテーマについて非常に優れた記事を見つけました。私の要件に対応しているため、おそらく同じ道をたどることになるでしょう。

  3. WinRM を使用していますか? ワークステーションから直接接続していますか、それとも中央管理サーバーを持っていますか? WinRM へのアクセスをそれらの管理サーバーに制限しましたか?

  4. 管理されていない環境 (AD ドメインにないサーバー) で WinRM を使用していますか? WinRM をどのように構成しますか?

    サーバーが AD ドメインの一部ではないネットワーク ゾーンがあるため、WinRM の Kerberos 認証に頼ることはできません。

  5. 全体的に、あなたの経験は何ですか、結果に満足していますか?

編集: 質問 2 に関しては、中央リポジトリを配置することにしました。

アイデアは、バージョン管理 (GIT) の下にあり、私たちだけが書き込みアクセスできるメイン リポジトリを持つことです。

そのリポジトリから、rsync のようなツール (この場合は robocopy) を使用してモジュールを他のセカンダリ リポジトリ (読み取り専用コピー) にコピーします。クライアントがアクセスできるのは、これらのリポジトリのみです (これらのクライアントで PSModulePath を更新して、リポジトリにアクセスできることを確認する必要があります)。

また、リリースを段階的に行うため、リポジトリには、開発、統合、および運用の複数のバージョンが利用可能になります。

4

1 に答える 1

9

各号をカテゴリー別に取り上げましょう。

伝道

同僚にPowerShellへの関心を持たせるために、自動化の基本から始めることをお勧めします。実装が比較的簡単な（同僚の前に何かをすばやく表示するための）一般的な問題点を見つけて、PowerShellで自動化します。次に、そこから展開します。

もう1つの良いアイデアは、オフィスで「スクリプトクラブ」を開始し、そこでトレーニングを行って、PowerShellでのスクリプトに関するアイデアや問題を共有することです。あなたは数週間に一度から始めて、それがどうなるかを見ることができます。私の仕事では、テスト、設計、プログラミングに関するさまざまな技術書を読むブッククラブがあり、うまく機能しています。

包装

  • モジュール-PowerShellモジュールはパッケージ化の最良の形式です。それらは非常に使いやすく、簡単な展開やプライベート変数/関数などのいくつかの優れた機能を提供します。
  • スクリプト-同僚は確かにスクリプトに慣れているので、スクリプトは進行中の作業や最初から始めるのに適しています。

展開

現在、展開するためのいくつかのオプションがあります。

  • すべてのマシンにデプロイする-これにより、ネットワークの問題を回避し、各マシンの柔軟性を高めることができますが、欠点は、モジュールの更新がより面倒になる可能性があることです。
  • 中央リポジトリ（別名ネットワーク共有）-すべてのモジュールを中央ネットワーク共有に保存することもできます。これにより、すべてのマシンへのデプロイに関する問題が回避され、変更を制御する場合は、モジュールを読み取り専用にすることができます。ただし、ネットワーク共有を$ env：PSModulePath変数に追加するには、各マシンにプロファイルを展開する必要があります。これは、all-users-all-hostsプロファイルで設定するのが最適です。それ以降は、パスが変更されない限り、更新する必要はありません。
  • NuGet - NuGetは、パッケージ管理を.NET開発にもたらすオープンソースプロジェクトです。それの良いところは、パブリックリポジトリとローカル/プライベートリポジトリを持つ機能です。PowerShellモジュールの展開にNuGetを活用 するPowerShellモジュールの初期バージョンがすでにあります。

リモートアクセス

ビルドエンジニアである私は、マシンが比較的少なく、それらを完全に制御できます。だから私はリモーティングを有効にしました。IT担当者にもっと良いアドバイスを求める必要があります。

于 2011-03-17T16:50:44.457 に答える