Power Shell Desired State configuration (DSC) – Aplicando las configuraciones

Buenas,

En este post de la serie me gustaría hablaros sobre el procedimiento para aplicar las configuraciones definidas mediante DSC. Aunque es perfectamente posible aplicar las configuraciones usando un Pull server el cual se encargará de aplicar las configuraciones definidas mediante DSC en los nodos destino, en este caso veremos cómo aplicar las configuraciones de manera manual en nuestros nodos destinos partiendo del fichero MOF y haciendo un push.

Antes de meterme en harina con este post me gustaría recomendaros la lectura de las dos primeras entradas de la serie:
Power Shell Desired State configuration (DSC) – Introducción Teórica
Power Shell Desired State configuration (DSC) – Recuros y Generación del fichero MOF

Primero que todo me gustaría mencionar que existen dos métodos de aplicar las configuraciones definidas mediante DSC. El primero de ellos sería mediante Pull y en la cual necesitaríamos apoyarnos en pull server el cual es consultado por los nodos de DSC para recibir dichas configuraciones, es cierto que este método añade un modo de automatización adicional a la hora de aplicar las configuraciones de dsc y suele ser la mejor opción en la mayoría de los escenarios. La segundo de los métodos sería mediante Push, con este método aplicar las configuración definidas mediante dsc de manera manual en nuestros nodos destinos, si bien esta opción requiere ejecutar un par de comandos de powershell en los los nodos donde queremos aplicar la configuración, será la mejor opción cuando queremos testear una configuración definida mediante DSC o cuando queremos aplicar una configuración la cual por algún motivo solo se debe aplicar una vez.

Como ya adelante al principio de este post, en este ocasión me centrare en el procedimiento para aplicar de manera manual mediante push las configuraciones definidas en el fichero mof y será en la siguientes entradas de la serie en las que veremos configurar un servidor de DSC el cual se encargará de hacer un pull de las configuraciones

Una vez hecha esta breve introducción teórica paso a detallar los dos requerimientos que deben tener los nodos donde queremos aplicar las configuraciones definidas mediante.

1- Tener en el nodo destino los recursos de DSC necesarios para recibir la configuración: En el segundo post de la serie podéis encontrar información detallada sobre los recursos de DSC. Como regla general podemos decir que si usamos recursos que vienen por defectos estos probablemente estén incluidos en nuestro nodo corriendo bajo Windows server. Sin embargo, si hemos descargado algún recurso personalizado este deberá ser copiado en el nodo destino antes de aplicar las configuraciones de DSC

2- PowerShell remoting habilitado: Para saber si PowerShell remoting está habilitado podemos usar la función de PowerShell detallada en el siguiente link

Llegados a este punto pasamos a ver los pasos que debemos seguir para hacer un push de la configuración de DSC en nuestro nodo destino, los cuales serían los siguientes:

1- Copiamos el ficheros mof al nodo donde queremos aplicar las configuraciones

2- Aplicamos la configuración ejecutando el siguiente comando:
Start-DSCConfiguration -Path ‘C:\TestDSC’ -Wait –Verbose

Espero que resulte de utilidad, en la siguiente entrada de la serie veremos cómo configurar el pull server.

Un saludo

Los Jueves Tecnológicos de Itpro.es – Serie de Webcast

Buenos días

Desde la comunidad Itpro.es estamos organizando una serie de webcast que dará comienzo el próximo jueves 28/01 con el primero de los webcast de la serie y que se extenderá durante 8 semanas todos los jueves de 19:00 a 20:00.

Todos los ponentes de estos webcast somos Microsoft MVP o empleados de Microsoft y la temática de los mismo es bastante diversa pero siempre tratando temas candentes en el mundo de los ITpros

En el siguiente link podéis encontrar información acerca de las temática, ponentes y fechas de los distintos webcast para registraros en los que os parezcan más interesantes.

Link webcasts – Jueves tecnológicos de Itpro.es

Espero que os resulten interesantes.

Un saludo

Power Shell Desired State configuration (DSC) – Recuros y Generación del fichero MOF

Buenas,

En esta segunda entrada de la serie veremos como usar los recursos de DSC los cuales nos permitirán generar ficheros MOF, estos ficheros serán los que tendrán las configuraciones que posteriormente aplicaremos mediante DSC en nuestro entorno.

Antes de iniciar este post me gustaría recomendaros la lectura de la primera entrada de la serie en la cual introducía DSC de manera un poco más teórica con el objetivo de aclarar los conceptos principales de esta tecnología. Este artículo podéis encontrarlo en el siguiente link

