Llegamos a ustedes gracias a:



Reportajes y análisis

Guerras de contenedores

Rocket vs. Odin vs. Docker

[14/08/2015] Los contenedores han tomado el mundo de las redes, ofreciendo una alternativa ligera y más flexible a la máquina virtual tradicional. La principal diferencia entre un contenedor y una máquina virtual es que un contenedor puede compartir archivos comunes, mientras que los procesos de las MV son discretos y atómicos, aunque el almacenamiento y las redes se virtualicen y compartan. Las máquinas virtuales se parecen más a las islas; los contenedores pueden estar aislados o ser comunes.

Un día, predecimos, la mayoría de los sistemas operativos que están sobre los hipervisores serán contenedores. De hecho, los fabricantes de sistemas operativos ya tropiezan entre sí para hacer versiones de sus productos ultra-livianas y amigables con los contenedores.

Por lo tanto ¿Los contenedores están listos para tomar el protagonismo en su red? ¿Cuáles son los pros y los contras? Para investigar estas preguntas, hemos probado tres métodos de contenedores, Docker, Rocket/rkt y OpenVZ/Odin (anteriormente Parallels.)

Docker está a la vanguardia en términos de impulso, pero también hay problemas potenciales que deben ser superados. Rocket/rkt aborda algunos de estos problemas, pero aún no está listo para la producción.

OpenVZ/Odin proporciona una metodología de contenedores y un "entorno virtual" que recuerda a las populares plataformas de hipervisor, pero con algunas limitaciones.

Los tres son potencialmente útiles y también potencialmente peligrosos en comparación con el hipervisor tradicional y combinaciones de MV. Sin embargo, con el cuidado aplicado y la consideración metódica, los tres tienen un gran potencial.

Probamos estos productos en el contexto de la infraestructura de los sistemas de la empresa, en lugar de DevOps y desarrollo continuo. La energía detrás de los contenedores, sin embargo, significa que es muy difícil liberar la infraestructura de los sistemas y sus planos de control frente a las necesidades/beneficios de despliegues rápidos, escala y las filosofías detrás de las prácticas de desarrollo continuo.

Cada uno de los productos analizados se encuentra en rápida transición, aunque OpenVZ/Virtuozzo juega un papel ligeramente diferente, hacia un producto de control plano para los proveedores de servicios.

Los problemas que resuelven los contenedores

La evolución de los contenedores es impulsada por una necesidad de orquestación del proceso para que sea más ligero que el despliegue de máquinas virtuales, pero con algunos de los mismos enfoques de sistemas para el clustering, la configuración rápida y el desmontaje. Todo esto se debe hacer con fiabilidad y seguridad, que es de donde viene la crítica más pesada de cada plataforma, y es uno de los subproductos de la evolución de los conceptos de cloud computing.

En el esquema de OpenVZ/Virtuozzo, el proceso de envase y la rápida puesta en marcha apuntan más hacia los proveedores de servicios, que están ofreciendo infraestructura orientada al dispositivo para los clientes. Los ejemplos incluyen almacenamiento enlatado del sitio web/correo electrónico, página web de merchandising, ofertas altamente localizadas en dispositivos y servicios asociados. En este escenario, la instrumentación y la facturación de varias instancias de los sistemas operativos son clave para un cliente potencial.

Odin, la renombrada ramificación de Parallels que patrocina OpenVZ y ofrece Virtuozzo, ha estado haciendo esto por mucho tiempo. Es más predecible, más cuajado, y también lo suficientemente flexible para ser utilizado como una metodología de alojamiento para Docker.

Docker suministra un entorno de sistema operativo ligero que está subyugado y disciplinado por los controles de la instrumentación aplicada. Esta instrumentación puede ser rudimentaria o involucrar sofisticados planos de control de la gestión.

Rocket/rkt es similar a Docker, pero de alguna manera más primitivo (y no está listo para la producción). Sin embargo, como Rocket parece que se ha generado como respuesta a la expansión y la inseguridad percibida en Docker, encontramos que rkt satisfizo algunos de nuestros instintos de ingeniería que no podíamos completar en el desarrollo de Docker.

Odín y la creación de OpenVZ como un entorno virtual, un modelo híbrido en el que se utiliza un kernel modificado para hacer ambos trabajos de un hipervisor tradicional, y alternativamente, el trabajo de un entorno de almacenamiento de contenedores. Por ejemplo, podría ejecutar Docker o Rocket en OpenVZ.

Encontramos que estos tres utilizan metodologías muy similares. De hecho la fertilización cruzada entre ellas, y una larga lista de otros colaboradores visibles, es enorme. Cada uno parece patrocinar el otro en diferentes formas, y son representativos de una solución emergente de gestión ligera sin la "pesadez" de los hipervisores tradicionales.

