Instalación de containers en Windows 10 / Server 2016. Ejemplos de contenedor web

by jmtella 4. diciembre 2016 12:11

 

INSTALACION Y USO DE LOS CONTAINERS

Windows 10 / Server 2016 traen la tecnología de base, para ello hay que tener instalado el role de Hyper-V así como los "Containers" instalados. Esto crea la base de uso de DOCKER, así como suministra el aislamiento básico a nivel de red para la comunicación entre máquinas y la red usando los switchs, o redes virtuales de Hyper-V.

La instalación de DOCKER es diferente si se realiza en Windows 10 o en Server 2016. En ambos casos hay que hacerlo desde una consola de PowerShell arrancada con derechos Administrativos.

En Windows 10:

Código:

 Invoke-WebRequest "https://download.docker.com/components/engine/windows-server/cs-1.12/docker.zip" -OutFile "$env:TEMP\docker.zip" -UseBasicParsing

 expand-archive -path "$env:TEMP\docker.zip" -DestinationPath $env:ProgramFiles

 [Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\Docker", [EnvironmentVariableTarget]::Machine)

 $env:path += ";c:\program files\docker"

dockerd --register-service

 Start-Service Docker

En Windows Server 2016

 Código:

 Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

 Install-Package -Name docker -ProviderName DockerMsftProvider

 Restart-Computer -Force

 

NOTA: Los comandos anteriores de PowerShell nos pueden solicitar confirmación. Responder afirmativamente.

Una vez instalado, podemos comprobar la version con el comando (siempre en PowerShell):

Código:

 docker version

 NOTA:

Particularmente no me gusta que se tenga que descargar aparte del sistema operativo y encima que tengamos que preocuparnos de la versión y que Windows no lo mantenga. Pero de momento esto es lo que hay.

Ahora, vamos a cargar las "Imágenes" del Sistema operativo Recordar el concepto de "imagen", que no es lo mismo que el contenedor, tal y como se vio en la introducción:

https://jmtella.com/jmt/post/2016/12/04/Introduccion-a-los-Contenedores-(containers)-Su-implementacion-en-Windows-10-Windows-Server-2016-.aspx


Para la carga de imágenes se usa el comando docker pull, en este caso:

Código:

 docker pull microsoft/windowsservercore

 docker pull microsoft/nanoserver

 

Con esto tendremos ya las imágenes base para su uso, tanto en Windows 10, como en Server 2016.

Siempre podremos analizar las imágenes que tenemos en el repositorio local con el comando:

 Código:

 docker images

Si una imagen no tiene containers asociados, siempre podremos borrarla, por ejemplo:

Código:

 docker rmi microsoft/nanoserver

 El comando docker admite muchos parámetros, para verlos, debéis ejecutar:

Código:

 docker --help

Comandos más comunes:

 Código:

 docker ps -a

(nos muestra los containers creados en nuestro repositorio local)

 docker ps

(nos muestra los containers que están en ejecución)

  docker rm container_ID

(nos borra un container enviando el "container_ID" que nos ha mostrado previamente el comando docker ps -a)

 

EJERCICIO:
Crear un container con un servidor Web.

El comando docker run nos permite la creación de un container a partir de una imagen. Este comando admite su subparámetros, por ejemplo -it indica que voy a actuar con una consola interactiva en el nuevo container y por tanto ejecutar en él el comando que le indique (que en general, un cmd o un powershell). El comando -p puerto_origen: puerto_destino, indica que vamos a hacer un NAT desde nuestra maquina real, puerto_origen, al contenedor, en el puerto_destino. En el caso de un server web, seria un -p 80:80.

Por tanto, ejecutaríamos:

Código:

 docker run -it -p 80:80 microsoft/windowsservercore powershell

 La primera vez, tarda un poco (dependiendo de nuestro disco, en un SSD es rápido).

Cuando finalice, parece que no ha hecho nada, ya que seguimos en la misma consola de PowerShell, pero no es así, la consola, aunque sea la misma, es un powershell que ya se está ejecutando "dentro" del nuevo contenedor, por lo que cualquier comando que demos, realmente se ejecuta dentro del contenedor, en este caso, dentro de un Windows 2016 ServerCore que es la imagen que hemos precargado.

Como es un server "virgen" debemos instalarle el IIS. Como la consola es un powershell dentro del contenedor, ejecutamos para ello el comando:

 Código:

 Install-WindowsFeature web-server

 Una vez finalizado, dentro de esa consola podemos ejecutar un IPCONFIG para ver la IP que tiene ese contenedor virtual. Será del rango 172.xx.xx.xx (mas adelante, veremos que realmente la maquina real, ha creado un servicio de NAT usando los switchs virtuales de Hyper-V)

Desde nuestra maquina podemos lanzar ahora un navegador a esa IP y veremos que nos saca la pagina por defecto del server IIS recién instalado.

Recordemos que en general, y una vez hayamos finalizado el container, realmente desde la red se lanzará un acceso a nuestra ip del host. Pero como el container tiene la redirección mediante NAT (-p 80:80) esta se redirigirá al container.

Dentro del PowerShell del container, nos creamos una pagina de prueba. Para ello, ejecutamos:

Código:

 echo "Hola gente. Esto es desde un container de Windows" > c:\inetpub\wwwroot\test.html

 Para "cerrar" el contenedor, simplemente salimos de la consola de PowerShell con el comando exit. Esto nos devuelve ahora al PowerShell de nuestra máquina.

Ahora mismo, recordemos que con el comando docker ps -a podemos ver el container. Si nos hemos salido de forma normal, con el exit, el contenedor se cierra y no queda en ejecución. Para ver que no está en ejecución, ejecutad docker ps. Si hubiésemos cerrado la consola, seguiría en ejecución.

En ese caso, si quisiéramos pararlo, simplemente con el comando:

 Código:

 docker stop container_ID

 Siendo container_ID el numero de identificación que nos devuelve el comando docker ps.

Evidentemente para iniciar un container, se puede hacer con el subcomando start:

 Código:

 docker start container_ID

 

* Podemos probar el container desde nuestra red. Para ello, verificad que tenemos abierto el puerto 80 en el cortafuegos anfitrión o bien crear una regla en el cortafuegos de nuestra maquina anfitrión para permitir dicho puerto. Podemos hacerlo desde Herramientas Administrativas, o ya que estamos en PowerShell en nuestra maquina anfitrión, mediante el comando:

Código:

New-NetFirewallRule -Name "ServidorWeb" -DisplayName "ServidorWeb" -Protocol tcp -LocalPort 80 -Action Allow -Enabled True

 Ahora desde cualquier maquina de nuestra red, id a la pagina recién creada en nuestro contenedor:

Código:

 http://ip_de_la_maquina_anfitrion/test.html

 Estos containers son ya permanentes. Si reiniciásemos la maquina los containers siguen existiendo pero estarían apagados por lo que hay que arrancarlos con el comando start.

El subcomando start admite subparametros. Es interesante el -i (interactive) ya que ejecutando, en nuestro caso:

Código:

 docker start -i container_ID

 entraríamos en la consola de PowerShell del contendor con lo cual podríamos seguir configurándolo (por ejemplo).

Ese contenedor ya está operativo. Pero si quisiéramos crear una imagen del contenedor en nuestro repositorio local, puede hacerse con el comando:

Código:

 docker commit Container_ID jmtella/servidorweb[:version1]

 Lo que va entre corchetes es opcional, y lo que hace es permitirnos guardar versiones de nuestro contenedor. (muy útil cuando estamos desarrollando o probando).

Podemos comprobar que la imagen se ha añadido al repositorio con el comando docker images.

Otros comandos útiles:

1) Exportar una imagen para usarla en otra maquina:

 

