Az Automator

A PowerShell modulokkal való munka a PowerShell automatizálás fontos része. Amikor elkezdjük tanulni a PowerShellt, az első lépések általában az egyes parancsok használatával történnek. Ez szkriptek készítéséhez vezet, amelyek aztán függvények készítéséhez vezetnek.

A függvények használatával modulárisabbá teheti szkriptjeit. Ez lehetővé teszi, hogy ugyanazt a kódot sok helyen használhassa anélkül, hogy a kódot mindenhova másolná és beillesztené. A függvények használatával kevesebb időt tölthet azzal, hogy ugyanazt a kódot mindenhol ugyanazzal a szerkesztéssel módosítja. Ehelyett egyetlen helyen dolgozhat a kódja jobbá tételén.

A függvények magasabb szintre emeléséhez ezeket a függvényeket modulban egyesítheti.

A modul függvények gyűjteménye egy psm1 kiterjesztésű szövegfájlban. Van néhány opcionális kiegészítés, mint például a modul manifeszt és a komment alapú vagy külső súgó, amely szintén tartalmazhat. Ezekről később lesz szó.

Előfeltételek

Ez a cikk a Windows PowerShell 5.1-et használja. Ha régebbi verziót vagy a PowerShell Core-t használja, a látott eredményeket illetően eltérhet a mérföldköze.

A modulokkal való interakció

A PowerShell munkamenet első megnyitásakor két modullal indul. Az első a Microsoft.PowerShell.Utility, amely számos olyan alapvető PowerShell-funkciót tartalmaz, amelyet már használ. A másik modul a PSReadline. Ezeket a kezdőmodulokat a Get-Module paranccsal láthatja.

Azt mondjuk, hogy ez nem egy teljes lista az összes elérhető modulról. A PowerShell 3 óta a telepített modulok szükség szerint importálódnak. Ha a PowerShell egy régebbi verzióját használja, akkor a Import-Module paranccsal először importálnia kell a modult, mielőtt bármelyik parancsot használná.

Vannak olyan esetek, amikor még a későbbi verziókban is érdemes használni a Import-Module parancsot. Ha egy modult a már telepített modul után szeretnénk importálni, akkor a Import-Module parancsot a következőképpen használhatjuk:

Míg a Get-Module megmutatja az összes importált modult, addig a még nem importált modulokat nem látjuk. Ekkor a ListAvailable paraméterrel megjelenítheti az összes többi elérhető modult.

Nem minden parancs jelenik meg alapértelmezés szerint

A ExportedCommands tulajdonság tartalmazza a modulból exportált összes elérhető parancs listáját. Előfordulhat, hogy eltérés van e lista és a modulfájlban található lista között. Az exportált parancsok a modul manifesztjébe épített funkció, amely lehetővé teszi az író számára, hogy egy funkciót rejtve hagyjon. A modulírók használhatják a Export-ModuleMember cmdletet is, de ez nem tartozik ennek a cikknek a tárgykörébe.

A modulíróknak lehet, hogy azért kell elrejteniük egy funkciót, mert az más funkciók támogatására szolgál, nem pedig a felhasználó számára. Ahhoz, hogy egy függvényt elrejtsenek, a szerzőnek ki kell zárnia azt a FunctionsToExport tömbből a manifesztben. Itt látható a ExportedCommands tulajdonság kibővített nézete.

Modulok importálása

A modulok használatának megkezdéséhez számos lehetőség van. Kézzel importálhatja a modult a modulfájlok elérési útvonalának segítségével. Ez lehetővé teszi, hogy sok munka nélkül tesztelhesse és frissíthesse a modult. Ez azonban nem sok hordozhatóságot tesz lehetővé, mivel a modul pontos elérési útvonalát kellene használnod. A PowerShell a $env:PSModulePath változóban nem szereplő modulokat sem importálja automatikusan.

Parancsok szelektív importálása

A Import-Module paraméter használatával a Function paraméter segítségével a teljes modul helyett csak bizonyos funkciókat importálhat. Ez időt takaríthat meg a távoli rendszerekből származó modulok, például az Office 365 modulok importálásakor.