Por lo tanto ¿Los métodos de alojamiento de contenedores reemplazan a los tradicionales hipervisores tipo 1? Nuestra respuesta hoy: no del todo -son especies diferentes. Pero también observamos que las instancias ligeras del sistema operativo, como CoreOS, instancias muy livianas de Ubuntu Server, y hasta la próxima distribución Atomic de Red Hat, están diseñadas para servir como el marco dentro del método de alojamiento de contenedores. Y no nos sorprendería ver contenedores de Windows 10 en el horizonte, aunque los contenedores MacOS son una extensión de la imaginación.

Estas son las opiniones individuales:

OpenVZ/Odin Virtuozzo 6.0

OpenVZ es una distribución Linux que aloja instancias huésped de máquinas virtuales y/o contenedores. Los recursos de OpenVZ están en modernos kernels Linux 3.X+, y existe un kernel OpenVZ para descarga. Solo el kernel OpenVZ garantiza la compatibilidad de todas las funciones -a pesar de que se puede instalar una larga lista de servicios parciales de OpenVZ en Linux 3.X+.

Las instancias invitadas de OpenVZ pueden ser máquinas virtuales o contenedores. Cuando agrega la instrumentación, la facturación y un plano de gestión, se obtiene el producto comercial Odin Virtuozzo. Odin es un cambio de marca de este producto hecho por Parallels, una empresa suiza.

Revisamos Virtuozzo en su encarnación para Windows en el 2008. Las limitaciones de memoria de servidores de 32 bits en ese momento redujeron la utilidad de Virtuozzo. El producto de Windows permanece, pero Virtuozzo ahora tiene la capacidad de utilizar un kernel común para hacer contenedores en el reino de Linux.

Descargamos OpenVZ y lo instalamos en una Lenovo ThinkServer RD640. Como este esquema rodea un núcleo Linux de orígenes relativamente antiguos, la compatibilidad del hardware debe garantizarse. Teníamos muchas características de servidor, y nos dijeron -pero no lo comprobamos- que la compatibilidad de hardware del servidor asociado con Red Hat 6 trabajaría con OpenVZ u Odin.

Usted está atado al combo HBA y disco JBOD que pueda reunir, aunque comprobamos que OpenVZ y Odín trabajarán con combos RAID. IPv6 no es completamente compatible, aunque las direcciones de una MV/contenedor IPv6 "dura son compatibles y se pusieron a prueba.

Virtuozzo es un entorno virtual, y en nuestras pruebas, las máquinas virtuales alojadas suelen ser los servidores de Windows. Linux y FreeBSD actúan mejor como contenedores. Virtuozzo está controlado a través de una aplicación web, y tiene componentes necesarios de la línea de comandos que no están en la interfaz de usuario. Puede ser casi totalmente controlado por CLI, si lo desea.

Los contenedores se pueden hacer de Docker, Rocket o LinuXContainers/LXC. También hay un depósito de contenedores OpenVZ/Virtuozzo disponible vía descarga desde Odín.

La implementación en OpenVZ es similar a Docker y Rkt. Los entornos virtualizados se instalaron fácilmente y ofrecieron el mismo rendimiento que el mismo hardware bajo VMware 5.5, configurado de manera similar. No utilizamos puntos de referencia extensos para llegar a esta conclusión, solo las pruebas de navegador SciMark que utilizamos como una métrica para el rendimiento flojo con Firefox 35, que nos dio cargas de trabajo y perfiles similares.

Visto de esta manera, OpenVZ es muy parecido a un hipervisor, aunque más ligero en el peso del proceso general que VMware, y más parecido a Windows Hyper-V. Tampoco tiene costo o la extensa lista ESXi 5.X de VMware.

La prueba de OpenVZ y Virtuozzo

Provamos OpenVZ/OVZ primero. Hay dos ramas de la instalación, una para las versiones RedHat y similares, y la otra para los lanzamientos Debian. Debajo de cada una de ellas hay una rama para pre-sysctrl e inferencias para post-sysctrl. La funcionalidad esencialmente fue la misma para todas las ramas, al igual que los binarios de cimentación de la instalación.

Los documentos están dirigidos a instaladores expertos de Linux y no son lo suficientemente completos para los principiantes.

OpenVZ quiere metal básico a pesar de que se puede ejecutar como una máquina virtual. Cuando se utiliza una computadora sin sistema operativo, el rendimiento puede ser asombrosamente rápido. Se aconseja encarecidamente no utilizar OpenVZ o Virtuozzo como máquinas virtuales si se corta el rendimiento, especialmente cuando la relocalización de recursos hará que el anfitrión falle.

Los contenedores OpenVZ, o "entornos virtuales", se inician como un servicio cgroup-degradado. Si el kernel OpenVZ se utiliza en lugar del estándar kernel Linux, entonces podríamos usar un sistema de archivos llamado Ploop para disminuir el número utilizado de nodos-i Linux.

