¿Cuál es la diferencia entre contenedorización (Docker) y virtualización (VMWare, VirtualBox, Xen)?

Estamos bien entrados en 2017 y supongo que hasta ahora todos están familiarizados con la diferencia básica entre las plataformas Docker y Virtualization, por lo que no estoy centrando mi respuesta en el aspecto del hipervisor. En cambio, trataré de cubrir diferencias no tan obvias en términos cortos y simples.

1. ¿Por qué se hicieron?
   La virtualización nació de la necesidad de usar múltiples sistemas operativos en un solo hardware y la principal motivación es reducir el costo de mantenimiento de servidores de hardware y aprovechar los beneficios económicos de ejecutar múltiples cargas de trabajo aisladas en una sola máquina.

   Mientras que Docker nació de la necesidad de abstraer el ecosistema global de una aplicación (SO, Network Stack, CPU, módulos de software, etc.) para que una aplicación se ejecute de manera predecible en todos los entornos (Desarrollo / Puesta en escena / Producción, etc. )

2. Hay contribución al mundo de Micro Servicios
   Implementar servicios Micro es mucho más fácil en una plataforma de administración de contenedores como Kubernetes, Elastic Container Service y Mesos de Amazon que en máquinas virtuales.

   Las plataformas de administración de contenedores hacen que Service Discovery sea muy fácil, aunque hasta ahora no existen tales herramientas para las máquinas virtuales (no al menos en las instalaciones), puede usar Nginx o HAProxy para lograr el mismo efecto, pero esta forma de hacer Service Discovery sería más artificial que natural.

3. Rendimiento de red en servidores Bare Metal
   Muchos hipervisores modernos usan una técnica llamada SR-IOV (Single Root IO Virtualization) para obtener el máximo rendimiento de la red, esto está en conjunto con la tarjeta de interfaz de red subyacente. Por lo tanto, si su hardware no es compatible con SR-IOV, tendrá dificultades para obtener el rendimiento de la red para aplicaciones de alto rendimiento.

   Por otro lado, Docker no requerirá SR-IOV ya que no hay una capa de virtualización entre Docker y el SO, lo que le da acceso total al rendimiento de la red.

4. Orquestación
   VMWare ESX y Co. están más orientados a los ingenieros y desarrolladores de infraestructura que no necesariamente tienen experiencia para acelerar las máquinas virtuales y el entorno de orquestación según sea necesario a partir de una plantilla que use VMWare ESX, etc.

   Docker, por otro lado, tiene un formato de archivo muy simple para crear contenedores y herramientas como Swarm, Marathon y Kubernetes, lo que hace que la orquestación de contenedores sea fácil, si no brisa.

Comprendamos la virtualización y la contenedorización uno por uno.

Referencia: este es uno de mis blogs de Edureka.

¿Qué es la virtualización?

La virtualización es la técnica de importar un sistema operativo Guest encima de un sistema operativo Host. Esta técnica fue una revelación al principio porque permitía a los desarrolladores ejecutar múltiples sistemas operativos en diferentes máquinas virtuales, todas ejecutadas en el mismo host. Esto eliminó la necesidad de recursos de hardware adicionales. Las ventajas de las máquinas virtuales o la virtualización son:

• Se pueden ejecutar múltiples sistemas operativos en la misma máquina
• El mantenimiento y la recuperación fueron fáciles en caso de fallas
• El costo total de propiedad también fue menor debido a la menor necesidad de infraestructura

En el diagrama, puede ver que hay un sistema operativo host en el que se ejecutan 3 sistemas operativos invitados que no son más que máquinas virtuales.

Como sabes, nada es perfecto, la virtualización también tiene algunas deficiencias. La ejecución de múltiples máquinas virtuales en el mismo sistema operativo host conduce a la degradación del rendimiento. Esto se debe a que el SO invitado se ejecuta sobre el SO host, que tendrá su propio núcleo y un conjunto de bibliotecas y dependencias. Esto ocupa una gran parte de los recursos del sistema, es decir, disco duro, procesador y especialmente RAM.

Otro problema con las máquinas virtuales que utiliza la virtualización es que lleva casi un minuto arrancar. Esto es muy crítico en el caso de aplicaciones en tiempo real.

Las siguientes son las desventajas de la virtualización:

