Virtualización de Aplicaciones / Parte 1

Junto con la de servidores, la llamada virtualización de aplicaciones es uno de las tecnologías que en estos últimos años ha acaparado más post y notas técnicas. La tecnología VDI también ha impulsado la evolución de las soluciones que permiten ejecutar una aplicación sin instalarla previamente.

Quien, como yo hasta hace poco, reinstalaba su PC cada cierto tiempo, conoce la sensación de pérdida de tiempo que supone la instalación de las aplicaciones. En casi cualquier sistema operativo,  prácticamente todas las aplicaciones modifican el o el estado del mismo, o su configuración o sus archivos. En el particular caso de Windows, la instalación de una aplicación supone modificaciones en las dll registradas, controles, entradas del registro y una buena cantidad de modificaciones en el árbol de ficheros. Así mismo, estas modificaciones no sólo afectan a la aplicación, sino al estado global del sistema, lo que puede impedirnos la instalación de otras o alterar su funcionamiento. Por ejemplo, mantener distintas versiones del browser de internet es a menudo imposible.

Por otro lado, una vez instalada, y como una buena novia, desinstalarla suele dejar trazas en nuestro sistema (basta echar un ojo al siempre creciente – como la prima de riesgo – directorio c:\windows\winsxs para comprobarlo), y en ocasiones estas trazas pueden interferir con futuras aplicaciones.

En entornos VDI, este comportamiento supone un dolor de cabeza adicional, ya que estas dificultades pueden obligarnos a tener que trabajar con múltiples imágenes maestras, cada una con la configuración necesaria, lo que puede convertirse en una auténtica pesadilla a la hora de actualizar copias maestras.

Tradicionalmente, soluciones como Citrix Metaframe (hoy XenApp) y Terminal services nos ayudaban en este problema: Desplegábamos la aplicación en los desktops mediante una sesión con el servidor que la hospedaba. Esto desplaza el “problema” a una ignota granja de servidores en donde los nunca totalmente considerados ingenieros Citrix/TS  toreaban el problema como buenamente podían (hay aplicaciones que deberían ser usadas como prueba de cargo en un juicio contra sus desarrolladores) la coexistencia. Muchas veces, para bien o para mal, no hay más remedio que añadir servidores a la granja.

Por otro lado, aparecieron soluciones basadas en el streaming de la aplicación al desktop bajo demanda. Este es el caso de SoftGrid (renombrada App-V tras ser adquirida por Microsoft). Softgrid actúa como servidor de los ejecutables y ficheros relacionados con las aplicaciones, desplegando su entorno completo de ejecución (aplicación, dlls y demás) en el cliente según fuera requerido.

Desafortunadamente, siempre hay aplicaciones, ya por diseño, ya por requerimientos, que no son susceptibles de ser desplegadas por este medio y siempre terminan instaladas en el PC local, o lo que es peor, en un VDI dedicado y personalizado (que requiere otra serie de medidas, como son el backup específico)

Frente a estas tecnologías, que desplazan de una u otra manera los problemas inherentes a la instalación de aplicaciones hacia el servidor, nace otra visión.

¿Qué una aplicación modifica el sistema? Pues usemos una capa de abstracción entre la aplicación y el sistema que recree los requerimientos específicos de la aplicación durante su ejecución y que estos desaparezcan al dejar de utilizar la misma. Es lo que normalmente es conocido como “virtualización de aplicaciones”, aunque yo veo más acertado denominarlo como “empaquetado del entorno de ejecución”.

Este método requiere de la ejecución de una delgada capa de software que recree el entorno que la aplicación instalada espera encontrar: dll, entradas de registro y modificaciones del filesystem.

Esta capa “aprende” las modificaciones durante el paso previo de la paquetización: es decir, la instalación de la aplicación se realiza sobre un sistema operativo “limpio” y es monitorizada por un aplicativo que toma una “foto” del sistema antes de la instalación y otra después, comparando ambos entornos. El diferencial se empaqueta en un archivo que, además de este, incluye la capa de software antes mencionada. Dependiendo del producto usado, el resultado será un ejecutable o un ejecutable más un archivo que contiene ese diferencial.