Después de decidir el tipo de sistema de archivos, instalamos vzctl, el controlador principal del contenedor, luego vzquota, que controla el volumen/cuotas de recursos en los contenedores. La aplicación vzctl se puede utilizar para implementar diferentes imágenes de contenedores desde el sitio openvz.org. Los contenedores son muy pequeños en el desplazamiento inicial, recuperados en forma de un archivo tar en un directorio de caché, y desplegados desde allí.

Advertimos que no todos los núcleos (excepto el kernel de OpenVZ) utilizados en la última era de kernels Linux 3.x ofrecen soporte completo para los controles de memoria y CPU. No tuvimos problema alguno, pero podemos imaginar escenarios en los que un kernel no tiene todas las palancas OpenVZ compiladas en él, lo que resulta en la dominación de la MV o del contenedor huésped. Aparentemente, un kernel puede ser re compilado con todas las características encendidas, si lo desea, pero no probamos esto.

Las imágenes se envían con una clave GPG con el fin de autenticar la imagen. Esto es importante. Es posible construir sus propias imágenes si lo desea, aunque hay abundantes imágenes de Linux OpenVZ. Las imágenes descargadas se pueden implementar directamente desde la caché de imágenes. Empezamos muchas imágenes de los scripts; las imágenes s desplegaron rápidamente, pero no tan rápido como Docker sobre CentOS en nuestro entorno de prueba. La diferencia en los tiempos son insignificantes, tal vez un par de segundos, tal vez por el tiempo que necesita Ploop para crear su sistema de archivos.

Odin Virtuozzo 6 SP1

El lado comercial instrumentado de OpenVZ es Virtuozzo de Odín, que en nuestras pruebas, tuvo un aspecto muy similar a Red Hat 6. Virtuozzo tomó mucho tiempo para instalarse, y, finalmente, fue capaz de entender nuestro almacenamiento iSCSI aunque encontramos que iSCSI lo ralentiza; es compatible con .NFS y fue ligeramente más rápido que iSCSI en las pruebas.

Virtuozzo ofrece una página web para la minuta de configuración IP (IPv4), incluyendo tarjetas de red virtuales y VLAN. Esto es similar a la forma en que Xen/XenServer y VMware unen redes entre sí, y está lista en configuraciones de inquilinos múltiples.

Hay dos métodos de creación de entornos virtuales Odin, uno dirigido hacia el uso nativo del hipervisor -lo que significa procesador/plataforma racional soportada por el sistema operativo-,y otro diseñado para cargas útiles de contenedores Linux.

Esas cargas útiles pueden ser atendidas por los sistemas de archivos Ploop, sino también pfcached/ParallelsFileCacheDaemon que realiza la deduplicación de archivos comúnmente accedidos en su propia caché de sistema de archivos Ploop. El pfcached utiliza un algoritmo para elegir cómo y cuándo hacer la deduplicación, y no esperábamos ver un incremento inicial de rendimiento debido a que el algoritmo necesita tiempo para trabajar en el logro de mayor efectividad.

Los contenedores OpenVZ/Virtuozzo son instancias controladas por vzctl o prctl. Se los contacta en las formas habituales, SSH, RDP, o por la consola. A su vez, los contenedores se ejecutan en sus propios mundos, haciendo el trabajo, la digestión y el almacenamiento de datos, o tal vez ofreciendo una página web.

Los contenedores o máquinas virtuales están aisladas a través de Ethernet virtualizado y no está habilitado ningún inter-contenedor especial o enlaces de comunicaciones con MV; esto lo debe hacer por su cuenta, tal vez pueda utilizar Puppet, Chef u otro método. Están disponibles USB virtuales, unidades de disquete, DVD, pero solo de video primitivo. Es posible construir varios servidores de hardware que estén conectados entre sí para los propósitos de alta disponibilidad, pero esto no ha sido probado.

Instalamos cuatro pruebas binarias de Windows y Linux ISO (nuestras propias fuentes ISO) como máquinas virtuales huésped, con éxito. No probamos gráficos avanzados, puertos USB virtualizados, o puertos de sonido. También probamos varias imágenes Odin de las mismas fuentes distro de Linux, y no encontramos diferencias entre las pruebas de ambas (por ejemplo: Ubuntu 14.04 vs Ubuntu de origen Odin 14.04).

Al igual que con OpenVZ, las imágenes se pueden descargar, listas para desplegarse en el sustrato del huésped. El uso de plantillas pre-formateadas, o las imágenes de OpenVZ/Parallels/Odin, o generadas por los usuarios, ofrece los beneficios de la utilización de memoria optimizada, aunque los techos durante el estallido de una actividad periódica pueden retrasar algunas máquinas virtuales o a los contenedores, así como sucedería en otros techos administrativamente-establecidos de otros hipervisores .