• La ejecución de múltiples máquinas virtuales conduce a un rendimiento inestable
• Los hipervisores no son tan eficientes como el sistema operativo host
• El proceso de arranque es largo y lleva tiempo

Estos inconvenientes llevaron a la aparición de una nueva técnica llamada Containerization. Ahora déjame contarte sobre Containerization.

¿Qué es la contenedorización?

La contenedorización es la técnica de llevar la virtualización al nivel del sistema operativo. Mientras que la virtualización aporta abstracción al hardware, la contenedorización aporta abstracción al sistema operativo. Tenga en cuenta que la contenedorización también es un tipo de virtualización. Sin embargo, la contenedorización es más eficiente porque no hay un sistema operativo invitado aquí y utiliza el sistema operativo de un host, comparte bibliotecas y recursos relevantes cuando sea necesario, a diferencia de las máquinas virtuales. Los binarios y las bibliotecas de contenedores específicos de la aplicación se ejecutan en el núcleo del host, lo que hace que el procesamiento y la ejecución sean muy rápidos. Incluso arrancar un contenedor lleva solo una fracción de segundo. Debido a que todos los contenedores comparten, alojan el sistema operativo y solo contienen los binarios y bibliotecas relacionados con la aplicación. Son ligeros y más rápidos que las máquinas virtuales.

Ventajas de la contenedorización sobre la virtualización:

• Los contenedores en el mismo núcleo del sistema operativo son más livianos y pequeños
• Mejor utilización de recursos en comparación con las máquinas virtuales
• El proceso de arranque es corto y toma unos segundos.

En el diagrama de la derecha, puede ver que hay un sistema operativo host que todos los contenedores comparten. Los contenedores solo contienen bibliotecas específicas de la aplicación que están separadas para cada contenedor y son más rápidas y no desperdician ningún recurso.

Todos estos contenedores son manejados por la capa de contenedorización que no es nativa del sistema operativo host. Por lo tanto, se necesita un software que le permita crear y ejecutar contenedores en su sistema operativo host.

Mira este video tutorial de Docker entregado por mí para una mejor comprensión de Docker.

Espero que la respuesta ayude. Feliz aprendizaje 🙂

Trataré de explicarte en palabras muy simples.

Virtualización

Las máquinas virtuales tienen un sistema operativo completo con su propia administración de memoria instalada con la sobrecarga asociada de los controladores de dispositivos virtuales. En una máquina virtual, se emulan recursos valiosos para el SO huésped y el hipervisor, lo que hace posible ejecutar muchas instancias de uno o más sistemas operativos en paralelo en una sola máquina (o host). Cada sistema operativo invitado se ejecuta como una entidad individual del sistema host.

Contenedores Docker

Por otro lado, los contenedores Docker se ejecutan con el motor Docker en lugar del hipervisor. Por lo tanto, los contenedores son más pequeños que las máquinas virtuales y permiten un arranque más rápido con un mejor rendimiento, menos aislamiento y una mayor compatibilidad posible debido al uso compartido del núcleo del host.

Ventajas de usar Docker sobre VM:

1. Portabilidad
2. Aislamiento
3. Reusabilidad
4. Uso efectivo del hardware
5. Mejores DevOps
6. Despliegue continuo y pruebas.

A menudo se comparan, tal vez porque los contenedores parecen ser una versión “ligera” de las máquinas virtuales. Sin embargo, son diferentes. De hecho, los contenedores y las máquinas virtuales buscan resolver dos problemas diferentes. Inicialmente, las máquinas virtuales estaban destinadas a resolver un problema con el uso del servicio. En su mayoría, resumen el hardware del sistema operativo y crean un entorno separado para sistemas operativos y aplicaciones. En consecuencia, es posible consolidar “muchas” máquinas virtuales en un único servidor físico.

A su vez, los contenedores tienen como objetivo abstraer aplicaciones del sistema operativo. Su objetivo es hacer que las aplicaciones sean más portátiles. Sin embargo, si los comparamos, los contenedores pueden ser más eficientes que las máquinas virtuales en uno o varios niveles: comienzan en fracciones de segundo en lugar de minutos; ocupan MB en lugar de GB en el disco; y la misma estación de trabajo puede ejecutar 10 o 100 veces más contenedores que las máquinas virtuales. Sin embargo, puede –y puede ser conveniente– desplegar contenedores en máquinas virtuales.

