¿En qué se diferencia Docker de una máquina virtual?

Sigo releyendo la documentación de Docker para tratar de comprender la diferencia entre Docker y una máquina virtual completa. ¿Cómo se las arregla para proporcionar un sistema de archivos completo, un entorno de red aislado, etc. sin ser tan pesado?

¿Por qué implementar software en una imagen de Docker (si ese es el término correcto) es más fácil que simplemente implementarlo en un entorno de producción consistente?

Docker usó originalmente LinuX Containers (LXC), pero luego cambió a runC (anteriormente conocido como libcontainer ), que se ejecuta en el mismo sistema operativo que su host. Esto le permite compartir muchos de los recursos del sistema operativo host. Además, utiliza un sistema de archivos en capas ( AuFS ) y administra las redes.

AuFS es un sistema de archivos en capas, por lo que puede tener una parte de solo lectura y una parte de escritura que se fusionan. Uno podría tener las partes comunes del sistema operativo como de solo lectura (y compartidas entre todos sus contenedores) y luego dar a cada contenedor su propio soporte para escribir.

Entonces, supongamos que tiene una imagen de contenedor de 1 GB; si desea utilizar una máquina virtual completa, necesitaría tener 1 GB x número de máquinas virtuales que desea. Con Docker y AuFS, puede compartir la mayor parte de 1 GB entre todos los contenedores y, si tiene 1000 contenedores, es posible que solo tenga un poco más de 1 GB de espacio para el sistema operativo de los contenedores (suponiendo que todos estén ejecutando la misma imagen del sistema operativo) .

Un sistema virtualizado completo obtiene su propio conjunto de recursos asignados y comparte de manera mínima. Obtienes más aislamiento, pero es mucho más pesado (requiere más recursos). Con Docker obtienes menos aislamiento, pero los contenedores son livianos (requieren menos recursos). Por lo tanto, podría ejecutar fácilmente miles de contenedores en un host, y ni siquiera parpadeará. Intenta hacerlo con Xen, y a menos que tengas un host realmente grande, no creo que sea posible.

Un sistema virtualizado completo suele tardar unos minutos en iniciarse, mientras que los contenedores Docker / LXC / runC tardan segundos y, a menudo, incluso menos de un segundo.

Hay ventajas y desventajas para cada tipo de sistema virtualizado. Si desea un aislamiento total con recursos garantizados, una máquina virtual completa es el camino a seguir. Si solo desea aislar los procesos entre sí y desea ejecutar una tonelada de ellos en un host de tamaño razonable, entonces Docker / LXC / runC parece ser el camino a seguir.

Para obtener más información, consulte este conjunto de publicaciones de blog que explican cómo funciona LXC.

¿Por qué es más fácil implementar software en una imagen acoplable (si ese es el término correcto) que simplemente implementarlo en un entorno de producción consistente?

Implementar un entorno de producción consistente es más fácil decirlo que hacerlo. Incluso si usa herramientas como Chef y Puppet , siempre hay actualizaciones del sistema operativo y otras cosas que cambian entre hosts y entornos.

Docker le brinda la capacidad de capturar el sistema operativo en una imagen compartida y facilita la implementación en otros hosts Docker. Localmente, dev, qa, prod, etc .: toda la misma imagen. Claro que puedes hacer esto con otras herramientas, pero no tan fácil o rápido.

Esto es genial para probar; supongamos que tiene miles de pruebas que necesitan conectarse a una base de datos, y cada prueba necesita una copia inmaculada de la base de datos y realizará cambios en los datos. El enfoque clásico para esto es restablecer la base de datos después de cada prueba, ya sea con código personalizado o con herramientas como Flyway ; esto puede llevar mucho tiempo y significa que las pruebas deben ejecutarse en serie. Sin embargo, con Docker podría crear una imagen de su base de datos y ejecutar una instancia por prueba, y luego ejecutar todas las pruebas en paralelo, ya que sabe que todas se ejecutarán en la misma instantánea de la base de datos. Dado que las pruebas se ejecutan en paralelo y en contenedores Docker, podrían ejecutarse todas en la misma caja al mismo tiempo y deberían terminar mucho más rápido. Intenta hacerlo con una máquina virtual completa.

De los comentarios ...

¡Interesante! Supongo que todavía estoy confundido por la noción de "instantánea [ting] del sistema operativo". ¿Cómo se hace eso sin, bueno, hacer una imagen del sistema operativo?

Bueno, veamos si puedo explicarlo. Comienza con una imagen base, y luego realiza los cambios, y los confirma utilizando Docker, y se crea una imagen. Esta imagen contiene solo las diferencias de la base. Cuando desea ejecutar su imagen, también necesita la base, y coloca su imagen en la parte superior de la base usando un sistema de archivos en capas: como se mencionó anteriormente, Docker usa AuFS. AuFS combina las diferentes capas y obtienes lo que quieres; solo necesitas ejecutarlo. Puede seguir agregando más y más imágenes (capas) y continuará guardando solo las diferencias. Dado que Docker generalmente se basa en imágenes preparadas de un registro , rara vez tiene que "capturar" todo el sistema operativo usted mismo.

Buenas respuestas Solo para obtener una representación de la imagen del contenedor frente a la VM, eche un vistazo a la siguiente.

Fuente

Puede ser útil comprender cómo funcionan la virtualización y los contenedores a bajo nivel. Eso aclarará muchas cosas.

Nota: Estoy simplificando un poco al describir a continuación. Ver referencias para más información.

¿Cómo funciona la virtualización a bajo nivel?

En este caso, el administrador de VM toma el anillo de CPU 0 (o el "modo raíz" en las CPU más nuevas) e intercepta todas las llamadas privilegiadas realizadas por el SO huésped para crear la ilusión de que el SO huésped tiene su propio hardware. Dato curioso: antes de 1998 se pensaba que era imposible lograr esto en la arquitectura x86 porque no había forma de hacer este tipo de intercepción. La gente de VMWare fue la primera que tuvo la idea de reescribir los bytes ejecutables en la memoria para llamadas privilegiadas del sistema operativo invitado para lograr esto.

