PDF de programación - infraestructura distribuida para la construcción de paquetes Debian

INFRAESTRUCTURA DISTRIBUIDA PARA LA CONSTRUCCIÓN DE

PAQUETES DEBIAN

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA

INGENIERÍA

EN INFORMÁTICA

PROYECTO FIN DE CARRERA

Infraestructura distribuida para la construcción de paquetes

Debian

José Luis Sanroma Tato

Septiembre, 2014

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA

Departamento de Tecnologías y Sistemas de Información

PROYECTO FIN DE CARRERA

Infraestructura distribuida para la construcción de paquetes

Debian

Autor:
Director: Dr. Francisco Moya Fernández

José Luis Sanroma Tato

Septiembre, 2014

José Luis Sanroma Tato

Ciudad Real – Spain
E-mail:
[email protected]
Web site: http://www.icebuilder.org
c(cid:13) 2014 José Luis Sanroma Tato
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.

TRIBUNAL:

Presidente:

Secretario:

Vocal:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE

SECRETARIO

VOCAL

Fdo.:

Fdo.:

Fdo.:

Resumen

Desde hace algunos años, empresas, universidades, grupos de investigación, o similares,
que se dedican al desarrollo de software, desarrollan sus propios paquetes que posteriormente
son usados por sus propios trabajadores o clientes. Estos paquetes de software (como todo
software), necesitan ser servidos, mantenidos y actualizados de alguna forma. Para ello se
usan repositorios. En el caso del Software Libre, una de las opciones es utilizar repositorios
no oficiales de Debian que gestionan paquetes Debian. Estos repositorios no oficiales pueden
crearse con la ayuda de reprepro que permite al usuario crear un repositorio personal con
todas las características de uno oficial.

En lugares como el Laboratorio de investigación ARCO de la Escuela Superior de Infor-
mática de la Universidad de Castilla-La Mancha, existen computadores de diferentes arqui-
tecturas debido a la renovación que van sufriendo los equipos con el paso del tiempo. Por
ello, un problema típico que existe es la construcción de un paquete, por ejemplo, con arqui-
tectura amd64. En el momento que se sube al repositorio, sucederá que a este paquete solo
podrán acceder los usuarios de amd64. Si un usuario de i386 quiere acceder a ese paquete,
tiene que conseguir el código fuente, construirlo y volver a subir el paquete al repositorio.
Por lo tanto, es un requisito contar con al menos un computador con esa arquitectura que
pueda utilizarse para construir el paquete y que ese usuario, o alguien que sepa hacerlo, se
dedique a construirlo usando ese computador u otro con la misma arquitectura. Con lo cual
existe una necesidad, y es tener una versión de los paquetes compatible con cada una de las
arquitecturas soportadas en el laboratorio para que pueda ser usada por los trabajadores.

Aunque lo ideal sería tener una infraestructura dedicada con al menos un computador de
cada una de las arquitecturas soportadas, en pequeños entornos de trabajo como el laboratorio
ARCO, llegamos al primer problema, y es que existen recursos limitados y esto no es posible
debido a que:

No se dispone de computadores con el propósito de estar disponibles y dedicados para
construir paquetes.
Los computadores con los que se cuenta podrían no estar siempre disponibles cuando
se necesiten para realizar la construcción, bien por estar apagados, bien por estar siendo
usados por los trabajadores o cualquier otra circunstancia. Por lo tanto no se puede
saber en que instante va a haber un computador disponible.

Algunas veces los usuarios pueden necesitar características que están solamente presentes
en la rama unstable o incluso experimental. Por ejemplo un programador de la biblioteca
Orca puede necesitar la versión más actual del paquete ZeroC Ice pero no tiene la necesi-
dad de actualizar todo el sistema a unstable. Actualmente los usuarios usan apt-pinning para
solucionar el problema, pero puede llevar a actualizaciones de paquetes críticos(libc, biblio-
tecas de tiempo de ejecución de C++) y los binarios pueden acabar enlazados con diferentes
versiones de una misma biblioteca. A menudo, los debian developers vuelven a construir

XI

el paquete desde el código fuente de unstable o experimental en un entorno pbuilder para
stable y crean repositorios personalizados.