Es sorprendente las pocas desventajas que hay considerando que no tiene acceso directo al hardware como la mayoría de las máquinas virtuales (hipervisores) que pueden simular las instrucciones de E / S de la máquina directamente al hardware que lo admite.

En su lugar, utiliza características de contención del kernel de Linux incorporadas como CGroups, Namespaces, UFS y chroot.

– El motor Docker utiliza características de kernel específicas de Linux .
Sin embargo, exigir a los usuarios / sistemas que no son de Linux ( OSX ) que usen entornos virtuales simplificados con utilidades como boot2docker.

– El registro es [actualmente] un aspecto desordenado de Docker, pero no veo que dure mucho más.

– La seguridad es un tema delicado, ya que no debería ser un factor, sin embargo, es probable que los contenedores sean menos seguros de forma predeterminada. Sin mencionar la función `docker pull`, que abre una superficie de ataque propia.

– Las llamadas del sistema entre el host y los contenedores ‘invitados’ no son tan mágicas como cabría esperar. Todavía hay muchos servicios que resultan difíciles o imposibles de implementar en contenedores (systemd, por ejemplo).

– El hecho de que Docker use espacios de nombres de usuario para administrar estas funciones de bajo nivel pero no las soporta [todavía] por completo causa dolor de cabeza al tratar de contener varios servicios.

A medida que la adopción y la recepción de Docker aumenten y la plataforma madure, tendremos una plataforma virtual robusta que debería usarse junto con las máquinas virtuales en lugar de reemplazarlas. Docker es más que una plataforma virtual, pero menos que una solución virtualizada de hardware.

A medida que la plataforma madura y continúa siendo implementada y adoptada por organizaciones masivas (incluida VMware), podemos esperar ver a Docker convertirse en parte de entornos virtuales, en lugar de en lugar de.

VirtualBox es un software que crea una pieza virtualizada de hardware. Normalmente, un sistema operativo se ejecuta en hardware, donde la comunicación entre el hardware y el sistema operativo se realiza moviendo datos a direcciones en la memoria y luego emitiendo instrucciones que informan al hardware que los datos pueden usarse (o que necesitan ser leídos). VirtualBox (y otras máquinas virtuales) configuran un entorno donde esas ubicaciones de memoria son en realidad solo regiones de memoria en el software, y las instrucciones son interpretadas por el software en lugar de ir directamente a la CPU subyacente. El resultado práctico es que ejecuta un sistema operativo en VirtualBox y, para el sistema operativo, la aplicación VirtualBox parece una computadora, hardware y todo. No sabe que en realidad se está ejecutando dentro de otro programa.

Docker, por otro lado, no virtualiza el hardware en absoluto. En cambio, lo que hace es crear un sistema de archivos que se parece a un sistema de archivos Linux normal, y ejecuta aplicaciones en un entorno bloqueado donde todos los archivos y recursos están dentro de ese sistema de archivos. Efectivamente, el contenedor de la aplicación no emula ningún hardware, la aplicación aún se ejecuta en el hardware, solo aísla la aplicación en ejecución y le permite ejecutar aplicaciones con software y bibliotecas que podrían ser específicas para esa aplicación y no el sistema operativo host en todos. Esto significa que casi no hay sobrecarga al iniciar o detener una aplicación acoplable, no requieren asignaciones previas de memoria y espacio en disco, etc. Por lo tanto, son muy fáciles de configurar y desmontar. Además, los contenedores Docker no desperdician ninguna sobrecarga en la ejecución de software que pretende ser varios componentes de hardware en el sistema: utiliza el hardware directamente.

VirtualBox virtualiza el hardware, Docker virtualiza el sistema operativo.

Depende de lo que esté ejecutando: cómo está escrita su aplicación, qué supone, y en qué se ejecuta.

Leí mitos comunes sobre los contenedores cada vez más a menudo, así que echemos un vistazo a los 3 principales

