Bien amigos, en las anteriores entregas hemos hablado acerca de contenedores y qué son, además de haberles mostrado algunas opciones interesantes para probar la plataforma sin necesidad de instalar software localmente.
Esta segunda parte tiene más elementos que nos van a ayudar a conocer más acerca de los contenedores y particularmente de Docker, que es lo que hemos venido trabajando en esta serie de entregas.
La vez pasada vimos un poco más lo que pasa por debajo cuando ejecutamos un contenedor.
Hoy vamos a hablar del aislamiento entre contenedores y otros aspectos que nos harán entender más acerca de esta tecnología.
Al igual que en la anterior ocasión, vamos a usar un contenedor con Linux Docker para nuestros ejercicios, entonces como la imagen no se encuentra localmente es necesario descargarla la primera vez que se ejecuta. (En realidad yo “limpio” mi sistema antes de empezar a hacer los ejercicios del blog, pero si no fuese así, ya la imagen la tendría descargada de la última vez).
Simplemente usé el comando Docker run alpine
Si lo notaron, me encuentro en un ambiente de Powershell, por eso se ve el prompt PS, y sin duda me encuentro en una máquina Windows, en este caso Windows 10 Pro, que me permite tener Docker instalado, -de ello hablaré en otra entrega-
Como ya se dijo, -y sólo por recordarlo- fue necesario descargar la imagen de Linux Docker dado que no se encontraba localmente.
Ahora puedo ejecutar la imagen y dentro de ella puedo decidir que me liste el contenido de sus directorios: (Esto es lo que hay adentro del contenedor)
Ahora podemos listar los contenedores de nuestro sistema y observamos lo siguiente:
Todos se encuentran con el status Exited (0), que indica que ya ejecutaron, además observen el comando que se ejecutó en cada uno de ellos.
Uno se pregunta por qué se ven tantos contenedores listados siendo que todos vienen de la misma imagen.
Este es un concepto muy importante de seguridad en este mundo de los contenedores. A pesar de que cada vez que se ejecutó el comando Docker container run se usó la misma imagen de Docker, cada ejecución se hizo en un contenedor separado y aislado de los demás.
Cada contenedor tiene su propio filesystem (sistema de archivos) separado y corre en su propio espacio separado de los demás (namespace).
Por defecto, no hay manera que un contenedor interactúe con otros contenedores, incluso así vengan de la misma imagen como en este caso. Cada uno es como una isla y es independiente de los demás.
Veamos esto un poco más. Intentemos ahora ejecutar un Shell (Es un ambiente de trabajo y ejecución de tareas) en un contenedor alpine de la siguiente manera:
Docker container run -it alpine /bin/ash
Observen que ya estamos adentro del contenedor, el signo de número (#) nos indica que somos el usuario root
Como estamos adentro de la máquina, ahora vamos a crear un archivo de texto:
Creamos el archivo hola.txt con el contenido Hola Mundo! y con el comando ls lo listamos.
Ahora nos salimos con exit del contenedor.
Si ejecutamos ahora el siguiente comando:
Docker container run alpine ls
Es el mismo comando ls que usamos estando adentro del contenedor, observemos el resultado:
Esta vez no se encuentra el archivo hola.txt. ¿Por qué? Justamente por el aislamiento del que venimos hablando. El comando se ejecutó en una nueva instancia de alpine, a pesar de usar la misma imagen base de alpine. Son dos instancias diferentes que no interactúan entre sí debido a que no hemos hecho nada hasta ahora para que suceda esta interacción.
Ya de entrada podemos ver que con este comportamiento podemos sacar ventaja de esta característica puesto que podemos usarla para crear copiadas aisladas de una aplicación o servicio y tenerlas en ejecución en la misma máquina sin que una imagen interfiera con la otra, y aquí empiezan a surgir conceptos muy importantes como el de DevOps, dado que puedo probar los efectos de un cambio que haga en mis aplicaciones usando este aislamiento.
Por supuesto, puedo volver a mi contenedor en donde se encuentra el archivo hola.txt.
Ejecutemos un comando ya conocido para ver los contenedores:
Docker container ls -a
El contenedor en el que se creó el archivo hola.txt es aquel en donde ejecutamos el shell /bin/ash, lo cual se puede ver en la columna COMMAND (ver imagen de arriba). El campo CONTAINER ID identifica esta instancia en particular, o sea que en este ejemplo es la identificada con el ID 74e7e8c34570.
Para ejecutar de nuevo la instancia podemos usar el comando con la estructura
Docker container start <container ID>
Es decir, en nuestro ejemplo usar el comando:
Docker container start 74e7e8c34570
Incluso se puede ejecutar el mismo comando usando algunos de los caracteres del ID del contenedor, dado que dicho ID es único:
Docker container start 74e7e
Con ese comando ya iniciamos el contenedor, ahora si usamos
Docker container ls
Vemos los contenedores en ejecución y en efecto nuestro contenedor, en donde ejecutamos /bin/ash:
Y ahora podemos listar el contenido de los directorios en dicho contenedor:
Docker container exec <container ID> ls
Es decir, en nuestro caso el comando es:
Docker container exec 74e7e ls
(Recuerden que usamos el ID abreviado)
Bueno, espero que les haya gustado el contenido que he venido desarrollando hasta ahora.
En nuestras próximas entregas hablaremos acerca de cómo crear nuestras propias imágenes a través de un archivo denominado Dockerfile y muchas más cosas interesantes.
¡No se pierdan la próxima entrega! Un abrazo para todos.