Para entender de manera correcta como debemos proceder para crear un fichero MOF es necesario primeramente entender el papel que juegan los recursos en el mismo. Un recurso funciona de una manera similar a un cmdlet de PowerShell y define las funcionalidades que se podrán aplicar en un fichero MOF. Por defecto DSC incorpora una serie de recursos los cuales nos permiten definir configuraciones en los elementos listados a continuación:

– Procesos de Windows
– Funcionalidades de Windows
– Gestión de usuarios locales
– Servicios
– Script
– Registro
– Gestión de paquetes (MSI & EXE)
– Log
– Gestión de grupos locales
– Variables de entorno
– Carpetas y ficheros

Por supuesto existe la posibilidad de descargar recursos adicionales a los incorporados por defecto teniendo en cuenta que los ficheros MOF se basan en un standard definido por la industria.

Una vez hecha esta breve introducción sobre los recursos de DSC, veremos donde podemos descargar dichos recursos así como el procedimiento de instalación de los mismos.

Aunque los recursos se pueden encontrar en diversos sitios de internet y basta con hacer una búsqueda en nuestro buscador preferido para encontrarlos, me gustaría dejaros un par de links a dos sitios que considero interesantes y los cuales suelo usar para buscar recursos.

– Technet gallery recursos para IT profesional
https://gallery.technet.microsoft.com/site/search?f%5B0%5D.Type=Tag&f%5B0%5D.Value=DSC%20Resource%20Kit&f%5B0%5D.Text=DSC%20Resource%20Kit
– Apartado de DSC en Github
https://github.com/PowerShellOrg/DSC

Una vez tenemos descargado el recurso de DSC que queremos instalar, el procedimiento de instalación es super sencillo. Tan solo debemos descomprimir los archivos descargados y copiarlos en el directorio C:\Program Files\WindowsPowershell\Modules de la máquina que usaremos para crear los archivos MOF

Llegados a este punto ya debemos de tener la máquina de desarrollo que usaremos para crear los ficheros MOF lista para realizar a esta tarea, por lo tanto abrimos Power Shell ISE donde procederemos a crear el fichero MOF.

Como ya mencione anteriormente los ficheros MOF esta basados en un standard definido por la industria pero se pueden crear y editar perfectamente usando PowerShell y el tener conocimiento de PowerShell nos facilitará muchísimo su creación. Para explicar la estructura de estos ficheros usare el siguiente fichero de ejemplo el cual tiene como objetivo forzar la instalación del cliente telnet mediante DSC.

Como podéis observar el fichero tiene tres partes claramente diferenciadas. Una primera parte que empieza en el comienzo del script y acaba en el final del mismo define donde comienza y acaba la configuración. La segunda parte que define los Nodos sobre los que se aplicará la configuración y la tercera indica las configuraciones que realizaran (en nuestro caso forzará a que el cliente telnet se encuentre presente)

Por último, una vez tenemos definida la estructura del fichero de configuración, guardamos el mismo con extensión .ps1 y lo ejecutamos para generar el fichero MOF.

Estos serían todos los pasos que debemos realizar para crear un fichero MOF de DSC, en la siguiente entrada de la serie veremos cómo aplicarlos en un máquina.

Espero que resulte de utilidad.

Un saludo

Power Shell Desired State configuration (DSC) – Introducción Teórica

Buenas

Comienzo hoy una serie de artículos sobre PowerShell Desired State Configuracion, DSC a partir de ahora. El objetivo de esta serie es cubrir tanto la teoría como la práctica de DSC y aunque aún no tengo 100% claro cuántos artículos compondrán la serie, estoy totalmente seguro que serán al menos 3 o 4.

En este primer articulo de la seríe me gustaría explicar de una manera un poco más teórica que es DSC, como podemos usarlo, así como los requisitos que debemos asegurar para poder ejecutar la solución

Obviamente me gustaría este post explicando que es DSC. PowerShell Desired State Configuration es una extensión de Power Shell incluida a partir de la versión 4 que contiene todos los cmdlets y la lógica necesaria para poder forzar configuraciones en nuestros sistemas. Cuando forzamos una configuración con DSC como puede ser por ejemplo la instalación de el cliente telnet en nuestro servidores, todos los servidores reciben esta configuración y si se cambia a mano por algún administrador se volverá aplicar de nuevo en el próximo refresco de DSC. Por lo tanto podemos decir que funciona de una manera muy similar a como funcionan las GPOs en este aspecto pero con DSC podemos utilizar todos el potencial de PowerShell.