Algunos proponentes dicen que los contenedores son más eficientes en memoria porque cada uno no tiene que contener una copia completa del sistema operativo a diferencia de una VM. Sin embargo, esto supone que el hipervisor no es lo suficientemente inteligente como para compartir páginas de memoria de solo lectura idénticas entre máquinas virtuales; esto no es cierto para VMware ESX, por ejemplo. ¿Ejecuta Windows, BSD, Mac OS, Solaris como uno de sus sistemas operativos? No tienes suerte con los contenedores de Linux. Entonces, si desea aprovechar, es mejor elegir una sola imagen de Linux como base para todo.

Es cierto que es más rápido iniciar un contenedor simplemente porque hay menos que hacer frente a hacer que un arranque completo de un sistema operativo desde cero. Esta es una de las razones por las que a Google le gustan los contenedores: su modelo operativo y de desarrollo consiste en generar instancias constantemente (razón por la cual ejecutan 2 mil millones por semana). La mayoría de nosotros no escribimos / operamos software como ese hoy, por lo que la pregunta es si esto ayuda a su aplicación. ¿Escribes código como Google? ¿Está ejecutando grandes trabajos de reducción de mapas que necesitan iniciar rápidamente muchas instancias que son iguales o muy similares?

Tenga en cuenta que un hipervisor podría clonar una máquina virtual en ejecución en una nueva máquina virtual y lograr la misma ventaja de velocidad. Para que la velocidad se pueda replicar mediante virtualización regular.

En tercer lugar, la superficie de ataque de los contenedores es mucho más alta que un hipervisor tipo 1 porque se ejecutan sobre un sistema operativo completo. Simplemente hay mucho menos código y menos oportunidades de escalada de privilegios con algo como VMware ESX. Los contenedores son muy parecidos a los hipervisores tipo 2 (por ejemplo, Microsoft Hyper-V) cuando se trata de seguridad, ya que los atacantes simplemente tienen más oportunidades de encontrar vulnerabilidades.

Esto no quiere decir que los contenedores son “malos”. Una de las principales ventajas es la gestión de la configuración de algo como Docker. Es realmente difícil capturar todas las dependencias de una aplicación que se ejecuta en Linux, pero Docker resuelve ese problema increíblemente bien. Eso simplifica la implementación de aplicaciones, con menos pasos de configuración. Probablemente pueda empaquetar más contenedores que ejecuten el mismo kernel en un solo servidor frente a máquinas virtuales independientes, siempre y cuando esté utilizando una sola imagen base de Linux. Hoy en día, puede iniciar contenedores mucho más rápido que las máquinas virtuales (aunque es poco probable que sea una ventaja a largo plazo).

Los contenedores y las máquinas virtuales tienen diferentes áreas de aplicación. Los contenedores son buenos cuando habla de ejecutar el mismo sistema operativo en el huésped y el host. Los contenedores (= virtualización a nivel del sistema operativo) obviamente consumen menos recursos. Las máquinas virtuales son más universales pero tienen una sobrecarga mayor.

Si hablamos de problemas de seguridad, las máquinas virtuales son más seguras desde mi punto de vista. Esto no es causado por la madurez de la tecnología. Hoy en día, la virtualización de hardware se vuelve cada vez más poderosa, por lo que los vendedores de máquinas virtuales deben realizar cada vez menos trabajo de virtualización. Por lo tanto, cada vez menos errores de código (incluso si existen) podrían ser afectados. Por otro lado, la virtualización a nivel del sistema operativo (contenedores) se basa en elementos internos del sistema operativo. El sistema operativo puede contener errores, el código del sistema operativo se vuelve aún más complicado cada año. Además, el código de VM es universal para todos los tipos de invitados, mientras que los contenedores podrían tener diferencias significativas incluso en versiones menores del sistema operativo invitado.

Entonces, la posibilidad de vulnerabilidad en el código de contenedores es mayor que la posibilidad de vulnerabilidad en el código de VM.

Virtualización vs Containerización

Maquinas virtuales

• Están formados por la emulación o virtualización de los recursos de hardware subyacentes. Utilizado principalmente en máquinas virtuales.
• Las máquinas virtuales actúan como las propias PC con la capacidad de encenderse, arrancarse, reiniciarse e incluso conectar dispositivos periféricos a ellas; la ventaja es que puede cargar diferentes sistemas operativos en ellas.
• Debido a la virtualización del hardware, si algo afecta a la VM, el hardware no se ve afectado.
• Puede usar múltiples sistemas operativos en los múltiples núcleos y hardware.
• El inconveniente es que la virtualización de hardware y las máquinas virtuales son extremadamente pesadas en recursos. Las máquinas virtuales terminan ocupando mucho espacio en la RAM y ciclos de CPU, lo que finalmente incurre en una sobrecarga de rendimiento significativa.

