Adam the Automator

PowerShell-moduulien kanssa työskentely on tärkeä osa PowerShell-automaatiota. Kun aloitat PowerShellin opettelun, ensimmäiset askeleet ovat yleensä yksittäisten komentojen käyttöä. Tämä johtaa skriptien rakentamiseen, joka taas johtaa funktioiden rakentamiseen.

Funktioita käyttämällä voit tehdä skripteistäsi modulaarisempia. Näin voit käyttää samaa koodia monissa paikoissa kopioimatta ja liittämättä koodia kaikkialle. Käyttämällä funktioita voit käyttää vähemmän aikaa saman koodin muokkaamiseen kaikkialla, missä sitä käytetään. Sen sijaan voit työskennellä parantaaksesi koodia yhdessä paikassa.

Voidaksesi viedä funktiot seuraavalle tasolle, voit yhdistää nämä funktiot moduuleiksi.

Moduuli on kokoelma funktioita tekstitiedostossa, jolla on psm1-pääte. Mukana voi olla myös joitakin valinnaisia lisäyksiä, kuten moduulin manifesti ja kommenttipohjainen tai ulkoinen ohje. Näitä käsitellään myöhemmin.

Edellytykset

Käytän tässä artikkelissa Windows PowerShell 5.1:tä. Jos käytät vanhempaa versiota tai PowerShell Corea, näkemäsi tulokset voivat vaihdella.

Vuorovaikutus moduulien kanssa

Kun avaat PowerShell-istunnon ensimmäisen kerran, aluksi käytössäsi on kaksi moduulia. Ensimmäinen on Microsoft.PowerShell.Utility, joka sisältää monia jo käyttämiäsi PowerShellin perustoimintoja. Toinen moduuli on PSReadline. Näet nämä aloittavat moduulit komennolla Get-Module.

Tämä ei kuitenkaan ole täydellinen luettelo kaikista käytettävissä olevista moduuleista. PowerShell 3:sta lähtien asennetut moduulit tuodaan tarpeen mukaan. Jos käytössäsi on vanhempi PowerShell-versio, sinun on ensin tuotava moduuli Import-Module-komennolla ennen minkään komennon käyttämistä.

On tilanteita, joissa haluat käyttää Import-Module-komentoa myös uudemmissa versioissa. Jos haluaisit tuoda moduulin sen jälkeen, kun se on jo asennettu, voit käyttää komentoa Import-Module näin:

Vaikka Get-Module näyttää kaikki tuodut moduulit, et näe moduuleja, joita ei ole vielä tuotu. Voit sitten käyttää ListAvailable-parametria näyttääksesi kaikki muut käytettävissä olevat moduulit.

Kaikkia komentoja ei näytetä oletusarvoisesti

Ominaisuus ExportedCommands sisältää luettelon kaikista käytettävissä olevista komennoista, jotka viedään moduulista. Tämän luettelon ja moduulitiedostossa olevan luettelon välillä saattaa olla eroja. Viedyt komennot on moduulin manifestiin rakennettu ominaisuus, jonka avulla kirjoittaja voi jättää toiminnon piiloon. Moduulin kirjoittajat voivat käyttää myös Export-ModuleMember-komentoa, mutta se ei kuulu tämän artikkelin aihepiiriin.

Moduulin kirjoittajat voivat haluta pitää funktion piilossa, koska sen on tarkoitus tukea muita toimintoja, ei olla käyttäjälle näkyvä. Jotta funktio olisi piilotettu, tekijä jättää sen pois FunctionsToExport-joukosta manifestissa. Tässä näet laajennetun näkymän ExportedCommands-ominaisuudesta.

Moduulien tuonti

Moduulien käytön aloittamiseen on monia tapoja. Voit tuoda moduulin manuaalisesti käyttämällä moduulitiedostojen polkua. Näin voit testata ja päivittää moduulia ilman, että sinun tarvitsee tehdä paljon työtä. Tämä ei kuitenkaan mahdollista suurta siirrettävyyttä, koska sinun pitäisi käyttää tarkkaa polkua moduuliin. PowerShell ei myöskään tuo automaattisesti moduuleja, jotka eivät ole $env:PSModulePath-muuttujassa.

Komentojen valikoiva tuonti

Voit käyttää Import-Module-parametrin Function avulla tuoda vain tiettyjä toimintoja koko moduulin sijaan. Tämä voi säästää aikaa tuotaessa moduuleja etäjärjestelmistä, kuten Office 365 -moduuleja.

Kaikki käyttäjämoduulit

