¿Qué agrega Docker a lxc-tools (las herramientas LXC del espacio de usuario)?

398

Si echa un vistazo a las características de Docker, LXC ya proporciona la mayoría de ellas.

Entonces, ¿qué agrega Docker? ¿Por qué usaría Docker sobre LXC simple?

docker lxc Flimm
fuente

Respuestas:

550

De las preguntas frecuentes de Docker :

Docker no es un reemplazo para lxc. "lxc" se refiere a las capacidades del kernel de Linux (específicamente espacios de nombres y grupos de control) que permiten procesos de sandboxing entre sí y controlan sus asignaciones de recursos.

Además de esta base de bajo nivel de características del núcleo, Docker ofrece una herramienta de alto nivel con varias funcionalidades poderosas:

  • Implementación portátil en máquinas.Docker define un formato para agrupar una aplicación y todas sus dependencias en un solo objeto que se puede transferir a cualquier máquina con Docker y ejecutar allí con la garantía de que el entorno de ejecución expuesto a la aplicación será el mismo. Lxc implementa sandboxing de proceso, que es un requisito previo importante para la implementación portátil, pero eso por sí solo no es suficiente para la implementación portátil. Si me envió una copia de su aplicación instalada en una configuración lxc personalizada, es casi seguro que no se ejecutará en mi máquina como lo hace en la suya, porque está vinculada a la configuración específica de su máquina: redes, almacenamiento, registro, distribución, etc. Docker define una abstracción para estas configuraciones específicas de la máquina, para que el mismo contenedor de Docker pueda ejecutarse, sin cambios, en muchas máquinas diferentes,

  • Centrado en la aplicación. Docker está optimizado para el despliegue de aplicaciones , a diferencia de las máquinas. Esto se refleja en su API, interfaz de usuario, filosofía de diseño y documentación. Por el contrario, las secuencias de comandos auxiliares lxc se centran en los contenedores como máquinas livianas, básicamente servidores que se inician más rápido y necesitan menos ram. Creemos que hay más en los contenedores que solo eso.

  • Construcción automática . Docker incluye una herramienta para que los desarrolladores ensamblen automáticamente un contenedor a partir de su código fuente, con control total sobre las dependencias de la aplicación, herramientas de compilación, empaquetado, etc. Son libres de usar make, maven, chef, puppet, salt, debian paquetes, rpms, source tarballs, o cualquier combinación de lo anterior, independientemente de la configuración de las máquinas .

  • Versionado Acoplable incluye git-como capacidades para el seguimiento de las versiones sucesivas de un contenedor, inspeccionando el diff entre las versiones, la comisión de nuevas versiones, retroceder, etc. La historia también incluye cómo se monta un recipiente y por quién, para que pueda obtener una trazabilidad completa desde el servidor de producción todo el camino de regreso al desarrollador upstream. Docker también implementa cargas y descargas incrementales, similares a "git pull", por lo que las nuevas versiones de un contenedor se pueden transferir solo enviando diferencias.

  • Reutilización de componentes. Cualquier contenedor se puede utilizar como una "imagen base" para crear componentes más especializados. Esto se puede hacer manualmente o como parte de una compilación automatizada. Por ejemplo, puede preparar el entorno ideal de Python y usarlo como base para 10 aplicaciones diferentes. Su configuración ideal de postgresql se puede reutilizar para todos sus proyectos futuros. Y así.

  • Compartir Docker tiene acceso a un registro público ( https://registry.hub.docker.com/ ) donde miles de personas han subido contenedores útiles: cualquier cosa, desde redis, couchdb, postgres, gorritos irc, rails, servidores de aplicaciones, hadoop o imágenes base para Varias distribuciones. El registro también incluye una "biblioteca estándar" oficial de contenedores útiles mantenidos por el equipo acoplable. El registro en sí es de código abierto, por lo que cualquiera puede implementar su propio registro para almacenar y transferir contenedores privados, por ejemplo, para implementaciones de servidores internos.

  • Ecosistema de herramientas. Docker define una API para automatizar y personalizar la creación e implementación de contenedores. Hay una gran cantidad de herramientas que se integran con Docker para ampliar sus capacidades. Despliegue tipo PaaS (Dokku, Deis, Flynn), orquestación de múltiples nodos (maestro, salt, mesos, openstack nova), paneles de administración (docker-ui, openstack horizon, astillero), gestión de configuración (chef, marioneta), integración continua (jenkins, strider, travis), etc. Docker se está estableciendo rápidamente como el estándar para herramientas basadas en contenedores.

¡Espero que esto ayude!

Solomon Hykes
fuente
3
Cuando dice "cualquier contenedor se puede usar como imagen base", supongo que se refiere a un contenedor Docker, no a un contenedor LXC creado independientemente de Docker. Por lo que puedo decir, uno no puede crear un contenedor Docker desde cero, siempre debe heredar de otro contenedor Docker (pregunta relacionada: stackoverflow.com/questions/18274088/… ).
Flimm
18
Puede crear fácilmente un nuevo contenedor desde cualquier tarball con "docker import". Por ejemplo: "debootstrap raring ./rootfs; tar -C ./rootfs -c. | Docker import flimm / mybase".
Solomon Hykes
3
¿Es esto cierto ahora que Docker tiene libcontainer (que no es un reemplazo)?
Garet Claborn
3
@GaretClaborn sí, dado que libcontainer es solo su propia biblioteca para acceder a espacios de nombres y grupos c, todo lo que Solomon dijo todavía se aplica.
John Morales
10
Un contenedor de Linux es el resultado de restringir y aislar un proceso usando un conjunto de instalaciones de Linux: chroot, cgroups y namespaces. LXC es una herramienta de espacio de usuario que manipula esas instalaciones. libcontainer es una alternativa a LXC que manipula esas mismas instalaciones. Docker usa libcontainer de forma predeterminada, pero puede usar LXC en su lugar. Dicho esto, Docker es (mucho) más que una capa de compatibilidad en la parte superior de libcontainer / LXC; agrega características adicionales que las otras respuestas han enumerado.
user100464
71

Echemos un vistazo a la lista de características técnicas de Docker y verifiquemos cuáles son proporcionadas por LXC y cuáles no.

caracteristicas:

1) Aislamiento del sistema de archivos : cada contenedor de procesos se ejecuta en un sistema de archivos raíz completamente separado.