El efecto neto es que la virtualización le permite ejecutar dos sistemas operativos completamente diferentes en el mismo hardware. Cada sistema operativo invitado pasa por todo el proceso de arranque, carga del kernel, etc. Puede tener una seguridad muy estricta, por ejemplo, el sistema operativo invitado no puede obtener acceso completo al sistema operativo host u otros invitados y arruinar las cosas.

¿Cómo funcionan los contenedores a bajo nivel?

Alrededor de 2006 , las personas, incluidos algunos de los empleados de Google, implementaron una nueva función de nivel de kernel llamada espacios de nombres (sin embargo, la idea existía mucho antes en FreeBSD) Una función del sistema operativo es permitir compartir recursos globales como la red y el disco con los procesos. ¿Qué sucede si estos recursos globales se envuelven en espacios de nombres para que sean visibles solo para aquellos procesos que se ejecutan en el mismo espacio de nombres? Digamos, puede obtener un trozo de disco y ponerlo en el espacio de nombres X y luego los procesos que se ejecutan en el espacio de nombres Y no pueden verlo ni acceder a él. Del mismo modo, los procesos en el espacio de nombres X no pueden acceder a nada en la memoria asignada al espacio de nombres Y. Por supuesto, los procesos en X no pueden ver ni hablar con los procesos en el espacio de nombres Y. Esto proporciona un tipo de virtualización y aislamiento para los recursos globales. Así es como funciona Docker: cada contenedor se ejecuta en su propio espacio de nombres pero usa exactamente el mismokernel como todos los demás contenedores. El aislamiento ocurre porque el kernel conoce el espacio de nombres asignado al proceso y durante las llamadas a la API se asegura de que el proceso solo pueda acceder a los recursos en su propio espacio de nombres.

Las limitaciones de los contenedores frente a la VM deberían ser obvias ahora: no puede ejecutar un sistema operativo completamente diferente en contenedores como en las máquinas virtuales. Sin embargo, puede ejecutar diferentes distribuciones de Linux porque comparten el mismo núcleo. El nivel de aislamiento no es tan fuerte como en VM. De hecho, había una forma para que el contenedor "invitado" se hiciera cargo del host en las primeras implementaciones. También puede ver que cuando carga un nuevo contenedor, la nueva copia completa del sistema operativo no se inicia como lo hace en VM. Todos los contenedores comparten el mismo núcleo. Es por eso que los contenedores son livianos. Además, a diferencia de VM, no tiene que asignar previamente una porción considerable de memoria a los contenedores porque no estamos ejecutando una nueva copia del sistema operativo. Esto permite ejecutar miles de contenedores en un sistema operativo al tiempo que los pone en un espacio aislado, lo que podría no ser posible si estuviéramos ejecutando una copia separada del sistema operativo en su propia VM.

Me gusta la respuesta de Ken Cochrane.

Pero quiero agregar un punto de vista adicional, no cubierto en detalle aquí. En mi opinión, Docker difiere también en todo el proceso. A diferencia de las máquinas virtuales, Docker no se trata (solo) de compartir recursos óptimos de hardware, además proporciona un "sistema" para empaquetar aplicaciones (preferible, pero no obligatorio, como un conjunto de microservicios).

Para mí encaja en la brecha entre las herramientas orientadas al desarrollador como rpm, paquetes Debian , Maven , npm + Git en un lado y herramientas de operaciones como Puppet , VMware, Xen, lo que sea ...

¿Por qué es más fácil implementar software en una imagen acoplable (si ese es el término correcto) que simplemente implementarlo en un entorno de producción consistente?

Su pregunta supone un entorno de producción consistente. Pero, ¿cómo mantenerlo consistente? Considere cierta cantidad (> 10) de servidores y aplicaciones, etapas en la tubería.

Para mantener esto sincronizado, comenzará a usar algo como Puppet, Chef o sus propios scripts de aprovisionamiento, reglas inéditas y / o mucha documentación ... En teoría, los servidores pueden ejecutarse indefinidamente y mantenerse completamente consistentes y actualizados. La práctica no logra administrar completamente la configuración de un servidor, por lo que hay un margen considerable para la deriva de la configuración y cambios inesperados en los servidores en ejecución.

Hay un patrón conocido para evitar esto, el llamado servidor inmutable . Pero el patrón de servidor inmutable no fue amado. Principalmente debido a las limitaciones de las máquinas virtuales que se usaron antes de Docker. Tratar con imágenes grandes de varios gigabytes, mover esas imágenes grandes solo para cambiar algunos campos en la aplicación, fue muy muy laborioso. Comprensible...

Con un ecosistema Docker, nunca necesitará moverse alrededor de gigabytes en "pequeños cambios" (gracias a aufs y Registry) y no debe preocuparse por perder rendimiento al empaquetar las aplicaciones en un contenedor Docker en tiempo de ejecución. No necesita preocuparse por las versiones de esa imagen.

Y finalmente, incluso podrá reproducir entornos de producción complejos incluso en su computadora portátil Linux (no me llame si no funciona en su caso;))

Y, por supuesto, puede iniciar contenedores Docker en máquinas virtuales (es una buena idea). Reduzca el aprovisionamiento de su servidor en el nivel de VM. Todo lo anterior podría ser gestionado por Docker.

PD Mientras tanto, Docker usa su propia implementación "libcontainer" en lugar de LXC. Pero LXC todavía es utilizable.

Docker no es una metodología de virtualización. Se basa en otras herramientas que realmente implementan la virtualización basada en contenedores o la virtualización a nivel del sistema operativo. Para eso, Docker inicialmente usaba el controlador LXC, luego se movió a libcontainer, que ahora se renombra como runc. Docker se centra principalmente en automatizar la implementación de aplicaciones dentro de contenedores de aplicaciones. Los contenedores de aplicaciones están diseñados para empaquetar y ejecutar un solo servicio, mientras que los contenedores del sistema están diseñados para ejecutar múltiples procesos, como máquinas virtuales. Por lo tanto, Docker se considera una herramienta de administración de contenedores o de implementación de aplicaciones en sistemas en contenedores.

