Domanda Perché dovrei scegliere Powershell su WMI per sviluppare interfacce di gestione?


Stiamo discutendo dello sviluppo di un'infrastruttura di gestione migliorata per il nostro sistema distribuito. Usiamo COM, servizi Web e componenti .NET. Dato che siamo basati su Microsoft Windows Server XP / 2003, immagino, abbiamo fondamentalmente due opzioni:

  1. Cmdlet di PowerShell
  2. Classi WMI che utilizzano System.Management e provider WMI per codice nativo (classe, istanza, metodo, evento)

Perché dovremmo scegliere Powershell su WMI?


11
2017-11-03 15:40


origine


risposte:


Vorrei scegliere PowerShell su WMI per i seguenti motivi:

  1. La scrittura di un cmdlet sta solo aggiungendo una classe .NET.
  2. Il runtime di PowerShell fornisce l'analisi della riga di comando integrata.
  3. La scrittura dell'interfaccia di gestione in PowerShell consente agli amministratori di integrare la gestione della propria applicazione con quella di altre applicazioni e servizi (come Exchange, Active Directory o SQL Server).
  4. L'ambiente PowerShell rende disponibile la pipeline agli amministratori, consentendo di eseguire le attività di gestione per l'applicazione in modo più efficiente.
  5. Discoverability. PowerShell, tramite Get-Command, Get-Member e Get-Help, fornisce un ambiente estremamente rilevabile in cui gli amministratori possono lavorare, determinando una curva di apprendimento più breve per il mantenimento dell'applicazione.

Anche se si esegue la route WMI, PowerShell ha il supporto per lavorare con WMI (anche se ci sono alcuni problemi).

Per me, PowerShell è il modo migliore per far emergere a compito orientato interfaccia a un'applicazione. Con il supporto fornito da Microsoft PowerShell, è e sarà un'interfaccia coerente per la gestione di applicazioni e servizi in tutta l'azienda.

Il mio lavoro diurno è come un amministratore e sto spingendo tutti i fornitori con cui lavoro per far emergere un'API di gestione di PowerShell, poiché questo rende molto più bassa la curva di apprendimento e il cambio di contesto per la gestione delle applicazioni. Sul lato dello sviluppo, ho scritto (e sto ancora lavorando) una serie di cmdlet di PowerShell per un prodotto open source con cui lavoro e sto lavorando su un altro set per un'applicazione separata.


10
2017-11-03 19:16



Jeffrey Snover risponde al "perché PowerShell" Qui. Il post è nel contesto di SQL, ma molto applicabile qui.


4
2017-11-03 19:35



Non sono sicuro di prendere una decisione. Non è esattamente neanche l'uno o ... puoi scegliere di fare entrambe le cose.

WMI può essere consumato da una serie di cose diverse, non solo da PowerShell. Perché non scrivere la tua strumentazione di gestione in PowerShell e quindi racchiudere tale WMI in alcuni cmdlet orientati alle attività per semplificare le cose sugli amministratori? Questo è ciò che alcuni team di prodotto MS scelgono di fare, specialmente quando hanno altri consumatori di WMI che vogliono continuare a supportare.

Se hai già ottenuto il codice .NET adatto, trasformarlo in un cmdlet potrebbe essere più veloce che trasformarlo in un provider WMI. Se è così, e la velocità è una preoccupazione, vai con ciò che è più facile. Ma qualunque cosa tu faccia, puoi sempre racchiuderlo in un cmdlet di PowerShell per gli amministratori, che è sicuramente l'approccio consigliato.


2
2017-11-24 21:54



Non sono sicuro che questo possa essere risolto con le informazioni che hai fornito finora. Il mio istinto sarebbe che dovresti usare PowerShell poiché sembra che tu possa già avere un codice .Net. Ma dipende solo esattamente da quello che stai cercando di fare.


0
2017-11-03 17:04