Provisto de LXC simple.

2) Aislamiento de recursos : los recursos del sistema como CPU y memoria se pueden asignar de manera diferente a cada contenedor de proceso, utilizando cgroups.

Provisto de LXC simple.

3) Aislamiento de la red : cada contenedor de procesos se ejecuta en su propio espacio de nombres de red, con una interfaz virtual y una dirección IP propia.

Provisto de LXC simple.

4) Copia en escritura : los sistemas de archivos raíz se crean usando copia en escritura, lo que hace que el despliegue sea extremadamente rápido, barato en memoria y en disco.

Esto lo proporciona AUFS, un sistema de archivos de unión del que Docker depende. Puede configurar AUFS usted mismo manualmente con LXC, pero Docker lo usa como estándar.

5) Registro : las secuencias estándar (stdout / stderr / stdin) de cada contenedor de proceso se recopilan y registran para la recuperación en lote o en tiempo real.

Docker proporciona esto.

6) Gestión de cambios: los cambios en el sistema de archivos de un contenedor pueden confirmarse en una nueva imagen y reutilizarse para crear más contenedores. No se requieren plantillas ni configuraciones manuales.

La "configuración de plantillas o manual" es una referencia a LXC, donde necesitaría aprender sobre estas dos cosas. Docker le permite tratar contenedores de la forma en que está acostumbrado a tratar máquinas virtuales, sin conocer la configuración de LXC.