Para saber cómo es diferente de otras virtualizaciones, veamos la virtualización y sus tipos. Entonces, sería más fácil entender cuál es la diferencia allí.

Virtualización

En su forma concebida, se consideró un método de división lógica de mainframes para permitir que varias aplicaciones se ejecuten simultáneamente. Sin embargo, el escenario cambió drásticamente cuando las compañías y las comunidades de código abierto pudieron proporcionar un método para manejar las instrucciones privilegiadas de una forma u otra y permitir que múltiples sistemas operativos se ejecuten simultáneamente en un solo sistema basado en x86.

Hipervisor

El hipervisor maneja la creación del entorno virtual en el que operan las máquinas virtuales invitadas. Supervisa los sistemas invitados y se asegura de que los recursos se asignen a los invitados según sea necesario. El hipervisor se encuentra entre la máquina física y las máquinas virtuales y proporciona servicios de virtualización a las máquinas virtuales. Para darse cuenta, intercepta las operaciones del sistema operativo invitado en las máquinas virtuales y emula la operación en el sistema operativo de la máquina host.

El rápido desarrollo de las tecnologías de virtualización, principalmente en la nube, ha impulsado el uso de la virtualización aún más al permitir que se creen múltiples servidores virtuales en un solo servidor físico con la ayuda de hipervisores, como Xen, VMware Player, KVM, etc., y incorporación de soporte de hardware en procesadores básicos, como Intel VT y AMD-V.

Tipos de virtualización

El método de virtualización se puede clasificar en función de cómo imita el hardware a un sistema operativo invitado y emula un entorno operativo invitado. Principalmente, hay tres tipos de virtualización:

• Emulación
• Paravirtualización
• Virtualización basada en contenedores

Emulación

La emulación, también conocida como virtualización completa, ejecuta el núcleo del sistema operativo de la máquina virtual completamente en software. El hipervisor utilizado en este tipo se conoce como hipervisor tipo 2. Se instala en la parte superior del sistema operativo host que se encarga de traducir el código del kernel del sistema operativo invitado a las instrucciones del software. La traducción se realiza completamente en software y no requiere participación de hardware. La emulación permite ejecutar cualquier sistema operativo no modificado que admita el entorno que se emula. La desventaja de este tipo de virtualización es una sobrecarga de recursos del sistema adicional que conduce a una disminución en el rendimiento en comparación con otros tipos de virtualizaciones.

Los ejemplos en esta categoría incluyen VMware Player, VirtualBox, QEMU, Bochs, Parallels, etc.

Paravirtualización

La paravirtualización, también conocida como hipervisor Tipo 1, se ejecuta directamente en el hardware o "bare metal" y proporciona servicios de virtualización directamente a las máquinas virtuales que se ejecutan en él. Ayuda al sistema operativo, al hardware virtualizado y al hardware real a colaborar para lograr un rendimiento óptimo. Estos hipervisores suelen tener una huella bastante pequeña y, por sí mismos, no requieren amplios recursos.

Los ejemplos en esta categoría incluyen Xen, KVM, etc.

Virtualización basada en contenedores

La virtualización basada en contenedores, también conocida como virtualización a nivel del sistema operativo, permite múltiples ejecuciones aisladas dentro de un solo núcleo del sistema operativo. Tiene el mejor rendimiento y densidad posibles y presenta una gestión dinámica de recursos. El entorno de ejecución virtual aislado que proporciona este tipo de virtualización se denomina contenedor y se puede ver como un grupo de procesos rastreados.

El concepto de contenedor es posible gracias a la función de espacios de nombres agregada a la versión 2.6.24 del kernel de Linux. El contenedor agrega su ID a cada proceso y agrega nuevas verificaciones de control de acceso a cada llamada al sistema. Se accede mediante la llamada al sistema clone () que permite crear instancias separadas de espacios de nombres previamente globales.

Los espacios de nombres se pueden usar de muchas maneras diferentes, pero el enfoque más común es crear un contenedor aislado que no tenga visibilidad o acceso a objetos fuera del contenedor. Los procesos que se ejecutan dentro del contenedor parecen ejecutarse en un sistema Linux normal, aunque comparten el núcleo subyacente con procesos ubicados en otros espacios de nombres, lo mismo para otros tipos de objetos. Por ejemplo, cuando se usan espacios de nombres, el usuario root dentro del contenedor no se trata como root fuera del contenedor, lo que agrega seguridad adicional.

El subsistema de Grupos de control de Linux (cgroups), el siguiente componente principal para habilitar la virtualización basada en contenedores, se usa para agrupar procesos y administrar su consumo de recursos agregados. Se usa comúnmente para limitar el consumo de memoria y CPU de los contenedores. Dado que un sistema Linux en contenedores solo tiene un núcleo y el núcleo tiene una visibilidad completa de los contenedores, solo hay un nivel de asignación y programación de recursos.

Hay varias herramientas de administración disponibles para contenedores Linux, incluidas LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, etc.

Contenedores vs Máquinas Virtuales

A diferencia de una máquina virtual, un contenedor no necesita iniciar el núcleo del sistema operativo, por lo que los contenedores se pueden crear en menos de un segundo. Esta característica hace que la virtualización basada en contenedores sea única y deseable que otros enfoques de virtualización.

Dado que la virtualización basada en contenedores agrega poca o ninguna sobrecarga a la máquina host, la virtualización basada en contenedores tiene un rendimiento casi nativo

Para la virtualización basada en contenedores, no se requiere software adicional, a diferencia de otras virtualizaciones.

Todos los contenedores en una máquina host comparten el planificador de la máquina host, lo que ahorra la necesidad de recursos adicionales.

Los estados del contenedor (imágenes Docker o LXC) son de tamaño pequeño en comparación con las imágenes de máquinas virtuales, por lo que las imágenes del contenedor son fáciles de distribuir.