Para almacenar la definición de las configuraciones las cuales aplicaremos a nuestros sistemas, DSC usa unos ficheros con extensión MOF los cuales veremos un poco más en detalles en futuros post. Estos ficheros con extensión MOF puede ser aplicados directamente haciendo un push de los mismos a los servidores destinos o bien mediante un pull server de DSC el cual será el encargado de aplicar las configuraciones.

Como pienso que muchas veces es mucha más explicativa una imagen que 1000 palabras me gustaría dejaros la siguiente, la cual creo que explica bastante bien cómo funciona DSC y como se aplican sus configuraciones en los sistemas destino.

Antes de pasar a mencionar los requerimientos me gustaría dejar claro que el principal beneficio detrás de DSC es poder asegurar que los servidores de nuestra infraestructura están configurados como nosotros queremos, igualmente nos facilita bastante la labor a la hora de configurar nuevos servidores puesto que nos aseguraremos de una manera fácil y automática que estos reciben las configuraciones definidas, y quizás la mayor ventaja es tener la certeza en todo momento de que si una configuración es modificada fuera de lo que dicen los parámetros de nuestro fichero MOF de DSC está será aplica en el siguiente refresco de configuraciones de DSC.

Por último, para finalizar este post, paso a detallar los requisitos de DSC que son los siguientes:

Windows PowerShell 4.0 o superior
Windows Management Framework 4.0 o superior
PowerShell Remoting Habilitado
Windows Server 2008 R2 SP1 o superior
Windows 7 Sp1 o superior
.Net 4.5 o superior

Espero que resulte de utilidad.

En el siguiente post de la serie veremos cómo construir ficheros mof de DSC.

Un saludo

Gestión de Máquinas virtuales de Azure usando el server manager en local

Buenas,
Aunque en la mayoría de los casos gestionamos nuestras máquinas virtuales en Azure usando una conexión rdp hay veces que es más conveniente, fácil y sencillo usar el Server Manager o PowerShell remoting para gestionar las mismas. Por lo tanto paso a detallar los pasos que debemos seguir para conseguirlo.

1- Evidentemente la máquina en local que queramos usar para gestionar nuestras vms de azure debe de tener el server manager. Si esta máquina es un Windows server 2012 o 2016 no debemos hacer nada extra sin embargo si esta máquina es un Windows 8 o un Windows 10 debemos instalar las remote server administration tool que encontraremos fácilmente en la página de Microsoft.

2- Habilitamos el remote managent en las máquinas de azure que queramos gestionar, para ello nos conectamos a las mismas por rdp y habilitamos el remote management dentro de las propiedades de local server en el server manager.

3- Dentro de nuestra vm en azure accedemos la consola de administración de firewall avanzada y dentro de las inbound rules localizamos Windows Remote Managent (public profile)

Hacemos doble clic sobre la misma y accedemos a la pestaña scope donde definiremos la ip desde la que nos conectaremos o como en este ejemplo permitiremos la conexión desde cualquier ip.

4- Definimos un endpoint en Azure para cada máquina a gestionar por WINRM usando el puerto 5985

5- Añadimos las máquinas de azure que queremos gestionar como confiables en la máquina de gestión ejecutando las siguiente línea de PowerShell como administrador
Set-Item WSMan:\localhost\Client\TrustedHosts SERVERNAME.cloudapp.net -Concatenate –Force

6- Abrimos el ServerManager en la máquina local que usaremos para gestionar las vms de azure y añadimos nuestras vms.

7- Por último pinchamos con el derecho sobre el nombre de el servidor y pulsamos en Manage As para introducir las credenciales de la máquina en Azure

Estos serían todos los pasos que debemos seguir

Espero que resulte de utilidad

Un saludo

Hyper-V 2016 – Shielded Vms con Virtual TPM

Buenas

Una de las novedades que trae Hyper-V en windows server 2016 es shielded VMS la cual nos proporciona una capa de protección a nuestras máquinas virtuales con una combinación de tecnologías conocidas como shielded vms. Esta tecnologías nos permiten encriptar de las vms con Bitlocker o con otra solución de encriptado así como aislar de manera segura las tareas de administración entre los administradores de el Fabric de las administración de la propio role que se ejecuta en la máquina virtual.

Las Shielded Vms solo se puede ejecutar en el fabric en el que se crean el cual será el propietario y se encargará de encriptar la máquina virtual.