Se pueden asignar los CPU MHz (ciclos de reloj), los límites de la explosión, y el número de CPUs. No hay afinidad de CPU, probablemente porque es difícil de hacer con un kernel Linux en general.

Con el uso de Ploop la toma de imágenes del sistema de archivos se hace más simple, y es necesario hacer posible la migración en vivo a Virtuozzo de máquinas virtuales o contenedores. Esto es ayudado por el hecho de que los sistemas de archivos de las máquinas virtuales o de los contenedores son almacenados como un objeto grande, en lugar de un conjunto discreto de archivos, carpetas, nodos-i, gobernados por diversos comportamientos sysctls. No probamos la migración en vivo.

En uso

Podríamos meter un número impresionante de contenedores y máquinas virtuales en Virtuozzo. El acceso se comportó con normalidad, y el sistema operativo se encontró todos los 24 núcleos de CPU en el host, y nos permitió asignarlos a máquinas virtuales o contenedores. Con solo unos pocos terabytes de almacenamiento y 128GB de memoria, nos preguntamos cuál se gastaría primero -el chip o la memoria de almacenamiento. Podríamos relocalizar el disco o la memoria, por lo que lo hicimos y provocamos que algunas máquinas virtuales se comporten erróneamente.

No recibimos aviso de que una máquina virtual o contenedor se comportaba mal, a menos que la misma máquina virtual o contenedor nos haya enviado el mensaje. Nos entristeció, pero este problema no es inusual. Uno no puede establecer umbrales mínimos de CPU que desencadenen una alerta cuando falla la máquina virtual, solo de que se está acelerando o alcanzando picos en términos de CPU. La mensajería IPMI, o un conjunto similar de APIs que envió condiciones de acogida para la instrumentación sería útil y es posible incrustar nagios u otro tipo de monitoreo para las cargas útiles de MV/contenedor, si lo desea. Sin embargo, encontramos lo mismo con el disco como recurso -obtiene mensajes cuando está lleno, no cuando no ha existido actividad durante 24 horas (una posible indicación de que el anfitrión murió).

Si bien Virtuozzo no es VMware XenServer o Hyper-V, podría satisfacer las necesidades de nubes internas multi huésped, o pequeños/medianos proveedores de servicios como una plataforma de nube.

Los contenedores también se pueden formar y ejecutar con Docker, si se desea el ecosistema de Docker. Si bien Parallels hace lo mismo, encontramos que Docker es algo superfluo, aunque probamos la plataforma de host con Docker bajo CentOS. Usando nuestra primitiva referencia SciMark, el tiempo de ejecución es aproximadamente 18% más largo en comparación de una prueba ejecutada en un contenedor nativo, pero solo el 15% más largo que ejecutar una máquina virtual equivalente. Sí, puede utilizar Docker; no, no lo recomendamos porque anida una máquina al interior de una máquina en el interior de una máquina.

Docker 1.6

Docker se ejecuta como un proceso de raíz en una vasta lista de las distribuciones de Linux, versiones de MacOS, y en plataformas piloto de Microsoft. Probamos cuatro versiones de hosts de Linux y un host MacOS. Esto es bueno y malo. Docker obtiene gran parte de su popularidad desde su sencillez, y su poder para orquestar recipientes similares y diversos controles igualitarios.

La mayoría de los kernel Linux actuales, junto con MacOS, tienen la capacidad de ejecutar contenedores Docker. Se obtiene Docker desde la plataforma de acogida, a continuación, ejecuta una instancia del sistema operativo "dentro" del control de Docker. Docker tiene muchas comodidades para aquellos casosde sistema operativo alojado, que por otro nombre, son simplemente máquinas virtuales aisladas cuyos recursos han sido orquestados por Docker.

Parte del valor de Docker es la enorme variación de los casos que se pueden seleccionar desde su repositorio. El registro y depósito de contenedores en Docker.com, está lleno de imágenes "oficiales" de famosos fabricantes de aplicaciones, algunas alojadas en el sitio de Docker, otras que vinculan al sitio del fabricante de la aplicación, otras conectadas a GitHub. Una impresionante variedad de plataformas de desarrollo de aplicaciones y aparatos enlatados (piense en variaciones de WordPress, componentes del clúster Hadoop, etc.) están disponibles para ser utilizados.

Un ejemplo típico de Docker podría ser una instancia de servidor Ubuntu 14.04, ya relativamente pequeña en términos de recursos de host utilizados. Tal vez el recipiente está ejecutando una instancia Linuz/Apache/MySQL/PHP/Perl (LAMP) y los casos genéricos son abundantes y variados. Muchas imágenes, aligeradas ya están disponibles de Canonical, Red Hat, e incluso imágenes cuyas entrañas se han hecho más livianas intencionalmente para evitar que los procesos no utilizados roben contenedores de ciclos de CPU.

