• No results found

Member Cluster Participation Pattern Mining

Chapter 5 Temporal Ensemble Analysis

5.7 Member Cluster Participation Pattern Mining

2.4.1. Bootstrapping

La creación de un sistema operativo desde cero implica de forma inherente el llevar a cabo un proceso de bootstrapping. En este contexto, este término se refiere a la técnica utilizada para obtener una imagen de base funcional de un sistema operativo partiendo de sus componentes disponibles, y en el caso específico de los basados en Debian GNU/Linux, estos componentes se encuentran en los paquetes publicados en algún repositorio. Hacer bootstrapping a este tipo de sistema operativo requiere descargar los paquetes necesarios, descomprimir su contenido en un sistema de archivos seleccionado, configurar los programas, y arrancar el sistema operativo de

nueva creación utilizando como directorio raíz al sistema de archivos seleccionado. Las distribuciones basadas en Debian se pueden apoyar en un script existente para realizar esta tarea:

debootstrap. Construir paquetes para cierta distribución requiere la utilización de la distribución de destino como entorno de generación, lo que significa que es necesario crear una imagen base de la distribución destino para basarse en ella en el sistema operativo hospedero donde los nodos esclavos están en ejecución.

Existen dos tipos de bootstrapping presente en el proceso de construcción. Uno es el

boostrapping básico intra-distribución que es básicamente el procedimiento descrito antes. Este proceso sólo es posible si los paquetes binarios necesarios para crear la imagen base ya existen. Para la creación de un sistema operativo completamente desde cero, con sólo el código fuente disponible al principio, es necesario utilizar previamente otro sistema operativo como imagen base para construir los paquetes esenciales del sistema operativo destino. Esto puede ser calificado como

bootstrapping cross-distribución, y es una de las principales características distintivas de este sistema de construcción.

2.4.2. Construcción individual de un paquete en el nodo esclavo

Para la construcción de un paquete en específico se ha decidido utilizar pbuilder, herramienta estudiada durante la revisión del estado del arte para la presente investigación. Esta utilidad se basa en muchas otras herramientas como chroot, debootstrap, apt y dpkg para la construcción de un sistema base, así como para la actualización y mantenimiento del mismo. Sobre dicho sistema es capaz de instalar las dependencias de construcción de cualquier paquete y llevar a cabo el proceso de construcción del mismo para las arquitecturas de hardware soportadas por el nodo de compilación. En concreto, pbuilder utiliza debootstrap para crear un sistema base en un directorio a partir de los repositorios que se le especifiquen por línea de comandos, usa chroot para cambiar la raíz del sistema de archivos del proceso hacia este directorio, y luego utiliza las distintas funcionalidades que brindan apt y dpkg para la instalación y construcción de paquetes. Además,

pbuilder permite hacer “dist-upgrade” invocando una de sus opciones por línea de comandos, funcionalidad clave para poder lograr realizar el bootstrapping cross-distribución que caracterizará a este nuevo sistema.

2.4.3. Arquitectura de un nodo esclavo

En los nodos esclavos se implementa una arquitectura de múltiples capas. La capa más baja es la capa de herramientas, que es responsable de llamar a las distintas herramientas por línea de comandos necesarias para administrar el sistema de archivos que se utiliza para el bootstrapping

(también conocido como chroot o una imagen base); para gestionar los paquetes, ya sea en su instalación, remoción o construcción; para gestionar repositorios y otras tareas de "bajo nivel". La capa intermedia contiene la lógica de negocio que define los algoritmos que guían el proceso de construcción de paquetes. La capa superior o capa de presentación está orientada a la comunicación con otras aplicaciones, pues el demonio que se ejecuta en los nodos esclavos está destinado a ser ejecutado bajo demanda por el demonio del nodo principal, mientras tanto, no necesita estar en ejecución. Esto se logra en el demonio esclavo al registrarlo como un servicio D-Bus y mediante la publicación de una interfaz que puede ser invocada por una aplicación remota debidamente autenticada en la sesión de usuario del sistema, donde el demonio esclavo se ejecutaría. A través de D-Bus es posible enviar mensajes al demonio esclavo para comenzar a realizar su tarea de construcción de paquetes y para comprobar su estado. En la figura 1 se puede ver una representación de la arquitectura del nodo esclavo así como las tecnologías que se utilizan en cada capa.

2.4.4. Clases principales en un nodo esclavo

En el Anexo III se muestra el diagrama de clases de un nodo esclavo. A simple vista se pueden apreciar tres clases principales, cada una enmarcada en una de las capas de la aplicación. Estas son:

• PBuilder: la clase que se encuentra en la capa más baja, en la capa de herramientas. Esta envuelve a la herramienta pbuilder, actuando como una interfaz que permite invocar a las funcionalidades de esta desde la capa de negocios a través de la llamada a sus métodos. • Builder: la clase que contiene toda la lógica del negocio de los nodos esclavos y que actúa

como clase controladora del proceso de compilación en los mismos. Sus métodos proveen todas las funcionalidades necesarias que el nodo máster puede necesitar para mandar a construir un paquete.

• DBusBuilder: la clase que conforma la capa de presentación. Su objetivo consiste en exportar los métodos de la clase Builder a través de D-Bus, de forma que puedan ser invocados remotamente desde el nodo máster.

Otras clases útiles que se observan en el diagrama de clases se utilizan fundamentalmente para el pase de información entre las capas. PBuilderConfig permite transferir información de configuración entre Builder y PBuilder, la clase Capabilities permite transferir información del hardware del nodo entre Builder y DBusBuilder, y esta última se encarga de enviar y recibir objetos equivalentes a instancias de Capabilities, pero de la clase DBusCapabilities compatible con D-Bus, hacia y desde el proceso que se encuentra corriendo en el nodo máster.

Related documents