lunes, 19 de junio de 2017

Powershell Desired State Configuration

Powershell Desired State Configuration (DSC)

DSC es la tecnología de Powershell que nos permite, a través de scripts, mantener un estado deseado de configuración en los equipos.

De este modo podemos lograr un estado de cumplimiento que puede automatizarse para que se ejecute regularmente, permitiendo que nuestros equipos tengan siempre el estado de configuración deseada.

En esta nota mostramos un ejemplo básico de Powershell DSC que define como estado deseado la presencia de un rol determinado en un servidor.


Modos de configuración de DSC

Modo Push: un administrador envía manualmente las configuraciones a los nodos. Este método es manual y no garantiza que los equipos que estén apagados o desconectados en ese momento reciban la configuración.

Modo Pull: se crea un servidor (pull server) y los nodos lo contactan regularmente para obtener su configuración.

Su principal ventaja es que cuando los equipos se conectan a la red reciben la configuración deseada. Como desventaja requiere un equipo configurado como Pull server.

DSC Resources

Los recursos de DSC representan lo que queremos configurar en cada nodo en forma forzada, por ejemplo servicios, roles, archivos, etc.

Ejecutando Get-DSCResource podemos obtener una lista de recursos (entre los que vemos Windows Feature, Service, File, WindowsProcess, etc).

Ejemplo: lista de recursos obtenida al ejecutar Get-DSCResource
  • File
  • SignatureValidation
  • Archive
  • Environment
  • Group
  • GroupSet
  • Log
  • Package
  • ProcessSet
  • Registry
  • Script
  • Service
  • ServiceSet
  • User
  • WaitForAll
  • WaitForAny
  • WaitForSome
  • WindowsFeature
  • WindowsFeatureSet
  • WindowsOptionalFeature
  • WindowsOptionalFeatureSet
  • WindowsPackageCab
  • WindowsProcess

Sintaxis del script


En la configuración siguiente, que llamamos TestConfig se trata de forzar que en el nodo LON-SVR1 esté instalado el rol de DNS Server (DNS)

Configuration TestConfig
{
                Node “LON-SVR1”
                                {
                                WindowsFeature DNSExample
                                                {
                                                Ensure = “Present”
                                                Name = “DNS”                                                }
                                }
}

NOTA: en Node podría usarse una variable previamente definida, por ejemplo $Servers o eventualmente Localhost para que sirva en varios equipos.


Antes de comenzar con la configuración verificamos que el rol DNS no está instalado en el servidor LON-SVR1












Consulta de Sintaxis para el Resource "WindowsFeature"

Mediante Get-DscResource windowsfeature -Syntax averiguamos la sintaxis para el recurso Feature. El resultado nos muestra las opciones "Name" y "Ensure" utilizadas en el script del ejemplo.


WindowsFeature [String] #ResourceName
{
    Name = [string]
    [Credential = [PSCredential]]
    [DependsOn = [string[]]]
    [Ensure = [string]{ Absent | Present }]
    [IncludeAllSubFeature = [bool]]
    [LogPath = [string]]
    [PsDscRunAsCredential = [PSCredential]]
    [Source = [string]]
}


Preparación del Script:

El script se debe ejecutar como función. Una forma sencilla de lograrlo es agregar el nombre de la función en la última línea del script (TestConfig en el ejemplo)

En la figura siguiente vemos el script editado en Powershell ISE



Guardamos el script con  en la carpeta C:\DSC con el nombre TestConfig.ps1


Ejecución del script:

Lo ejecutamos mediante la sentencia C:\DSC\> .\TestConfig.ps1




El script en sí no aplica la configuración, sino que crea un archivo MOF que es un archivo de texto con la configuración que se va a aplicar.

El archivo MOF podría crearse manualmente, aunque es más sencillo seguir los pasos previos.

Puede verse el archivo MOF editado con Notepad.




















A continuación se invoca el MOF usando el CMDLET Start-DscConfiguration

Start-DscConfiguration –Wait –Verbose –Path .\TestConfig

La opción Verbose permite que se vea el progreso de la configuración.



























Al terminar se volvió a ejecutar Get-WindowsFeature para ver el estado del rol DNS.
Puede verse en la pantalla siguiente que DNS Server está instalado. 



lunes, 5 de junio de 2017