Cuando ejecutamos este, el Appvisor (llamemos así a la capa de abstracción del sistema operativo tal como lo hace el “hypervisor” del hardware) genera en base al contenido del archivo de imagen diferencial el entorno que la aplicación espera, y procede a ejecutarla. El AppVisor introduce conceptos como el registro virtual (lo que le permite añadir las entradas y configuraciones que la aplicación espera encontrar y/o espera escribir) y un sistema de ficheros virtual (donde la aplicación encuentra y/o escribe lo que espera encontrar y espera escribir). La suma de estos dos conceptos es lo que viene siendo llamado VOS o Virtual Operating System.

En lo referente al registro virtual, el appvisor simplemente “incrusta” las claves de registro que ha generado la aplicación de forma que esta pueda encontrarlas tal y como si estuviesen en el registro del sistema. En lo referente al filesystem, el appvisor hace algo parecido al chroot de unix: Cambia el path relativo del filesystem virtual a absoluto… es decir, si  ejecutamos nuestra aplicación virtual en c:\app\virtual\app1 y la aplicación fue instalada en c:\archivos de programa\app1, el hypervisor hace ese “chroot” para que la aplicación encuentre los ficheros que necesita (ejecutables, dll, etc) donde espera encontrarlos.

Como resumen, vaya esta gráfico:

Sin ánimo de entrar en polémicas sobre cuál de las aproximaciones descritas es la mejor, suena evidente el hecho de que esta última no requiere de servidores o infraestructura externa al propio desktop para ejecutar una aplicación virtual y así evitar el inconveniente de las instalaciones locales.

Modos de interacción con el sistema.

Adicionalmente, el appvisor suministra varios modos de interacción con el sistema que ejecuta la aplicación virtual, basadas en la permanencia de los cambios que está puede o no realizar en el sistema operativo donde se ejecuta.

Modo integrado: En este modo, los cambios que la aplicación haga tanto en el filesystem (en lo referente a archivos de datos generados por la misma, no por sus dll o ejecutables) se realizan en el sistema operativo real. Esto permite, por ejemplo, que se graben entradas de registro o ficheros de datos que permanecerán en sistema operativo tras cerrar la aplicación. En un ejemplo real, un Outlook virtualizado dejaría el PST en el disco duro del Windows donde lo ejecutemos. Así mismo, las modificaciones que la aplicación realice al sistema (ficheros o registro) quedarían plasmadas en el sistema. Por otro lado, la aplicación virtualizada tendría acceso a los archivos del sistema (Un Outlook virtualizado, por ejemplo, podría acceder a un documento existente para enviarlo como fichero adjunto). Si ese Outlook descargase un adjunto, podría hacerlo en el filesystem del sistema operativo.

Modo Mixto: En este modo, la app virtual tiene acceso de lectura al filesystem real, pero todos los cambios que realice en el mismo, sólo se reflejarán en el VOS. Por seguir el ejemplo del Outlook, este podrá adjuntar ficheros existentes, pero si descarga un adjunto, este se almacenará en el VOS. Lo mismo aplica a entradas de registro.

Modo aislado: En este modo la aplicación virtual no tiene visibilidad del sistema operativo.  Sólo podrá acceder a los archivos contenidos en el VOS. Los datos generados por la misma serán almacenados en el VOS. En este modo, el Outlook virtual no podría acceder a un documento previamente  almacenado en el disco del PC ni podría escribir en el mismo.

Veamos todo esto en una tabla resumen:

Modo	Visibilidad del sistema	Modificación de la app virtual	Modificación del sistema	Nuevos elementos
Mixto	Completa(*)	VOS	VOS	VOS
Integrado	Completa(*)	VOS	Sistema	Sistema
Aislado	No visible	VOS	No accesible	VOS

