Microsoft lanzó PowerShell Core 6 en enero de 2018, el primer lanzamiento desde que la compañía cambió el motor de automatización estándar basado en Windows y el lenguaje de scripting a un producto multiplataforma de código abierto para administrar máquinas Linux y macOS. PowerShell 6 no es una actualización directa para Windows PowerShell versión 5.1. Los dos productos pueden funcionar en paralelo y deberán hacerlo hasta que PowerShell Core alcance la paridad de características con Windows PowerShell.
PowerShell 6 no es un reemplazo de Windows PowerShell
La principal diferencia entre los dos productos PowerShell es que Windows PowerShell se ejecuta en .NET Common Language Runtime solo para Windows, mientras que PowerShell 6 se ejecuta en .NET Core, que funciona en Windows, muchas distribuciones de Linux y macOS.
PowerShell Core funciona junto con Windows PowerShell, pero los ejecutables tienen nombres diferentes. PowerShell Core carece del entorno de scripting integrado de PowerShell; Microsoft recomienda que los usuarios de PowerShell Core adopten Visual Studio Code, un producto multiplataforma, como reemplazo.
La naturaleza multiplataforma de PowerShell Core significa que carece de algunas características centradas en Windows, como cmdlets de registro de eventos y cmdlets de Instrumentación de administración de Windows. Flujos de trabajo de PowerShell también faltan en PowerShell Core. Parte de esta funcionalidad volverá a PowerShell Core con la versión futura del Paquete de compatibilidad de Windows para .NET Core.
Hay varias fuentes diferentes de la funcionalidad actualmente disponible en Windows PowerShell versión 5.1:
- la funcionalidad básica de PowerShell proporcionada por el equipo de PowerShell;
- módulos enviados como parte del sistema operativo Windows, como NetAdapter y almacenamiento;
- módulos suministrados como parte de una función de Windows, como Active Directory o módulos del sistema de nombres de dominio, incluidos los módulos de la utilidad Herramientas de administración de servidor remoto;
- módulos suministrados con un producto de Microsoft, como Exchange Server o SQL Server;
- módulos suministrados a través de la galería de PowerShell; y
- módulos suministrados por terceros.
PowerShell 6 parece ligero en funcionalidad porque solo cubre el primer elemento. Muchos de los módulos del segundo elemento se ejecutarán en PowerShell Core, pero no todos.
Los nuevos usuarios de PowerShell pueden desarrollar scripts completos pero compactos una vez que dominen la función de canalización.
Cuando bajamos más en la lista, algunos módulos, como Active Directory y Exchange, no funcionarán en PowerShell 6 porque están escritos para .NET completo en lugar de .NET Core. El paquete de compatibilidad de .NET Core Windows permite la creación de scripts en Active Directory.
Con suerte, PowerShell Core recuperará toda esta funcionalidad, pero llevará tiempo lograrlo.
La administración remota simplificada
La administración de un servidor se logra fácilmente con las herramientas estándar. Para cuando esté administrando 100, 1,000 o más servidores, las herramientas estándar simplemente no escalan. PowerShell establece sesiones en máquinas remotas para ejecutar la misma acción, o conjunto de acciones, en varias máquinas. Este enfoque de distribución, definir lo que quiere que suceda y luego automatizar esas tareas, es clave para administrar una gran cantidad de servidores de forma remota.
PowerShell trabaja con el programador de Windows para realizar trabajos de administración de rutina durante períodos nocturnos. Los administradores pueden crear scripts que notifiquen errores y realicen acciones correctivas para superar los problemas.
La comunicación remota de PowerShell usa el protocolo Web Services for Management (WSMan) para la conectividad remota en las versiones 2.0 a 5.1 de Windows PowerShell. Esto funciona dentro de un dominio de Active Directory, pero pueden surgir problemas al trabajar en varios dominios o al comunicarse de forma remota desde y hacia máquinas en un grupo de trabajo.
PowerShell Core ofrece comunicación remota basada en WSMan para sistemas Windows (la implementación de WSMan en Linux y macOS no está completa) y conexión remota Secure Socket Shell (SSH). Al comunicarse de forma remota entre máquinas Linux, o si Linux está en un extremo de una conexión y Windows en el otro, entonces SSH es el protocolo que se debe usar.
La comunicación remota SSH simplifica el acceso a una máquina fuera del dominio, pero es difícil configurar la comunicación remota con ella. Es posible crear sesiones de comunicación remota basadas en WSMan en varias computadoras simultáneamente, pero usar SSH significa crear cada sesión individualmente y proporcionar una contraseña de forma interactiva, a menos que las máquinas remotas usen claves SSH para admitir la autenticación de usuario basada en claves. Esto requiere mucho esfuerzo de configuración.
¿Debería cambiarse a PowerShell 6?
¿Debería permanecer en Windows PowerShell o migrar a PowerShell Core 6? Si su centro de datos consta exclusivamente de máquinas con Windows en un dominio de Active Directory, no hay ningún beneficio en cambiar en este momento debido a una caída en las capacidades de las funciones. Si administra una combinación de máquinas Windows y Linux, o una cantidad significativa de máquinas Windows sin dominio, PowerShell Core ofrece una opción de administración multiplataforma, pero es probable que su configuración involucre ambas plataformas PowerShell.
La capacidad de PowerShell para manejar una variedad de sistemas y escenarios: tareas únicas en un solo servidor; tareas únicas en varios servidores; múltiples tareas en múltiples servidores, máquinas que no son de dominio y máquinas que no son de Windows: proporciona la versatilidad requerida en muchas empresas.