Para convertir una máquina virtual standard en una Shielded vm “máquina virtual protegida” tenemos dos posibilidades:

1- Mediante Active Directory:
Simplemente requiere introducir los host the hyper-V en un grupo creado para tal propósito en directorio activo de tal manera que solo los administradores de hyper-v que tienen credenciales en ese dominio podrán administrar las vms protegidas con este mecanismo.

2- Mediante Virtual TPM: Creo un TPM virtual el cual se encarga de encriptar todo el contenido de la máquina virtual usando Bitlocker. Evidentemente esta funcionalidad requiere que host que ejecuta las máquinas virtuales tenga un TPM físico

Igualmente es importante mencionar que las shielded vms tienen los siguientes prerrequisitos:

1- Correr en un host con Windows server 2016

2- La máquina virtual debe ser de generación

3- El sistema guest de la vm será Windows server 2012, Windows 8 o superiores

Una vez hecha este breve intro acerca de cómo podemos proteger nuestras vms corriendo bajo hyper-v en Windows 10 y Server 2016 pasamos a ver de manera práctica como habilitar la protección en una de nuestras máquinas virtuales mediante virtual TPM.

1- Comprobamos que nuestro host tiene un chip TPM. Para ello accedemos al administrador de dispositivos y lo comprobamos dentro de los Security devices. Es recomendable que el tpm sea versión 2.0 aunque en esta demo use uno versión 1.2

2- Ejectuamos el siguiente script de powershell para habilitar el modo aislado en nuestro Host de Hyper-V

Install-WindowsFeature Isolated-Usermode
New-Item -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Force
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name EnableVirtualizationBasedSecurity -Value 1 -PropertyType DWord –Force

3- Accedemos a la configuración de la vm sobre la que queremos habilitar el tpm virtual, opciones de seguridad y habilitamos el virtual tpm

Por ultimo me gustaría mencionar que podemos definir las tres siguientes opciones dentro de security profile.

– No adittional protection:
Su propio nombre lo indica.

– Data protection: Encripta las máquinas virtuales en saved state y el tráfico de lives migrations

– Shielding: Ademas de encriptar las máquinas virtuales en saved state y el trafico de lives migrations deshabilita las consolas de gestión de las máquinas para los administradores de el fabric.

Espero que resulte de utilidad y tener la posibilidad de ampliar este post incluyendo información de el role host guardian service para gestionar las shielded vms.

Un saludo

Backup de maquinas virtuales en Azure

Buenas

Hoy me gustaría explicar el procedimiento para realizar copias de seguridad en Azure de máquinas virtuales que están ejecutándose en el mismo Azure.

El procedimiento para configurar el backup es bastante sencillo y nos permite por supuesto restaurar por completo una máquina virtual en Azure.
Para configurar el backup de nuestras máquinas virtuales en Azure seguiremos los siguientes pasos:

1- Accedemos a la parte de recovery services y nos aseguramos que tenemos un backup vault el cual debe estar en el mismo datacenter que las máquinas sobre las que queremos hacer backup. En caso de no tenerlo podemos crearlo de una manera muy sencilla.

2- Accedemos al backup vault y pulsamos en Discovery para que azure nos busque las máquinas sobre las que podemos hacer backup

3- Pulsamos en register para iniciar el wizard que nos permitirá registrar las máquinas con la funcionalidad de backup

4- Seleccionamos las máquinas que queremos registrar y por lo tanto que queremos hacer backup y aceptamos

5- Seguidamente pulsamos en protect

6- Posteriormente selecciones la máquina que queremos proteger la cual debe haberse registrado antes

7- Definimos un nombre para la política de protección e indicamos con que frecuencia realizaremos los backups.

8-– Definimos el periodo de retención para los backups y finalizamos el wizard definiendo de esta manera la política de protección para nuestras vms.

Espero que os resulte de utilidad.

Un saludo

Licenciamiento en Windows Server 2016

Buenas

El pasado 3 diciembre Microsoft público un whitepaper que está dando bastante de que habar acerca de los cambios en el licenciamiento de Windows server 2016 los cuales me gustaría resumiros en este post.

Primero que todo me gustaría mencionar que teniendo en cuenta que Windows Server 2016 no ha sido liberado en versión final no descarto que la información publicada en este post esté sujeta a cambios una vez liberada la versión final.