Código:

 docker save -o c:\containers_imagenes\mi_servidor_web.tar jmtella/servidorweb

 Ese fichero .tar lo podemos llevar a otra maquina y allí importarlo.

2) Importar una imagen desde fichero .tar:

 Código:

 docker load -i c:\containers_imagenes\mi_servidor_web.tar

 En la nueva maquina, evidentemente deberemos lo primero crear un container a partir de esa imagen importada, se hace tal y como vimos al principio:

Código:

 docker run -it -d -p 80:80 jmtella/servidorweb powershell

 Fijaros que igualmente podemos arrancar un segundo container en el puerto 8080 (por ejemplo).

Código:

 docker run -it -d -p 8080:80 jmtella/servidorweb powershell

 Y tendríamos dos servidores web en ejecución cada uno en un puerto. (si lo probáis, acordaros de poner una regla en el cortafuegos permitiendo ese puerto).

En próximos artículos veremos la red en los containers. En este caso hemos usado la característica de NAT, pero puede hacer en bridge, etc..

 

Introducción a los Contenedores (containers). Su implementación en Windows 10 / Windows Server 2016.

by jmtella 4. diciembre 2016 11:41

Algunos lo ven como el futuro de la virtualización, un paso más alla de la virtualizacion. Veremos que nos depara...

