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

Sigo releyendo la documentación de Docker para tratar de entender la diferencia entre Docker y una VM 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é es más fácil implementar software en una imagen de Docker (si ese es el término correcto) que simplemente implementarlo en un entorno de producción consistente?

    Docker originalmente usó 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, usa 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 fusionadas. Uno podría tener las partes comunes del sistema operativo como de solo lectura (y compartidas entre todos sus contenedores) y luego darle a cada contenedor su propio assembly para escribir.

    Entonces, digamos que tiene una imagen de contenedor de 1 GB; si desea utilizar una máquina virtual completa, deberá tener 1 GB multiplicado por x cantidad de máquinas virtuales que desee. Con Docker y AuFS puede compartir la mayor parte de los 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 contenedores (suponiendo que todos ejecuten la misma imagen del sistema operativo) .

    Un sistema virtualizado completo obtiene su propio conjunto de recursos asignados y realiza un intercambio mínimo. Obtiene más aislamiento, pero es mucho más pesado (requiere más recursos). Con Docker, obtiene 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 hacer eso con Xen, y a menos que tengas un gran anfitrión, no creo que sea posible.

    Un sistema virtualizado completo generalmente demora unos minutos en comenzar, mientras que los contenedores Docker / LXC / runC toman segundos, y con frecuencia incluso menos de un segundo.

    Existen ventajas y desventajas para cada tipo de sistema virtualizado. Si desea un aislamiento completo con recursos garantizados, una VM completa es el camino a seguir. Si solo desea aislar 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 de acoplador (si ese es el término correcto) que simplemente implementarlo en un entorno de producción uniforme?

    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 de SO y otras cosas que cambian entre hosts y entornos.

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

    Esto es genial para probar; digamos que tiene miles de pruebas que necesitan conectarse a una base de datos, y cada prueba necesita una copia prístina de la base de datos y hará cambios a los datos. El enfoque clásico de 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 consumir mucho tiempo y significa que las pruebas se deben ejecutar en serie. Sin embargo, con Docker puede 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 se ejecutarán todas contra 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 hacer eso con una VM 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 puede hacer eso sin, bueno, hacer una imagen del sistema operativo?

    Bueno, veamos si puedo explicarlo. Empiezas con una imagen base y luego haces los cambios y los comprometes con la ventana acoplable y 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 mediante un sistema de archivos en capas: como se mencionó anteriormente, Docker usa AUFS. AUFS combina las diferentes capas y obtiene lo que desea; solo necesitas ejecutarlo. Puede seguir agregando más y más imágenes (capas) y solo continuará guardando las diferencias. Debido a que Docker generalmente se basa en las imágenes ya preparadas de un registro , rara vez tiene que hacer una “instantánea” de todo el sistema operativo usted mismo.

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

    enter image description here

    Fuente: https://www.docker.com/what-container#/package_software

    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 0 de la CPU (o el “modo raíz” en las CPU más nuevas) e intercepta todas las llamadas privilegiadas realizadas por el sistema operativo invitado para crear la ilusión de que el sistema operativo invitado tiene su propio hardware. Dato curioso: antes de 1998 se pensaba que era imposible lograr esto en la architecture x86 porque no había forma de hacer este tipo de interceptación. La gente de VMWare fue la primera que tuvo la idea de reescribir los bytes ejecutables en memoria para las llamadas privilegiadas del sistema operativo invitado para lograr esto.

    El efecto neto es que la virtualización le permite ejecutar dos SO completamente diferentes en el mismo hardware. Cada sistema operativo invitado realiza todo el proceso de arranque, carga del kernel, etc. Puede tener una seguridad muy ajustada, por ejemplo, el sistema operativo invitado no puede obtener acceso completo al sistema operativo anfitrión u otros invitados y puede complicar 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 ya existía mucho antes en FreeBSD ). Una función del sistema operativo es permitir compartir recursos globales como red y disco a 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? Supongamos que puede obtener un trozo de disco y ponerlo en el espacio de nombres X y luego procesa la ejecución en el espacio de nombres Y no puede ver ni acceder a él. De manera similar, 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 procesos en el espacio de nombres Y. Esto proporciona un tipo de virtualización y aislamiento para recursos globales. Así es como funciona Docker: cada contenedor se ejecuta en su propio espacio de nombres, pero utiliza exactamente el mismo kernel que todos los demás contenedores. El aislamiento ocurre porque Kernel conoce el espacio de nombre que se le asignó 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 máquina virtual deberían ser obvias ahora: no puede ejecutar sistemas operativos completamente diferentes en contenedores como en máquinas virtuales. Sin embargo, puede ejecutar diferentes distribuciones de Linux porque comparten el mismo kernel. 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 contenedor nuevo, la copia nueva completa del sistema operativo no se inicia como lo hace en la máquina virtual. Todos los contenedores comparten el mismo kernel . Esta es la razón por la cual los contenedores son livianos. Además, a diferencia de VM, no tiene que asignar previamente una cantidad significativa de memoria a los contenedores porque no estamos ejecutando una nueva copia del sistema operativo. Esto permite ejecutar miles de contenedores en un SO mientras los guarda en cajas de seguridad, lo que podría no ser posible si estuviéramos ejecutando una copia separada del sistema operativo en su propia máquina virtual.

    Me gusta la respuesta de Ken Cochrane.

    Pero quiero agregar un punto de vista adicional, que no se trata en detalle aquí. En mi opinión, Docker también difiere en todo el proceso. A diferencia de las máquinas virtuales, Docker no es (solo) sobre el intercambio óptimo de recursos de hardware, además proporciona un “sistema” para la aplicación de empaquetado (preferible, pero no obligatorio, como un conjunto de microservicios).

    Para mí encaja en la brecha entre herramientas orientadas a desarrolladores como rpm, paquetes Debian , Maven , npm + Git por un lado y herramientas opcionales como Puppet , VMware, Xen, lo que sea …

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

    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 propias secuencias de comandos de aprovisionamiento, reglas no publicadas y / o gran cantidad de documentación … En teoría, los servidores pueden ejecutarse de forma indefinida y mantenerse completamente consistentes y actualizados. La práctica no puede administrar completamente la configuración de un servidor, por lo que existe un margen considerable para la deriva de configuración y cambios inesperados en los servidores en ejecución.

    Entonces 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 VM 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 laborioso. Comprensible…

    Con un ecosistema Docker, nunca tendrás que moverte por gigabytes en “pequeños cambios” (gracias aufs y Registry) y no tendrás que preocuparte por perder rendimiento empacando aplicaciones en un contenedor Docker en tiempo de ejecución. No necesita preocuparse por las versiones de esa imagen.

    Y finalmente, incluso con frecuencia 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 su aprovisionamiento de servidor en el nivel de VM. Todo lo anterior podría ser administrado por Docker.

    Mientras tanto, Docker utiliza 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 de sistema operativo. Para eso, Docker inicialmente estaba usando el controlador LXC, luego se movió a libcontainer, que ahora se renombra como runc. Docker se centra principalmente en la automatización de 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 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 empresas 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 varios 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 asignan a los invitados según sea necesario. El hipervisor se ubica entre la máquina física y las máquinas virtuales y brinda 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 aún más el uso de la virtualización al permitir la creación de múltiples servidores virtuales en un único servidor físico con la ayuda de hipervisores, como Xen, VMware Player, KVM, etc. incorporación de soporte de hardware en procesadores de productos básicos, como Intel VT y AMD-V.

    Tipos de virtualización

    El método de virtualización se puede clasificar según la forma en que imita el hardware a un sistema operativo invitado y emula el 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 el software. El hipervisor utilizado en este tipo se conoce como hipervisor Tipo 2. Está instalado en la parte superior del sistema operativo del host, que es responsable de traducir el código kernel del SO invitado a las instrucciones del software. La traducción se realiza completamente en software y no requiere participación de hardware. La emulación hace posible ejecutar cualquier sistema operativo no modificado que sea compatible con el entorno que se emula. La desventaja de este tipo de virtualización es una sobrecarga adicional de recursos del sistema que conduce a una disminución en el rendimiento en comparación con otros tipos de virtualizaciones.

    Emulación

    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, el hardware virtualizado y el hardware real a colaborar para lograr un rendimiento óptimo. Estos hipervisores suelen tener una huella bastante pequeña y no requieren recursos extensos.

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

    Paravirtualización

    Virtualización basada en contenedores

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

    Virtualización basada en contenedores

    El concepto de contenedor es posible gracias a la función de espacios de nombres añadida a la versión 2.6.24 del kernel de Linux. El contenedor agrega su ID a cada proceso y agrega nuevas comprobaciones 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 estar ejecutándose 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, al usar espacios de nombres, el usuario raíz dentro del contenedor no se trata como raíz fuera del contenedor, lo que agrega seguridad adicional.

    El subsistema 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 el consumo total de recursos. Se usa comúnmente para limitar la memoria y el consumo de CPU de los contenedores. Dado que un sistema Linux contenedorizado tiene solo un kernel y el núcleo tiene una visibilidad total de los contenedores, solo hay un nivel de asignación de recursos y progtwigción.

    Varias herramientas de administración están disponibles para contenedores Linux, incluyendo 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 arrancar 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 carga a la máquina host, la virtualización basada en contenedores tiene un rendimiento casi nativo

    Para la virtualización basada en contenedor, 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 de host, lo que ahorra la necesidad de recursos adicionales.

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

    La administración de recursos en contenedores se logra a través de cgroups. Cgroups no permite que los contenedores consumn más recursos que los asignados. Sin embargo, a partir de ahora, todos los recursos de la máquina host son visibles en máquinas virtuales, pero no se pueden usar. Esto puede realizarse ejecutando top o htop en contenedores y máquina host al mismo tiempo. La salida en todos los entornos se verá similar.

    A través de esta publicación vamos a dibujar algunas líneas de diferencias entre máquinas virtuales y LXCs. Vamos a definirlos primero.

    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 gestionados por una capa de virtualización que traduce estas solicitudes al hardware físico subyacente.

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

    LXC s:

    Linux Containers (LXC) son capacidades de nivel de sistema operativo que hacen posible ejecutar múltiples contenedores 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. Virtualbox, KVM, Xen, etc.

    Ahora, a menos que usted haya sido drogado por Alan (Zach Galifianakis, de la serie Hangover) y haya estado en Las Vegas durante el último año, será muy consciente del enorme interés que despierta la tecnología de contenedores Linux, y si voy a ser específico, un contenedor El proyecto que generó revuelo en todo el mundo en los últimos meses es Docker, que generó algunas opiniones de que los entornos de computación en 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 scope a una instancia de Linux. Pueden ser diferentes sabores de Linux (por ejemplo, un contenedor Ubuntu en un host CentOS pero sigue siendo Linux). Del mismo modo, los contenedores basados ​​en Windows tienen un scope para una instancia de Windows ahora si observamos las VM tienen un scope bastante más amplio y usan el hipervisores no está limitado a los sistemas operativos Linux o Windows.

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

    Entonces, el mejor enfoque es que los proveedores de infraestructura en la nube deben abogar por un uso apropiado de las VM y LXC, ya que cada una de ellas es adecuada para manejar cargas de trabajo y escenarios específicos.

    Abandonar máquinas virtuales no es práctico a partir de ahora. Por lo tanto, ambas VM y 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 de una línea a esta pregunta que me ha ayudado más en los últimos años de usar Docker. Es esto:

    Docker es simplemente 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 qué es Docker para que entiendas esto más que para explicar qué es una máquina virtual. Especialmente porque hay muchas buenas respuestas aquí que le dicen exactamente a qué se refiere alguien cuando dicen “máquina virtual”. Asi que…

    Un contenedor Docker es solo un proceso (y sus hijos) que se divide en compartimentos usando cgroups dentro del kernel del sistema host del rest de los procesos. En realidad, puede ver los procesos de contenedor Docker ejecutando ps aux en el host. Por ejemplo, iniciar apache2 “en un contenedor” solo está iniciando apache2 como un proceso especial en el host. Simplemente ha sido compartimentado 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 contenedorizado. Cuando su proceso muere, su contenedor muere. Eso es porque Docker reemplaza pid 1 dentro de su contenedor con su aplicación ( pid 1 es normalmente el sistema init). Este último punto sobre pid 1 es muy importante.

    En cuanto al sistema de archivos utilizado por cada uno de esos procesos de contenedor, Docker utiliza imágenes respaldadas por UnionFS , que es lo que está descargando cuando hace una docker pull ubuntu . Cada “imagen” es solo una serie de capas y metadatos relacionados. El concepto de estratificación es muy importante aquí. Cada capa es solo un cambio de la capa debajo de ella. Por ejemplo, cuando elimina un archivo en su archivo Docker mientras construye un contenedor Docker, en realidad solo está creando una capa sobre la última capa que dice “este archivo ha sido eliminado”. Por cierto, esta es la razón por la que puede eliminar un archivo grande de su sistema de archivos, pero la imagen aún ocupa la misma cantidad de espacio en el disco. El archivo todavía está allí, en las capas debajo del actual. Las capas en sí son solo archivos de archivos. Puede probar esto con el docker save --output /tmp/ubuntu.tar ubuntu y luego cd /tmp && tar xvf ubuntu.tar . Entonces puedes echar un vistazo alrededor. Todos esos directorios que parecen hashes largos son en realidad las capas individuales. Cada uno contiene archivos ( layer.tar ) y metadatos ( json ) con información sobre esa capa en particular. Esas capas solo describen los 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 estuvieran mirando las capas superiores de cambios. Es por eso que el archivo parece ser eliminado, aunque todavía existe en capas “anteriores”, porque el sistema de archivos solo está mirando las capas superiores. Esto permite que contenedores completamente diferentes compartan sus capas de sistema de archivos, aunque algunos cambios significativos pueden haberle ocurrido 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, cuando monta directorios y archivos desde el sistema host en su contenedor por medio de volúmenes, esos volúmenes “pasan por alto” el UnionFS, por lo que los cambios no se almacenan en capas.

    La conexión en red en Docker se logra utilizando un puente de ethernet (llamado docker0 en el host) e interfaces virtuales para cada contenedor en el host. Crea una subred virtual en docker0 para que sus contenedores se comuniquen “entre ellos”. Aquí hay muchas opciones para establecer redes, incluida la creación de subredes personalizadas para sus contenedores, y la capacidad de “compartir” la stack de redes de su host para que su contenedor pueda acceder directamente.

    Docker se mueve muy rápido. Su documentación es una de la mejor documentación que he visto en mi vida. Por lo general, está bien escrito, es 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 a #docker en Freenode IRC y preguntar allí (¡incluso puede usar el chat #docker 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 se puede ejecutar en una máquina de metal desnudo.

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

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

    ¿Qué hay de 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 ahí. Además de LXC, Docker proporciona un backend de almacenamiento ( http://www.projectatomic.io/docs/filesystems/ ), por ejemplo, un sistema de archivos union mount donde puede agregar capas y compartir capas entre diferentes espacios de nombres de assembly.

    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 y escritura (también conocida como copiar al escribir). También proporciona muchas otras envolturas, como registro y control de versiones de imágenes.

    Con el LXC normal necesita venir con algunos rootfs o compartir los rootfs y cuando se comparte, y los cambios se reflejan en otros contenedores. Debido a la gran cantidad de estas características adicionales, Docker es más popular que LXC. LXC es popular en entornos integrados para implementar seguridad en procesos expuestos a entidades externas como la red y la IU. Docker es popular en el entorno multi-tenancy en la nube donde se espera un entorno de producción consistente.

    Una VM normal (por ejemplo, VirtualBox y VMware) usa un hipervisor y las tecnologías relacionadas tienen firmware dedicado que se convierte en la primera capa para el primer sistema operativo (sistema operativo host o OS huésped 0) o un software que se ejecuta en el sistema operativo host. proporcione emulación de hardware, como CPU, USB / accesorios, memoria, red, etc., a los sistemas operativos invitados. Las máquinas virtuales aún son (a partir de 2015) populares en entornos 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 y cuando tengas kernel más nuevo) frente a VM 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 el sistema operativo, como Windows (a partir de noviembre de 2014), donde los tipos de máquinas virtuales pueden ejecutarse en Windows, Linux y Mac.

    Aquí hay una foto de docker / rightscale: Aquí hay una foto de la escala de derechos

    1. Ligero

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

    En primer lugar, las imágenes acoplables generalmente son más pequeñas que las imágenes VM, lo que facilita la creación, copia y uso compartido.

    Second, Docker containers can start in several milliseconds, while VM starts in seconds.

    2. Layered File System

    This is another key feature of Docker. Images have layers, and different images can share layers, make it even more space-saving and faster to build.

    If all containers use Ubuntu as their base images, not every image has its own file system, but share the same underline ubuntu files, and only differs in their own application data.

    3. Shared OS Kernel

    Think of containers as processes!

    All containers running on a host is indeed a bunch of processes with different file systems. They share the same OS kernel, only encapsulates system library and dependencies.

    This is good for most cases(no extra OS kernel maintains) but can be a problem if strict isolations are necessary between containers.

    ¿Por qué es importante?

    All these seem like improvements, not revolution. Well, quantitative accumulation leads to qualitative transformation .

    Think about application deployment. If we want to deploy a new software(service) or upgrade one, it is better to change the config files and processes instead of creating a new VM. Because Creating a VM with updated service, testing it(share between Dev & QA), deploying to production takes hours, even days. If anything goes wrong, you got to start again, wasting even more time. So, use configuration management tool(puppet, saltstack, chef etc.) to install new software, download new files is preferred.

    When it comes to docker, it’s impossible to use a newly created docker container to replace the old one. Maintainance is much easier!Building a new image, share it with QA, testing it, deploying it only takes minutes(if everything is automated), hours in the worst case. This is called immutable infrastructure : do not maintain(upgrade) software, create a new one instead.

    It transforms how services are delivered. We want applications, but have to maintain VMs(which is a pain and has little to do with our applications). Docker makes you focus on applications and smooths everything.

    Docker, basically containers, supports OS virtualization ie your application feels that it has a complete instance of an OS whereas VM supports hardware virtualization . You feel like it is a physical machine in which you can boot any OS.

    In Docker, the containers running share the host OS kernel, whereas in VMs they have their own OS files. The environment (the OS) in which you develop an application would be same when you deploy it to various serving environments, such as “testing” or “production”.

    For example, if you develop a web server that runs on port 4000, when you deploy it to your “testing” environment, that port is already used by some other program, so it stops working. In containers there are layers; all the changes you have made to the OS would be saved in one or more layers and those layers would be part of image, so wherever the image goes the dependencies would be present as well.

    In the example shown below, the host machine has three VMs. In order to provide the applications in the VMs complete isolation, they each have their own copies of OS files, libraries and application code, along with a full in-memory instance of an OS. Without Containers Whereas the figure below shows the same scenario with containers. Here, containers simply share the host operating system, including the kernel and libraries, so they don’t need to boot an OS, load libraries or pay a private memory cost for those files. The only incremental space they take is any memory and disk space necessary for the application to run in the container. While the application’s environment feels like a dedicated OS, the application deploys just like it would onto a dedicated host. The containerized application starts in seconds and many more instances of the application can fit onto the machine than in the VM case. enter image description here

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

    In relation to:-

    “Why is deploying software to a docker image easier than simply deploying to a consistent production environment ?”

    Most software is deployed to many environments, typically a minimum of three of the following:

    1. Individual developer PC(s)
    2. Shared developer environment
    3. Individual tester PC(s)
    4. Shared test environment
    5. QA environment
    6. UAT environment
    7. Load / performance testing
    8. Live staging
    9. Producción
    10. Archivo

    There are also the following factors to consider:

    • Developers, and indeed testers, will all have either subtlely or vastly different PC configurations, by the very nature of the job
    • Developers can often develop on PCs beyond the control of corporate or business standardisation rules (eg freelancers who develop on their own machines (often remotely) or contributors to open source projects who are not ’employed’ or ‘contracted’ to configure their PCs a certain way)
    • Some environments will consist of a fixed number of multiple machines in a load balanced configuration
    • Many production environments will have cloud-based servers dynamically (or ‘elastically’) created and destroyed depending on traffic levels

    As you can see the extrapolated total number of servers for an organisation is rarely in single figures, is very often in triple figures and can easily be significantly higher still.

    This all means that creating consistent environments in the first place is hard enough just because of sheer volume (even in a green field scenario), but keeping them consistent is all but impossible given the high number of servers, addition of new servers (dynamically or manually), automatic updates from o/s vendors, anti-virus vendors, browser vendors and the like, manual software installs or configuration changes performed by developers or server technicians, etc. Let me repeat that – it’s virtually (no pun intended) impossible to keep environments consistent (okay, for the purist, it can be done, but it involves a huge amount of time, effort and discipline, which is precisely why VMs and containers (eg Docker) were devised in the first place).

    So think of your question more like this “Given the extreme difficulty of keeping all environments consistent, is it easier to deploying software to a docker image, even when taking the learning curve into account ?” . I think you’ll find the answer will invariably be “yes” – but there’s only one way to find out, post this new question on Stack Overflow.

    There are three different setups that providing a stack to run an application on (This will help us to recognize what a container is and what makes it so much powerful than other solutions):

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

    1) Traditional server stack consist of a physical server that runs an operating system and your application.

    Ventajas:

    • Utilization of raw resources

    • Aislamiento

    Desventajas:

    • Very slow deployment time
    • Costoso
    • Wasted resources
    • Difficult to scale
    • Difficult to migrate
    • Complex configuration

    2) The VM stack consist of a physical server which runs an operating system and a hypervisor that manages your virtual machine, shared resources, and networking interface. Each Vm runs a Guest Operating System, an application or set of applications.

    Ventajas:

    • Good use of resources
    • Easy to scale
    • Easy to backup and migrate
    • Cost efficiency
    • Flexibilidad

    Desventajas:

    • Resource allocation is problematic
    • Vendor lockin
    • Complex configuration

    3) The Container Setup , the key difference with other stack is container-based virtualization uses the kernel of the host OS to rum multiple isolated guest instances. These guest instances are called as containers. The host can be either a physical server or VM.

    Ventajas:

    • Aislamiento
    • Ligero
    • Resource effective
    • Easy to migrate
    • Seguridad
    • Low overhead
    • Mirror production and development environment

    Desventajas:

    • Same Architecture
    • Resource heavy apps
    • Networking and security issues.

    By comparing the container setup with its predecessors, we can conclude that containerization is the fastest, most resource effective, and most secure setup we know to date. Containers are isolated instances that run your application. Docker spin up the container in a way, layers get run time memory with default storage drivers(Overlay drivers) those run within seconds and copy-on-write layer created on top of it once we commit into the container, that powers the execution of containers. In case of VM’s that will take around a minute to load everything into the virtualize environment. These lightweight instances can be replaced, rebuild, and moved around easily. This allows us to mirror the production and development environment and is tremendous help in CI/CD processes. The advantages containers can provide are so compelling that they’re definitely here to stay.

    There are many answers which explain more detailed on the differences, but here is my very brief explanation.

    One important difference is that VMs use a separate kernel to run the OS . That’s the reason it is heavy and takes time to boot, consuming more system resources.

    In Docker, the containers share the kernel with the host; hence it is lightweight and can start and stop quickly.

    In Virtualization, the resources are allocated in the beginning of set up and hence the resources are not fully utilized when the virtual machine is idle during many of the times. In Docker, the containers are not allocated with fixed amount of hardware resources and is free to use the resources depending on the requirements and hence it is highly scalable.

    Docker uses UNION File system .. Docker uses a copy-on-write technology to reduce the memory space consumed by containers. Read more here

    With a virtual machine , we have a server, we have a host operating system on that server, and then we have a hypervisor. And then running on top of that hypervisor, we have any number of guest operating systems with an application and its dependent binaries, and libraries on that server. It brings a whole guest operating system with it. It’s quite heavyweight. Also there’s a limit to how much you can actually put on each physical machine.

    Ingrese la descripción de la imagen aquí

    Docker containers on the other hand, are slightly different. We have the server. We have the host operating system. But instead a hypervisor , we have the Docker engine , in this case. In this case, we’re not bringing a whole guest operating system with us. We’re bringing a very thin layer of the operating system , and the container can talk down into the host OS in order to get to the kernel functionality there. And that allows us to have a very lightweight container.

    All it has in there is the application code and any binaries and libraries that it requires. And those binaries and libraries can actually be shared across different containers if you want them to be as well. And what this enables us to do, is a number of things. They have much faster startup time . You can’t stand up a single VM in a few seconds like that. And equally, taking them down as quickly.. so we can scale up and down very quickly and we’ll look at that later on.

    Ingrese la descripción de la imagen aquí

    Every container thinks that it’s running on its own copy of the operating system. It’s got its own file system, own registry, etc. which is a kind of a lie. It’s actually being virtualized.

    I have used Docker in production environments and staging very much. When you get used to it you will find it very powerful for building a multi container and isolated environments.

    Docker has been developed based on LXC (Linux Container) and works perfectly in many Linux distributions, especially Ubuntu.

    Docker containers are isolated environments. You can see it when you issue the top command in a Docker container that has been created from a Docker image.

    Besides that, they are very light-weight and flexible thanks to the dockerFile configuration.

    For example, you can create a Docker image and configure a DockerFile and tell that for example when it is running then wget ‘this’, apt-get ‘that’, run ‘some shell script’, setting environment variables and so on.

    In micro-services projects and architecture Docker is a very viable asset. You can achieve scalability, resiliency and elasticity with Docker, Docker swarm, Kubernetes and Docker Compose.

    Another important issue regarding Docker is Docker Hub and its community. For example, I implemented an ecosystem for monitoring kafka using Prometheus, Grafana, Prometheus-JMX-Exporter, and Dokcer.

    For doing that I downloaded configured Docker containers for zookeeper, kafka, Prometheus, Grafana and jmx-collector then mounted my own configuration for some of them using yml files or for others I changed some files and configuration in the Docker container and I build a whole system for monitoring kafka using multi-container Dockers on a single machine with isolation and scalability and resiliency that this architecture can be easily moved into multiple servers.

    Besides the Docker Hub site there is another site called quay.io that you can use to have your own Docker images dashboard there and pull/push to/from it. You can even import Docker images from Docker Hub to quay then running them from quay on your own machine.

    Note: Learning Docker in the first place seems complex and hard, but when you get used to it then you can not work without it.

    I remember the first days of working with Docker when I issued the wrong commands or removing my containers and all of data and configurations mistakenly.

    This is how Docker introduces itself:

    Docker is the company driving the container movement and the only container platform provider to address every application across the hybrid cloud. Today’s businesses are under pressure to digitally transform but are constrained by existing applications and infrastructure while rationalizing an increasingly diverse portfolio of clouds, datacenters and application architectures. Docker enables true independence between applications and infrastructure and developers and IT ops to unlock their potential and creates a model for better collaboration and innovation.

    So Docker is container based, meaning you have images and containers which can be run on your current machine. It’s not including the operating system like VM s, but like a pack of different working packs like Java, Tomcat, etc.

    If you understand containers, you get what Docker is and how it’s different from VM s…

    So, what’s a container?

    A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.

    Estibador

    So as you see in the image below, each container has a separate pack and running on a single machine share that machine’s operating system… They are secure and easy to ship…

    There are a lot of nice technical answers here that clearly discuss the differences between VMs and containers as well as the origins of Docker.

    For me the fundamental difference between VMs and Docker is how you manage the promotion of your application.

    With VMs you promote your application and its dependencies from one VM to the next DEV to UAT to PRD.

    1. Often these VM’s will have different patches and libraries.
    2. It is not uncommon for multiple applications to share a VM. This requires managing configuration and dependencies for all the applications.
    3. Backout requires undoing changes in the VM. Or restring it if possible.

    With Docker the idea is that you bundle up your application inside its own container along with the libraries it needs and then promote the whole container as a single unit.

    1. Except for the kernel the patches and libraries are identical.
    2. As a general rule there is only one application per container which simplifies configuration.
    3. Backout consists of stopping and deleting the container.

    So at the most fundamental level with VMs you promote the application and its dependencies as discrete components whereas with Docker you promote everything in one hit.

    And yes there are issues with containers including managing them although tools like Kubernetes or Docker Swarm greatly simplify the task.

    Difference between how apps in VM use cpu vs containers

    Source: Kubernetes in Action.

    I think this should be the basis of understanding all other answers and extra information linked.

    Honestly, we cannot compare docker to VM. From all answers before me, many of them have already shown such a point. But they still failed to say it out specifically.

    To compare one thing to another, they must have the similar position or functionality, in their field at least.

    Below I come up with a rough pair list which includes all concept/software I know. I will appreciate it if someone could make it up for all of us. ¡Gracias!

    Docker — VMWare
    libcontainer/runc — hypervisor
    Docker image — VM OS image
    Docker container — VM/virtual machine

    Hope this would help all of you. From my opinion, Docker is a tool(based on libcontainer/runc) that could somehow carry kernel instructions to multiple containers. VMWare is a tool (based on hypervisor) that could somehow carry hardware instructions to multiple virtual machine instances.

    Eso es.