Minden felhasználói modul

Az összes felhasználó számára telepített modulok a C:\Program Files\WindowsPowerShell\Modules könyvtárba kerülnek. Ez a könyvtár számos előre hozzáadott modult tartalmaz, beleértve a Install-Module használatával telepített modulokat is, az alapértelmezett AllUsers hatókörrel.

Jelenlegi felhasználói modulok

Ha egy modult telepít, de csak egyetlen felhasználó szeretné használni, akkor van egy CurrentUser hatókör. Ez a modulfájlokat a Dokumentumok mappába helyezi a C:\Users\<felhasználónév>\Dokumentumok\WindowsPowerShell\Modules címre. Ez hasznos lehet olyan környezetben, ahol mappaátirányítást használ a Documents mappával.

Ebben az esetben telepíthet egy modult az egyik számítógépre, és használhatja a másikon, mivel mindkettő ugyanazt a documents mappát használja.

Rendszer modulok

A teljesség kedvéért a C:\Windows\System32\WindowsPowerShell\1.0\Modules könyvtárban is van egy modulkönyvtár. Bár technikailag egy ebbe az elérési útvonalba helyezett modul ugyanúgy importálható, mint a többi elérési útvonal valamelyike, de ez nem ajánlott, mivel ez a Microsoft rendszermoduljai számára van fenntartva.

Az elnevezés fontos

A modulját manuálisan is elhelyezheti ezen elérési utak egyikébe, hogy alapértelmezés szerint elérhető legyen egy új munkamenettel, de ügyelnie kell arra, hogy a modulokra előírt elnevezést kövesse. A mappának, amelybe a modulfájlok kerülnek, ugyanolyan nevűnek kell lennie, mint a psm1 modulfájlnak és a psd1 modul manifesztjének, ha van ilyen.

A korábban említett Get-Module -ListAvailable használata utal ezekre az elérési utakra. Az összes modul elérési útvonalát a $env:PSModulePath -Split ';' használatával láthatja. Lehet, hogy más elérési utakat is észrevesz a listában, mint ami itt látható. Sok program telepítéskor saját modulútvonalakat ad hozzá. Az egyik példa erre az SQL, amelynek saját moduljai a saját modulútvonalaiban szerepelnek.

Modulútvonalak megtekintése a $env:PSModulePath

Ezek között vannak olyan modulok is, amelyeket egy másik folyamattal telepítene. Az egyik legjelentősebb példa erre az ActiveDirectory modul. A Windows 7-től egészen a Windows 10 1803-ig a Remote Server Administration Tools (RSAT) telepítőprogrammal telepítené.

A Windows 10 újabb verzióinál (1809+) ez csak a Features On Demand segítségével érhető el. Az RSAT telepítése telepíti az ActiveDirectory modulokat és sok mást, amelyeket más Windows-szerepkörök kezeléséhez használna. A Windows kiszolgáló operációs rendszereken ezek a modulok a Kiszolgálókezelőn keresztül települnek.

Távoli modulok importálása (Implicit Remoting)

Vannak olyan esetek, amikor nem célszerű, hogy egy modul helyben fusson. Ehelyett jobb, ha egy távoli eszközhöz csatlakozunk, és az arra telepített modult importáljuk. Ilyenkor a parancsok ténylegesen a távoli gépen kerülnek végrehajtásra. Ezt gyakran használják a Microsoft Office 365 moduljainál. Sokan csatlakoznak egy Office 365 kiszolgálóhoz, amely aztán importál egy modult. Amikor bármelyik parancsot futtatja, azok lefutnak a távoli kiszolgálón, majd a kimenet visszakerül a munkamenetébe.

A távoli modulok importálásának másik felhasználási módja az, amikor a modul nincs helyileg telepítve. Ezt kapná, ha nem lenne telepítve az ActiveDirectory modul, de megpróbálná importálni.

Távoli modul importálásához először létre kell hoznia egy PSSessiont. A munkamenet létrehozásához használhatja a New-PSSession parancsot. Ezután a távoli eszközön elérhető modult a PSSession paraméterrel a Import-Module segítségével importálja a

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