Hacer que las cosas funcionen es tan simple como usar el comando de ejecución de Docker. Este comando crea una instancia del contenedor/MV, que utilizará un subdirectorio para el almacenamiento, no muy diferente de lo que hace Linux chroot en términos de reducción del significado de seguridad, y similar a OpenVZ/Virtuozzo.

Las imágenes de los contenedores Docker utilizan el sistema de archivos de unión/unionfs, que se convierte en la infraestructura de la carpeta para los contenedores. Como OpenVZ/Virtuozzo, Docker hace capas dedicadas para cada proceso que lanza vía unionfs. Esto permite imágenes similares para compartir archivos de base, lo que requiere solo una actualización, y conservar espacio para cuando es necesario tomar imágenes, o cuando éstas necesitan actualizaciones. Actualice openssh, por ejemplo, y hágalo para 20 contenedores a la vez, ya que dependen de la imagen actualizada.

El uso de unionfs es conveniente para la eficiencia de Docker, pero también es el quid de muchas críticas, ya que una sola imagen fallida malogra todo lo que depende de ella. El control de Docker también se puede hacer de los comandos de inicio del usuario utilizando RESTfut para poner/obtener las imágenes del contenedor. Este usuario es tan útil o peligroso como el usuario rooteado, por lo que se recomiendan encarecidamente los controles de usuario relacionadas con el acceso, contraseñas, repositorios seguros de claves SSH, y otros mecanismos de seguridad estándar. Es un poco rápido pero no del todo divertido.

Las imágenes ISO se pueden construir de una forma automática, si una organización desea mantener su propia jerarquía de imágenes y monitorear su propio control de seguridad de imagen.

El acceso a los componentes internos de Docker se puede realizar a través de comunicaciones SSH u otras APIs, incluyendo construcciones de comunicaciones, como Puppet. El almacenamiento se degrada, y se puede controlar aún más a través de la seguridad del usuario (chroot, chmod u otras limitaciones/metadatos impuestos para el control de archivos). En algunos casos, puede utilizar Ploop u otros sistemas de archivos para lograr algunos de los beneficios que describimos con OpenVZ/Virtuozzo.

Docker como barco de contenedores

Docker no está conservando conscientemente espacio común en la forma en que lo hace OpenVZ/Virtuozzo, en términos de de-duplicación de archivos comunes almacenados. En teoría, OpenVZ/Virtuozzo puede empaquetar contenedores en un resultado más estrecho. Dicho esto, en la misma plataforma de hardware utilizada para probar OpenVZ/Virtuozzo, pudimos poner un gran número de casos de contenedores Docker, tal vez con más facilidad.

Pero Docker no tiene los controles que se comparan con Virtuozzo. Docker requiere una gestión estudiosa de secuencias de comandos y teclas de control, lo cual es una comodidad en Virtuozzo. Hay una oleada de terceros que comienzan a hacer precisamente esto con ofertas de aplicaciones, pero no fueron probados.

La gestión de una gran flota de los ejércitos de contenedores no es difícil, aunque requiere un conjunto ligeramente elevado de habilidades. Docker Swarm es una API que permite que un grupo de contenedores Docker se comporte como un objeto, lo que resulta en un conjunto de contenedores con un único punto de control. Esto permite un rápido avance de la instancia, y quizá su crecimiento.

Aquí es donde más nos divertimos, al hacer que los contenedores marchen al mismo ritmo que nuestras órdenes. Esta pieza todavía no se ha perfeccionado, y también es otro lugar para advertir que los usuarios que aborden Docker Swarm también pueden, como el episodio de Star Trek Next Generation, hacer que el Borg de contenedores se ponga a dormir, o cualquier otro comando deseado.

La creación de una flota de contenedores que se pueda manejar como un objeto requiere una gran responsabilidad. Dicho esto, existen aplicaciones como Apache Mesos que pueden controlar conjuntos de datos muy grandes así como contenedores agrupados. Desde el perfil de seguridad de la organización, hay que hacerlo con mucho cuidado, ya que los recursos expuestos podrían ser hackeados.

Rocket/rkt 0.5.4

Rocket se introdujo y evoluciona de algún modo en conjunto con CoreOS, como un sistema operativo diseñado como una superficie de pocos ataques, si se sustrae la alta eficiencia, para Docker. Factura en GitHub como contenedor de aplicaciones en ejecución (sistema), es una plataforma de aplicaciones diseñada para dejar una huella pequeña pero ofrecer alta estabilidad.

Rocket carece de algunos componentes clave y requiere más expertos en la construcción que Docker o Virtuozzo. Nos complace ver que se centra en la seguridad con procedencia de imagen de origen y control de carga útil.