La gestión de recursos en contenedores se logra a través de cgroups. Cgroups no permite que los contenedores consuman más recursos de los asignados. Sin embargo, a partir de ahora, todos los recursos de la máquina host son visibles en las máquinas virtuales, pero no se pueden usar. Esto puede realizarse ejecutando topohtop en contenedores y máquina host al mismo tiempo. El resultado en todos los entornos será similar.

Actualizar:

¿Cómo ejecuta Docker contenedores en sistemas que no son Linux?

Si los contenedores son posibles debido a las características disponibles en el kernel de Linux, entonces la pregunta obvia es cómo los sistemas que no son Linux ejecutan contenedores. Tanto Docker para Mac como Windows usan máquinas virtuales Linux para ejecutar los contenedores. Docker Toolbox se usa para ejecutar contenedores en máquinas virtuales de Virtual Box. Pero, el último Docker usa Hyper-V en Windows e Hypervisor.framework en Mac.

Ahora, permítanme describir cómo Docker para Mac ejecuta contenedores en detalle.

Docker para Mac usa https://github.com/moby/hyperkit para emular las capacidades del hipervisor e Hyperkit usa hypervisor.framework en su núcleo. Hypervisor.framework es la solución de hipervisor nativa de Mac. Hyperkit también usa VPNKit y DataKit para la red de espacio de nombres y el sistema de archivos, respectivamente.

La máquina virtual Linux que Docker ejecuta en Mac es de solo lectura. Sin embargo, puedes atacarlo ejecutando:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Ahora, incluso podemos verificar la versión Kernel de esta VM:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Todos los contenedores se ejecutan dentro de esta VM.

Existen algunas limitaciones para hypervisor.framework. Debido a eso, Docker no expone docker0la interfaz de red en Mac. Por lo tanto, no puede acceder a los contenedores desde el host. A partir de ahora,docker0 solo está disponible dentro de la VM.

Hyper-v es el hipervisor nativo en Windows. También están tratando de aprovechar las capacidades de Windows 10 para ejecutar sistemas Linux de forma nativa.

A través de esta publicación vamos a dibujar algunas líneas de diferencias entre máquinas virtuales y LXC. Primero los definimos.

VM :

Una máquina virtual emula un entorno informático físico, pero las solicitudes de CPU, memoria, disco duro, red y otros recursos de hardware son administradas por una capa de virtualización que traduce estas solicitudes al hardware físico subyacente.

En este contexto, la VM se llama como Invitado, mientras que el entorno en el que se ejecuta se llama host.

LXC s:

Los Contenedores de Linux (LXC) son capacidades de nivel de sistema operativo que hacen posible ejecutar múltiples contenedores de Linux aislados, en un host de control (el host LXC). Los contenedores de Linux sirven como una alternativa ligera a las máquinas virtuales, ya que no requieren los hipervisores a saber. Virtualbox, KVM, Xen, etc.

Ahora, a menos que haya sido drogado por Alan (Zach Galifianakis- de la serie Hangover) y haya estado en Las Vegas durante el último año, estará muy consciente del tremendo interés por la tecnología de contenedores Linux, y si voy a ser un contenedor específico El proyecto que ha creado un gran revuelo en todo el mundo en los últimos meses es: Docker, que lleva a algunas opiniones que hacen eco de que los entornos de computación en la nube deberían abandonar las máquinas virtuales (VM) y reemplazarlas con contenedores debido a su menor sobrecarga y un rendimiento potencialmente mejor.

Pero la gran pregunta es, ¿es factible ?, ¿será sensato?

a. Los LXC tienen un alcance para una instancia de Linux. Es posible que se trate de diferentes versiones de Linux (por ejemplo, un contenedor de Ubuntu en un host CentOS pero sigue siendo Linux). De manera similar, los contenedores basados ​​en Windows ahora tienen un alcance para una instancia de Windows si miramos las máquinas virtuales, tienen un alcance bastante más amplio y utilizan Los hipervisores no están limitados a los sistemas operativos Linux o Windows.

si. Los LXC tienen gastos generales bajos y un mejor rendimiento en comparación con las máquinas virtuales. Herramientas a saber. Docker, construido sobre los hombros de la tecnología LXC, ha proporcionado a los desarrolladores una plataforma para ejecutar sus aplicaciones y, al mismo tiempo, ha dado a las personas de operaciones una herramienta que les permitirá implementar el mismo contenedor en servidores de producción o centros de datos. Intenta crear la experiencia entre un desarrollador que ejecuta una aplicación, arranca y prueba una aplicación y una persona de operaciones que implementa esa aplicación sin problemas, porque aquí es donde reside toda la fricción y el propósito de DevOps es romper esos silos.

Por lo tanto, el mejor enfoque es que los proveedores de infraestructura en la nube deberían abogar por un uso adecuado de las máquinas virtuales y LXC, ya que cada uno de ellos es adecuado para manejar cargas de trabajo y escenarios específicos.

Abandonar máquinas virtuales no es práctico a partir de ahora. Por lo tanto, tanto las máquinas virtuales como las LXC tienen su propia existencia e importancia individual.

La mayoría de las respuestas aquí hablan de máquinas virtuales. Voy a darle una respuesta única a esta pregunta que me ha ayudado más en los últimos años de usar Docker. Es esto:

Docker es solo una forma elegante de ejecutar un proceso, no una máquina virtual.

Ahora, déjame explicarte un poco más sobre lo que eso significa. Las máquinas virtuales son su propia bestia. Tengo ganas de explicar lo que Docker es lo ayudará a comprender esto más que explicar qué es una máquina virtual. Especialmente porque hay muchas respuestas excelentes aquí que te dicen exactamente lo que alguien quiere decir cuando dice "máquina virtual". Entonces...

Un contenedor Docker es solo un proceso (y sus elementos secundarios) que se divide en compartimentos utilizando cgroups dentro del núcleo del sistema host del resto de los procesos. En realidad, puede ver los procesos del contenedor Docker ejecutándose ps auxen el host. Por ejemplo, comenzar apache2"en un contenedor" es solo comenzar apache2como un proceso especial en el host. Se acaba de dividir en compartimentos de otros procesos en la máquina. Es importante tener en cuenta que sus contenedores no existen fuera de la vida útil de su proceso en contenedores. Cuando su proceso muere, su contenedor muere. Esto se debe a que Docker reemplaza pid 1dentro de su contenedor con su aplicación ( pid 1normalmente es el sistema init). Este último punto sobrepid 1 es muy importante.

