Creación de módulos

Introducción

La palabra "módulo" generalmente evoca la idea de "modular". Se concibe como un elemento básico central, alrededor del cual se agrupan otros elementos más pequeños que completan su funcionalidad. Estos elementos pueden eliminarse, mejorarse, añadirse o incluso transferirse.

Ilustración de la modularidad en PowerShell

Lo mismo ocurre con los módulos PowerShell, aunque son algo más que simples complementos. De hecho, todos los comandos de PowerShell, especialmente los comandos básicos, están contenidos en módulos. Los módulos se introdujeron con PowerShell 2.0. Sustituyeron a los snapins, que aparecieron en la primera versión de PowerShell. Los snapins se siguen utilizando, pero Microsoft recomienda el uso de módulos, que son mucho más sencillos de configurar.

Los módulos permiten organizar adecuadamente el código. Sobre todo, facilitan el intercambio de código con colegas e incluso con toda la comunidad.

¿Qué tipos de archivos son? ¿Y qué pueden contener?

Módulo dinámico

La segunda opción para crear un módulo es el comando New-Module. Esto crea un módulo dinámico. Se carga en memoria y existe mientras dura la sesión de PowerShell. Esto significa que no se escribe en el disco y, por lo tanto, es invisible para el comando Get-Module (más adelante veremos cómo hacerlo visible). Sin embargo, las funciones creadas permanecen visibles a través del comando Get-Command.

Argumentos para el comando New-Module:

Ahora se crearán...

Módulo script

Los módulos script son los más conocidos porque son rápidos y fáciles de crear. También son sencillos de desplegar y de utilizar.

Crear un módulo es relativamente sencillo. Se puede almacenar en diferentes lugares. Para ello, conviene comprobar el contenido de la variable de entorno $Env:PSModulePath. Si el módulo creado no está contenido en uno de los directorios de esta variable, entonces no será descubierto automáticamente por PowerShell. También es posible modificar esta variable para añadir sus propias rutas de acceso.

Si se decide prescindir de $Env:PSModulePath, siempre es posible importar el módulo manualmente, especificando la ruta completa al applet en el comando Import-Module. Puede consultar el contenido de la variable $Env:PSModulePath con el siguiente comando:

PS > $Env:PSModulePath.Split(';')  
C:\Users\Nicol\Documents\WindowsPowerShell\Modules  
C:\Program Files\WindowsPowerShell\Modules  
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules 

Una vez encontrada la ubicación, basta con crear una carpeta con el nombre del módulo y, a continuación, un archivo PSM1. Debe tener el mismo nombre que la carpeta. Este archivo contendrá el código PowerShell, e incluso puede llamar a scripts PS1.

Ejemplo de creación de un módulo

PS > New-Item -Path $Home\Documents\WindowsPowerShell\Modules `  
            -Name MyModuleTools -Type directory  
  
PS > New-Item -Name MyModuleTools.psm1 -Type File `  
-Path $Home\Documents\WindowsPowerShell\Modules\MyModuleTools 

Por el momento, el módulo está vacío. A continuación, añadiremos algunas funciones útiles. También es una buena idea incluir una función que llame a una segunda función bastante larga que se utiliza regularmente.

Manifiesto de módulo

El manifiesto de un módulo es un elemento importante si quieres compartir tu trabajo. Es un archivo en formato PSD1. Está estructurado como una tabla hash (hashtable), donde cada campo contiene metadatos sobre el módulo. Estos metadatos agrupan una serie de elementos sobre el módulo, como el nombre del autor, el número de versión, las notas de publicación, los diferentes archivos que se deben cargar y los diferentes requisitos previos del módulo. Esta última sección no es meramente informativa. Tiene un impacto importante cuando se carga el módulo.

Si se especifica una versión mínima de PowerShell en el manifiesto, el módulo no podrá utilizarse si la versión de PowerShell que ejecuta el sistema es anterior a la especificada.

PowerShell incluye dos cmdlets principales para trabajar con manifiestos: New-ModuleManifest, que permite crearlos, y Test-ModuleManifest, que verifica su validez.

Exportación de los miembros de un módulo

Function Get-PSSerialNumber {  
    (Get-WMIObject -Class Win32_Bios).SerialNumber  
}  
  
Function Get-PSFolderSize {  
    Param(  
           [ValidateScript({Test-Path $_})]  
           [String]$Path  
    )  
    (Get-ChildItem -Path $Path -Recurse -File | `  
    Measure-Object -Property Length -Sum ).Sum /1MB  
}  
Set-Alias -Name gpsn -Value 'Get-PSSerialNumber'  
$ScriptAuthor = 'Nicolas Baudin'  
  
Export-ModuleMember -Function `   
    'Get-PSFolderSize','Get-PSSerialNumber'  
Export-ModuleMember -Variable 'ScriptAuthor' -Alias 'gpsn' 

PS > $PSVersionTable  ...

Estructura multiarchivo

A la hora de mantener y desarrollar un módulo, su estructura es un punto importante. Si está muy mal organizado, nadie querrá trabajar en él, ni siquiera utilizarlo. En cambio, si la estructura está clara y definida, a la gente le gustará participar en su ciclo de vida.

Realmente no existe una estructura convencional. Lo más importante es documentar la finalidad de cada carpeta y archivo. Esto facilitará mucho el trabajo de un corrector o colaborador.

La estructura que se muestra aquí es un ejemplo. No es perfecta, pero tiene grandes ventajas a la hora de facilitar el mantenimiento de un módulo.

Estructura jerárquica

$Env:PSModulePath  
  └─<Versión>  
    └─<Nombre del módulo>  
      ├─Public  
         └─<Nombre Script>.ps1  
      ├─Private  
         └─<Nombre de script>.ps1  
      ├─<Manifiesto del módulo>.psd1  
      ├─<Archivo principal>.psm1  
      └─<other files> 

El módulo consta...

Pasar a Build con Sampler

La filosofía de desarrollo de un paquete suele incluir una fase de construcción (build). Esta fase toma el código fuente y lo organiza para generar el paquete que luego se desplegará. Esta fase de build suele incluir con frecuencia la compilación del código.

En nuestro caso, se trata de un módulo. El objetivo es poder combinar la estructura vista anteriormente con la ventaja de un archivo PSM1 completo y de alto rendimiento. Para ello, partimos de una estructura multiarchivo, similar a la presentada en el apartado anterior, para el desarrollo del módulo. A continuación, se utiliza una herramienta de compilación para crear un módulo construido sobre un único PSM1. La herramienta presentada aquí es Sampler. Es un módulo comunitario desarrollado por Gael Colas. Existen otras herramientas similares, como Stucco.

La principal motivación de Gael para diseñar este módulo fueron los recursos DSC. De hecho, Gael es uno de los miembros fundamentales de la comunidad DSC y quería normalizar la redacción de recursos DSC basando su desarrollo en una estructura y unos procesos de validación y despliegue comunes.

Sampler utiliza una serie de módulos para construir un módulo de principio a fin. He aquí algunos de ellos:

El módulo Sampler está disponible en la PowerShell Gallery. El módulo se instala mediante el módulo PowerShellGet. Para obtener más información sobre el uso de este módulo, consulte el capítulo Gestión de módulos y paquetes. 

  PS > Install-Module Sampler