Basado sobre los kernels de Linux, CoreOS ha ido evolucionando a un ritmo ligeramente más lento que Docker, ya que era un sistema operativo para los clústeres en lugar de un plano de control. CoreOS es uno de varios patrocinadores de rkt, que en realidad no está listo para la producción. Normalmente, nuestra política nos dice que no debemos incluir estos productos en reseñas de opinión sin una demanda muy alta, ya que la industria está llena de expectativas beta que no conocen la realidad de la producción.

Como las tres metodologías de contenedores utilizan los mismos componentes algo maduros de Linux, incluimos rkt más por su ideología que por su práctica. Rkt no es simple, pero creemos que es menos riesgoso debido a su metodología de seguridad más estricta en muchos niveles.

Rocket impone una disciplina que se inicia en la gestión de construcción de contenedores, ya que las imágenes deben ser construidas de una manera específica antes de que rkt pueda lanzarlas. Esto varía de la gestión OpenVZ y Docker, ya que ambos controladores de contenedores pueden utilizar imágenes ISO que están fuera del estante, las que evolucionaron a partir de máquinas de trabajo, repositorios/registros del controlador contenedor, o de su amigo que está en el cubículo próximo. No necesariamente pasa lo mismo con Rocket.

En las pruebas encontramos que rkt funciona de manera muy similar a Docker y OpenVZ en los conceptos básicos de control de tiempo de ejecución de contenedores: utiliza un demonio para controlar las poblaciones de contenedores, y controla las instancias de contenedores a través del ciclo de vida. La forma en que lo hace está mucho más reglamentada y, potencialmente, es mucho más segura que Docker.

Históricamente, algunas de las deficiencias de seguridad/fiabilidad percibidas en Docker fueron las que inspiraron el desarrollo de Rocket/rkt. Se generó un manifiesto, diseñado para encarnar diferentes valores fundamentales alrededor de los contenedores. App Containers (APPC) es la especificación resultante anunciada para abordar las percepciones de que la seguridad de Docker es débil, y que la fiabilidad de sistemas inherentes debe ser colocada en cadenas de autoridad, no importa cuán grande o pequeño se vuelva el barco de contenedores. Sin embargo, rkt permite anulaciones.

Para estos fines, la especificación de APPC resultante busca asegurar que las imágenes descargadas tengan firmas de procedencia y la integridad del método de montaje. Citamos la especificación de la aplicación Github:

Los objetivos principales de la especificación son:

  • Diseñar para descargas rápidas y arranques de App Containers
  • Asegurar que las imágenes sean criptográficamente verificables y altamente "cacheables
  • Diseñar para implementaciones de componentes e independientesUtilizar las tecnologías comunes para la criptografía, el archivo, la compresión y el transporte
  • Utilizar el espacio de nombres DNS para nombrar y descubrir imágenes

Rocket se considera una implementación de esta especificación, y otros han firmado los principios de esta especificación, incluyendo Red Hat, Google, VMware y Apcera. Y aunque parece que CoreOS + rkt es sinónimo de la APPC, rkt es una implementación, al igual que las implementaciones de VMware (Lightwave/Photon) y Apcera (Continuum), ninguna de los cuales estuvo disponibles para su comparación en el tiempo que se hizo la revisión.

Rkt utiliza la metodología de APPC para obtener sus imágenes como archivos tar (Tape Archive), en lugar de ISOs, de manera que sus claves GPG se enlazan con un ISO para que la imagen base de contenedores tenga autoridad. Esto hace que los archivos de origen sea difíciles de perturbar (imagine sustituciones de archivos, niveles de parches inadvertidos, malware, paquetes rotos que se pueden insertar en ISOs). Un resultado ImageID que es único para la imagen.

Hemos creado una carpeta para utilizarla como rootfs de RKT o sistema de archivos de nivel superior. Nosotros no comprimimos imágenes, que tienen un formato-manifiesto de imagen JSON previamente insertado sobre lo que debe estar dentro de la imagen un-tar'd (sin comprimir). También se pueden tomar algunos pasos adicionales de cifrado de manera que se requiera una clave (AES-256 era nuestra favorita) a la hora de descomprimir/descifrar una imagen. Estamos a la espera del panel de control que pueden hacer esto sin CLI, pero no es difícil.

Una vez que se hace el cifrado y el manifiesto JSON para la imagen está satisfecho, la imagen puede ser ejecutada. Se convierte esencialmente en un pod, un contenedor, pero la palabra "pod" también evoca otras imágenes mentales.