Contenedorización

• Está formado por la virtualización del sistema operativo en lugar del hardware, es decir, utilizan sistemas operativos compartidos.
• Los contenedores proporcionan entornos virtuales livianos que agrupan ciertos procesos y recursos (CPU, memoria, disco) en un entorno de contenedor,
• Al usar el mismo núcleo del sistema host, las aplicaciones de contenedor son extremadamente rápidas con poca o ninguna sobrecarga de rendimiento en comparación con las VM.
• Los contenedores Docker (recursos de código abierto para desarrollar contenedores de aplicaciones) se basan en el formato de capas. Se crea una sola capa de imagen base sobre un proceso. Se crean capas adicionales sobre los procesos adicionales de la imagen base
• Esto hace que la contenedorización sea extremadamente eficiente en recursos, ligera y fácil de transportar.
• Sin embargo, a diferencia de las máquinas virtuales, no puede utilizar múltiples sistemas operativos y núcleos para cada contenedor.

Recursos : 5 minutos de lectura para máquinas virtuales, Docker, Contenedores de aplicaciones y contenedores de SO

Los contenedores Docker le dan a cada aplicación que se ejecuta en un servidor su propio entorno aislado para ejecutar, pero todos comparten el sistema operativo del servidor host. Recuerde esto para distinguir entre virtualización y contenedores: en la contenedorización, no se lanzan múltiples imágenes virtuales del sistema operativo con hardware dedicado para cada aplicación.

Docker (plataforma de código abierto para desarrolladores)

• Utiliza motor acoplable
• Más rápido en comparación con las máquinas virtuales
• menos aislamiento (solo inconveniente sobre VM)
• actuar como un proceso
• Se pueden ejecutar múltiples contenedores simultáneamente actuando como un proceso en os
• comparte un solo núcleo y bibliotecas de aplicaciones
• Las aplicaciones que se ejecutan en contenedores tienen el mismo o mejor rendimiento que VM
• su mecanismo es aislar todas las dependencias (bibliotecas) por aplicación empaquetándolas en contenedores.
• No es necesario especificar recursos dedicados durante la ejecución, ya que comparte todo el núcleo.
• DevOps es la principal ventaja de Docker
• Tómese unos segundos para iniciar un sistema operativo
• Se usa cuando es necesario usar una o más aplicaciones
• el contenedor que se ejecuta en una plataforma puede no funcionar igual en otro, ya que la plataforma proporciona capacidades para ejecutar el contenedor
• Max. de 400 contenedores que puede ejecutar en un sistema RAM de 4 Gb simultáneamente.

Maquinas virtuales

• Utiliza hipervisor
• Más lento que Docker
• más aislamiento
• Cargue el sistema operativo completo con su propia administración de memoria
• múltiples sistemas operativos se ejecutan simultáneamente o en paralelo
• Todos los sistemas operativos tienen su propio entorno de hardware virtual.
• Es necesario especificar recursos dedicados como ram, CPU.
• Toma tiempo lanzar un SO
• Se usa cuando es necesario usar todo el sistema operativo
• Max. de 4 VM que puede ejecutar en un sistema RAM de 4 Gb simultáneamente.

– La principal diferencia entre un contenedor y un hipervisor radica en la técnica de hacer posible la multitenencia
– Los hipervisores y sus inquilinos de VM llevan, para cada inquilino, muchas más cosas que los contenedores. Los hipervisores y sus inquilinos de VM transportan casi todo, desde el núcleo del sistema operativo hasta los controladores de hardware, para que puedan usar no solo CPU, RAM, disco, red sino incluso dispositivos como una impresora o un monitor. Los contenedores están mucho más cerca del sistema operativo host en su dependencia de las características del sistema operativo host que permiten el uso compartido de múltiples inquilinos de los recursos disponibles para el sistema operativo host.
– Docker es un sistema de gestión de contenedores de tercer nivel.
– +1 a ese Docker es un sistema de administrador de LXC glorificado (sin embargo, esto está cambiando).
– En pocas palabras: el contenedor depende mucho más de las características de multipropiedad del sistema operativo host, en comparación con un hipervisor que es un software mucho más complejo que emula todo lo que tiene un sistema operativo host e incluso lo que otros sistemas operativos host pueden tener. En otras palabras, las máquinas virtuales emulan los recursos de hardware disponibles no para ellos, sino para alojar sistemas operativos que admite, mientras que los contenedores usan hardware real disponible para ellos mediante el aprovechamiento de las funciones de intercambio de recursos “nativos” del sistema operativo host.