CONTENEDORES - INTRODUCCION.

 Tanto windows 10 como Server 2016 traen un nuevo concepto (en windows), pero viejo en informatica y muy extendido e implementado en otras plataformas que son los containers (contenedores).

 ¿Qué son los contenedores?: son "algo" que está aislados del sistema operativo base totalmente. Recuerda por ejemplo a las aplicaciones virtualizados con Thinapp de Vmware. El ejemplo es sencillo: un programa o un servicio, por ejemplo un servidor web, que está totalmente aislado: "contenido" en una imagen que es ejecutable pero que nunca interfiere al sistema principal: ni a los registros, ni tan siquiera al sistema de archivos.

 El padre de los contenedores es un proyecto llamado Docker (de software libre) www.docker.com Contiene unas 100.000 imágenes, tanto para Linux, como para Mac, e incluso, aunque menos, para windows.

Docker, consiste en:

 1) Un repositorio de imágenes.
 2) Un "daemon" (servicio) que usando esas imágenes es capaz de ejecutarlas aisladas del sistema operativo.
 3) Un cliente Docker, el cual es capaz de usar los servicios ofrecidos por los contenedores. El cliente puede estar an la maquina servidora (que tiene el daemon), o bien incluso en cualquier otra maquina accediendo a la servidora a traves de dicho cliente. La comunicacion es lo mas estandar del mundo (trafico http).

Por capas, consta de 4 conceptos:

 * Engine (Docker Cliente y Docker Server). Se comunican via http.

 * Images (imágenes) Son como piezas de Lego ... se puede ejecutar cualquier contenedor desde "esa" imagen. Son archivos por capas que usan un sistema de archivos UFS -Union File System-

 * Registries. Es donde Docker alamacena las imagenes. Hay de dos tipos: Publico y Privado. Docker gestiona el publico: es lo que se llama Docker HUB. Podeis, y debeios quien vaya a trabajar con COntainers, crearos una cuenta (gratuita) en http://hub.docker.com en donde estan todas las imagenes que otros han ido creando (incluso las que el propio Microsoft ha creado y subido allí) y en odne podreis, si quereis compartirlo con la comunidad, subir vuestras propias imagenes.

 * Containers: Es un conjunto de "Imágenes", "Operaciones sobre ellas" y "Entorno de ejecucion (chroot)". Docker nos crea dichos containers para paquetizar aplicaciones y servicios.


 Microsoft, con la característica de Containers, que debe instalarse como una característica en el sistema (Windows 10 / Server 2016), y además hay que instalar Hyper-V, lo que hace es crear una infraestructura para que Docker. Es decir, aparte de eso, deberemos instalar Docker. Ya veremos que version y como.

 No es exclusivo de W10 / Server 2016: hay Deamon / Cliente de Docker para W7 y superiores (8, y 8.1), por ejemplo.

 Como anticipo: los contenedores son de dos tipos:

 1) Los que se ejecutan directamente sobre el sistema operativo anfitrión.
 2) Los que se ejecutan dentro de un entorno virtual izado (por ejemplo, Hyper-V, o bien Virtual Box en sistemas anteriores). Esto últimos proporcionan mayor nivel de aislamiento.

 Windows 10 solo soporta el tipo 2). Windows Server 2016, tanto el 1) como el 2).

 * El tipo 1) se ejecutan sobre el mismo anfitrión compartiendo el mismo núcleo común.
 * El tipo 2) las diferentes instancias se ejecutan también sobre el anfitrión, pero no comparten el mismo núcleo ya que se aísla de cada uno usando la tecnología de virtualización de Hyper-V (usa la tecnología, no quiere decir que sea realmente una maquina virtual.

 NOTA: Windows 10, debe ser el Anniversay Update (o superior).

x86: Sobrepasar los 4 GB. Usar hasta 128 GB de RAM en 32 bits (Vista - Windows 7)

by jmtella 15. diciembre 2012 22:01
TIP para modificar el kernel de Windows 7 (32 bits) para que use toda la memoria instalada en nuestra maquina (hasta un máximo de 128 GB)
 
Necesario:
 
 
El proceso es tan simple como:
 
a) Modificar unos cuantos bytes en hexadecimal en el kernel.
b) Con el software del punto 2) crearnos un certificado autofirmado para firmar el nuevo kernel (ya que al modificarlo, el certificado anterior queda invalidado así como el checksum del archivo. En ese caso, el cargador del sistema: WINLOAD denegará su carga).
c) Modificar el boot mediante el comando bcdedit para poder arrancar, bien con el kernel viejo o bien con el nuevo modificado. (multiboot)
 
 
PUNTO a)  Modificar archivo.
 