Es un conjunto de ejecutables con su propio ID, que se convierte en un práctico UUID de objeto (cubierto por IETF RFC 4122) para manipular las características de la ejecución del pod. El UUID obtiene su propio espacio de nombres, creado y hecho subsecuentemente administrable por rkt; esto proporciona control de instancia. Rkt entonces se encarga de, en la ejecución inicial, crear rootfs para esta UUID con un conjunto de la lista blanca de carpetas asociadas con el manifiesto JSON. Crea el sistema de archivos nuevo, cada vez que se arranca el objeto contenedor, asegurándose de que no haya sobras.

Encontramos que el manifiesto es crítico. Nada funciona si es incorrecto. Una vez construido, sin embargo, su reutilización revisa la autenticidad de la fuente. Esta edición más reciente también obtiene imágenes Docker. En general, sentimos que su reglamentación vale la pena, y la instrumentación será clave para su evolución exitosa.

Prueba Rkt

Construimos un banco de pruebas desde un huésped CentOS6 en la misma plataforma Lenovo utilizada para OpenVZ y Virtuozzo, puesta en marcha en un entorno de acogida mínima, en lugar de utilizar CoreOS, por conveniencia. Creamos dos imágenes, una imagen de WordPress desde TurnKeyLinux que habíamos arreglado para WordPress 4.2.2, y otra imagen de servidor de Ubuntu 14.04 genérico, que se había actualizado una vez, y fue construida para dar servicios mínimos. Más tarde, descubrimos imágenes de repositorio para ambas y utilizamos esas.

Los recursos, tales como la asignación de memoria demandada por pod, ancho de banda, y así sucesivamente se pueden configurar con un comando rkt basado en CLI Aquí, falta la instrumentación y las secuencias de comandos son necesarias, por ahora. Hemos vuelto a aprender la sintaxis JSON.

La versión que probamos también permite la descarga, a través de http nombre de usuario/contraseña, imágenes del registro Docker (o parecido a Docker). Esto también es el presagio de que mientras los depósitos se pueden utilizar, las anulaciones de seguridad pueden romper la cadena de autoridades, lo que podría romper las necesidades de auditoría/cumplimiento a menos que los registros se controlen estrictamente para este comportamiento y se hagan cumplir las correcciones de errores.

Los scripts que hicimos se convirtieron en la base para la replicación rápida en nuestro servidor host Lenovo. Nos deslizamos en nuestro script de ejemplo, y cuando empezamos a las máquinas bajo comandos títeres incrustados, llenamos la instancia de cráteres, dejando un agujero humeante en la Lenovo, mientras se iba a la basura, y luego se encerró más apretado que un neumático inflado.

Nos habíamos olvidado de establecer recursos compartidos de CPU, y comenzar todos los casos a la vez creó una enorme demanda de inicio en los núcleos de acogida. Probablemente ningún servidor habría sobrevivido. Afortunadamente, un reinicio nos permitió corregir el error (nuestros errores de secuencia de comandos).

En la práctica, se obtuvieron dos imágenes más de Docker, y después de muchas artimañas, pudimos conseguir que se ejecute con el tiempo de ejecución rkt. Escribimos una serie de lanzamientos de contenedores, y pudimos hacer un piloto escalable de ejecutables, pero no sin mucho trabajo. Las herramientas de terceros ayudarán a rkt, y en su defecto, se convertirán en un altruismo sin mantenimiento.

¿Cuáles son los contenedores ¿Y en qué se diferencian de las máquinas virtuales?

Las aplicaciones en contenedores son "luz de hipervisor". La ejecución de contenedores de una instancia difiere de la ejecución tradicional del hipervisor en la que cada contenedor puede compartir archivos comunes, en lugar de existir como instancias monolíticas que combinan sistemas operativos/aplicaciones discretas.

Conceptualmente, los contenedores son elementos que comprenden una instancia de un sistema operativo, código de la aplicación, y las coyunturas de comunicación, incluyendo el almacenamiento de datos temporales y permanentes.

Al igual que instancias de máquinas virtuales, los contenedores tienen enchufes para conectar la comunicación y las necesidades de almacenamiento (si es necesario) con el mundo exterior a través de la configuración de administración del gestor de contenedores.

Los contenedores están aislados de los procesos básicos y de root de un host mediante muros de seguridad, y trabajan a menudo en conjunción con otros contenedores a bordo del mismo host.

Los contenedores se pueden formar para ser independientes de un sistema operativo huésped específico, y se pueden construir de manera intercambiable, por lo que son posibles mezclas de los contenedores construidos con Ubuntu, Red Hat Atomic, CoreOS y SUSE u otros sistemas operativos. Los hosts de contenedores desconocen en gran medida lo que sucede al interior de un contenedor a menos que esté conectado a propósito.