A távoli modulok importálásának ezen módszerét használva gyorsabb kódfuttatást tesz lehetővé elosztott környezetben. Ha például a saját számítógépéről dolgozik, de a kiszolgálók, amelyeken dolgozik, az Egyesült Államokban vannak, bizonyos parancsok helyi futtatása a kiszolgálókkal szemben jelentősen tovább tarthat. Míg a parancsok futtatása egy kiszolgálón és a kimenet visszatáplálása a helyi munkamenetbe sokkal gyorsabb.

Modul előtag hozzáadása

A távoli gépről importált függvényekhez előtagot is hozzáadhat. Ez a lehetőség a helyi modulok importálása során áll rendelkezésre, de egy modul különböző verzióinak egymás melletti tesztelésén kívül ritkán használjuk.

Ha a fenti import parancsot futtatjuk, és a parancsok megtekintésekor ezt látjuk:

Ez esetben egy előtaggal jelezhetjük, hogy nem helyi modulról van szó. Ez olyan esetekben használható, amikor olyan modult importál, amely lokálisan is elérhető. Az előtag hozzáadása csökkenti a kód végrehajtási helyével kapcsolatos félreértéseket.

Modulok eltávolítása

Eltávolíthat egy modult az aktuális munkamenetből a Remove-Module használata nélkül is. Ez eltávolít egy modult a helyi munkamenetből a modulfájlok eltávolítása nélkül. Ezt abban az esetben érdemes használni, ha egy modult távoli munkamenetben használtunk. A Remove-Module segítségével megtisztíthatja a munkamenetet, majd megszakíthatja a távoli munkamenetet.

A Remove-Module másik felhasználási módja, ha egy modulon változtat, és nem akar új PowerShell-munkamenetet indítani. Ebben az esetben a Remove-Module és az utána következő Import-Module segítségével tölthetjük vissza a munkamenetbe. Alternatív megoldásként használhatja a Force paramétert a Import-Module paraméterrel együtt. Ez elvégzi a modul ki- és visszatöltését az Ön számára.

Mi alkotja a PowerShell modult

A modul egy vagy több fájlból állhat. Ahhoz, hogy egy modul minimális követelményeinek megfeleljen, rendelkeznie kell egy modulfájllal. Ez lehet egy PSM1 fájl vagy bármilyen más modulfájl, például egy bináris modulfájl. Hogy erre építhessünk, a psm1 modulodnak tartalmaznia kell benne definiált függvényeket, különben senkinek sem lesz sok haszna belőle.

Noha nincsenek követelmények arra vonatkozóan, hogy a függvényeknek hogyan kell kinézniük vagy mit kell tenniük, van néhány irányelv. Általában előnyösebb, ha egy modulban az összes függvény ugyanarra a koncepcióra épül.

A modulok hasonló jellegű függvényeket tartalmaznak

Az ActiveDirectory modul például csak olyan függvényeket tartalmaz, amelyek valamilyen módon kölcsönhatásba lépnek az Active Directoryval. Általában a függvénynevek is tartalmaznak egy előtagot. Visszatérve az ActiveDirectory modulra mint példára, a függvénynevekben az összes főnév AD-vel kezdődik.

Ezen irányelvek használata segíti a függvények felfedezhetőségét. Képzelje el, hogy éppen most importálta ezt az új modult, és a függvények között szeretne lapozni. Ezt sokkal könnyebb megtenni, ha az összes függvénynek hasonló a névszerkezete. Bár gyakran láthatja, hogy a modulok PS-sel kezdődnek, ez az előtag hivatalosan csak a Microsoft modulok számára van fenntartva. Valószínűleg nem okoz problémát, ha a PS-t használja a modul elején, konfliktust okozhat egy másik modul nevével.

Ezeket az irányelveket használva, ha egy csomó olyan függvénye lenne, amelyeknek mind a registryvel való interakcióhoz van közük, akkor valami ilyesmi lehetne:

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

Modulmanifesztek