Personalmente, creo que hay más amenazas masivas para VMware que Docker. Como VMware fue el innovador para la virtualización en sistemas abiertos, Docker parece ser lo mismo para el contenedor. Ambas tecnologías y métodos eran conocidos y utilizados en el mundo de mainframe décadas antes de que surgieran cosas en el mundo de los sistemas abiertos.

Y el contenedor tampoco fue el final de la virtualización en el mundo de mainframe.

Estoy totalmente de acuerdo con Kacey, en que ambas soluciones (perdón por reducir VMware a una tecnología por ahora) resuelven problemas diferentes. Pero ambos tienen diferentes limitaciones también.

Docker obviamente carece de la posibilidad de ejecutar sistemas operativos heterogéneos. Pero puede ejecutar Docker dentro de la virtualización de VMware y muchas empresas lo están haciendo.
Ese hecho solo responde a las discusiones a corto plazo sobre quién todavía tiene el liderazgo.

Primero, la mayoría de las aplicaciones en TI necesitarían ejecutarse en Linux, para que Docker sea el sistema principal que se utilizará sin necesidad de virtualización. O Docker necesitaría soportar Linux y Windows en el mismo Host, pero el contenedor ya no es suficiente, se necesita virtualización.

Eso significa que la TI no está lista hoy y es poco probable que mañana migre y ejecute todas las aplicaciones en el mismo sistema operativo. Por lo tanto, el uso de Docker se limita automáticamente a las aplicaciones de Linux. Por supuesto, cada vez se ejecutan más aplicaciones en Linux, pero especialmente la TI empresarial tiene más aplicaciones de Windows que de Linux.

Si usted es una tienda de Linux Only y no necesita ninguno de los beneficios de virtualización, Container podría ser la mejor opción.

En mi humilde opinión, ambas tecnologías pueden trabajar juntas para lograr los mejores resultados, no habrá una sustitución real.

En realidad, la contenedorización es más como colocar algunos programas en un “sandbox” dentro del sistema operativo actual. Es decir, simplemente ejecutarlos normalmente (como si fueran solo un programa normal instalado en el sistema operativo) están “contenidos” en una caja de arena que solo les muestra las partes necesarias, lo que hace que sea menos posible que cualquiera de estos cause estragos. algo más. También significa que cada uno puede tener su propia configuración / dependencias adicionales o en conflicto (piense en Python 2 vs 3) / etc. sin afectar los programas en otros contenedores o aquellos en el sistema operativo principal.

La virtualización (cuando se refiere a cosas como VMWare / VirtualBox / etc.) es un método para dividir hardware entre múltiples sistemas operativos. Digamos que tiene más RAM de la que pueda necesitar, su CPU está inactiva la mayor parte del tiempo, etc. Luego se da cuenta de que necesita otro servidor para ejecutar (por ejemplo, tiene un servidor web, una base de datos, un servidor de archivos, dominio, correo electrónico, etc., etc., etc.). Puede instalar todos esos programas en un solo sistema operativo, pero eso lo obliga a los siguientes (no tan buenos) escenarios:

1. Todos esos programas de servidor deben ejecutarse en el mismo sistema operativo. Por ejemplo, ¿qué pasaría si quisieras un servidor SQL, pero para compartir archivos / carpetas querías ZFS? Si va con un servidor de Windows para SQL, entonces está atascado con NTFS / ReFS como sus únicas opciones de sistema de archivos. Si utiliza Solaris / BSD / Linux, obtendrá ZFS (bueno, Solaris / BSD, el controlador ZFS de Linux no es tan bueno), pero no hay forma de ejecutar SQLServer. Lo mismo ocurre con los programas normales, por ejemplo, digamos que necesita ejecutar uno que solo está disponible en Windows y otro que solo es para OSX.
2. Si uno de estos servidores / programas se encuentra con problemas como fallas o (peor) un bucle infinito que consume toda la RAM, es muy posible que todos los demás servidores / programas también se bloqueen a medida que se derrumba todo el sistema operativo.
3. Cuando una actualización requiere un reinicio, todos los servidores / programas se detendrán debido al reinicio completo del sistema operativo, no solo el programa que se actualizó.
4. Algunos de estos programas / servidores pueden requerir dependencias diferentes y / o conflictivas, podría ser muy difícil o imposible de instalar en un solo sistema operativo.