7) Shell interactivo : Docker puede asignar un pseudo-tty y adjuntarlo a la entrada estándar de cualquier contenedor, por ejemplo, para ejecutar un shell interactivo desechable.

LXC ya proporciona esto.

Recién comencé a aprender sobre LXC y Docker, por lo que agradecería cualquier corrección o mejor respuesta.

Flimm
fuente
35
En mi humilde opinión, esta respuesta pierde el punto. Docker no "proporciona" esas características; simplemente los hace trivialmente fáciles de usar. Si queremos ser quisquillosos, podemos decir que LXC no proporciona aislamiento: los espacios de nombres lo proporcionan, y LXC es solo una herramienta básica de usuario para que sea más fácil de usar que con la unshareherramienta básica (o directamente la clone()llamada al sistema). Del mismo modo, Docker hace que esas cosas sean más fáciles de usar (y trae muchas más funciones sobre la mesa, como la capacidad de empujar / tirar imágenes). Mi 2c.
jpetazzo
66
@jpetazzo: LXC es realmente bastante fácil, ¿cómo lo hace Docker más fácil (además de agregar otras características como empujar y tirar de imágenes)?
Flimm
31
@Flimm: Me gusta la comparación en el número 16 de la revista Admin , p. 34: Docker agrupa LXC junto con algunas otras tecnologías de soporte y lo envuelve en una interfaz de línea de comandos fácil de usar. El uso de contenedores es un poco como tratar de usar Git con comandos al igual que update-indexy read-tree, sin necesidad de herramientas familiares como add, commit, y merge. Docker proporciona esa capa de "porcelana" sobre la "tubería" de LXC, lo que le permite trabajar con conceptos de nivel superior y preocuparse menos por los detalles de bajo nivel.
0xC0000022L
44
Ejecuté puntos de referencia de UnixBench dentro de un contenedor docker y un contenedor LXC, ejecutando el mismo sistema operativo, y LXC ha sobresalido en puntaje. Siendo docker basado en LXC, estoy muy desconcertado sobre mis resultados.
Gextra
77
Me parece que el rendimiento más lento de Docker estaba relacionado con la E / S de disco, por lo tanto, tal vez debido a la adopción de AUFS.
Gextra
16

La publicación y las respuestas anteriores se están volviendo rápidamente obsoletas a medida que el desarrollo de LXD continúa mejorando LXC . Sí, sé que Docker tampoco se ha detenido.

LXD ahora implementa un repositorio para imágenes de contenedor LXC que un usuario puede empujar / extraer para contribuir o reutilizar.

La API REST de LXD para LXC ahora permite la creación / implementación / administración local y remota de contenedores LXC utilizando una sintaxis de comando muy simple.

Las características clave de LXD son:

  • Seguro por diseño (contenedores sin privilegios, restricciones de recursos y mucho más)
  • Escalable (desde contenedores en su computadora portátil hasta miles de nodos de cómputo)
  • Intuitivo (API simple y clara y experiencia de línea de comandos nítida)
  • Basado en imágenes (no más plantillas de distribución, solo imágenes buenas y confiables) Migración en vivo

Ahora hay un complemento NCLXD para OpenStack que permite a OpenStack utilizar LXD para implementar / administrar contenedores LXC como máquinas virtuales en OpenStack en lugar de usar KVM, vmware, etc.

Sin embargo, NCLXD también permite una nube híbrida de una combinación de máquinas virtuales HW tradicionales y máquinas virtuales LXC.

El plugin OpenStack nclxd incluye una lista de características compatibles que incluyen:

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

Para cuando se lance Ubuntu 16.04 en abril de 2016, habrá funciones interesantes adicionales, como soporte para dispositivos de bloque, soporte para migración en vivo .

bmullan
fuente
4