Moduulit, jotka on asennettu kaikille käyttäjille, sijoitetaan C:\Program Files\WindowsPowerShell\Modules. Tämä hakemisto sisältää monia valmiiksi lisättyjä moduuleja, mukaan lukien kaikki moduulit, jotka on asennettu Install-Module:n avulla käyttäen oletuslaajuutta AllUsers.

Nykyisen käyttäjän moduulit

Jos olet asentamassa moduulia, mutta haluat, että vain yksi käyttäjä käyttää sitä, on olemassa CurrentUser-laajuus. Tämä asettaa moduulitiedostot Documents-kansioon osoitteessa C:\Users\<käyttäjätunnus>\Documents\WindowsPowerShell\Modules. Tämä voi olla hyödyllistä ympäristössä, jossa käytät kansioiden uudelleenohjausta Documents-kansion kanssa.

Tällöin voit asentaa moduulin yhdelle tietokoneelle ja käyttää sitä toisella tietokoneella, koska molemmat jakavat saman Documents-kansion.

Järjestelmämoduulit

Täydellisyyden vuoksi moduulien hakemisto on myös osoitteessa C:\Windows\System32\WindowsPowerShell\1.0\Modules. Vaikka teknisesti tähän polkuun sijoitettu moduuli tuodaan kuten muutkin polut, sitä ei kuitenkaan suositella, koska se on varattu Microsoftin järjestelmämoduuleille.

Nimeäminen on tärkeää

Voit sijoittaa moduulisi manuaalisesti johonkin näistä poluista, jotta se olisi oletusarvoisesti käytettävissä uuden istunnon yhteydessä, mutta sinun on varmistettava, että noudatat moduuleille vaadittavaa nimeämistä. Kansiossa, johon moduulitiedostot sijoitetaan, on oltava sama nimi kuin psm1-moduulitiedostossa ja psd1-moduulin manifestissa, jos sellainen on olemassa.

Käyttämällä aiemmin mainitsemaamme nimeä Get-Module -ListAvailable viitataan näihin polkuihin. Näet kaikki moduulipolut käyttämällä $env:PSModulePath -Split ';'. Saatat huomata luettelossa muitakin polkuja kuin mitä tässä näytetään. Monet ohjelmat lisäävät omia moduulipolkujaan, kun ne asennetaan. Yksi esimerkki tästä on SQL, jolla on omat moduulinsa sisällytettynä omiin moduulipolkuihinsa.

On myös joitakin moduuleja, jotka asentaisit eri prosessilla. Yksi merkittävimmistä esimerkeistä tästä on ActiveDirectory-moduuli. Windows 7:stä aina Windows 10 1803:een asti asentaisit tämän RSAT-asennusohjelmalla (Remote Server Administration Tools).

Uudemmissa Windows 10 -versioissa (1809+) tämä on saatavilla vain Features On Demand -ohjelman kautta. RSAT:n asentaminen asentaa ActiveDirectory-moduulit ja monia muita moduuleja, joita käytät muiden Windows-roolien hallintaan. Windows-palvelinkäyttöjärjestelmissä nämä moduulit asennetaan Server Managerin kautta.

Etämoduulien tuominen (Implicit Remoting)

Tietyissä tapauksissa ei ole käytännöllistä pitää moduulia käynnissä paikallisesti. Sen sijaan on parempi muodostaa yhteys etälaitteeseen ja tuoda siihen asennettu moduuli. Kun näin tehdään, komennot todella suoritetaan etäkoneella. Tätä käytetään usein Microsoftin Office 365 -moduulien kanssa. Monet niistä muodostavat yhteyden Office 365 -palvelimeen, joka sitten tuo moduulin. Kun suoritat minkä tahansa komennon, se suoritetaan etäpalvelimella, ja sen jälkeen tulosteet lähetetään takaisin istuntoosi.

Toinen etämoduulien tuonnin käyttökohde on silloin, kun moduulia ei ole asennettu paikallisesti. Näin käy, jos sinulla ei ole asennettuna ActiveDirectory-moduulia, mutta yrität tuoda sen.

Tuoaksesi etämoduulin sinun on ensin luotava PSSession. Voit käyttää New-PSSession istunnon luomiseen. Sitten tuodaan etälaitteessa käytettävissä oleva moduuli käyttäen PSSession-parametrin kanssa Import-Module.

PS51> $AdminServer = New-PSSession -ComputerName $AdminServerName -Credential (Get-Credential)PS51> Import-Module -Name ActiveDirectory -PSSession $AdminServer -Prefix 'Rmt'