A su vez, los aparatos y los procesos resultantes viven en un mundo aislado, y pueden ser transportados como un objeto de un huésped a otro. Los anfitriones son en gran parte de Linux, pero Docker también trabaja en Apple, BSD, y Microsoft recientemente demostró imágenes Docker en movimiento utilizando adaptaciones .Net desde una plataforma de servidor de Windows hacia un host Linux, siempre y cuando las familias de acogida de la CPU sean similares (no, no se puede desarrollar contenedores en ARM y ejecutarlos en Intel/AMD). La intercambiabilidad de las plataformas de acogida es un objetivo de los diseñadores de sistemas que utilizan contenedores como bloques de construcción de Lego.

Nuestra principal crítica: Es posible hacer sistemas con contenedores de origen desconocido o cuyo origen en términos de cadenas de autoridad son desconocidos. Ya que los contenedores suelen compartir aplicaciones de código, la infiltración o la desaparición de una aplicación pueden causar problemas con todas las instancias de todos los contenedores.

Esto se debe a que, a menos que un repositorio que emite los contenedores haya reunido cada unidad desde cero o una fuente autorizada, sus bloques de construcción deben ser considerados sospechosos, y la gestión de versiones de contenedores basados en archivos comunes requiere grandes controles.

El lado opuesto de esto es que en un acto, se puede restaurar, mejorar o re-configurar (en cierta medida) la funcionalidad e incluso la personalidad de un grupo de contenedores.

Críticas

Las tres aplicaciones se ejecutan como root, ya que necesitan ganar velocidad del núcleo. AppArmor y SELinux reciben tratamiento leve en la documentación de los tres, pero los tres pueden utilizar estas cajas de arena para aislar contenedores de los recursos corruptos del sistema.

Una plataforma de hardware de contenedor no impedirá que un contenedor infectado tenga un privilegio de seguridad en otro contenedor que hace su trabajo para otros recipientes en el mismo barco; o tal vez, la misma instalación en general. Los contenedores son tan seguros como su funcionamiento interno, de forma nativa.

A nivel de la nave/host, los procesos para controlar los demonios que controlan los procesos del contenedor deben ser especialmente protegidos, algo que es ya una actividad central de seguridad en la mayoría de las organizaciones. Luego viene el control de clave, que Virtuozzo hace bastante bien, pero no es exhaustivo. Una arquitectura que administra correctamente las claves SSH, y controla el plano de comunicaciones para los contenedores respectivos necesita evolucionar, y aquí, Virtuozzo tiene un comienzo. Los otros internos de red definidos por software que necesitan la coordinación de los tres productos requieren madurar.

Pero hay posibilidades de eficiencia a través de densidad que no tienen un verdadero paralelo en los hipervisores Tipo 1, especialmente donde puede ocurrirdeduplicación de los archivos almacenados y ejecutados. En cierto modo, los contenedores son instancias de metal básico híbridos con habilidades en virtualización. Las máquinas virtuales basadas en hipervisor viven en aislamiento, por lo general como casos discretos, algo que no es necesariamente cierto para los contenedores. Los hipervisores van a un nivel muy bajo para proteger casos de robo de los recursos, sin que se den cuenta, o por medio de malware. Las paredes de las cajas de arena son teóricamente mucho más altas para las máquinas virtuales de los contenedores, aunque los errores de seguridad pueden romper fácilmente las políticas de cualquier tipo de instancia.

Resumen

Los contenedores son muy, muy prácticos, y permiten que las instancias del sistema operativo + los ejecutables se intercambien en una atmósfera simplificada, a veces en recursos compartidos (en el nivel de sistema operativo). La procedencia de los contenedores, sus niveles de parches/arreglos, no son totalmente opacos, pero a menos que se utilice una metodología rigurosa para aplicar auditoría y registro de los hábitos, son una explosión en busca de un lugar marcado con una X.

Dicho esto, admitimos la seducción de una rápida escalabilidad hacia arriba o abajo de los casos. OpenVZ tuvo el espacio más maduro de contenedores en nuestra opinión, y su modelo híbrido de virtualización completa o contenerización a bordo tiene sentido para su mercado objetivo, ISPs y los proveedores de servicios gestionados.

Docker es una construcción seria establecida con mucha energía detrás en términos de desarrollo. Si el recuento de los participantes GitHub son una indicación, hay una abrumadora cantidad de actividad en el desarrollo de Docker. Hemos tomado nota de que con la energía proviene el ruido de los problemas con las imágenes del registro de Docker, incluyendo algunas que elegimos como muestras. Nos pone nerviosos pensar que los contenedores son difíciles de probar, y sus componentes compuestos e individuales son difíciles de ver de forma sencilla y de auditar por la cadena de autoridades de sus fuentes, incluso de organizaciones importantes.

Esto, a su vez, hace esperar que las primitivas asociadas con la especificación de APPC, como se ve en rkt, siguan evolucionando. Hay disciplina en rkt y el cumplimiento de APPC merece aplausos, aunque rkt no esté listo para el horario estelar, excepto para implementaciones avanzadas o experimentales.

Puede ver también: