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..