Ahora, en lugar de comprar una computadora completamente nueva para dividir estos programas, puede usar esos recursos de hardware inactivos ejecutándolos en un entorno virtual. Es decir, como si una computadora se convirtiera en dos, o en tres o en 1000. Cada una de esas computadoras virtuales tiene su propio sistema operativo instalado, junto con cualquier programa que tenga instalado. Efectivamente, como si ahora tuvieras varias computadoras separadas.

La contenedorización efectiva permite beneficios similares según los puntos 2, 3 y 4 anteriores, pero no puede solucionar el punto 1. Podría consumir menos memoria, aunque hay algunos hipervisores de virtualización que comparten cosas como RAM de forma dinámica entre los sistemas operativos en ejecución, e incluso podrían compartir código de solo lectura en ejecución entre dos o más. Además, algunas cosas dentro de una ventana acoplable pueden necesitar cargarse varias veces y no estar realmente diseñadas para uso multiproceso, por lo que no siempre es más eficiente.

Por lo general, si solo necesita un tipo de sistema operativo y tiene muchos programas pequeños (ish) que se inician y detienen constantemente, pero tiene algunos problemas simplemente con ejecutarlos en un entorno normal normal (por ejemplo, desea evitar que uno de ellos se bloquee todo el sistema, o algunos de ellos pueden requerir algunas configuraciones / bibliotecas especiales), entonces la contenedorización es una mejor apuesta que la virtualización. Si necesita 2 o más tipos de SO, necesita más hardware o un entorno virtual, no tiene otra opción. Además, si se trata de procesos de larga duración, puede ser más eficiente mantenerlos en entornos virtuales, especialmente debido a las actualizaciones que podrían provocar un reinicio o bloqueos, al menos, dichos reinicios / bloqueos pueden ser específicos solo para uno y no derribar todo.

Piense en la “contenedorización” como virtualización del sistema operativo, mientras que las “máquinas virtuales” son virtualización de hardware. Entonces, el primero, simplemente aísla su aplicación como si fuera la única que se ejecuta en un sistema operativo específico (el sistema operativo no cambia y no puede cambiar); mientras que una máquina virtual implementa un servidor de hardware donde puede ejecutar diferentes sistemas operativos simultáneamente. Otra diferencia clave es que la contenedorización tiene tiempos de inicio mucho más rápidos que la virtualización. La contenedorización lleva segundos, mientras que la virtualización suele tardar minutos en iniciarse.

¡Los mejores deseos!

Simple. La principal diferencia es –

En Virtualization, puede configurar cualquier cantidad de máquinas virtuales con un sistema operativo diferente en cada VM (no es necesario que sea el mismo que el sistema operativo host), mientras que en Docker, crea VM que tienen el mismo sistema operativo que el sistema operativo host. Y lo que es más importante, Docker utiliza un sistema operativo Linux.

Yo diría que Docker es ventajoso porque al tener el mismo sistema operativo que el sistema operativo host, está reduciendo la sobrecarga en gran medida. Aparte de eso, será más fácil de instalar, construir e implementar. La utilización de recursos es mucho mejor. Pero en lo que respecta a la seguridad, puede ver la vulnerabilidad al usar comandos como Docker Pull que facilita los ataques.

Lo enmarcaría así para el lego. Una máquina virtual o instancia es un servidor virtualizado. Tiene CPU dedicada, memoria, disco, red y un sistema operativo completo. Dos máquinas virtuales en un solo host físico no pueden compartir recursos entre ellas si así lo desean.

Docker, Rocket, Solaris Zones, etc. pueden considerarse virtualización del sistema operativo. Cada uno comparte la CPU subyacente, la memoria y un solo núcleo entre todos los contenedores en el host físico. Tenga en cuenta que esta es una explicación muy simplificada, ya que hay excepciones con respecto a la asignación de recursos físicos.

