MxOS/ansible-koji
SHA256
Watch
6
0
Fork
You've already forked ansible-koji
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat: deploy Caddy repository server for BaseOS packages

Browse source 
- Provision cs10-repo.mx-os VM with 500 GB system disk using OpenTofu.
- Create and apply Ansible role to install and configure Caddy to serve /srv/repo/.
- Update Koji Hub export script to rsync signed binary RPMs to the repo server and trigger createrepo_c.
- Record ADR-05 detailing this design decision and update package compilation guide.
- Log progress in the project journal.

Co-developed-by: Gemini AI <renich+gemini@woralelandia.com>
Signed-off-by: Rénich Bon Ćirić <renich@woralelandia.com>
This commit is contained in:
Rénich Bon Ćirić 2026-06-16 16:10:32 -06:00
commit c290878c96
Signed by: renich
GPG key ID: AB2A9F49384FE324
9 changed files with 243 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

31
docs/technical/decisiones/2026-06-16-05-bootstrap_orden_y_exportacion_forgejo.rst → docs/technical/decisiones/2026-06-16-05-bootstrap_orden_y_servidor_caddy.rst
View file

@ -1,6 +1,6 @@
====================================================================
ADR 2026-06-16-05: Orden de Bootstrap y Exportación al Registro Forgejo
====================================================================
=====================================================================
ADR 2026-06-16-05: Orden de Bootstrap y Servidor de Repositorio Caddy
=====================================================================
Estatus
-------
@ -13,7 +13,7 @@ Contexto
Para iniciar la compilación masiva de CentOS Stream 10 BaseOS en el entorno Koji de MxOS, necesitamos resolver dos desafíos clave:
1. **Orden de Bootstrap**: La compilación en Koji requiere un orden estructurado para evitar fallos masivos por dependencias faltantes. Aunque Koji puede utilizar repositorios externos como semilla para resolver las dependencias iniciales, determinar el orden de dependencias internas de la distribución nos permite estructurar la compilación y rastrear el progreso de forma determinista.
2. **Exportación al Registro Final**: Una vez que Koji compila y firma los paquetes (mediante el spooler de firma integrado), estos RPMs firmados deben ser exportados al repositorio de producción oficial, que es el Registro de Paquetes de Forgejo (Forgejo Package Registry) en ``git.mx-os.mx/api/packages/RPMs/rpm``.
2. **Exportación al Registro Final**: Una vez que Koji compila y firma los paquetes (mediante el spooler de firma integrado), estos RPMs firmados deben ser exportados al repositorio de producción oficial, haciéndolos disponibles para consumo mediante DNF. Inicialmente se consideró el Registro de Paquetes de Forgejo, pero debido al volumen masivo de paquetes y la necesidad de una sincronización ágil y ligera, se optó por desplegar un servidor de repositorio independiente.
Decisión
--------
@ -29,19 +29,24 @@ Adoptaremos la siguiente estrategia técnica:
2. **Automatización de Compilaciones**:
* El script de orquestación (``bootstrap-baseos.py``) en el Koji Hub controlará y enviará las tareas de compilación respetando la concurrencia y siguiendo el orden determinista obtenido.
3. **Exportación Automatizada a Forgejo**:
* Escribimos y desplegamos el script de exportación ``/root/export-koji-to-forgejo.py`` en el Koji Hub.
* Este script utiliza el API de Koji para listar todas las compilaciones completadas bajo el tag ``mxos0``, busca sus RPMs correspondientes en `/mnt/koji/packages/`, y los sube mediante peticiones HTTP PUT al API de Forgejo utilizando el token del usuario ``renich`` (almacenado localmente de forma segura en las llaves del CLI de Forgejo).
* El script filtra los archivos ``.src.rpm`` y los paquetes con sufijos ``debuginfo`` y ``debugsource``, subiendo únicamente los RPMs binarios finales con sus firmas GPG incrustadas.
* Se implementa un manejo transparente de conflictos HTTP 409 (Conflict) para ignorar paquetes que ya existen en el registro.
3. **Servidor de Repositorio Dedicado con Caddy**:
* Provisionamos una máquina virtual dedicada ``cs10-repo.mx-os`` mediante OpenTofu con un disco virtual del sistema redimensionado a 500 GB de capacidad.
* Automatizamos la instalación de Caddy, la configuración de firewalld para HTTP (puerto 80) y la creación del directorio ``/srv/repo/`` mediante el rol de Ansible ``caddy``.
* Caddy está configurado para servir y permitir el listado de este directorio (``file_server browse``), actuando como nuestro servidor de repositorio oficial.
4. **Exportación y Sincronización Automatizada vía Rsync**:
* Escribimos y desplegamos el script de exportación ``/root/export-koji-to-repo.py`` en el Koji Hub.
* Este script utiliza el API de Koji para listar todas las compilaciones completadas bajo el tag ``mxos0``, busca sus RPMs correspondientes en `/mnt/koji/packages/`, y los sincroniza mediante ``rsync`` al directorio ``/srv/repo/`` en ``cs10-repo.mx-os`` utilizando la llave SSH del usuario root de Koji Hub (previamente autorizada en el servidor de repositorio).
* El script filtra los archivos ``.src.rpm`` y los paquetes con sufijos ``debuginfo`` y ``debugsource``, exportando únicamente los RPMs binarios firmados.
* Tras la sincronización, el script ejecuta de forma remota el comando ``createrepo_c /srv/repo`` en el servidor de repositorios para regenerar los metadatos de DNF en caliente.
Consecuencias
-------------
* **Positivas**:
* Orden de compilación de bootstrap 100% determinista basado en el estado real de los metadatos de CentOS Stream 10.
* Flujo de trabajo automatizado y continuo que firma y publica los paquetes completados en el registro público de Forgejo, haciéndolos disponibles de inmediato para DNF.
* Aislamiento de paquetes debug y fuentes para no contaminar el repositorio binario de consumo.
* Servidor de repositorio dedicado ligero y rápido de 500 GB que puede servir de manera escalable los metadatos y RPMs de la distribución sin depender del registro de Forgejo.
* Uso de ``rsync`` para sincronizaciones súper eficientes que minimizan el tráfico y tiempo de red al omitir transferencias redundantes.
* Regeneración automática de metadatos de DNF mediante ``createrepo_c`` en caliente tras cada sincronización.
* **Negativas / Desafíos**:
* La compilación inicial del ciclo principal (SCC core de 225 paquetes) tardará tiempo significativo y consumirá recursos de buildroot debido a la naturaleza iterativa del bootstrap.
* Requiere el mantenimiento de una VM adicional y su servicio Caddy.