A szöveges modulfájlra építve modulmanifesztet is csatolhat. Ezek a fájlok PSD1 kiterjesztésűek, és a modulra vonatkozó metaadatokat tartalmaznak. Ide kerülhetnek a szerzőre, a modul leírására, más szükséges modulokra és sok más attribútumra vonatkozó információk. A tárolóba való közzétételhez szükséges, hogy a Author és Description mezők kitöltve legyenek.

Itt egy példa egy manifesztre, amelyet a regisztrációs modulunkhoz készíthetünk:

#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 = ''}

Bár ez elsőre ijesztőnek tűnhet, a Microsoftnak van egy praktikus cmdletje, amellyel létrehozhat egy modulmanifesztet. A mellékelt parancs a New-ModuleManifest. A fent látható manifeszt létrehozásához a következő parancsot használhatja:

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.'

Külső súgófájlok

Egyes modulokban külső súgófájlokat is láthat. Ezeket a fájlnév végén található <Modulnév>-Help.xml azonosíthatja. Ezek a külső súgófájlok ugyanazokat az információkat tartalmazzák, amelyeket általában a függvénydefinícióban található parancsalapú súgó tartalmaz.

Ezeknél is szükséges a # .ExternalHelp <ModulePath>-Help.xml hozzáadása a függvényhez, hogy a modul importálása után a Get-Help parancs használatakor megfelelően működjön. Külső súgófájlokkal általában csak nagyon nagy moduloknál találkozunk, és emiatt nem tartoznak a hatókörbe.

Míg ezek a leggyakoribb fájltípusok, amelyekkel egy modulban találkozhatunk, nem ezek az egyedüli fájlok. Néha egy szöveges modul mellett bináris fájlokat is látni fog, mivel más függőségek is vannak. A modul elérési útvonalakat vizsgálva számos példát találhat a modulokban található további fájltípusokra.

A nem szabványos modulfájlok megfelelő közzétételéhez a modul manifesztjének FileList paraméterében más fájlokat kell felvennie.

A modul manifesztjében számos más paramétert is észrevehet, amelyek jelenleg üresek. Ezeket felhasználhatja a modul használatához szükséges egyéb követelmények meghatározására. Például meghatározhatja a PowerShell azon verzióit, amelyekkel a modul működhet. Ha a modult a PowerShell egy nem támogatott verzióján próbálja importálni, a következőt látja:

PSRepozitóriumok

A modulok egyik legfontosabb terjesztési lehetősége a PSRepozitórium. Egy 1000′-es nézetben a PSRepository egy olyan hely, ahol több ember vagy több eszköz férhet hozzá a modulfájlokhoz. Ezek gyakran webkiszolgálók, ahol közzéteheti a fájlokat.

Egy könyvtárat is használhat az adattárhoz, de ez korlátozza az adattár funkcionalitását. A PSRepository-t maga is üzemeltetheti, vagy felhasználhatja az interneten elérhető számos lehetőség egyikét, például a PowerShell Galériát. A PSRepozitóriumait a Get-PSRepository parancs segítségével láthatja.

Egyetlen bejegyzés van alapértelmezés szerint, és ez a PowerShell Galéria. Észreveheti, hogy azt fogja mondani, hogy nem megbízható. Ez azért van, mert a PowerShell felhívja a figyelmét arra, hogy a PowerShell Galéria használatával olyan kódot használhat, amelyet nem a Microsoft írt és hagyott jóvá. Ez azt jelenti, hogy mielőtt bármilyen modult telepítene belőle, kifejezett engedélyt kell adnia.

PSRepositories hozzáadása

A saját tárolókat is hozzáadhat. Ha megbízik a PowerShell Galériában, akkor futtathatja a Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted vagy elfogadhatja a figyelmeztetést, amikor először telepít modult a PowerShell Galériából.

Az összes parancs, amelyet ezekkel a PSRepositorykkal való interakcióhoz használna, megtalálható a PowerShellGet modulban. A funkciókat itt tekintheti meg:

A PowerShellGet modul frissítése szükséges lehet bizonyos tárolókkal való interakció előtt.

Modulok keresése

A PSRepository használatának másik fontos jellemzője a modulok keresése. Ezt a Find-Module paranccsal érhetjük el. Többféleképpen lehet szűrni, hogy pontosan azt találjuk meg, amit keresünk, de egyelőre a következőképpen kereshetünk a VMware modulokra:

Ez az összes olyan modult megmutatja, amely VMware-rel kezdődik. Bár ezek többsége a VMware-től származik, meg kell nézni a szerzői attribútumot, hogy megtudjuk, ki tette közzé a modult.

Mivel bárki feltöltheti a PowerShell Galériába, több ezer modul áll rendelkezésre. Ez azt jelenti, hogy találhat olyan modulokat, amelyek nem működnek megfelelően az Ön felhasználási esetéhez. Sok modul, amit talál, nyílt forráskódú, így hozzájárulhat hozzájuk, hogy javítsa a modul funkcionalitását.

Modulok telepítése

A Install-Module parancs használatához egy megbízható PSRepositoryra van szükség, amely a modult tárolja. Ez lehet a PowerShell Galéria, egy másik internetes PSRepository vagy egy saját tárhelyű webhely. A Find-Module parancsból pipázhat, hogy a modul telepítése előtt könnyen megerősíthesse a modult.

A modul verzióját a MinimumVersion, MaximumVersion vagy RequiredVersion paraméterekkel is meghatározhatja.

A Install-Module paranccsal telepített összes modul megtekintéséhez használhatja a Get-InstalledModule parancsot. Ez felsorolja a AllUsers hatókörbe vagy a CurrentUser hatókörbe telepített összes modult.

Modulok eltávolítása

Ahogyan, ahogyan telepíthet egy modult, úgy távolíthat el egy modult is. Ha a modult nem a Install-Module paranccsal telepítettük, akkor a Uninstall-Module paranccsal nem tudjuk eltávolítani.

Mint látható, itt az ActiveDirectory modult próbáljuk eltávolítani. Mivel ez a modul nincs telepítve a Install-Module segítségével, hibaüzenetet kapnánk, ha megpróbálnánk használni a Uninstall-Module-at. Ahhoz, hogy ezt a modult eltávolíthassuk, fordított módon kellene eltávolítanunk, amit a modul telepítéséhez használtunk.

A modul sikeres eltávolítását láthatjuk a korábban telepített VMware.PowerCLI modul eltávolításával.

A VMware.PowerCLI eltávolítása ellenére is látható, hogy még mindig számos függőség van telepítve. Ha az összes modult szeretnénk eltávolítani, akkor használhatjuk a Get-InstalledModule VMware.* | Uninstall-Module -Force.

A modul teljes eltávolítása azért okozna ilyen nehézséget, mert nagyon sok függőséget tartalmaz. Ráadásul ezek közül néhány modul egymás függősége, ezért lenne szükség a Force paraméterre.

Modulok frissítése

Most, hogy már tudja, hogyan kell telepíteni és eltávolítani egy modult, talán kíváncsi, hogyan lehet frissíteni egy már telepített modult.

A többi folyamathoz hasonlóan, ha a modult nem a Install-Module segítségével telepítette, nem tudja frissíteni a PowerShell parancsok segítségével. A Update-Module segítségével frissítheti a modult a legújabb kiadásra vagy egy újabb specifikus verzióra.

A AllowPreRelease kapcsoló is létezik, amely lehetővé tenné a frissítést egy hivatalosan még ki nem adott verzióra. Néha ez segíthet, mivel lehet, hogy javítás történt egy általad tapasztalt hibára, vagy egy új funkciót adtak hozzá, amit használni szeretnél.

Modul ellenőrzése/mentése

Az egyik sokkal ritkábban használt parancs, ami nagyon hasznos a modulok használat előtti ellenőrzésénél, a Save-Module. Ezzel a paranccsal letölthetünk egy modult egy elérési útvonalra anélkül, hogy telepítenénk.

Ezután megvizsgálhatjuk a fájlokat, és ha a modul nem bináris modul, akkor megnyithatjuk és megnézhetjük a modult alkotó kódot. Ez nem csak arra lehet jó, hogy megbizonyosodjon arról, hogy egy modul nem csinál semmi rosszindulatú dolgot, hanem arra is, hogy megtudja, mások hogyan strukturálják a moduljaikat.

Ebben a példában nem csak a VMware.PowerCLI modul kerül letöltésre, hanem az összes függőség is. Íme, mi látható a VMware.PowerCLI mappában:

Ez egy jó példa arra, hogy néha nem szabványos modulfájlok is szerepelnek a modulban, például a végfelhasználói licencszerződés.

Saját modul írása

Most láthatta, hogyan léphet kapcsolatba valaki más moduljával. Most azt szeretné megtanulni, hogyan hozza létre a sajátját, hogy elkezdhesse optimalizálni a kódját a skálázhatóság érdekében.

Sablonfájlok létrehozása

Először is létre kell hoznia egy mappát az összes modulfájljának. Miután megvan a tároló, létre kell hoznia a modulfájlját. Meg kell győződnie arról, hogy a modulfájlnak ugyanaz a neve, mint a mappának, különben a modul közzétételénél a PowerShell nem fogja helyesen felfedezni a modult.

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

Most ha manifesztet is szeretne használni, akkor azt is ugyanúgy kell elneveznie, mint a konténert és a modulfájlt.

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'

A konténer, a modulfájl és a manifeszt fájl segítségével egy teljesen működő modulja van. Ezt a modult közzéteheted egy PSRepositoryban, és elkezdheted telepíteni, ahová csak akarod. Bár mivel a modulfájl üres, valószínűleg nem sok jót fog tenni. Ezeket a fájlokat még mindig használhatja a közzététel tesztelésére, hogy megbizonyosodjon arról, hogy az adattár működik.

PSRepository regisztrálása

A modul közzététele előtt hozzá kell adnia egy másik PSRepository-t a munkamenetéhez. A teszteléshez használhatsz egy helyi elérési utat PSRepository-ként, mivel azt könnyű lesz felállítani és leszerelni.

Normális esetben, ha egy PSRepository-t egy könyvtárral állítanál be, biztosítani szeretnéd, hogy több számítógép is hozzáférhessen. A helyi adattárat így hozhatja létre:

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

Ha csak a PSRepositoryból töltene le, és soha nem publikálna, akkor a PublishLocation paramétert kizárhatná.

A modul publikálása

Mivel a telepítési házirendet már megbízhatóra állította, nem kap visszaigazolást a modul telepítésének engedélyezésére az adattárból. Most, hogy egy új PSRepository áll rendelkezésre, a Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo segítségével közzéteheti a modulját.

A modul közzététele után a fenti parancsokkal megkeresheti és telepítheti a modult.

Most, hogy telepítette a modult, a Get-Module segítségével láthatja a modul importálását a helyi munkamenetbe. Mivel a manifesztben a FunctionsToExport tömbhöz nem adtál hozzá függvényeket, a ExportedCommands tulajdonság üres.

Hozzáadás a modulodhoz

Most, hogy tudod, hogy közzéteheted és telepítheted a modulodat, elkezdheted hozzáadni néhány funkciót. Hozzáadhatsz egy függvényt, amely visszaad egy registry kulcsot, így néz ki:

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

Ha a manifesztet úgy hagynád, ahogy van, és megpróbálnád feltölteni az új modulodat, két problémába ütköznél. Az első, hogy hibaüzenetet kapnál, miszerint a modulod verziója már létezik az adattáradban. Ez azért van, mert nem változtatta meg a modul verzióját a manifeszt fájlban.

Modulfüggvények exportálása

A másik probléma az lenne, hogy a modul importálása után még mindig nem látna függvényeket a ExportedCommands tulajdonságban, mert nem adta hozzá az új függvényét a manifeszthez.

Míg a függvénye használható lenne anélkül is, hogy a FunctionsToExport listában szerepelne, sokkal nehezebbé tenné a megtalálását.

Az említett két probléma megoldásához a következőképpen frissítheti a modulfájlját:

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

Most, miután hozzáadott egy funkciót a moduljához, és frissítette a manifesztjét, hogy tükrözze ezeket a változásokat, a modul új verzióját ugyanazzal a paranccsal közzéteheti, mint korábban.

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

A modul frissítése