Elegir entre Windows Containers y Hyper-V Containers

Introducción

Windows Server 2016 incluye el rol Containers, que permite crear y administrar Windows Containers y Hyper-V Containers.

La creación y administración de ambos tipos de containers es muy similar. En esta nota daremos algunas pautas para ayudar a elegir el modelo más conveniente.


Diferencias en el licenciamiento

Los Hyper-V Containers adhieren al mismo modelo de licenciamiento de las máquinas virtuales.
En un Host Datacenter Edition se pueden crear ilimitados Hyper-V Containers
En un Host Standard Edition se pueden crear hasta dos Hyper-V Containers por cada paquete de licencias.

En cambio, los Windows Containers son ilimitados para ambas ediciones de Windows Server 2016.



Diferencias de aislamiento de procesos

En las máquinas virtuales, el sistema operativo se ejecuta en User mode y Kernel mode (hay un kernel mode para cada guest).

Los Windows Server Containers solamente utilizan user mode, permitiendo a los procesos de Windows y procesos de aplicaciones ejecutarse en el container, aislado del user mode de otros containers.
Por este motivo, los Windows Containers no consiguen un completo aislamiento, ya que trabajan con un único Kernel mode en común.

Los Hyper-V Containers en forma similar a las máquinas virtuales son child partitions, el sistema operativo guest del Hyper-V container no es el sistema operativo Windows normal, sino una versión reducida (que tampoco es la versión Nano).


El nivel de aislamiento que provee el Hyper-V container para cada child partition es entre el Hyper-V container con otros Hyper-V containers en el host, el hipervisor y la parent partition del host.

La siguiente figura muestra la diferencia entre ambos tipos de containers.



Ejemplo 1: Hyper-V Container

A continuación se crea un Hyper-V Container llamado TestIISH y se ejecuta dentro del container Notepad.exe

Para crear el container se ejecutó el siguiente comando:

docker run -d --name TestIISH --isolation=hyperv microsoft/iis -p 80:80

Ejecutamos un CMD dentro del container y luego Notepad.exe:

docker exec -i TestIISH cmd

C:\Windows\System32>notepad.exe

PS C:\Windows\System32> get-process -name n*

Vemos el proceso Notepad con ID 2668 dentro del Container


Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id     SI  ProcessName
-----------   -------        -----         ------         ----           -----    ---   -------------
  128            9           1984       7632        0.08        2668   1     notepad

Se ejecuta el comando Get-Process en el host y se verifica que no está el proceso del notepad pero si aparecen procesos llamados vmwp (virtual machine work process)

PS C:\Users\Administrator> get-process n* (no hay resultados)

PS C:\Users\Administrator> get-process v*

Handles  NPM(K)    PM(K)       WS(K)     CPU(s)     Id   SI    ProcessName
-------         ------        -----            -----        ------          --    --     -----------------
    294        31         4928         13264       0.14   2996     0       vmcompute
      0      2770      1072600     616020      0.00   1280     0       vmmem
      0       2717     1050640     346972      0.00   3184     0       vmmem
      0      2724     1050640         16           0.00   3852     0       vmmem
    617      22         10288         23936       0.27   2312     0       vmms
   4488     18         40688         21756      10.05  1872     0      vmwp
    238       5          35640         16392       1.41   3844     0      vmwp
    130       9            1588           7716        0.02   1192    0      VSSVC


Ejemplo 2: Windows Container


Se crea un Windows Container llamdo TestIISW se ejecuta Notepad y se ve el proceso dentro del container con ID 3768

docker run -d --name IISTestW -p 80:80 microsoft/iis

docker exec -i IISTestW cmd

C:\Windows\System32>notepad.exe

PS C:\Windows\System32> get-process -name n*


Handles  NPM(K)    PM(K)      WS(K)     CPU(s)    Id       SI    ProcessName
   -------       ------      -----          -----            ------       --        --      -----------
    128         9           1684       7600           0.02     3768    3      notepad


A continuación Se ejecuta Get-Process en el host 

PS C:\Users\Administrator> get-process -name n*

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id       SI   ProcessName
-------       ------          -----          -----          ------        --       --      -----------
   128        9             1684         7600        0.02      3768    3      notepad

El proceso Notepad con ID 3768 también está presente en el host. Se nota la diferencia de aislamiento respecto del Hyper-V Container.