En cuanto al sistema de archivos utilizado por cada uno de esos procesos de contenedor, Docker usa UnionFS imágenes respaldadas por , que es lo que está descargando cuando hace un . Cada "imagen" es solo una serie de capas y metadatos relacionados. El concepto de capas es muy importante aquí. Cada capa es solo un cambio de la capa debajo de ella. Por ejemplo, cuando elimina un archivo en su Dockerfile mientras crea un contenedor Docker, en realidad solo está creando una capa en la parte superior de la última capa que dice "este archivo ha sido eliminado". Por cierto, es por eso que puede eliminar un archivo grande de su sistema de archivos, pero la imagen todavía ocupa la misma cantidad de espacio en disco. El archivo todavía está allí, en las capas debajo de la actual. Las capas mismas son solo tarballs de archivos. Puedes probar esto con y luego . Entonces puedes echar un vistazo. Todos esos directorios que parecen hashes largos son en realidad las capas individuales. Cada uno contiene archivos ( ) y metadatos (docker pull ubuntudocker save --output /tmp/ubuntu.tar ubuntucd /tmp && tar xvf ubuntu.tarlayer.tarjson) con información sobre esa capa en particular. Esas capas solo describen cambios en el sistema de archivos que se guardan como una capa "encima" de su estado original. Al leer los datos "actuales", el sistema de archivos lee los datos como si solo estuviera mirando las capas superiores de cambios. Es por eso que el archivo parece haber sido eliminado, aunque todavía existe en las capas "anteriores", porque el sistema de archivos solo está mirando las capas superiores. Esto permite que contenedores completamente diferentes compartan sus capas del sistema de archivos, a pesar de que algunos cambios significativos pueden haberle sucedido al sistema de archivos en las capas superiores de cada contenedor. Esto puede ahorrarle una tonelada de espacio en disco, cuando sus contenedores comparten sus capas de imagen base. Sin embargo,

La conexión en red en Docker se logra mediante el uso de un puente de Ethernet (llamado docker0en el host) e interfaces virtuales para cada contenedor en el host. Crea una subred virtual docker0para que sus contenedores se comuniquen "entre". Aquí hay muchas opciones para la creación de redes, incluida la creación de subredes personalizadas para sus contenedores y la capacidad de "compartir" la pila de redes de su host para que su contenedor acceda directamente.

Docker se mueve muy rápido. Su documentación es una de las mejores que he visto. Generalmente está bien escrito, conciso y preciso. Le recomiendo que consulte la documentación disponible para obtener más información y confíe en la documentación sobre cualquier otra cosa que lea en línea, incluido Stack Overflow. Si tiene preguntas específicas, le recomiendo unirse #dockera Freenode IRC y preguntar allí (¡incluso puede usar el chat web de Freenode para eso!).

Docker encapsula una aplicación con todas sus dependencias.

Un virtualizador encapsula un sistema operativo que puede ejecutar cualquier aplicación que normalmente puede ejecutar en una máquina de metal desnudo.

Ambos son muy diferentes. Docker es liviano y usa LXC / libcontainer (que se basa en el espacio de nombres del kernel y cgroups) y no tiene emulación de máquina / hardware como hipervisor, KVM. Xen que son pesados.

Docker y LXC están diseñados más para sandboxing, contenedorización y aislamiento de recursos. Utiliza la API de clonación del sistema operativo host (actualmente solo el kernel de Linux) que proporciona espacio de nombres para IPC, NS (montaje), red, PID, UTS, etc.

¿Qué pasa con la memoria, E / S, CPU, etc.? Eso se controla mediante cgroups donde puede crear grupos con ciertas especificaciones / restricciones de recursos (CPU, memoria, etc.) y poner sus procesos allí. Además de LXC, Docker proporciona un back-end de almacenamiento ( http://www.projectatomic.io/docs/filesystems/ ), por ejemplo, sistema de archivos de montaje de unión donde puede agregar capas y compartir capas entre diferentes espacios de nombres de montaje.

Esta es una característica poderosa donde las imágenes base son típicamente de solo lectura y solo cuando el contenedor modifica algo en la capa escribirá algo en la partición de lectura-escritura (también conocida como copia en escritura). También proporciona muchos otros contenedores como el registro y el control de versiones de imágenes.

Con LXC normal, debe venir con algunos rootfs o compartir los rootfs y cuando se comparten, y los cambios se reflejan en otros contenedores. Debido a muchas de estas características adicionales, Docker es más popular que LXC. LXC es popular en entornos integrados para implementar seguridad alrededor de procesos expuestos a entidades externas como la red y la interfaz de usuario. Docker es popular en el entorno de múltiples inquilinos en la nube, donde se espera un entorno de producción consistente.

Una máquina virtual normal (por ejemplo, VirtualBox y VMware) usa un hipervisor, y las tecnologías relacionadas tienen un firmware dedicado que se convierte en la primera capa para el primer sistema operativo (sistema operativo host o sistema operativo invitado 0) o un software que se ejecuta en el sistema operativo host para proporcionar emulación de hardware como CPU, USB / accesorios, memoria, red, etc., a los sistemas operativos invitados. Las máquinas virtuales siguen siendo (a partir de 2015) populares en el entorno de múltiples inquilinos de alta seguridad.

Docker / LXC casi se puede ejecutar en cualquier hardware barato (menos de 1 GB de memoria también está bien siempre que tenga un kernel más nuevo) en comparación con las máquinas virtuales normales que necesitan al menos 2 GB de memoria, etc., para hacer algo significativo con él . Pero el soporte de Docker en el sistema operativo host no está disponible en sistemas operativos como Windows (a partir de noviembre de 2014), donde muchos tipos de máquinas virtuales se pueden ejecutar en Windows, Linux y Mac.

Aquí hay una foto de Docker / Rightscale:

1. ligero

Esta es probablemente la primera impresión para muchos estudiantes de docker.

Primero, las imágenes de Docker suelen ser más pequeñas que las imágenes de VM, lo que facilita la creación, la copia y el intercambio.

En segundo lugar, los contenedores Docker pueden comenzar en varios milisegundos, mientras que VM se inicia en segundos.

2. Sistema de archivos en capas

Esta es otra característica clave de Docker. Las imágenes tienen capas, y diferentes imágenes pueden compartir capas, lo que hace que ahorre aún más espacio y sea más rápido de construir.

Si todos los contenedores usan Ubuntu como sus imágenes base, no todas las imágenes tienen su propio sistema de archivos, pero comparten los mismos archivos ubuntu subrayados, y solo difieren en sus propios datos de aplicación.

3. Kernel de SO compartido

¡Piense en los contenedores como procesos!

Todos los contenedores que se ejecutan en un host son, de hecho, un montón de procesos con diferentes sistemas de archivos. Comparten el mismo núcleo del sistema operativo, solo encapsula la biblioteca del sistema y las dependencias.

Esto es bueno para la mayoría de los casos (no se mantiene un kernel adicional del sistema operativo) pero puede ser un problema si se necesitan aislamientos estrictos entre los contenedores.

¿Por qué es importante?

Todo esto parece una mejora, no una revolución. Bueno, la acumulación cuantitativa conduce a la transformación cualitativa .

Piense en la implementación de la aplicación. Si queremos implementar un nuevo software (servicio) o actualizar uno, es mejor cambiar los archivos y procesos de configuración en lugar de crear una nueva VM. Porque Crear una VM con servicio actualizado, probarlo (compartir entre Dev y QA), implementar en producción lleva horas, incluso días. Si algo sale mal, debes comenzar de nuevo, perdiendo aún más tiempo. Por lo tanto, utilice la herramienta de administración de configuración (títere, saltstack, chef, etc.) para instalar un nuevo software, se prefiere descargar nuevos archivos.

Cuando se trata de Docker, es imposible usar un contenedor Docker recién creado para reemplazar el antiguo. ¡El mantenimiento es mucho más fácil! Construir una nueva imagen, compartirla con QA, probarla, implementarla solo lleva minutos (si todo está automatizado), horas en el peor de los casos. Esto se llama infraestructura inmutable : no mantenga el software (actualización), cree uno nuevo.

Transforma la forma en que se entregan los servicios. Queremos aplicaciones, pero tenemos que mantener máquinas virtuales (lo cual es una molestia y tiene poco que ver con nuestras aplicaciones). Docker te hace concentrarte en las aplicaciones y suaviza todo.

Docker, básicamente contenedores, admite la virtualización del sistema operativo, es decir, su aplicación considera que tiene una instancia completa de un sistema operativo, mientras que VM admite la virtualización de hardware . Sientes que es una máquina física en la que puedes arrancar cualquier sistema operativo.

En Docker, los contenedores que se ejecutan comparten el núcleo del sistema operativo host, mientras que en las máquinas virtuales tienen sus propios archivos del sistema operativo. El entorno (el SO) en el que desarrolla una aplicación sería el mismo cuando la implemente en varios entornos de servicio, como "prueba" o "producción".

Por ejemplo, si desarrolla un servidor web que se ejecuta en el puerto 4000, cuando lo implementa en su entorno de "prueba", ese puerto ya lo utiliza algún otro programa, por lo que deja de funcionar. En contenedores hay capas; todos los cambios que haya realizado en el sistema operativo se guardarían en una o más capas y esas capas serían parte de la imagen, por lo que donde quiera que vaya la imagen, las dependencias también estarán presentes.

En el ejemplo que se muestra a continuación, la máquina host tiene tres máquinas virtuales. Para proporcionar el aislamiento completo de las aplicaciones en las máquinas virtuales, cada una tiene sus propias copias de los archivos del sistema operativo, las bibliotecas y el código de la aplicación, junto con una instancia completa en memoria de un sistema operativo. Mientras que la figura a continuación muestra el mismo escenario con los contenedores. Aquí, los contenedores simplemente comparten el sistema operativo host, incluido el kernel y las bibliotecas, por lo que no necesitan iniciar un sistema operativo, cargar bibliotecas o pagar un costo de memoria privada por esos archivos. El único espacio incremental que ocupan es cualquier espacio de memoria y disco necesario para que la aplicación se ejecute en el contenedor. Si bien el entorno de la aplicación se siente como un sistema operativo dedicado, la aplicación se implementa como lo haría en un host dedicado. La aplicación en contenedores comienza en segundos y muchas más instancias de la aplicación pueden caber en la máquina que en el caso de VM.

Fuente: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Hay tres configuraciones diferentes que proporcionan una pila para ejecutar una aplicación (esto nos ayudará a reconocer qué es un contenedor y qué lo hace tan poderoso como otras soluciones):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) La pila de servidor tradicional consiste en un servidor físico que ejecuta un sistema operativo y su aplicación.

Ventajas:

• Utilización de recursos en bruto.

• Aislamiento

Desventajas

• Tiempo de despliegue muy lento.
• Costoso
• Recursos desperdiciados
• Difícil de escalar
• Difícil de migrar
• Configuración compleja

2) La pila VM consta de un servidor físico que ejecuta un sistema operativo y un hipervisor que administra su máquina virtual, recursos compartidos e interfaz de red. Cada Vm ejecuta un sistema operativo invitado, una aplicación o un conjunto de aplicaciones.

Ventajas:

• Buen uso de los recursos.
• Fácil de escalar
• Fácil de respaldar y migrar
• Eficiencia de costo
• Flexibilidad

Desventajas

• La asignación de recursos es problemática
• Dependencia de un proveedor
• Configuración compleja

3) La configuración del contenedor , la diferencia clave con otra pila es que la virtualización basada en el contenedor utiliza el núcleo del sistema operativo host para buscar múltiples instancias de invitados aisladas. Estas instancias de invitado se llaman como contenedores. El host puede ser un servidor físico o una VM.