La Debian Autbuilder Network es la infraestructura dedicada de Debian que se encarga
tanto de la construcción de paquetes para distintas arquitecturas, como de la distribución de
los paquetes a cada uno de los repositorios oficiales de las distintas arquitecturas soportadas
por la distribución. Está compuesta por varias máquinas que utilizan buildd para recoger los
paquetes del archivo de Debian y reconstruirlos.

Esta infraestructura funciona muy bien en Debian porque tienen máquinas dedicadas úni-
ca y exclusivamente a la construcción de paquetes para servirlos en los repositorios oficiales,
siguiendo la política de Debian, y además, tienen unas herramientas (como wanna-build,
buildd, sbuild y quinn-diff ) hechas por y para la infraestructura de Debian. Pero esta in-
fraestructura es difícil de configurar, excede las necesidades de los pequeños entornos (co-
mentadas al principio) y además éstos, requieren de otras necesidades distintas que no se
contemplan aquí debido a que no se dispone de los mismos recursos o porque la política de
la empresa tiene otras necesidades. Por lo tanto, en este caso buildd no cumple con las nece-
sidades y no nos sirve. Se necesita otra infraestructura que sí cumpla con las necesidades de
ARCO y es por lo que se propone este proyecto.

Para dar solución a estos problemas, este proyecto se ha ido desarrollando cumpliendo una

serie de objetivos que cubren las necesidades listadas anteriormente:

Diseño de una arquitectura distribuida P2P para donar ciclos de CPU, construcción de
paquetes Debian, construcción compartida en un entorno dado y monitorización del
proceso, además de ofrecer balanceo de carga y transparencia de localización para sa-
ber qué computadores están encendidos, y destinar la construcción de paquetes Debian
a aquellos computadores que tengan menos carga de CPU.
Desarrollo de nodos de construcción, que harán de entornos limpios, basados en má-
quinas virtuales en lugar de entornos chroot para facilitar la disponibilidad de los re-
cursos (la construcción de paquetes se puede parar, reanudar o migrar a otro nodo
compatible). Además, un único computador puede ejecutar varios nodos con el fin de
construir paquetes para distintas arquitecturas.
Implementación de construcción de paquetes mediante transacciones, que gracias ellas,
el sistema puede recuperarse frente a fallos tanto intencionados (cuando un trabajador
termina su jornada laboral y apaga su equipo) como no intencionados (como apagones
de luz).
Repositorios backports personalizados impulsados por las necesidades de los usuarios
en lugar de la política de Debian.

Abstract

Long time ago, companies, universities, research groups, that dedicates to software de-
velopment develops their own packages which later are used by their own workers or cus-
tomers. These software packages as all software needs to be maintained, used and updated
somehow, for this pourpose repositories can be used. In the case of Free Software, and in
the case that I am going to present, one of the options is to use non-offiial Debian reposito-
rioes which manages Debian packages. These non-official repositories can be created with
the help of reprepro, which allows the user to create a personal repository with the official
one features.

At some places as ARCO research lab of the computer science faculty of University of
Castilla-La Mancha, computers of differents architectures exists due to the undergoing reno-
vation over time. Thereby, a typical problem is when someone built a package, for example
with amd64 architecture, then is uploaded to the repository, and happens that this package
is only available for amd64 users. If an i386 user wants to accesss to the package, he has
to get the source code, built it and upload again the package to the repository. Therefore,
one requirement is have at least one computer with that architecture which can be used to
compile the package and that user, or someone who knows how to do it, compile it using that
computer or another one with the same architecture.

Although ideally would be have an infrastructure dedicated with at least one computer of
each architecture supported by the lab, in small workplaces as ARCO research lab, we reach
to the first problem, there are limited resources and this is not posible due to:

No computers are available in order to be available and dedicated to compiling packa-
ges.
Computers which we count with may not always be available when they are nedded
for the compilation, because they are turned off or because they can being used by
workers or anything else.

Sometimes users may require certain features which are only present in unstable or even
in experimental. For example, a developer of the Orca library may require a bleeding edge
ZeroC Ice package but there is no need to