Los acopladores utilizan imágenes que se crean en capas. Esto agrega mucho en términos de portabilidad, uso compartido, versiones y otras características. Estas imágenes son muy fáciles de portar o transferir y, dado que están en capas, los cambios en las versiones posteriores se agregan en forma de capas sobre las capas anteriores. Por lo tanto, al portar muchas veces no es necesario portar las capas base. Los Dockers tienen contenedores que ejecutan estas imágenes con un entorno de ejecución contenido, agregan cambios como nuevas capas que proporcionan un control de versión fácil.

Aparte de eso, Docker Hub es un buen registro con miles de imágenes públicas, donde puede encontrar imágenes que tienen instalado el SO y otros softwares. Por lo tanto, puede obtener una buena ventaja para su aplicación.

div
fuente
Cuando dice "capas integradas", ¿qué significa? (A) Una copia de las capas base, adaptadas y comprometidas con una capa "NUEVA". Entonces, ¿la capa base está desconectada de la siguiente? (B) Las capas base están incluidas en la capa "NUEVA" y también están vinculadas. Por lo tanto, los cambios en la capa base se reflejan automáticamente en la capa "NUEVA". Lo siento, si la aclaración buscada es demasiado ingenua. :( Kapil
Kapil
Las imágenes de Docker se construyen en capas. Para poner en términos granulares, todos los cambios hasta un punto cuando se compromete una capa están presentes en las capas de imagen realizadas hasta ese punto. Cualquier cambio realizado después de eso se agrega a las capas siguientes y superiores. Entonces, la nueva capa está vinculada a la capa base. No creo que se pueda agregar la misma nueva capa a una capa base diferente con cambios adicionales. Sin embargo, si varias entidades desean mantener la coherencia y tener una misma capa base, entonces solo las nuevas capas deben darse a estas entidades para alcanzar el mismo estado.
div
Sin embargo, no estoy actualizado sobre los desarrollos actuales en Docker y puede haber cambios en la implementación de la imagen de Docker que no están cubiertos en el comentario anterior.
div
Para ser más específicos, las capas se identifican por una firma (SHA-algo, creo), lo que significa que si cambia una capa, es una capa diferente. @Kapil: Eso significa que si bien su comportamiento es algo más cercano a su opción (B), en realidad no puede realizar cambios en una capa base. (o cualquier capa, para el caso) Una imagen se construye a partir de una lista de capas, cada una aplicada en orden; las capas se pueden limpiar (y creo que el docker las limpia automáticamente) cuando ya no se necesitan; es decir, cuando todas las imágenes de referencia han sido eliminadas.
codermonkeyfuel
@Kapil: Honestamente, su pregunta probablemente funcionaría mejor como una nueva pregunta, en lugar de como un comentario sobre esta, ya que es útil para que las personas puedan buscarla por sí mismas. Si quieres hacer una nueva pregunta, también responderé allí.
codermonkeyfuel
0

Para mantener esta pithier, esto ya se ha preguntado y respondido anteriormente .

Sin embargo, daría un paso atrás y respondería de manera un poco diferente, el motor de Docker agrega la orquestación como uno de sus extras y esta es la parte disruptiva. Una vez que comienza a ejecutar una aplicación como una combinación de contenedores que se ejecutan 'en algún lugar' a través de múltiples motores de contenedores, se vuelve realmente emocionante. Robustez, escala horizontal, abstracción completa del hardware subyacente, podría seguir y seguir ...

No es solo Docker lo que te brinda esto, de hecho, el estándar de orquestación de contenedores de facto es Kubernetes, que viene en muchos sabores, uno Docker, pero también OpenShift, SuSe, Azure, AWS ...

Luego, debajo de K8S hay motores de contenedores alternativos; los más interesantes son Docker y CRIO, recientemente construido, sin demonios, pensado como un motor contenedor específicamente para Kubernetes pero inmaduro. Es la competencia entre estos lo que creo que será la elección real a largo plazo para un motor de contenedor.

Will Rothwell
fuente