Contenedores de Linux (LXC) en Red Hat / CentOS EL6 - lxc-create versus libvirt?

Es complicado tratar de mantenerse dentro de las buenas gracias de Red Hat y aún planificar la longevidad del sistema ...

He sido un defensor de los contenedores de Linux (LXC) durante más de un año. Mis instalaciones iniciales se basaron en información obtenida de tutoriales en línea, como este y este . Esto se centró en lxc-create, lxc-start|stopy los lxc-destroycomandos y la modificación de las plantillas OpenVZ existentes .

Esto funciona bien y funciona felizmente en producción. Sin embargo, estoy presentando algunos sistemas adicionales y decidí verificar la documentación actual de Red Hat con respecto a los contenedores en EL6. Me sorprendió ver su postura oficial sobre esto.

En ¿RHEL 6 proporciona las herramientas LXC necesarias para usar contenedores de Linux? , Red Hat describe LXC como una Vista previa de tecnología y sugiere usar libvirt para administrar crear y administrar contenedores .

Sin embargo, Oracle aboga por una técnica de contenedorización totalmente diferente en su Unbreakable Linux.

Parece que faltan algunas funciones en el método libvirt, pero mi enfoque inicial con los comandos lxc- * fue un poco un proceso manual ... No puedo decir qué es lo correcto o el medio "aceptado" de administrar contenedores en EL6 .

• ¿Cuál es la sabiduría convencional con respecto a los sistemas similares a LXC y RHEL en la actualidad?
• ¿Cómo se les implementando en su organización?
• ¿Hay alguna ventaja en un enfoque frente a los otros?
• ¿Pueden estos coexistir?

¿Cuál es la sabiduría convencional con respecto a los sistemas similares a LXC y RHEL en la actualidad?

Personalmente, la configuración actual me parece un tanto deficiente. LXC parece más a la vanguardia, ciertamente más mantenido.

¿Cómo los estás implementando?

En términos de ofrecerlo como una opción de virtualización, no lo soy. Encuentro que falta la configuración tecnológica actual.

• Sin espacio de nombre de usuario.
• Ciertos puntos de montaje no son conscientes del espacio de nombres (cgroups, selinux)
• Los valores en / proc son globales del sistema engañosos que no tienen en cuenta la división de recursos en espacios de nombres.
• Rompe auditoria.

Sin embargo, me parece una herramienta realmente buena para la contención de nivel de aplicación. Utilizamos espacios de nombres y cgroups directamente para contener recursos de red e IPC para ciertas aplicaciones web administradas por usuarios. Proporcionamos nuestra propia interfaz para controlarlo. En RHEL7 estoy considerando trasladar esta funcionalidad a libvirt-lxclas nuevas revisiones de libvirtsoporte del concepto de ACL de usuario.

Para la virtualización en términos de un sistema completamente inicializado, estoy esperando para ver lo que se ofrece en RHEL7, pero honestamente, siento que solo podríamos ver una solución lo suficientemente buena una vez que estemos en una versión menor posterior de RHEL7 y luego tal vez solo en un estado de vista previa de tecnología.

Esté atento a systemd-nspawnalgo que me dice en los próximos 18 meses, o sea que podría ocupar su lugar, es la mejor herramienta para hacer una virtualización completamente contenida en Linux, ya sea que los autores del sistema aclaren que no es seguro en este momento. No me sorprendería si eventualmente libvirtcae libvirt-lxcy solo ofrece un envoltorio alrededorsystemd-nspawn con rebanadas systemd definidas.

Además, tenga cuidado de que se haya hablado mucho en los últimos 6 meses con respecto a la re-implementación de cgroups como una interfaz de programador de kernel en lugar de una interfaz de sistema de archivos (tal vez usando netlink o algo así, no lo he comprobado) por lo que systemd debería estar muy caliente en la cola de hacerlo bien muy rápido.

¿Hay alguna ventaja en un enfoque versus el otro?

Creo que la opción LXC (no libvirt-lxc) se mantiene mejor. Después de leer el libvirt-lxccódigo fuente, se siente apresurado. El LXC tradicional ciertamente tiene nuevas características que han sido mejor probadas. Ambos requieren un cierto grado de compatibilidad por parte del sistema init que se ejecuta en ellos, pero sospecho que encontrarás LXC un poco más "llave en mano" que la libvirt-lxcopción, particularmente en lo que respecta a conseguir que las distribuciones funcionen en ellos.

¿Pueden estos coexistir?

Claro, recuerde que para todos los efectos, ambos están haciendo lo mismo. Organización de espacios de nombres, cgroups y puntos de montaje. Todas las primitivas son tratadas por el núcleo mismo. Ambas lxcimplementaciones solo ofrecen un mecanismo para interactuar con las opciones de kernel disponibles.

Red Hat está haciendo un gran esfuerzo de contenedorización. Están construyendo un producto completamente nuevo, Red Hat Enterprise Linux Atomic Host , a su alrededor.

Para un enfoque menos radical, eche un vistazo a su RHEL7 beta Resource Management and Linux Containers Guide ; notarás que empuja libvirt-lxc y no menciona las herramientas lxc.

Los ejecutables lxc- * están empaquetados en el paquete lxc en EPEL . Sin embargo, es la antigua versión de "soporte a largo plazo". Ni siquiera tiene la opción "-f" en lxc-ls. Simplemente instalaría Ubuntu para mis hosts LXC.

La forma RHEL de administrar LXC parece ser a través de libvirt-lxc, pero aparentemente está en desuso .

Notó que Ubuntu es compatible con muchos de los nuevos desarrollos lxc / lxd, mientras que Redhat se enfoca en KVM y docker.