Referente a las ediciciones de Windows Server 2016 parece estar claro que solo tendremos dos ediciones de esta sistema operativo (Standard y Datacenter) al igual que sucede con Windows Server 2012 y Windows Server 2012 R2. Sin embargo si tendremos diferencia entre las funcionalidades incluidas en la versión Standard y Datacenter a diferencia de lo que sucede en Windows server 2012/R2 donde no hay ninguna diferencia en cuanto a funcionalidad entre las ediciones y la única diferencia entre las mismas es el número de máquinas virtuales que se pueden licenciar con cada una de ellas. Las diferencias de funcionalidades entre la versión Standard y Datacenter de Windows server 2016 creo que quedan bastante bien reflejadas en la siguiente imagen:

El siguiente cambio importante en la parte de licenciamiento es que Windows Server 2016 se licenciará siguiendo un modelo de core + cals en lugar de procesador + cals como venía sucediendo hasta ahora y aquí es importante mencionar las siguientes puntos.

– Todos los cores de un servidor físico se deben licenciar

– El mínimo de cores a licenciar por servidor físico será 16 y el mínimo de cores a licenciar por procesador será 8

– El precio de la licencia de Windows Server 2016 válida para 16 cores tanto en standard como en datacenter será el mimo que el precio de la licencia standard o datacenter válida para 2 procesadores que ahora tenemos en Windows Server 2012 R2

– En Servidores donde tengamos más de dos procesadores físicos o donde los procesadores físicos tengas más de 8 socket será donde tendremos un coste adicional.

– Las licencias para cores adicionales se venderán siempre en paquetes de dos y coste de las mismas será 1/8 del precio de licencia mínima que incluye 2 procesadores y 16 cores.

– El calculo de cores se hace por cores físicos y no por cores virtuales, por lo tanto dará igual de cara al licenciamiento si los cores tiene hyper-threading o no.
– Las cals de usuario o de dispositivo continuaran funcionado como hasta ahora y cada dispositivo o usuario que acceda al servidor necesitará una call.

– Los derechos de virtualización para máquina virtuales permanecen intactos o lo que es lo mismo una licencia de Standard nos permitirá ejecutar dos vms y una de datacenter un numero de vms ilimitado para el host licenciado.

– El licenciamiento de containers será idéntico al de máquinas virtuales, por lo tanto una licencia de standard dos container una de datacenter ilimitados containers

Como continuación de los puntos mencionados en la parte superior me gustaría anexar la siguiente imagen la cual creo que explica de una manera bastante grafica como funcionará el licenciamiento en Windows server 2016 para servidores como más 8 cores por procesador o con más de dos socket por servidor.

Espero que resulte de utilidad.

Un saludo

Hyper-V Containers en Windows server 2016 TP4 (2 de 2)

Buenas
Atendiendo a lo prometido, en esta segunda entrada de la serie me gustaría explicar el procedimiento paso a paso para desplegar un container host sobre Windows server 2016 TP4 el cual será configurado para alojar Hyper-V Containers.
Los pasos a realizar serán los siguientes.

1– Teniendo en cuenta que nuestro container host correrá en una máquina virtual de Hyper-V lo primero que debemos hacer es asegurarnos que nuestro host de Hyper-V corre sobre Windows 2016 TP4 o Windows 10 build 1056 o superior. Una vez hemos comprobado este punto desplegaremos la máquina virtual que funcionará como container host siguiendo el procedimiento que ya detalle en su momento en el siguiente post el cual también es valido para la versión TP4.

2– Arrancamos la máquina virtual que acabamos de crear y arrancamos powershell dentro de la misma.

3– En mi caso procederé a poner el teclado en Español para poder introducir los comandos de powershell con mayor comodidad, para ello ejecuto el comando
Set-WinUserLanguageList – languagelist es-es

4– Comprobamos que la vm que acabamos de desplegar ya tiene el role de container host instalado ejecutando el comando
Get-Windowsfeature | where {$._installed}

5– Chequeamos que tenemos un virtual switch configurado en modo nat para ejecutar containers en nuestra vm para ello ejecutamos el comando
Get-vmswitch

6– Comprobamos el direccionamiento nat del virtual switch ejecutando
Get-netnat

7– Por último comprobamos que la vm desplegada contiene únicamente la image de containers windowsservercore usando el comando
get-containerimage

8– Una vez realizada estas comprobaciones apagaremos la vm que funcionará como hyper-v container host con el objetivo de preparar la misma para que soporte nested virtualization. Para que la vm soporte Nested virtualization esta tiene que estar configurada con más de 1 virtual cpu, tener deshabilitada la memoria dinámica y tener habilitado el MAC addresss spoofing en la propiedades avanzadas de la tarjeta de red.