* Copiar el archivo ntkrnlpa.exe de \windows\system32 con otro nombre, a la misma carpeta. Por ejemplo ntkrnew.exe que es el vamos a modificar con el editor hexadecimal.
* Localizar con el editor la cadena:
 
7C XX 8B 45 FC 85 C0 74 YY
 
siendo XX e YY cualquier valor, es decir debemos localizar realmente la cadena intermedia 8B 45 FC 85 C0 74 y fijarnos que justo dos posiciones antes de ella hay un 7C. Esta cadena debemos encontrarla dos veces.
 
Sustituir desde 8B hasta YY por el contenido: B8 00 00 02 00 90 90 (en los dos sitios encontrados en el fichero). Y guardar el fichero.
 
PUNTO b) Crear Certificado
 
Se supone que instalamos el DDK de Microsoft citado anteriormente en: C:\Winddk\.
 
Ejecutamos en una consola con privilegios:
 
cd \windows\system32
C:\Winddk\7600.16385.0\bin\x86\makecert -r -ss my -n "CN=TuNombre"
C:\Winddk\7600.16385.0\bin\x86\signtool sign -s my -n "TuNombre" ntkrnew.exe
 
PUNTO c) Modificar boot
 
En consola con privilegios:
 
bcdedit /copy {current} /d "Windows 7 128GB"
 
Esto nos devolverá un {GUID} que vamos a usar ahora en los siguientes comandos:
 
bcdedit /set {GUID devuelto antes} pae ForceEnable
bcdedit /set {GUID devuelto antes} kernel ntkrnew.exe
bcdedit /set {GUID devuelto antes} testsigning on
 
 
NOTA:
 
Con el parche anterior, nuestro sistema ya será capaz de manejar hasta 128 GB de memoria. Recordemos que aunque el espacio de direcciones de 32 bits tien un máximo de 2 elevado a 32 direcciones (es decir 4GB), mediante PAE pueden usarse lineas extra de direcciones usando ciertos bits de uno de los registros de control con lo cual el espacio total de direcciones puede llegar a direccionar hasta 128 GB de memoria. Tipicamente, en las CPU's clásicas, solo pueden usarse 4 bits correspondientes a 4 lineas extras de direcciones y por tanto "unicamente" podremos llegar a los 64 GB de memoria.
 
Las versiones server de 32 bits no tienen esta limitación.
 
LIMITACIONES
 
El problema que surge es la capacidad de los drivers de manejar direcciones (punteros) de más de 32 bits. Los drivers que han pasado la certificacion WHQL son capaces de funcionar en modo PAE. Ahora bien, en drivers no certificados no tenemos la garantia que sean capaces de ello. Si dichos drivers usan acceso directo al hardware (típicamente MMIO) y no estan preparados para funcionar con espacios de direcciones mayores de 32 bits, fallaran al truncar direcciones reales de memoria y estar el hardware remapeado por encima del espacio de direcciones de 4 GB. Un fallo en un driver, al ejecutarse en modo Kernel, implica la caída del Kernel con la consabida pantalla azul.
 
 
DETALLES DEL PARCHE
 
Las versiones del nucleo PAE, NTKRNLPA.EXE llaman a una rutina llamada MxMemoryLicense en dos lugares del codigo. Cada secuencia llama a la función no documentada ZwQueryLicenseValue la cual comprueba, bien por fallo de llamada (valor negativo) o bien cuando el valor leido es cero.
 
La secuencia es:
 

En el momento de ejecución el registro eax contiene el estado devuelto por ZwQueryLicenseValue. La primera instrucción es para verificar el fallo de llamada (indicado por un valor negativo). El resto de las instrucciones verifican si el valor recuperado es cero.

Las dos ocurrencias de este código deben ser parcheadas de la misma forma. El parche está pensado para modificar la ejecución de la manera mas sencilla y corta posible, en este caso, mover al registro eax el codigo que representa 128GB el cual es el menor valor que elimina la restricción de licencia. Deberemos cambiar los 7 bytes comenzando en 0x8B por las siguientes instrucciones:

(el codigo 90, o nop son placeholders que indica "not operacion").

 

Fundamentos del TCP/IP

by jmtella 15. diciembre 2012 21:02

CMD-BAT Lenguaje de Comandos

by jmtella 14. diciembre 2012 18:35

Manual y minicurso sobre los scripts de comandos. BAT / CMD siguen vivos, y cada vez mas usados por administradores de sistemas, en los Windows actuales.

 

LENGUAJE DE COMANDOS.doc (179,00 kb)