Tämän etämoduulien tuontitavan käyttäminen mahdollistaa koodin nopeamman suorittamisen hajautetussa ympäristössä. Jos esimerkiksi työskentelet tietokoneeltasi, mutta palvelimet, joiden parissa työskentelet, ovat toisella puolella Yhdysvaltoja, tiettyjen komentojen suorittaminen paikallisesti palvelimia vastaan voi kestää huomattavasti kauemmin. Kun taas komentojen suorittaminen palvelimella ja tulosteiden syöttäminen takaisin paikalliseen istuntoon on paljon nopeampaa.

Moduulin etuliitteen lisääminen

Voit myös lisätä etuliitteen etäkoneelta tuotuihin funktioihin. Tämä vaihtoehto on käytettävissä tuotaessa paikallisia moduuleja, mutta sitä käytetään harvoin muulloin kuin testattaessa moduulin eri versioita vierekkäin.

Jos suorittaisit yllä olevan import-komennon ja näkisit komentoja katsellessasi tämän:

Tässä tapauksessa voit käyttää etuliitettä osoittaaksesi, että kyseessä ei ole paikallinen moduuli. Tätä voidaan käyttää tapauksissa, joissa olet tuomassa moduulia, joka on saatavilla myös paikallisesti. Etuliitteen lisääminen vähentää sekaannusta siitä, missä koodia suoritetaan.

Moduulien poistaminen

Moduulin voi poistaa nykyisestä istunnosta myös ilman Remove-Module:n käyttöä. Tämä poistaa moduulin paikallisesta istunnosta poistamatta moduulitiedostoja. Tätä kannattaa ehkä käyttää tapauksessa, jossa käytit moduulia etäistunnossa. Voit käyttää Remove-Module:tä istunnon siivoamiseen ja katkaista sitten etäistunnon yhteyden.

Toinen Remove-Module:n käyttötapa on, jos olet tekemässä muutoksia moduuliin etkä halua käynnistää uutta PowerShell-istuntoa. Tällöin käytät Remove-Module ja sen jälkeen Import-Module ladataksesi sen uudelleen istuntoon. Vaihtoehtoisesti voit käyttää Force-parametria yhdessä Import-Module:n kanssa. Tämä suorittaa moduulin purkamisen ja uudelleenlataamisen puolestasi.

Mistä PowerShell-moduuli koostuu

Moduuli voi koostua yhdestä tai useammasta tiedostosta. Jotta moduulin vähimmäisvaatimukset täyttyisivät, sinulla on oltava moduulitiedosto. Tämä voi olla PSM1-tiedosto tai mikä tahansa muu moduulitiedosto, kuten binäärimoduulitiedosto. Jotta voisit rakentaa sen päälle, psm1-moduulissasi pitäisi olla määriteltyjä funktioita, tai siitä ei ole paljon hyötyä kenellekään.

Vaikka ei ole mitään vaatimuksia sille, miltä funktioiden pitäisi näyttää tai mitä niiden pitäisi tehdä, on olemassa joitakin ohjeita. Yleensä on suotavaa, että kaikki moduulin funktiot rakentuvat saman käsitteen ympärille.

Moduulit sisältävät samanhenkisiä funktioita

Esimerkiksi ActiveDirectory-moduuli sisältää vain funktioita, jotka ovat jollakin tavalla vuorovaikutuksessa Active Directoryyn. Yleensä funktioiden nimet sisältävät myös etuliitteen. Kun palataan takaisin ActiveDirectory-moduuliin esimerkkinä, kaikki funktioiden nimissä olevat substantiivit alkavat AD:llä.

Näiden ohjeiden käyttäminen auttaa funktioiden löydettävyyttä. Kuvittele, että olet juuri tuonut tämän uuden moduulin ja haluat selata funktioita. Tämä on paljon helpompaa, jos kaikilla funktioilla on samanlainen nimirakenne. Vaikka moduulit alkavat usein PS:llä, tämä etuliite on virallisesti varattu vain Microsoftin moduuleille. Et luultavasti aiheuta ongelmaa, jos käytät PS:ää moduulisi alussa, mutta saatat aiheuttaa ristiriidan jonkin toisen moduulin nimen kanssa.

Käytettäessä näitä ohjeita, jos sinulla olisi joukko funktioita, jotka kaikki liittyvät vuorovaikutukseen rekisterin kanssa, voisit saada aikaan jotain tällaista:

function Get-ATARegistryKey {...}function Set-ATARegistryKey {...}