9– Tras preparar el hardware virtual de la máquina virtual que funciona como container host comprobamos que la misma no tiene configurada las virtualizations extensions necesarias para habilitar nested virtualization usando el comando.
Get-vmprocessor –vmname virtual_machine_name | FL *

10– Habilitamos las virtualizations extensions ejecutando el commando.
Set-vmprocessor -vmname virtual_machine_name –ExposevirtualizationExtensions $True

11– Arrancamos de nueva la máquina virtual que funcionará como Hyper-V container host y arrancamos una consola de powershell en la misma.

12– Instalamos la Feature de hyper-v en nuestro container host ejecutando el siguiente comando.
Install-WindowsFeature Hyper-V –Includemanagementtools -Restart

13– Ejecutamos los comandos siguientes para desplegar la imagen de containers Nanoserver. Esta es la únicamente imagen soportada para crear Hyper-V containers en Windows server 2016 tp4. Sin embargo en futuras releases se espera que la imagen de Windows server core también este soportada.
Install-PackageProvider ContainerProvider –Force

Find-ContainerImage

Install-ContainerImage –Name NanoServer –Version 10.0.10586.0

14– Por ultimo crearemos un container usando la imagen de NanoServer ejecutando el siguiente comando
New-Container –Name containername –ContainerImageName NanoServer –Switchname “virtual switch name” –Runtime HyperV

El resto commandos necesario para trabajar que el container serían los mismos que usamos para gestionar los Windows Server Container. Podéis encontrar más información sobre los mismos en este post.

Espero que resulte de utilidad

Un saludo

Hyper-V Containers en Windows server 2016 TP4 (1 de 2)

Buenas

El pasado 19/11/2015 salío a la luz la TP4 (Techinical Preview 4) de windows server 2016. Entre otras novedades incluidas en esta Technical Preview me gustaría destacar y comentar la funcionalidad de Hyper-V Containers.

En este primer post de la serie me gustaría hacer una introducción un poco más teórica sobre que son los Hyper-V Containers y en qué se diferencian de los Windows Servers Containers para en la segunda entrada de la serie demostrar de manera práctica como crear un Hyper-V server container sobre Windows Server 2016 TP4.

Primero que todo me gustaría refrescar que son los containers y que nos aportan. Los Containers en sí mismo son otro tipo de virtualización también conocida como virtualización del Sistema operativo en la cual la aplicación que corre bajo un container tiene la percepción de que sea ejecutando sobre un sistema operativo totalmente aislado e independiente.

Dentro de los containers en el mundo Windows encontramos dos tipos:

Windows server containers: Este tipo de containers ya existían en versiones anteriores a la TP4 de Windows server 2016 los cuales comparten el Sistema operativo con otros containers y con el propio host por lo tanto al no existir una capa que aislé realmente unos containers de otros podría suceder que un incidencia en un container afectará al resto o al porpio host. Estos containers son ideales para escenarios en los que el host realmente confía en el comportamiento de los containers que ejecuta y los containers también son confiables entre ellos, también serán la mejor opción para aplicaciones que se dividen en multiples container o micro-services.

Hyper-V containers: Como ya he mencionado anteriormente este tipo de containers han aparecido como novedad en la TP4 de Windows Sever 2016 y la principal diferencia con respecto a los Windows Server Containers es que los Hyper-V containers tienen una copia del kernel y parte de la memoria directamente asignado a los mismos, de esta manera se consigue un nivel de aislamiento total. Al ofrecer un nivel de aislamiento mayor los Hyper-V Containers tardan algo más de tiempo en arrancar y la densidad de consolidación por host es algo menor. Sin embargo, este tipo de containers serán la solución idónea para evitar que un incidente en un container pueda afectar al rendimiento del host o de otros containers.

Igualmente me gustaría menciona que tanto los Windows server container comos los hyper-V Containers se puede administrar tanto con el cliente de docker como con Power Shell y que es posible migrar fácilmente un aplicación de un Windows server Container a un Hyper-V container.

Por último, como normalmente una imagen suele ser más explicativa que 1000 palabras me gustaría dejaros una pequeña imagen que creo que refleja bien la diferencia entre Windows Server Container e Hyper-V Containers.

Espero que os resulte de utilidad, en la segunda entrada de la serie veremos como crear hyper-V container usando Windows server 2016 Tp4.

Un saludo