Ventajas:

• Aislamiento
• Ligero
• Recurso efectivo
• Fácil de migrar
• Seguridad
• Gastos indirectos bajos
• Ambiente de producción y desarrollo espejo

Desventajas

• Misma arquitectura
• Aplicaciones pesadas en recursos
• Problemas de redes y seguridad.

Al comparar la configuración del contenedor con sus predecesoras, podemos concluir que la contenedorización es la configuración más rápida, más efectiva en recursos y más segura que conocemos hasta la fecha. Los contenedores son instancias aisladas que ejecutan su aplicación. Docker hace girar el contenedor de una manera, las capas obtienen memoria de tiempo de ejecución con controladores de almacenamiento predeterminados (controladores de superposición) que se ejecutan en segundos y una capa de copia en escritura creada encima de ella una vez que nos comprometemos en el contenedor, lo que potencia la ejecución de contenedores.En el caso de las máquinas virtuales, tomará alrededor de un minuto cargar todo en el entorno de virtualización. Estas instancias livianas se pueden reemplazar, reconstruir y mover fácilmente. Esto nos permite reflejar el entorno de producción y desarrollo y es de gran ayuda en los procesos de CI / CD. Las ventajas que los contenedores pueden proporcionar son tan convincentes que definitivamente están aquí para quedarse.

En relación a:-

"¿Por qué es más fácil implementar software en una imagen acoplable que simplemente implementarlo en un entorno de producción consistente?"

La mayoría del software se implementa en muchos entornos, generalmente un mínimo de tres de los siguientes:

1. PC de desarrollador individual (es)
2. Entorno de desarrollador compartido
3. PC de prueba individual (es)
4. Entorno de prueba compartido
5. Entorno de control de calidad
6. Entorno UAT
7. Prueba de carga / rendimiento
8. Puesta en escena en vivo
9. Producción
10. Archivo

También hay que considerar los siguientes factores:

• Los desarrolladores, y de hecho los probadores, tendrán configuraciones de PC sutiles o muy diferentes, por la propia naturaleza del trabajo.
• Los desarrolladores a menudo pueden desarrollar en PC más allá del control de las reglas de estandarización corporativas o comerciales (por ejemplo, freelancers que desarrollan en sus propias máquinas (a menudo de forma remota) o contribuyentes a proyectos de código abierto que no están 'empleados' o 'contratados' para configurar sus PC en particular camino)
• Algunos entornos consistirán en un número fijo de máquinas múltiples en una configuración de carga equilibrada
• Muchos entornos de producción tendrán servidores basados ​​en la nube creados y destruidos dinámicamente (o 'elásticamente') dependiendo de los niveles de tráfico

Como puede ver, el número total extrapolado de servidores para una organización rara vez se encuentra en cifras únicas, muy a menudo en cifras triples y puede ser fácilmente aún mayor.

Todo esto significa que crear entornos consistentes en primer lugar es bastante difícil solo por el gran volumen (incluso en un escenario de campo verde), pero mantenerlos consistentes es casi imposible dada la gran cantidad de servidores, la adición de nuevos servidores (dinámicamente o manualmente), actualizaciones automáticas de proveedores de O / S, proveedores de antivirus, proveedores de navegadores y similares, instalaciones manuales de software o cambios de configuración realizados por desarrolladores o técnicos de servidores, etc. Permítanme repetirlo: es prácticamente imposible (sin juego de palabras) para mantener los entornos consistentes (está bien, para el purista, se puede hacer, pero implica una gran cantidad de tiempo, esfuerzo y disciplina, que es precisamente por qué las máquinas virtuales y los contenedores (por ejemplo, Docker) se diseñaron en primer lugar).

Así que piense en su pregunta más así: "Dada la extrema dificultad de mantener consistentes todos los entornos, ¿es más fácil implementar software en una imagen acoplable, incluso teniendo en cuenta la curva de aprendizaje?" . Creo que la respuesta siempre será "sí", pero solo hay una forma de averiguarlo, publique esta nueva pregunta en Stack Overflow.

Hay muchas respuestas que explican más detalladamente las diferencias, pero aquí está mi breve explicación.

Una diferencia importante es que las máquinas virtuales usan un núcleo separado para ejecutar el sistema operativo . Esa es la razón por la que es pesado y toma tiempo arrancar, consumiendo más recursos del sistema.

En Docker, los contenedores comparten el núcleo con el host; por lo tanto, es liviano y puede comenzar y detenerse rápidamente.

En la virtualización, los recursos se asignan al comienzo de la configuración y, por lo tanto, los recursos no se utilizan por completo cuando la máquina virtual está inactiva durante muchas veces. En Docker, los contenedores no están asignados con una cantidad fija de recursos de hardware y es libre de usar los recursos según los requisitos y, por lo tanto, es altamente escalable.

Docker usa el sistema de archivos UNION . Docker usa una tecnología de copia en escritura para reducir el espacio de memoria consumido por los contenedores. Leer más aquí

Con una máquina virtual , tenemos un servidor, tenemos un sistema operativo host en ese servidor y luego tenemos un hipervisor. Y luego ejecutándose sobre ese hipervisor, tenemos cualquier número de sistemas operativos invitados con una aplicación y sus binarios dependientes y bibliotecas en ese servidor. Trae todo un sistema operativo invitado con él. Es bastante pesado. También hay un límite en cuanto a lo que realmente puede poner en cada máquina física.

Los contenedores Docker, por otro lado, son ligeramente diferentes. Tenemos el servidor Tenemos el sistema operativo host. Pero en lugar de un hipervisor , tenemos el motor Docker , en este caso. En este caso, no estamos trayendo todo un sistema operativo invitado con nosotros. Estamos trayendo una capa muy delgada del sistema operativo , y el contenedor puede comunicarse con el sistema operativo host para llegar a la funcionalidad del núcleo allí. Y eso nos permite tener un contenedor muy ligero.