Moduulien manifesteja

Tekstimuotoisen moduulitiedoston pohjaksi voit liittää mukaan moduulin manifestin. Näillä tiedostoilla on PSD1-pääte ja ne sisältävät moduulin metatietoja. Siihen sisällytetään tiedot moduulin kirjoittajasta, moduulin kuvauksesta, muista tarvittavista moduuleista ja monista muista attribuuteista. Julkaiseminen arkistoon edellyttää, että Author– ja Description-kentät on täytetty.

Tässä on esimerkki manifestista, joka meillä voi olla rekisterimoduulillemme:

#Module manifest for module 'ATARegistry'#Generated by: Tyler#Generated on: 8/11/2019@{#Script module or binary module file associated with this manifest.RootModule = 'ATARegistry'#Version number of this module.ModuleVersion = '1.0'#Supported PSEditions#CompatiblePSEditions = @()#ID used to uniquely identify this moduleGUID = 'fef619fa-016d-4b11-a09d-b222e094de3e'#Author of this moduleAuthor = 'Tyler Muir'#Company or vendor of this moduleCompanyName = 'Adam the Automator'#Copyright statement for this moduleCopyright = '(c) 2019 tyler. All rights reserved.'#Description of the functionality provided by this moduleDescription = 'This is a test module.'#Minimum version of the Windows PowerShell engine required by this module#PowerShellVersion = ''#Name of the Windows PowerShell host required by this module#PowerShellHostName = ''#Minimum version of the Windows PowerShell host required by this module#PowerShellHostVersion = ''#Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.#DotNetFrameworkVersion = ''#Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.#CLRVersion = ''#Processor architecture (None, X86, Amd64) required by this module#ProcessorArchitecture = ''#Modules that must be imported into the global environment prior to importing this module#RequiredModules = @()#Assemblies that must be loaded prior to importing this module#RequiredAssemblies = @()#Script files (.ps1) that are run in the caller's environment prior to importing this module.#ScriptsToProcess = @()#Type files (.ps1xml) to be loaded when importing this module#TypesToProcess = @()#Format files (.ps1xml) to be loaded when importing this module#FormatsToProcess = @()#Modules to import as nested modules of the module specified in RootModule/ModuleToProcess#NestedModules = @()#Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export.FunctionsToExport = @('Get-RegistryKey','Set-RegistryKey')#Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export.CmdletsToExport = @()#Variables to export from this moduleVariablesToExport = '*'#Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export.AliasesToExport = @()#DSC resources to export from this module#DscResourcesToExport = @()#List of all modules packaged with this module#ModuleList = @()#List of all files packaged with this module#FileList = @()#Private data to pass to the module specified in RootModule/ModuleToProcess. This may also contain a PSData hashtable with additional module metadata used by PowerShell.PrivateData = @{PSData = @{#Tags applied to this module. These help with module discovery in online galleries.#Tags = @()#A URL to the license for this module.#LicenseUri = ''#A URL to the main website for this project.#ProjectUri = ''#A URL to an icon representing this module.#IconUri = ''#ReleaseNotes of this module#ReleaseNotes = ''} #End of PSData hashtable} #End of PrivateData hashtable#HelpInfo URI of this module#HelpInfoURI = ''#Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.#DefaultCommandPrefix = ''}

Vaikka tämä saattaa aluksi näyttää pelottavalta, Microsoftilla on kätevä cmdlet, jota voit käyttää moduulimanifestin luomiseen. Mukana oleva komento on New-ModuleManifest. Yllä esitetyn manifestin luomiseen voisi käyttää:

PS51> New-ModuleManifest -Path .\Scripts\TestModule.psd1 -Author 'Tyler Muir' -CompanyName 'Adam the Automator' -RootModule 'TestModule.psm1' -FunctionsToExport @('Get-RegistryKey','Set-RegistryKey') -Description 'This is a test module.'

Ulkoiset ohjetiedostot

Joissain moduuleissa saattaa olla myös ulkoisia ohjetiedostoja. Ne voisi tunnistaa tiedoston nimen lopussa olevasta <Moduulin nimi>-Help.xml-merkinnästä. Nämä ulkoiset ohjetiedostot sisältävät samat tiedot, jotka normaalisti sisältyvät komentopohjaiseen ohjeeseen, jonka saatat löytää funktion määritelmästä.

