{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Qu\u00e9 es Docker: breve excursi\u00f3n a la historia y las principales abstracciones","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El 10 de agosto comenz\u00f3 en Slerm un curso en video sobre Docker<\/a><\/noindex>, en el cual lo analizamos por completo, desde las abstracciones b\u00e1sicas hasta los par\u00e1metros de la red. <\/p>\n

<\/p>\n

En este art\u00edculo hablaremos sobre la historia de Docker y sus principales abstracciones: Image, CLI, Dockerfile. La conferencia est\u00e1 dirigida a principiantes, por lo que probablemente no interesar\u00e1 a los usuarios experimentados. No habr\u00e1 sangre, apendicitis ni una profunda inmersi\u00f3n. Solo lo m\u00e1s b\u00e1sico.<\/p>\n

<\/p>\n

\"Qu\u00e9<\/p>\n

<\/a><\/noindex><\/p>\n

\u00bfQu\u00e9 es Docker?<\/h2>\n

<\/p>\n

Veamos la definici\u00f3n de Docker de Wikipedia.<\/p>\n

<\/p>\n

Docker es un software para la automatizaci\u00f3n del despliegue y la gesti\u00f3n de aplicaciones en entornos compatibles con la contenerizaci\u00f3n.<\/p><\/blockquote>\n

De esta definici\u00f3n no se entiende nada. Especialmente no queda claro qu\u00e9 significa \u00aben entornos compatibles con la contenerizaci\u00f3n\u00bb. Para entenderlo, volvamos al pasado. Comencemos por la \u00e9poca que llamo 'la era monol\u00edtica'.<\/p>\n

<\/p>\n

Era monol\u00edtica<\/h2>\n

<\/p>\n

La era monol\u00edtica es a principios de los 2000, cuando todas las aplicaciones eran monol\u00edticas, con un mont\u00f3n de dependencias. El desarrollo tomaba tiempo. Adem\u00e1s, no hab\u00eda tantos servidores, todos los conoc\u00edamos por nombre y los monitore\u00e1bamos. Hay una comparaci\u00f3n divertida:<\/p>\n

\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Las mascotas son animales dom\u00e9sticos. En la era monol\u00edtica, trat\u00e1bamos a nuestros servidores como a mascotas, cuid\u00e1ndolos y mim\u00e1ndolos, soplando el polvo. Para gestionar mejor los recursos, utiliz\u00e1bamos virtualizaci\u00f3n: tom\u00e1bamos un servidor y lo divid\u00edamos en varias m\u00e1quinas virtuales, garantizando as\u00ed el aislamiento del entorno.<\/p>\n

<\/p>\n

Sistemas de virtualizaci\u00f3n basados en hipervisores<\/h2>\n

<\/p>\n

Seguro que todos han o\u00eddo hablar de sistemas de virtualizaci\u00f3n: VMware, VirtualBox, Hyper-V, Qemu KVM, etc. Proporcionan aislamiento de aplicaciones y gesti\u00f3n de recursos, pero tambi\u00e9n tienen desventajas. Para implementar la virtualizaci\u00f3n, se necesita un hipervisor. Y el hipervisor implica un sobrecosto de recursos. Adem\u00e1s, la m\u00e1quina virtual suele ser un gran bicho: una imagen pesada, con su sistema operativo, Nginx, Apache, tal vez MySQL. La imagen es grande y es inc\u00f3modo operar con m\u00e1quinas virtuales. Como consecuencia, trabajar con virtualizaciones puede ser lento. Para solucionar este problema, se crearon sistemas de virtualizaci\u00f3n a nivel de n\u00facleo.<\/p>\n

<\/p>\n

Sistemas de virtualizaci\u00f3n a nivel de n\u00facleo<\/h2>\n

<\/p>\n

La virtualizaci\u00f3n a nivel de n\u00facleo es soportada por sistemas como OpenVZ, Systemd-nspawn, LXC. Un ejemplo destacado de esta virtualizaci\u00f3n es LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u2014 un sistema de virtualizaci\u00f3n a nivel de sistema operativo para ejecutar m\u00faltiples instancias aisladas del sistema operativo Linux en un solo nodo. LXC no utiliza m\u00e1quinas virtuales, sino que crea un entorno virtual con su propio espacio de procesos y pila de red.<\/p>\n

<\/p>\n

Esencialmente, LXC crea contenedores. \u00bfCu\u00e1l es la diferencia entre m\u00e1quinas virtuales y contenedores?<\/p>\n

<\/p>\n

\"Qu\u00e9<\/p>\n

<\/p>\n

Un contenedor no es adecuado para aislar procesos: en los sistemas de virtualizaci\u00f3n a nivel de n\u00facleo se encuentran vulnerabilidades que permiten salir del contenedor al host. Por lo tanto, si necesitas aislar algo, es mejor usar una m\u00e1quina virtual.<\/p>\n

<\/p>\n

Las diferencias entre virtualizaci\u00f3n y contenedorizaci\u00f3n se pueden ver en el esquema.
\nExisten hipervisores de hardware, hipervisores sobre sistemas operativos y contenedores. <\/p>\n

<\/p>\n

\"Qu\u00e9<\/p>\n

<\/p>\n

Los hipervisores 'de hierro' son una gran herramienta si realmente quieres aislar algo. Porque hay posibilidad de aislamiento a nivel de p\u00e1ginas de memoria y procesadores.<\/p>\n

<\/p>\n

Existen hipervisores como programas, y hay contenedores, de los cuales vamos a hablar a continuaci\u00f3n. En los sistemas de contenedorizaci\u00f3n no hay hipervisor, sino un Motor de Contenedores que crea y gestiona los contenedores. Esta es una tecnolog\u00eda m\u00e1s ligera, por lo que, gracias a su trabajo con el n\u00facleo, la sobrecarga es menor o no existe en absoluto.<\/p>\n

<\/p>\n

\n

Lo que se utiliza para la contenedorizaci\u00f3n a nivel de n\u00facleo<\/h2>\n

Las principales tecnolog\u00edas que permiten crear un contenedor aislado de otros procesos son Namespaces y Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount y User. Hay m\u00e1s, pero para simplicidad nos detendremos en estos.<\/p>\n

El Namespace PID limita los procesos. Cuando, por ejemplo, creamos un Namespace PID y colocamos un proceso all\u00ed, se convierte en PID 1. Normalmente, en los sistemas PID 1 es systemd o init. Por lo tanto, cuando colocamos un proceso en un nuevo namespace, tambi\u00e9n recibe PID 1.<\/p>\n

El Networking Namespace permite restringir\/aislar la red y colocar sus interfaces dentro de \u00e9l. Mount es la restricci\u00f3n del sistema de archivos. User es la restricci\u00f3n de usuarios.<\/p>\n

Control Groups: Memoria, CPU, IOPS, Red \u2014 en total hay alrededor de 12 configuraciones. Tambi\u00e9n se les llama Cgroups (\"C grupos\").<\/p>\n

Los Control Groups gestionan los recursos para el contenedor. A trav\u00e9s de los Control Groups podemos decir que el contenedor no debe consumir m\u00e1s de cierta cantidad de recursos.<\/p>\n

Para que la contenedorizaci\u00f3n funcione plenamente, se utilizan tecnolog\u00edas adicionales: Capabilities, Copy-on-write y otras.<\/p>\n

Capabilities significa que le decimos al proceso lo que puede hacer y lo que no. A nivel del n\u00facleo, son simplemente mapas de bits con numerosos par\u00e1metros. Por ejemplo, el usuario root tiene privilegios completos y puede hacer todo. El servidor de tiempo puede cambiar la hora del sistema: tiene capacidades en Time Capsule, y eso es todo. A trav\u00e9s de los privilegios, se pueden configurar restricciones flexibles para los procesos, asegurando as\u00ed una mayor seguridad.<\/p>\n

El sistema Copy-on-write nos permite trabajar con im\u00e1genes de Docker de manera m\u00e1s eficiente.<\/p>\n

Actualmente, Docker tiene problemas con la compatibilidad de Cgroups v2, por lo que este art\u00edculo se centra en Cgroups v1.<\/em><\/p><\/blockquote>\n

Pero volvamos a la historia. <\/p>\n

<\/p>\n

Cuando surgieron los sistemas de virtualizaci\u00f3n a nivel de n\u00facleo, comenzaron a utilizarse activamente. Se elimin\u00f3 la sobrecarga en el hipervisor, pero algunos problemas persistieron:<\/p>\n

<\/p>\n