馃 Docker a nivel t茅cnico

馃嵖 驴C贸mo esta compuesta la arquitectura de Docker?

Docker utiliza una arquitectura cliente-servidor, lo que quiere decir que el servicio (demonio) Docker y el Docker client (cliente de Docker) son diferentes ejecutables. El cliente puede comunicarse con diferentes demonios (servicios de Docker) mientras que los demonios se encargan de la construcci贸n, ejecuci贸n y distribuci贸n.

Ambos cliente y servidor se comunican a traves de una REST API, esta comunicaci贸n puede llevarse a cabo mediante sockets de Unix o una interfaz de red.

馃イ 驴Qu茅 es dockerd?

El demonio que utiliza Docker es conocido como dockerd. Este escucha las peticiones a la Api y maneja los objetos en Docker como im谩genes, contenedores, redes y volumes.

馃イ 驴Qu茅 es el cliente de Docker?

El cliente de Docker es la aplicaci贸n a trav茅s de la cual el usuario interact煤a con Docker el servicio. Este cliente env铆a los comandos a dockerd. Por ejemplo si deseamos ejecutar un contenedor utilizando docker container run.

馃イ 驴Qu茅 son los docker registries?

El docker registry es muy similar a un repositorio de GitHub pero a diferencia de este almacena im谩genes en lugar de c贸digo. Docker utiliza DockerHub como su docker registry.

Cuando el cliente de Docker requiere crear un nuevo contenedor, este se comunica con el servidor Docker el cual a su vez solicita la imagen al Docker Registry (DockerHub). Cuando la imagen es descargada esta puede ser utilizada para crear el o los futuros contenedores.

馃イ 驴Qu茅 son los objetos de Docker?

Los objetos mas comunes de docker son:

Las im谩genes de Docker
Contienen instrucciones para crear los contenedores de Docker.
Los contenedores de Docker
Es una instancia aislada creada a trav茅s de una imagen de Docker.
Los servicios de Docker
Los servicios pueden escalar mediante contenedores alojados en m煤ltiples Docker hosts.
Se puede tener m煤ltiples Docker hosts trabajando en conjunto mediante Docker Swarm.
Cada miembro de este Docker Swarm contiene su propio demonio Docker.
Existen dos tipos de nodos en un Docker Swarm, los nodos managers (administradores de otros nodos) y los workers (encargados de ejecutar tareas).
Docker Swarm
Docker Swarm consiste de m煤ltiples demonios de Docker trabajando en conjunto.
Utiliza nodos managers y workers.
Los nodos se comunican utilizando la Docker Api.
Si se utiliza Docker 1.12 o superior se puede utilizar Docker Swarm Cluster.

馃嵖 驴Qu茅 es el docker engine (motor de Docker)?

El motor de Docker es el coraz贸n en donde se manejan y controlan todos los contenedores. El motor es modular, es decir esta forma por componentes. Los componentes principales son:

  • El Docker client (cliente de Docker)
  • El Docker daemon (demonio de Docker)
  • containerd
  • runc

Todos los elementos anteriores funcionan en conjunto para ejecutar los contenedores.

La primera versi贸n de Docker consist铆a de el demonio de Docker y LXC, en un inicio el demonio era un gran desorden, conten铆a el cliente, demonio, la api, etc, mientras que LXC prove铆a al demonio con los bloques fundamentales de los contenedores que exist铆an dentro de Linux, esto inclu铆a namespaces, cgroups (Control Groups) y el manejo del kernel. El problema con este modelo es que era espec铆fico para Linux, es decir que no hab铆a forma de darle un soporte adecuado en Windows o Mac.

LXC fue reemplazado tiempo despu茅s por libcontainer cuya funci贸n es ser agn贸stico en relaci贸n a la plataforma en donde se utilice, y provee a Docker con los bloques fundamentales que existen dentro del kernel. Esto es lo que permite a Docker en un sistema operativo Mac Windows.

Desde la Docker v0.9 libcontainer reemplaza completamente a LXC haciendo a Docker agn贸stico de la plataforma en la que se ejecute.

El dise帽o monol铆tico fue reemplazado para brindar mayor facilidad a los usuarios, descomponi茅ndose en piezas peque帽as mas especializadas. El resultado final resulto ser una serie de componentes montables con herramientas de terceros.

馃イ 驴Qu茅 es la Open Container Initiative (OCI)?

En el 2015 apareci贸 la Open Container Initiative (OCI) como parte de un trabajo conjunto entre Docker y otras compa帽铆as del ramo de los contenedores. El objetivo la de OCI es definir est谩ndares sobre acerca del formato y ejecuci贸n de contenedores. Actualmente existe dos especificaciones.

  • Image spec
  • Container runtime spec

La versi贸n 1.0 de esta especificaci贸n fue liberada en el 2017. Docker Inc es un contribuidor activo de la OCI y la versi贸n 1.11 de Docker utiliza en lo mayor posible dicha especificaci贸n.