Tällöin sinun on myös lisättävä # .ExternalHelp <ModulePath>-Help.xml funktioon, jotta se toimisi oikein, kun käytät Get-Help-komentoa moduulin tuonnin jälkeen. Ulkoisia ohjetiedostoja näkee yleensä vain hyvin suurissa moduuleissa, ja sen takia ne ovat soveltamisalan ulkopuolella.

Vaikka nämä ovat yleisimpiä moduulissa esiintyviä tiedostotyyppejä, ne eivät ole ainoita tiedostoja. Joskus näet tekstimoduulin lisäksi myös binääritiedostoja, koska moduulissa on muita riippuvuuksia. Tutustumalla moduulin polkuihin löydät monia esimerkkejä moduuleissa olevista ylimääräisistä tiedostotyypeistä.

Jotta ei-standardimoduulitiedostot julkaistaisiin kunnolla, sisällyttäisit moduulin manifestin FileList-parametrissa muita tiedostoja.

Moduulin manifestissa huomaat monia muita parametreja, jotka ovat tällä hetkellä tyhjiä. Voit käyttää näitä määrittelemään muita vaatimuksia moduulisi käytölle. Voit esimerkiksi määritellä PowerShell-versiot, joiden kanssa moduuli voi toimia. Jos yrität tuoda moduulin tukemattomalla PowerShell-versiolla, näet seuraavaa:

PSRepositories

Yksi moduulien tärkeimmistä jakeluvaihtoehdoista on PSRepository. 1000′ näkymässä PSRepository on paikallinen, jossa useat ihmiset tai useat laitteet voivat käyttää moduulitiedostoja. Nämä ovat usein verkkopalvelimia, joissa voit julkaista tiedostoja.

Voit käyttää arkistona myös hakemistoa, mutta tämä rajoittaa arkiston toiminnallisuutta. Voit isännöidä PSRepositorya itse, tai voit hyödyntää yhtä monista internetissä saatavilla olevista vaihtoehdoista, kuten PowerShell Gallerya. Näet PSRepositoriesi käyttämällä komentoa Get-PSRepository.

Oletusarvoisesti sinulla on vain yksi merkintä ja se on PowerShell Gallery. Saatat huomata, että siinä lukee untrusted. Tämä johtuu siitä, että PowerShell tekee sinut tietoiseksi siitä, että käyttämällä PowerShell Gallerya saatat käyttää koodia, jota Microsoft ei ole kirjoittanut ja hyväksynyt. Tämä tarkoittaa, että ennen kuin siitä asennetaan mitään moduuleja, sinun on annettava siihen nimenomainen lupa.

PSRepositorien lisääminen

Voit myös lisätä omia repositorioita. Jos haluat luottaa PowerShell Galleriaan, voit suorittaa Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted tai hyväksyä varoituksen, kun asennat moduulin ensimmäistä kertaa PowerShell Galleriasta.

Kaikki komennot, joilla voit olla vuorovaikutuksessa näiden PSRepositorien kanssa, löytyvät PowerShellGet-moduulista. Toiminnot näet täältä:

PowerShellGet-moduuli on ehkä päivitettävä, ennen kuin voi olla vuorovaikutuksessa tiettyjen repositorioiden kanssa.

Moduulien etsiminen

Toinen keskeinen ominaisuus PSRepositoryn käytössä on moduulien etsiminen. Tämä onnistuu komennolla Find-Module. On olemassa useita tapoja suodattaa, jotta löydät nimenomaan etsimäsi, mutta toistaiseksi voit etsiä VMware-moduuleja näin:

Tällöin näytetään kaikki moduulit, jotka alkavat kirjaimella VMware. Vaikka useimmat näistä ovat VMwarelta, sinun on katsottava tekijä-attribuutista, kuka moduulin on julkaissut.

Sen vuoksi, että kuka tahansa voi ladata PowerShell Galleryyn, moduuleja on saatavilla tuhansia. Tämä tarkoittaa, että saatat löytää moduuleja, jotka eivät toimi kunnolla käyttötapauksessasi. Monet löytämäsi moduulit ovat avoimen lähdekoodin moduuleja, joten voit osallistua niiden kehittämiseen moduulin toiminnallisuuden parantamiseksi.

Moduulien asentaminen

Komennon Install-Module käyttäminen edellyttää luotettavaa PSRepositorya, joka isännöi moduulia. Tämä voi olla PowerShell Gallery, toinen internetin PSRepository tai itse isännöity sivusto. Voit piiputtaa Find-Module-komennon, jotta voit helposti vahvistaa moduulin ennen sen asentamista.

Moduulin version voi määritellä myös MinimumVersion-, MaximumVersion– tai RequiredVersion-parametreilla.

