Cada vez que un administrador de IT comienza a ver lo que PowerShell puede hacer por su carrera, típicamente comienza a hacer un guión de todo. Escriben guiones para automatizar todo tipo de tareas diferentes. Cada vez que se presenta una nueva tarea, toman los conocimientos de escritura que han ido construyendo a lo largo del tiempo y crean otro guión. Este patrón continúa hasta que se sobrecargan de trabajo. Tienen guiones individuales que hacen cosas para diferentes servidores, archivos, carpetas y todo tipo de cosas. Admiro el entusiasmo, pero este comportamiento no es sostenible y puede ser considerado como una forma de deuda técnica.
Es hora de dejar de construir guiones y empezar a hacer herramientas.
Puede que te lo estés preguntando: ¿Cuál es la diferencia entre un guión y una herramienta? La diferencia no está realmente en la palabra, ya que una herramienta es en realidad sólo un guión, una función o una combinación de guiones. La principal diferencia es cómo te propones construir una herramienta. Una herramienta puede ser pensada como un pedazo de código que es reutilizable y se crea para ese propósito.
Una herramienta es un martillo. Un martillo puede ser usado en muchas situaciones diferentes. Puede martillar diferentes tipos de clavos, para romper cosas o ser usado como un objeto contundente. Un martillo es reutilizable. Nunca ves un «martillo de arma», un «martillo de clavos de un centavo» y un «martillo para romper vidrios», ¿verdad? Eso sería ridículo. Un «martillo» estándar puede ser usado para todas esas cosas. No necesitas un martillo en particular para cada propósito. Esta es la principal diferencia entre un guión y una herramienta. Piensa en «clavo de centavo», «arma» y «romper vidrios» como parámetros del martillo en el mundo de PowerShell.
Cubramos este concepto con un excelente ejemplo de cómo un simple script construido en PowerShell eventualmente se transforma en una herramienta.
Digamos que tienes un código que usas para asegurarte de que un ordenador está en línea y tiene WinRM disponible. Podría parecerse a algo como esto:
$nombre de la computadora = $0027MYCOMPUTER$0027
si ((Test-Connection -ComputerName $nombre de la computadora -Silencio – Cuenta 1) – y ((Invoke-Command -Nombre de la computadora $nombre de la computadora – Bloque de Script {1}) -eq 1)) {
## Haz algunas cosas aquí diferentes para cada guión
}
Cada vez que necesitas usar esto, lo copias y lo pegas en varios guiones. Dos de tus guiones pueden parecerse a esto:
Script1.ps1
$nombre de la computadora = $0027MYCOMPUTER$0027
si ((Test-Connection -ComputerName $nombre de la computadora -Silencio – Cuenta 1) – y ((Invoke-Command -Nombre de la computadora $nombre de la computadora – Bloque de Script {1}) -eq 1)) {
## Haz algunas cosas aquí
## Haz más cosas
}
Script2.ps1
$nombre de la computadora = $0027MYCOMPUTER123$0027
si ((Test-Connection -ComputerName $nombre de la computadora -Silencio – Cuenta 1) – y ((Invoke-Command -Nombre de la computadora $nombre de la computadora – Bloque de Script {1}) -eq 1)) {
## Haz algunas cosas aquí
## Haz algo impresionante aquí
}
Hasta ahora, ha funcionado muy bien hasta que descubres que necesitas ajustarlo de alguna manera. En ese momento, debes recordar cada script en el que tengas este fragmento de código y actualizar cada uno. Este método no es escalable. Necesitas una herramienta para esto; más precisamente, una función de PowerShell que pueda ser llamada en lugar de hacer copias del fragmento cada vez que necesites usarlo.
Construyamos ahora una «herramienta» o una función y mostremos cómo se puede hacer esto de una manera mucho más escalable y eficiente.
Prueba de funcionamiento – WinRm {
Param(
Parámetro (obligatorio)
[cadena]$Nombre de la computadora
)
si ((Test-Connection -ComputerName $ComputerName –
Silencio -Cuenta 1) – y ((Invocar-Comando – Nombre de la Computadora
$computerName -ScriptBlock {1}) -eq 1)) {
$verdadero
}
más
{
$falso
}
}
Ahora he envuelto este fragmento de código en una función. Además, ahora sólo estoy emitiendo un valor $verdadero si el ordenador tiene WinRM disponible o $falso si no. Esto es diferente del ejemplo anterior porque no estoy poniendo ningún otro tipo de código aquí. Una función sólo debe tener un propósito y, en este caso, es ver si un ordenador tiene WinRM disponible. Una simple salida de $verdadero/falso es todo lo que necesito.
En este punto, este fragmento de código es reutilizable si está disponible en su sesión. Puede elegir ponerlo en su perfil de PowerShell o tal vez agregarlo a un módulo para que esté disponible para usted todo el tiempo.
Los dos guiones que construyó arriba pueden verse ahora algo así:
Script1.ps1
Si (Test-WinRm -ComputerName MYCOMPUTER) {
## Haz algunas cosas aquí
## Haz más cosas
}
Script2.ps1
Si (Test-WinRm -ComputerName MYCOMPUTER) {
## Haz algunas cosas aquí
## Haz algo impresionante aquí
}
¿Notan que el código es mucho más simple y fácil de entender? No sólo eso, ya que estás haciendo referencia a una sola función en ambos guiones, si tuvieras que hacer un cambio, sólo cambiarías la función Test-WinRM. Ya no habría que copiar, pegar y buscar todos los scripts en los que se pone este fragmento de código.
Este fue un simple ejemplo de la mentalidad de la herramienta. El código puede ser clasificado como una herramienta sin importar si es un ejemplo simple como este o si estás construyendo grandes herramientas como lo demuestro en mi curso de Fundamentos de Fabricación de Herramientas de PowerShell. El punto principal es dar un paso atrás a veces, notar cuando te encuentras repitiendo una tarea y construir una herramienta reutilizable.