Wolf, Gunnar

RU-Económicas

050 SG.48Discutir acerca de mecanismos de virtualización implica cubrir una gran cantidad de tecnologías distin-tas. Y no me refiero con esto a diferentes proveedores que ofrecen productos con funcionalidad similar, sino que a herramientas de muy distinta naturaleza, que a veces incluso no parecen tener nada que ver entre sí.La primera acepción que vendrá a la mente de muchos, es la virtualización asistida por hardware, donde una computadora con ciertas capacidades de hardware (disponibles en la arquitectura x86 desde hace ya diez años, y hoy presentes incluso en los CPUs de más baja gama) ejecuta un hipervisor, software específico que se ubica por debajo del sistema operativo y permite que la computadora sea compartida entre distintos sistemas operativos (o distintas instancias del mismo), aparen-tando ante cada uno de ellos ser una computadora inde-pendiente. Como apéndice de esta categoría entraríanlos paravirtualizadores, que corren versiones de dichos sistemas operativos que saben que se ejecutarán dentro de una máquina virtual, con lo cual delegan algunos pro-cesos al sistema anfitrión, muchas veces aumentando la estabilidad o reduciendo la penalización de velocidad.Por otro lado, la emulación de hardware completa-mente distinto del sistema primario puede también considerarse virtualización. Podemos encontrarla como parte de los kits de desarrollo para dispositivos móviles, en que el código generado se compila para procesadores típicamente de arquitectura ARM, mien-tras que el desarrollo se efectúa sobre computadoras x86. La emulación incluso cubre a las máquinas virtua-les empleadas nativamente, como la JVM (Java) o CIL (.NET): El bytecode compilado para estas arquitecturas no corre nativamente en ningún procesador, son arqui-tecturas diseñadas para ser siempre emuladas.Una modalidad más de virtualización es el uso de con-tenedores. Esta modalidad puede comprenderse mejor si se contrasta con las anteriores dónde está el engaño — O (más bonito) dónde está la magia. En vez de pro-veer una computadora virtual a los sistemas operativos huéspedes, los contenedores buscan proveer un sis-tema operativo virtual a conjuntos de programas.¿Qué significa esto? Que a cambio de reducir la flexibili-dad, esta modalidad de virtualización provee un mucho mejor rendimiento (las aplicaciones virtualizadas tienen exactamente la misma velocidad que en el hardware nativo) y menor impacto en el resto del sistema (cuando los procesos que forman parte del contenedor no tienen trabajo por realizar, su consumo de recursos es verda-deramente cero, a diferencia de un sistema virtualizado, que debe seguir pendiente a posibles eventos).La reducción de flexibilidad referida consiste en que, dado que el núcleo del sistema operativo en ejecución es uno solo, todos los procesos que sean ejecutados empleando esta técnica deben estar compilados para la misma arquitectura y sistema operativo —esto sig-nifica que por ejemplo, en un sistema anfitrión x86 con Linux, todos los contenedores deberán ser también x86 con Linux. Esta tecnología hereda directamente de la llamada al sistema chroot(), en 1982. Claro está, a esta simple llamada se tuvieron que agregar numerosas fun-ciones implementando una separación más limpia ycompleta entre los distintos espacios de nombres. Poco a poco se desarrollaron mecanismos para limitar el uso total de memoria o de CPU de cada contenedor, y aislar la vista de la red que cada uno de ellos puede tener. El primer sistema en implementar lo que hoy conocemos con contenedores fue FreeBSD, en el año 2000; dado que están construidos alrededor de la llamada chroot(), resulta natural que casi todos los sistemas operativos en implementar contenedores sean tipo Unix; en el mundo Windows, hoy en día se tiene la promesa de que la ver-sión 10 incluirá esta característica.En Linux hay distintas implementaciones disponibles, y que han logrado madurar cada cual a su ritmo. Durante muchos años, la más fuerte fue VServer, pero reque-ría de cambios demasiado invasivos, que nunca fueron aceptados por Linus Torvalds para la rama principal del kernel. Posteriormente se popularizó OpenVZ, la versión libre de Virtuozzo, pero sufrió del mismo pro-blema. Sin embargo, a partir de la incorporación de los grupos de contexto (cgroups) al kernel de Linux 2007, el proyecto Linux Containers (lxc) logró una implemen-tación suficientemente eficaz y sencilla, y es hoy en día la más popular y consolidada.Distribución basada en contenedoresA principios de 2013, se anunció la liberación de un innovador programa que ha cambiado en gran medida las reglas del juego para el despliegue de aplicacio-nes: Docker. Su principal contribución es que cambia Gunnar Wolf es adminis-trador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org AISLAMIENTO, SÍ, PERO… ¿DISTRIBUCIÓN?—Por Gunnar WolfLos ContenedoresPROGRAMAR ES UN MODO DE VIDACSG.COM.MX 051el enfoque: presenta a cada contenedor ya no como una máquina virtual, como una instalación completa de una computadora, sino que como el entorno completo de ejecución de una aplicación. Esto tiene aspectos muy positivos, pero también tiene otros fran-camente dignos de cuidado. Pero antes de abordarlos, permí-tanme explicar un poco.Originalmente, instalar o aprovisionar un contenedor implicaba como paso necesario la instalación del software de sistema tal como si se tratara de una computadora real. La delgada capa de virtualización de los contenedores permitían tomar a un conjunto de máquinas virtuales como si fuera una granja de servidores — Y el trabajo del administrador de sistemas es, a fin de cuentas, gestionar a cada una de las máquinas virtuales cual si fuera un servidor completo — Que si bien es mucho menos complejo que si se tratara de una sola instalación con todo el software bajo el mismo espacio, implica una innegable complejidad. El principal cambio que introduce Docker es que permite generar un contene-dor por aplicación, y gestionarlo directamente como si fuera una unidad — ya no una colección de paquetes relacionados.Bibliotecas, versiones, infiernos y appsDemos un brinco conceptual a un tema, aparentemente, sin rela-ción. Prometo pronto explicar a qué viene esto.El desarrollo de los sistemas operativos que empleamos hoy en día cruzó hace unos treinta años por un punto crucial en lo concerniente a su flexibilidad: La introducción de formatos estándar de bibliotecas compartidas, que pueden ser utilizadas entre diversas aplicaciones. Gracias a ellas, el tamaño de cada uno de los programas se redujo fuertemente (puesto que éstos no tenían que incluir expresamente todas las definiciones que emplean), se estandarizaron interfaces (puesto que diversos programas aprovecharían las mismas bibliote-cas ampliamente conocidas), y –muy importante– dado que redujo fuertemente la duplicación de código, mejoró significativamente la seguridad de los sistemas operativos: Ante un error o vulnerabilidad, basta con actualizar una copia del código vulnerable para que todos los programas afectados reciban la corrección.Claro, surge complejidad del manejo de los cientos de bibliotecas compartidas que se instalan en un sistema típico, de la cual se deriva la expresión “DLL hell” (el infierno de los DLLs). Sin embargo, este es un problema en el que se ha invertido una gran cantidad de trabajo, y la situación hoy en día es radicalmente diferente a la de hace veinte años, cuando se acuñó dicho término.Ahora bien, ante la popularización de las apps en dispositivos móviles y el abaratamiento del almacenamiento, se impuso el concepto inverso: El empaquetamiento de todas las dependencias dentro de un mismo binario. Para evitar que el usuario final tenga que descargar todas las dependencias que empleó cada desarrolla-dor, y asegurar que cada paquete funcionará independientemente de los demás que tenga instalado el sistema, se ha optado por –de facto– reconvertir las bibliotecas dinámicas en objetos ligados estáticamente. Claro, esto obliga a que ante la actualización de una biblioteca compartida, cada una de las aplicaciones que la usa sea actualizada también — Pero en una era de conexión permanente a Internet, esta idea ha resultado del favor del mercado.Distribución y servidores virtualesUniendo, pues, los dos temas expuestos: La principal contribución de Docker es que convierte el engorroso despliegue de servidores virtua-les en un sencillo despliegue de aplicaciones — Y, claro está, de apli-caciones empaquetadas a la moda, con el mínimo de dependencias.Desde una perspectiva meramente de DevOps, esto suena muy bien. Sin embargo, también involucra grandes riesgos, como lo ilustran entre otros muchos los textos que han escrito al respecto dos de los desa-rrolladores de Debian GNU/Linux: Joey Hess [1] y Erich Schubert [2].En primer lugar, un uso irresponsable de Docker (aunque sea el recomendado por sus desarrolladores) nos puede llevar a confiar en software cuyo origen no necesariamente es el que esperamos, sin saber en qué consisten los cambios y cómo éstos nos afecta-rán. Los paquetes que dicen ser oficiales de determinadas distribu-ciones han demostrado haber sido alterados, lo cual debe poner a pensar mal a cualquier administrador de sistemas.En segundo lugar, y esto me parece más complicado y peligroso aún, el modelo que impulsa Docker nos invita a olvidarnos de la seguridad que debe mantenerse como parte de la gestión de cada sistema instalado. Un contenedor no puede ser creado una única vez y visto, a partir de ese momento, como una app, como un objeto estático e independiente. Y no, cada sistema debe integrar las correcciones a las vulnerabilidades (o simples bugs) que cons-tantemente van apareciendo y siendo corregidas, y un administra-dor de sistemas siempre debe estar familiarizado con la tecnología que tiene instalada. Resulta inexcusable poner al mismo nivel a un sistema operativo completo y a aplicaciones como Wordpress, pero eso es precisamente lo que ocurre [3].Obviamente, la tecnología no es mala, y la adopción que ha tenido habla de sus virtudes técnicas. Sin embargo, el uso y crecimiento que ha tenido dejando de lado las buenas prácticas de adminis-tración de sistemas, y el impacto que esto puede tener en nuestro campo, merecen ser consideradas.Referencias[1] “What does docker.io run -it debian sh run?”, https://joeyh.name/blog/entry/docker_run_debian/[2] “The sad state of sysadmin in the age of containers”, http://www.vitavonni.de/blo-g/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html[3] Repositorios oficiales de Docker: https://registry.hub.docker.com/search?q=library&f=official“Docker nos invita a olvidarnos de la seguridad que debe mantenerse como parte de la gestión de cada sistema instalado”.PROGRAMAR ES UN MODO DE VIDA C

Los contenedores: Aislamiento, sí, pero... ¿distribución?

http://ru.iiec.unam.mx/2722/1/SG48_gwolf.pdf

Los contenedores: Aislamiento, sí, pero... ¿distribución?

Abstract

Similar works

Full text

Available Versions

RU-Económicas