Käyttämällä komentoa

muuttujaa

voidaan nähdä kaikki moduulit, jotka on asennettu komennolla Install-Module. Tämä listaa kaikki moduulit, jotka on asennettu AllUsers-alueelle tai CurrentUser-alueellesi.

Moduulien poistaminen

Aivan kuten voit asentaa moduulin, voit myös poistaa moduulin. Jos moduulia ei ole asennettu Install-Module-komennolla, et voi poistaa sitä Uninstall-Module-komennolla.

Kuten näet tässä, yritämme poistaa ActiveDirectory-moduulin. Koska tätä moduulia ei ole asennettu Install-Module:llä, saat virheilmoituksen, kun yrität käyttää Uninstall-Module:aa. Jotta voisit poistaa tämän moduulin, meidän olisi poistettava se päinvastoin kuin mitä käytit moduulin asentamiseen.

Moduulin onnistuneen poistamisen näet poistamalla aiemmin asennetun VMware.PowerCLI-moduulin.

Vaikka poistitkin VMware.PowerCLI:n asennuksen, näet, että monia riippuvuuksia on edelleen asennettuna. Jos haluaisit poistaa kaikki moduulit, voisimme käyttää Get-InstalledModule VMware.* | Uninstall-Module -Force.

Syy siihen, että sinulla olisi tällaisia vaikeuksia poistaa tämä moduuli kokonaan, on se, että sillä on niin paljon riippuvuuksia. Tämän lisäksi jotkin näistä moduuleista ovat toistensa riippuvuuksia, minkä vuoksi Force-parametria tarvittaisiin.

Moduulien päivittäminen

Nyt kun tiedät, miten moduuli asennetaan ja poistetaan, ihmettelet ehkä, miten päivität asentamasi moduulin.

Aivan kuten muitakin prosesseja, jos moduulia ei ole asennettu Install-Module:n avulla, et voi päivittää sitä PowerShellin komennoilla. Voit käyttää Update-Module:tä päivittääksesi moduulin uusimpaan julkaisuun tai uudempaan tiettyyn versioon.

Moduuliin on myös kytkentä AllowPreRelease, jonka avulla voit päivittää versioon, jota ei ole virallisesti julkaistu. Joskus tämä voi olla avuksi, koska siinä on ehkä korjattu havaitsemasi virhe tai lisätty uusi ominaisuus, jota haluaisit käyttää.

Moduulin tarkastaminen/tallentaminen

Yksi paljon harvemmin käytetyistä komennoista, joka on erittäin hyödyllinen moduulien tarkastamisessa ennen käyttöä, on Save-Module. Tällä komennolla voit ladata moduulin polkuun asentamatta sitä.

Voit sitten tarkastaa tiedostot, ja jos moduuli ei ole binäärimoduuli, voit avata ja tarkastella moduulin muodostavaa koodia. Tämä voi olla hyvä keino paitsi varmistaa, ettei moduuli tee mitään haitallista, myös oppia, miten muut rakentavat moduulinsa.

Tässä esimerkissä ladataan VMware.PowerCLI-moduulin lisäksi myös kaikki sen riippuvuudet. Tässä näkyy, mitä VMware.PowerCLI-kansiossa näkyy:

Tämä on hyvä esimerkki siitä, että joskus moduuliin sisältyy myös muita kuin vakiomuotoisia moduulitiedostoja, kuten loppukäyttäjän lisenssisopimus.

Oman moduulin kirjoittaminen

Olet nyt nähnyt, miten vuorovaikutuksessa ollaan jonkun toisen moduulin kanssa. Nyt haluat oppia luomaan oman moduulisi, jotta voit alkaa optimoida koodisi skaalautuvuutta varten.

Mallitiedostojen luominen

Ensin sinun on luotava kansio kaikille moduulitiedostoille. Kun sinulla on säiliö, sinun on luotava moduulitiedostosi. Sinun on varmistettava, että moduulitiedostollasi on sama nimi kuin kansiollasi tai muuten, kun yrität julkaista moduulisi, PowerShell ei löydä moduulia oikein.

PS51> New-Item -Path .\Scripts -Name ATARegistry -ItemType DirectoryPS51> New-Item -Path .\Scripts\ATARegistry -Name ATARegistry.psm1

Ja nyt haluat käyttää myös manifestia, sinun on myös nimettävä se samalla nimellä kuin säiliö ja moduulitiedosto.

