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.