(*) En caso de coincidencia de un elemento en la aplicación virtual y en el sistema operativo, prevalece siempre el contenido del filesystem del VOS. Ejemplo Outlook: Si existe en el sistema la carpeta c:\attach y también existe en el VOS, prevalecerá el contenido de este último.

Cada producto implementa estas características con ligeras variaciones, pero básicamente todas las aproximaciones son similares.

VOS. ¿Cómo gestiona el filesystem?

Bien. Vamos a centrarnos en el sistema de ficheros.  Una aplicación “real”, es decir, instalada en el sistema operativo, toma como referencia la unidad lógica (nuestro C:, D: etc) del sistema donde se ejecuta para interacturar con los datos. Es decir… sabe que está instalada en c: o d: y que los datos han de ser guardados en estas unidades. En  lo referente a la instalación, este path suele ser inamovible: Si movemos la aplicación de c:\Program Files\app1 (que es donde la instalamos) a d:\program files\app2, lo más probable es que perdamos un par de horas en un académicamente instructivo per nada práctico paseo por el registro y por las utilidades de Windows para rendirnos horas más tarde. El appvisor “engaña” a la aplicación mostrándole una o varias unidades lógicas que, dependiendo del modo de empaquetado (ver tabla anterior) puede o no coincidir con las existentes en el sistema operativo real.  En modo integrado, por ejemplo, la aplicación modificará el fichero “c:\windows\system\readme.txt” en su localización original. En modo mixto, no podrá acceder a ese fichero, ya que el appvisor le “redirigirá” a la carpeta contenida en el VOS, y en modo aislado, no podrá acceder a ese fichero. El appvisor introduce un filtro que, dependiendo del modo, redirigirá hacia el sistema operativo real o a una carpeta que contiene el sistema operativo virtual. Esta localización variará dependiendo del modo y el producto. Veamos un gráfico.

Esta imagen ilustra un posible escenario aislado. Como puede observarse, la aplicación virtual al ser ejecutada e invocada por el appvisor, crea una estructura de directorios bajo la carpeta donde hayamos copiado el ejecutable (esto también puede variar) y despliega el filesystem virtual. A partir de ese momento, la app virtual verá el contenido de la carpeta VOS como el filesystem del sistema.

Esto nos permite, por ejemplo, llevarnos nuestro manido Outlook virtual (con sus pst) en un pen drive…. O colgarlo de una unidad de red. ¿No os parece que para VDI esta última posibilidad resulta de interés?

Jugando con los diferentes modos, conseguiremos mayor o menos visibilidad de los archivos generados por la app virtual desde otras aplicaciones (virtualizadas o no)

El lado oscuro.

Por supuesto, tiene sus contras. No todas las aplicaciones admiten ser virtualizadas, o requieren de especiales opciones de instalación o tuneo posterior del paquete para que funcionen. Los productos que requieren activación (especialmente los de Microsoft) suelen requerir de tunning específico.

Así mismo, cuidado con los updates. En muchos casos, actualizar una aplicación no puede ser delegado a su propio mecanismo de actualización y es posible que se requiera el despliegue de una nueva versión de la aplicación virtualizada. También el licenciamiento puede verse afectao, especialmente si no disponemos de licenciamiento enterprise (una sola key o activación para toda la compañía) y la aplicación pide esta durante el proceso de instalación (léase Office 2003 retail, por ejemplo).

Productos comerciales.

Tenemos los siguientes (hasta donde yo sé, claro).

•           Appzero
•           Argo Application installer
•           BoxedApp
•           Cameyo
•           InstallFree
•           JauntePE
•           Microsoft v-App (Modo standalone)
•           Ringcube MojoPack
•           Symantec Workspace Virtualization
•           VMware ThinApp
•           LanDesk Application Virtualization
•           MoleBox

Ya está bien por hoy. En el próximo post hablaré de la íntima relación entre la tecnología de desktop virtual y la virtualización de aplicaciones.