PS51> New-ModuleManifest -Path .\Scripts\ATARegistry\ATARegistry.psd1 -Author 'Tyler Muir' -CompanyName 'Adam the Automator' -RootModule ATARegistry.psm1 -Description 'Used for interacting with registry keys'

Säiliön, moduulitiedoston ja manifestitiedoston avulla sinulla on täysin toimiva moduuli. Voit julkaista tämän moduulin PSRepositoryyn ja alkaa asentaa sitä minne haluat. Tosin koska moduulitiedosto on tyhjä, siitä ei luultavasti ole paljon hyötyä. Voit silti käyttää näitä tiedostoja julkaisemisen testaamiseen varmistaaksesi, että arkistosi toimii.

PSRepositoryn rekisteröinti

Ennen kuin voit julkaista moduulisi, sinun on lisättävä toinen PSRepository istuntoosi. Testausta varten voit käyttää paikallista polkua PSRepositorynäsi, koska se on helppo perustaa ja purkaa.

Normaalisti, jos aiot perustaa PSRepositoryn hakemiston avulla, haluat varmistaa, että useat tietokoneet voivat käyttää sitä. Voit luoda paikallisen arkiston näin:

PS51> New-Item -Path C:\ -Name Repo -ItemType DirectoryPS51> Register-PSRepository -Name 'LocalRepo' -SourceLocation 'C:\Repo' -PublishLocation 'C:\Repo' -InstallationPolicy Trusted

Jos olisit vain lataamassa PSRepositorysta, etkä koskaan julkaisemassa, voisit jättää PublishLocation-parametrin pois.

Moduulin julkaiseminen

Koska olet jo asettanut asennuskäytännöksi trusted (luotettu), et saa vahvistusta moduulin asentamisen sallimisesta repositorysta. Nyt kun sinulla on uusi PSRepository käytettävissä, voit julkaista moduulisi käyttämällä Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.

Moduulisi julkaisemisen jälkeen voit käyttää edellä mainittuja komentoja moduulin etsimiseen ja asentamiseen.

Moduulin asentamisen jälkeen voit käyttää komentoa Get-Module nähdäksesi moduulin tuodun paikalliseen istuntoosi. Koska et lisännyt funktioita FunctionsToExport-matriisiin manifestissa, ExportedCommands-ominaisuus on tyhjä.

Moduulin lisääminen

Nyt kun tiedät, että voit julkaista ja asentaa moduulisi, voit ryhtyä lisäämään siihen toimintoja. Voisit lisätä toiminnon palauttamaan rekisteriavaimen niin, että se näyttää tältä:

function Get-ATARegistryKey { param ( $Path ) Get-Item $Path}

Jos jättäisit manifestin sellaisenaan ja yrittäisit ladata uuden moduulisi, törmäisit kahteen ongelmaan. Ensimmäinen on, että saisit virheilmoituksen, jonka mukaan moduulisi versio on jo olemassa arkistossasi. Tämä johtuu siitä, että et ole muuttanut moduulin versiota manifestitiedostossa.

Moduulin funktioiden vienti

Toinen ongelma olisi se, että moduulin tuonnin jälkeen et näkisi vieläkään mitään funktioita ExportedCommands-ominaisuudessa, koska et ole lisännyt uutta funktiotasi manifestiin.

Vaikka funktiotasi pystyisit käyttämään ilman, että sitä listattaisiin FunctionsToExport-luetteloon, se tekisi sen paikantamisesta paljon vaikeampaa.

Korjataksesi nämä kaksi ongelmaa voit päivittää moduulitiedostosi näin:

ModuleVersion = '1.1'FunctionsToExport = 'Get-RegistryKey'

Nyt kun olet lisännyt toiminnon moduuliin ja päivittänyt manifestin vastaamaan näitä muutoksia, voit julkaista moduulisi uuden version samalla komennolla kuin ennenkin.

PS51> Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.

Moduulin päivittäminen

Viimeisenä askeleena sinun pitäisi päivittää moduulisi istuntosi moduulitiedostoon, jotta se pystyy käyttämään päivitettyjä tiedostoja. Käyttämällä Update-Module ATARegistry lataat juuri julkaisemasi päivityksen arkistoon.

Nyt näet, että sinulla on moduulin uusi versio ja näet manifestissa määrittelemäsi toiminnon.

Ohjesisällön rakentaminen

Yksi aiemmin läpikäydyiksi vaihtoehdoiksi nousi PowerShellin sisäänrakennettu ohjekäyttöjärjestelmä. Olet todennäköisesti jossain vaiheessa käyttänyt Get-Help funktiossa. Nämä tiedot voidaan lisätä kahdella ensisijaisella tavalla.