En general, tanto VM (VMWARE, VirtualBox, etc.) como Contenedor (docker, lxc, etc.) tienen como objetivo mejorar la utilización del servidor / reducir la expansión física del servidor y reducir el costo total de propiedad del departamento de TI. Sin embargo, hay algunas diferencias entre los dos.

VM

1. Necesita un hipervisor instalado sobre el hardware del servidor desnudo (para hipervisor común como se menciona a continuación)
2. Cada VM recibirá su propio sistema operativo único, sus propios binarios / bibliotecas dedicadas y carga de trabajo de aplicaciones.
3. Cada máquina virtual está completamente aislada de otras máquinas virtuales, es decir, ninguna máquina virtual conoce / depende de otras máquinas virtuales.
4. Los hipervisores comunes incluyen: VMware vSphere, Microsoft Hyper-V, RedHat KVM Hypervisor, etc.
5. Ventajas:

• La falla del sistema operativo (SO) de una VM no afectará a otras VM (a diferencia del contenedor por el cual el SO compartido subyacente es un punto único de falla para que todos los contenedores también fallen).
• La VM se puede migrar a otros servidores con un sistema operativo diferente / más nuevo (mientras que el contenedor solo puede migrar a otros servidores con el mismo núcleo de sistema operativo compatible, es decir, opciones de migración limitadas.
• Los hipervisores comunes como VMware, Hyper-V y RedHat KVM admiten diferentes sistemas operativos invitados VM como Microsoft Windows Server, Linux, etc.

Envase

1. es un entorno de ejecución para ejecutar aplicaciones que comparten el mismo sistema operativo (SO) subyacente del host.
2. Todos los contenedores deben tener el mismo núcleo subyacente del sistema operativo.
3. Ejemplos de contenedores incluyen: Docker Containers, Linux Containers (LXC), Microsoft Windows Containers, etc.
4. Ventajas:

• Ligero: uso eficiente de los recursos porque cada contenedor no necesita su sistema operativo respectivo, es decir, menos sobrecarga.
• Un servidor físico puede alojar más contenedores frente a máquinas virtuales.
• Mayor velocidad de creación, provisión y migración (vs VM).
• Rendimiento de tiempo de ejecución casi desnudo (frente a VM).
• TCO aún más bajo (para aquellos OpenSource gratuitos).

Hola,

¡El contenedor Docker no es una máquina virtual en miniatura! Una máquina virtual tiene su propio espacio de kernel, mientras que un contenedor compartirá su espacio de kernel con la máquina host.

Docker es específico de la aplicación, mientras que VM no lo es. Muchas herramientas, usan contenedores como servidores más pequeños; que no es más que la pequeña versión de VM de la VM principal. Docker hace las cosas de manera diferente; un contenedor es como un proceso; y no una VM. Docker utiliza internamente espacios de nombres, sistemas de archivos de unión y funciones de grupo de control para proteger un proceso de otros procesos. Entonces, lógicamente, Docker proporciona una forma de admitir dos o más versiones de un software que tiene dependencias conflictivas o incluso dos o más productos de software conflictivos diferentes.

He tratado de explicar esto en detalle en mi blog. Visite DOCKER: ¿Por qué, qué y cómo? – Jaydeep Trivedi para más detalles.

Una máquina virtual ejecuta un sistema operativo completo dentro del entorno virtual, encima del sistema operativo host. Eso significa que ejecuta dos sistemas operativos completos. Esto se llama hipervisor .

Docker es un contenedor que virtualiza los servicios del sistema operativo host, como el sistema de archivos o la lista de procesos. Por ejemplo, si enumera los archivos de / tmp en dos contenedores separados, no verá los archivos del otro. De manera similar, si verifica el estado de su proceso usando ‘ps’ en cada contenedor, entonces no verán los procesos de los demás, aunque haya un sistema operativo.

Docker es realmente un contenedor glorificado sobre LXC, el Contenedor de Linux. El contenedor estándar antes de LXC era OpenVZ.

Editar:

A medida que trabajé más con Docker, aprendí que LXC ya no es el entorno de ejecución predeterminado, tal vez incluso cuando escribí esto 🙂