Pregunta ¿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 acoplador (si ese es el término correcto) que simplemente implementarlo en un entorno de producción uniforme?


2910
2018-04-16 21:19


origen


Respuestas:


Docker originalmente utilizado Contenedores LinuX (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 gestiona 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 montaje 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 más información, echa un vistazo este conjunto de publicaciones de blog que hacen un buen trabajo al explicar 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 usas herramientas como Cocinero y Marioneta, 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 Vía migratoria - 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. Dado que Docker normalmente se basa en las imágenes preparadas de un registro, usted raramente tiene que "capturar" todo el sistema operativo usted mismo.


2807
2018-04-16 22:35



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


338
2017-10-14 18:02



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 arquitectura x86 porque no había forma de hacer este tipo de interceptación. La gente de VMWare fueron los primeros quien tuvo la idea de reescribir los bytes ejecutables en la 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 2006, las personas, incluidos algunos de los empleados de Google, implementaron una nueva función de kernel llamada espacios de nombres (Sin embargo, la idea largo antes de existió 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í funciona Docker: cada contenedor se ejecuta en su propio espacio de nombres, pero usa exactamente el mismo kernel como 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 tú poder 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 compartir 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.


294
2018-01-13 01:49



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 empaque (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 Ops 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. Sobre todo debido a las limitaciones de las máquinas virtuales, se utilizó 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á que moverse alrededor de Gigabytes en "pequeños cambios" (Aufs de agradecimiento y Registro) y no tendrá que preocuparse 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 el aprovisionamiento de su servidor en el nivel de VM. Todo lo anterior podría ser administrado por Docker.

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


279
2017-09-19 16:21



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.

Emulation

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.

Paravirtualization

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.

Container-based virtualization

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 por el clon() llamada al sistema 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 programació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 consuman 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.


121
2018-04-02 00:55



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.

LXCs:

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 alcance 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 alcance para una instancia de Windows ahora si observamos las VM tienen un alcance 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.


117
2017-08-26 07:46



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 lo que Estibador te ayudará a entender esto más que a 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 compartimenta utilizando cgroups dentro del kernel del sistema host del resto de los procesos. En realidad, puede ver los procesos de contenedor Docker ejecutando ps aux en el host. Por ejemplo, comenzando apache2 "en un contenedor" acaba de comenzar 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 UnionFS-imágenes respaldadas, que es lo que estás descargando cuando haces 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. Puedes probar esto con docker save --output /tmp/ubuntu.tar ubuntuy entonces 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 mediante el uso de un puente 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" el uno con el otro. Aquí hay muchas opciones para establecer 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 pueda acceder directamente.

Docker se mueve muy rápido. Sus 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 #docker en Freenode IRC y preguntando allí (incluso puedes usar Freenode's chat web ¡para eso!).


89
2018-04-04 02:35



Docker encapsula una aplicación con todas sus dependencias, un virtualizador encapsula un O.S. que puede ejecutar cualquier aplicación que normalmente se puede ejecutar en una máquina de metal desnudo.


57
2017-08-27 18:25



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 (montaje), 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 back-end de almacenamiento (http://www.projectatomic.io/docs/filesystems/), por ejemplo, sistema de archivos union mount 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 (a.k.a., copia en escritura). 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: Here is a pic from rightscale


45
2017-11-03 17:44



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.

En segundo lugar, los contenedores Docker pueden comenzar en varios milisegundos, mientras que la 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 ahorra aún más espacio y es más rápido de construir.

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

3. Kernel del sistema operativo compartido

¡Piensa en los contenedores como procesos!

Todos los contenedores que se ejecutan en un host son, de hecho, un conjunto 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 OS adicional) pero puede ser un problema si se necesitan aislamientos estrictos entre contenedores.

¿Por qué es importante?

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

Piense en la implementación de aplicaciones. 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 máquina virtual. Debido a que al crear una máquina virtual con servicio actualizado, al probarla (compartir entre Dev y QA), la implementación en producción lleva horas, incluso días. Si algo sale mal, debes comenzar de nuevo, perdiendo incluso más tiempo. Por lo tanto, es preferible utilizar la herramienta de gestión de configuración (títere, salestack, chef, etc.) para instalar un nuevo software, descargar nuevos archivos.

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

Transforma cómo se entregan los servicios. Queremos aplicaciones, pero tenemos que mantener máquinas virtuales (lo cual es un problema y tiene poco que ver con nuestras aplicaciones). Docker te hace enfocarte en las aplicaciones y suaviza todo.


23
2017-08-10 04:25