Ensimmäinen on lisätä kommenttipohjainen ohje funktion määritelmään. Tämä on yleensä tapa, jonka monet moduulin kirjoittajat toteuttavat. Toinen tapa on käyttää ulkoista ohjetiedostoa. Parametrin Full avulla voit näyttää kaiken, mitä ohjeella on tarjottavana.

Kuten huomaat, tietoa ei todellakaan ole paljoa, ja siitä vähäisestä tiedosta, jonka saat, ei todennäköisesti olisi apua kenellekään.

Voit lisätä moduulitiedostoosi kommenttipohjaisen ohjeen, jolla voit täyttää nämä kentät ohjejärjestelmässä. Voit lukea kaikista kommenttipohjaisen ohjeen vaihtoehdoista käyttämällä Get-Help about_Comment_Based_Help.

Jatkossa voit päivittää funktiosi alla olevan kaltaiseksi. Tämä on luettelo yleisimmin käytetyistä apuparametreista, mutta kaikki nämä ovat edelleen valinnaisia, ja niiden tilalle voi lisätä muitakin.

Nyt funktiosi näyttää tältä:

 function Get-RegistryKey {<# .SYNOPSIS Returns registry key using provided path. .DESCRIPTION The function uses the Get-Item command to return the information for a provided registry key. .PARAMETER Path The path that will be searched for a registry key. .EXAMPLE Get-RegistryKey -Path 'HKLM:\HARDWARE\DESCRIPTION\System' .INPUTS System.String .OUTPUTS Microsoft.Win32.RegistryKey .NOTES This module is an example of what a well documented function could look. .LINKhttps://adamtheautomator.com#>param($Path)Get-Item $Path}

On joitakin erityisiä apuparametreja, kuten .FORWARDHELPTARGETNAME. Tämä vaihtoehto ohjaa kaikki saapuvat apupyynnöt toiseen komentoon. Tätä voitaisiin käyttää tapauksessa, jossa ohjeen pitäisi näyttää samat tiedot useille komennoille.

Nyt kun olet lisännyt ohjeen, voit päivittää version moduulin manifestiin, julkaista uuden version ja päivittää asennetun version istuntoosi, kuten teit aiemmin.

Jos katsot nyt toiminnon ohjetta, huomaat, että siinä on paljon enemmän tietoa saatavilla. Tämä on hyvä tapa sisällyttää dokumentaatio siitä, miten funktioita käytetään, erityisesti sellaisille, joilla on vähemmän kokemusta ja jotka eivät ehkä pysty nopeasti ymmärtämään, mitä moduuli tekee katsomalla koodia.

Ulkoisen ohjetiedoston tapauksessa lisättävät tiedot ovat samat, mutta tiedot sijoitetaan erilliseen tiedostoon, joka on linkitetty funktioon.

Jos katsot AllUsersmoduulin polkua, näet moduulin version ja kaikki asentamasi moduulitiedostot.

Jos palaat takaisin PSRepository-polkuun C:\Repo, jonka olet luonut aiemmin, voit nähdä joukon NUPKG-tiedostoja. Niitä on yksi kutakin julkaistua versiota kohden. Nämä ovat pakattuja versioita siitä, mitä julkaisit, kun käytit Publish-Module.

Yhteenveto

Kun hallitset PowerShell-konsolin, PowerShellin kielenä ja skriptien kirjoittamisen, omien moduulien rakentaminen on viimeinen vaihe. Moduulien avulla voit alkaa kehittää hyödyllisiä työkaluja PowerShellissä. Jos moduulit suunnitellaan ja rakennetaan oikein luomalla niitä yhteen tarkoitukseen, huomaat väistämättä kirjoittavasi ajan mittaan yhä vähemmän koodia. Alat viitata moduulifunktioihisi useammassa koodissa ja rakentaa siitä eteenpäin.

Moduulifunktioiden avulla voit abstrahoida pois koodin, jota toistat skripteissä. Ne edustavat ”tarroja”, joihin voit viitata myöhemmin koodissa ja joita voit kutsua milloin tahansa sen sijaan, että keksisit pyörän uudelleen ja yrittäisit selvittää, miten olit jo aiemmin saavuttanut tavoitteesi. Moduulit ovat PowerShell-koodin lopullinen ”pakkaus”, joka ryhmittelee samanhenkistä koodia, jotta aikaa ei tuhlattaisi jo ratkaistuihin ongelmiin.