Todo lo que tiene allí es el código de la aplicación y cualquier binario y biblioteca que requiera. Y esos binarios y bibliotecas pueden compartirse en diferentes contenedores si así lo desea. Y lo que esto nos permite hacer es una serie de cosas. Tienen un tiempo de inicio mucho más rápido . No puede soportar una sola VM en unos pocos segundos así. E igualmente, derribarlos tan rápido ... para que podamos escalarlos rápidamente y lo veremos más adelante.

Cada contenedor piensa que se está ejecutando en su propia copia del sistema operativo. Tiene su propio sistema de archivos, registro propio, etc., lo cual es una especie de mentira. En realidad se está virtualizando.

Fuente: Kubernetes en acción.

He usado Docker en entornos de producción y puesta en escena. Cuando te acostumbres, lo encontrarás muy poderoso para construir un contenedor múltiple y entornos aislados.

Docker ha sido desarrollado en base a LXC (Linux Container) y funciona perfectamente en muchas distribuciones de Linux, especialmente Ubuntu.

Los contenedores Docker son entornos aislados. Puede verlo cuando emite el topcomando en un contenedor Docker que se ha creado a partir de una imagen Docker.

Además de eso, son muy ligeros y flexibles gracias a la configuración de dockerFile.

Por ejemplo, puede crear una imagen Docker y configurar un DockerFile y decir que, por ejemplo, cuando se está ejecutando, luego wget 'this', apt-get 'that', ejecute 'alguna secuencia de comandos de shell', estableciendo variables de entorno, etc.

En proyectos y arquitectura de microservicios, Docker es un activo muy viable. Puede lograr escalabilidad, resistencia y elasticidad con Docker, Docker swarm, Kubernetes y Docker Compose.

Otra cuestión importante con respecto a Docker es Docker Hub y su comunidad. Por ejemplo, implementé un ecosistema para monitorear kafka usando Prometheus, Grafana, Prometheus-JMX-Exporter y Docker.

Para hacer eso, descargué contenedores Docker configurados para zookeeper, kafka, Prometheus, Grafana y jmx-collector y luego monté mi propia configuración para algunos de ellos usando archivos YAML, o para otros, cambié algunos archivos y configuraciones en el contenedor Docker y yo construya un sistema completo para monitorear kafka utilizando Dockers de contenedores múltiples en una sola máquina con aislamiento, escalabilidad y resistencia para que esta arquitectura pueda trasladarse fácilmente a múltiples servidores.

Además del sitio Docker Hub, hay otro sitio llamado quay.io que puede usar para tener su propio panel de imágenes Docker allí y tirar / empujar hacia / desde él. Incluso puede importar imágenes de Docker desde Docker Hub al muelle y luego ejecutarlas desde el muelle en su propia máquina.

Nota: Learning Docker, en primer lugar, parece complejo y difícil, pero cuando te acostumbras, no puedes trabajar sin él.

Recuerdo los primeros días de trabajo con Docker cuando emití los comandos incorrectos o eliminé mis contenedores y todos los datos y configuraciones por error.

Así se presenta Docker :

Docker es la compañía que impulsa el movimiento de contenedores y el único proveedor de plataformas de contenedores para abordar todas las aplicaciones en la nube híbrida. Las empresas de hoy están bajo presión para transformarse digitalmente, pero están limitadas por las aplicaciones y la infraestructura existentes al tiempo que racionalizan una cartera cada vez más diversa de nubes, centros de datos y arquitecturas de aplicaciones. Docker permite una verdadera independencia entre las aplicaciones y la infraestructura y los desarrolladores y las operaciones de TI para desbloquear su potencial y crea un modelo para una mejor colaboración e innovación.

Por lo tanto, Docker se basa en contenedores, lo que significa que tiene imágenes y contenedores que se pueden ejecutar en su máquina actual. No incluye el sistema operativo como máquinas virtuales, sino un paquete de diferentes paquetes de trabajo como Java, Tomcat, etc.

Si entiendes los contenedores, obtienes qué es Docker y en qué se diferencia de las máquinas virtuales ...

Entonces, ¿qué es un contenedor?

Una imagen de contenedor es un paquete ligero, independiente y ejecutable de un software que incluye todo lo necesario para ejecutarlo: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, configuraciones. Disponible para aplicaciones basadas en Linux y Windows, el software en contenedores siempre se ejecutará igual, independientemente del entorno. Los contenedores aíslan el software de su entorno, por ejemplo, las diferencias entre los entornos de desarrollo y preparación y ayudan a reducir los conflictos entre los equipos que ejecutan software diferente en la misma infraestructura.

Entonces, como puede ver en la imagen a continuación, cada contenedor tiene un paquete separado y se ejecuta en una sola máquina que comparte el sistema operativo de esa máquina ... Son seguros y fáciles de enviar ...

Aquí hay muchas buenas respuestas técnicas que discuten claramente las diferencias entre máquinas virtuales y contenedores, así como los orígenes de Docker.

Para mí, la diferencia fundamental entre VM y Docker es cómo gestiona la promoción de su aplicación.

Con las máquinas virtuales, usted promueve su aplicación y sus dependencias de una máquina virtual a la siguiente DEV a UAT a PRD.

1. A menudo, estas máquinas virtuales tendrán diferentes parches y bibliotecas.
2. No es raro que varias aplicaciones compartan una VM. Esto requiere administrar la configuración y las dependencias para todas las aplicaciones.
3. El retroceso requiere deshacer cambios en la VM. O restaurarlo si es posible.

Con Docker, la idea es agrupar su aplicación dentro de su propio contenedor junto con las bibliotecas que necesita y luego promocionar todo el contenedor como una sola unidad.

1. A excepción del núcleo, los parches y las bibliotecas son idénticos.
2. Como regla general, solo hay una aplicación por contenedor que simplifica la configuración.
3. El retroceso consiste en detener y eliminar el contenedor.

Entonces, en el nivel más fundamental con las máquinas virtuales, promueve la aplicación y sus dependencias como componentes discretos, mientras que con Docker promueve todo de una vez.

Y sí, hay problemas con los contenedores, incluida su administración, aunque herramientas como Kubernetes o Docker Swarm simplifican enormemente la tarea.