Az utolsó lépés az lenne, hogy frissítse a modulját a munkamenetben, hogy használni tudja a frissített fájlokat. A Update-Module ATARegistry segítségével letölti a frissítést, amelyet az imént publikált a tárolóba.

Most láthatja, hogy megvan a modul új verziója, és láthatja a manifesztben meghatározott funkciót.

Súgó tartalom építése

A korábban átadott lehetőségek egyike a PowerShellbe épített súgórendszer. Valószínűleg Ön is használt már valamikor Get-Help egy függvényen. Ezt az információt elsősorban kétféleképpen lehet hozzáadni.

Az első az, hogy a függvénydefinícióhoz megjegyzésalapú súgó adható. Ezt a módot általában sok modulíró valósítja meg. A másik mód egy külső súgófájl használata. A Full paraméterrel mindent megmutathat, amit a súgó kínál.

Amint látja, valóban nem sok információ áll rendelkezésre, és az a kevés információ, amit kap, valószínűleg senkinek sem lenne hasznos.

A modulfájljához hozzáadhat néhány megjegyzésalapú segítséget, hogy feltöltse ezeket a mezőket a súgórendszerben. A megjegyzés alapú súgó összes lehetőségéről a Get-Help about_Comment_Based_Help segítségével olvashat.

Előre frissítheti a függvényét, hogy az alábbiak szerint nézzen ki. Ez a leggyakrabban használt súgóparaméterek listája, de ezek mindegyike továbbra is opcionális, és vannak mások is, amelyeket hozzáadhatunk helyettük.

Most a függvényed így néz ki:

 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}

Létezik néhány speciális súgóparaméter, például a .FORWARDHELPTARGETNAME. Ez az opció minden bejövő súgó kérést továbbít egy másik parancshoz. Ezt olyan esetben lehet használni, amikor a súgónak több parancshoz ugyanazt az információt kell megjelenítenie.

Most, hogy hozzáadtad a súgót, frissítheted a verziót a modul manifesztjében, közzéteheted az új verziót, és frissítheted a telepített verziót a munkamenethez, ahogy korábban tetted.

Ha most megnézed a funkció súgóját, láthatod, hogy sokkal több információ áll rendelkezésre. Ez egy nagyszerű módja annak, hogy a függvények használatára vonatkozó dokumentációt is tartalmazzon, különösen azok számára, akik kevésbé gyakorlottak, és a kódot megnézve esetleg nem tudják gyorsan megérteni, hogy mit csinál a modul.

A külső súgófájl esetében a hozzáadott információ ugyanaz, de az információ egy külön fájlban van elhelyezve, és a függvényen belül kapcsolódik.

Ha megnézzük a AllUsersmodul elérési útvonalát, akkor láthatjuk a modul verzióját és az összes telepített modulfájlt.

Ha visszamegyünk a korábban létrehozott PSRepository C:\Repo elérési útvonalára, akkor egy csomó NUPKG fájlt láthatunk. Minden egyes közzétett verzióhoz lesz egy. Ezek tömörített változatai annak, amit a Publish-Module.

Összefoglaló

Ha már megismerte a PowerShell konzolt, a PowerShellt mint nyelvet és a szkriptek írását, a saját modulok készítése az utolsó lépés. A modulok lehetővé teszik, hogy elkezdje a hasznos eszközök fejlesztését a PowerShellben. Ha helyesen tervezed és építed meg a modulok létrehozásával egyetlen célra, akkor idővel elkerülhetetlenül egyre kevesebb kódot fogsz írni. Elkezd majd több kódban hivatkozni a modulfüggvényeire, és onnan építkezik.

A modulfüggvények lehetővé teszik, hogy absztrahálja a szkriptekben ismétlődő kódot. Olyan “címkéket” jelentenek, amelyekre később hivatkozhatsz a kódban, amelyeket bármikor meghívhatsz, ahelyett, hogy újra feltalálnád a kereket, és megpróbálnád kitalálni, hogyan érted el már korábban a célodat. A modulok a PowerShell kód végső “csomagolása”, amely csoportosítja a hasonló jellegű kódokat, hogy ne pazarolja az időt a már megoldott problémákra.