Todo el runtime code (c贸digo en tiempo de ejecuci贸n) esta ahora contenido en la capa OCI, ya no existe mas dentro del demonio de Docker. Aqu铆 es donde se sigue el est谩ndar de OCI, funcionando como un wrapper (una envoltura) de libcontainer.

Todos los controles del manejo del ciclo de vida del contenedor fueron tambi茅n extra铆dos del Docker daemon y puestos dentro de containerd, las operaciones como start, stop, pause y delete se encuentran aqu铆. Este se encuentra entre el demonio de Docker y runc en la capa OCI. Es responsable tambi茅n del manejo de las im谩genes, por lo que se encarga de descargarlas y empujarlas cuando es requerido. Desde la versi贸n 1.11 containerd es parte de Docker.

馃イ 驴Qu茅 son los shims?

shim es utilizado para desacoplar los contenedores en ejecuci贸n del demonio. Cuando un nuevo contenedor es creado containerd bifurca una instancia de runc para cada nuevo contenedor. Una vez que el contenedor es creado, el proceso runc finaliza y el proceso shim se vuelve el nuevo padre del contenedor. Esto permite tener cientos de contenedores sin tener que cientos de runc en ejecuci贸n.

shim es encargado de mantener los streams stdins y stdous abiertos. Esto quiere decir que si el demonio es reiniciado, el contenedor no finaliza debido a pipes cerrados. shim tambi茅n es responsable de reportar el estado al demonio de Docker.

馃イ 驴C贸mo se crea un nuevo contenedor de Docker?

docker container run -it --name NOMBRE_DEL_CONTENEDOR IMAGEN:TAG

馃イ 驴Cu谩l es el proceso de creaci贸n de un contenedor de Docker?

  • El CLI ejecuta un comando
  • Dependiendo del comando que se este ejecutando Docker utiliza el payload apropiado para el Api
  • El payload es enviado al endpoint apropiado del Api
  • El demonio recibe las instrucciones
  • El demonio llama a containerid para iniciar un nuevo contenedor
  • El demonio utiliza gRCP (una api tipo crud)
  • El containerd crea un paquete OCI desde el Docker image.
  • Le indica a runc se comunica con el kernel del sistema operativo para obtener los constructores necesarios para crear el contenedor.
  • La creaci贸n del contenedor incluye namespace, cgroups y otras capacidades.
  • El proceso del contenedor es inicializado como un proceso child (hijo).
  • Cuando el contenedor este puesto en marcha runc finalizar谩.
  • El contenedor esta ahora en ejecuci贸n.

馃嵖 驴C贸mo se relacionan las im谩genes y contenedores de Docker?

Una imagen es una plantilla o receta de cocina para un contenedor, si extrapolamos el concepto a la programaci贸n orientada a objetos podr铆amos referirnos a una imagen como si fuese una clase, mientras los contenedores ser铆an una instancia de esa clase.

Las im谩genes est谩n construidas de muchas capas, cada una de ellas encima de la siguiente. No se puede eliminar una imagen mientras no se hayan eliminado todos los contenedores que est茅n utilizando dicha imagen.

Las im谩genes se construyen a partir de dockerfiles, estos archivos contienen las instrucciones acerca de como las im谩genes deben de ser construidas. Estos archivos incluyen toda la informaci贸n acerca de los programas a instalar as铆 como las librer铆as necesarias para ejecutar una aplicaci贸n.

Un objetivo del uso de im谩genes es mantener im谩genes lo mas peque帽as posibles, de manera que solo tengan instalados los requisitos m铆nimos y as铆 se mantengan como contenedores peque帽os.

Cada una de las instrucciones del dockerfile representa una capa, estas capas una sobre la otra son las que construyen una imagen. Todas las capas son de solo lectura con excepci贸n de la 煤ltima. Cada capa representa un cumulo de diferencias con la capa anterior.

Cuando un contenedor es creado agrega una capa escribible llamada container layer (capa del contenedor) por encima de las capas de la imagen conocida. Cada que un cambio es realizado al contenedor, dicho cambio se efect煤a sobre la capa del contenedor.

Cuando eliminamos un contenedor lo que sucede en realidad es que eliminamos la container layer y las capas inferiores se mantienen intactas.

馃嵖 驴Qu茅 es el Docker Hub?

Como se ha mencionado anteriormente Dockerhub es un repositorio de im谩genes como lo es GitHub para proyectos de c贸digo. El utilizar este repositorio nos permite compartir nuestras im谩genes con otras personas dentro o fuera de nuestra organizaci贸n. En Dockerhub se puede tener un repositorio privado y un n煤mero ilimitado de repositorios p煤blicos de forma gratuita. Si se desea tener mas de un repositorio gratuito es posible adquirir una membresia de pago cuyo costo depender谩 del n煤mero de repositorios privados que se requieran.

Entre las caracter铆sticas de DockerHub est谩n el poder crear repositorio, equipos, organizaciones, im谩genes oficiales, publisher images (im谩genes oficiales creadas por vendors, certificadas y que ofrecen soporte), builds y webhooks.