KIWI Image Builder Configurations
Dieses Repository enthält Konfigurationen zur Erstellung von angepassten Betriebssystem-Images mit dem KIWI Image Appliance Builder (KIWI-NG). Die fertigen Images werden automatisiert über eine CI/CD-Pipeline gebaut und direkt in ein Harvester-Cluster hochgeladen.
Repository-Struktur
├── .gitea/
│ └── workflows/
│ └── kiwi-build.yaml # Gitea Actions Workflow für Linting, Build und Deploy
├── opensuse-leap-16-minimal/
│ ├── Minimal.kiwi # KIWI-Bildbeschreibung (XML) mit Profilen und Paketen
│ └── config.sh # Konfigurationsskript für die Chroot-Phase des Builds
├── renovate.json # Konfiguration für den Renovate Bot
└── README.md # Dieses Dokument
Enthaltene Images
1. openSUSE Leap 16.0 Minimal (opensuse-leap-16-minimal)
Dieses Verzeichnis enthält die Konfiguration für ein minimales openSUSE Leap 16.0 Image. Es stehen zwei Profile zur Verfügung:
| Profil | Zielplattform | Dateisystem | Format | Firmware | Besonderheiten |
|---|---|---|---|---|---|
kvm-and-xen |
KVM & Xen Hypervisoren | btrfs |
qcow2 |
UEFI | Inklusive Snapper-Snapshots, Rollback-Helper, Firewalld und jeos-firstboot |
Cloud (Default in CI) |
Cloud-Umgebungen (z. B. Harvester) | xfs |
qcow2 |
UEFI | Inklusive cloud-init, qemu-guest-agent und optimierter serieller Konsole |
Wichtige Voreinstellungen in config.sh:
- Zeitzone & Keymap: Standardmäßig auf
Europe/Zurichund Tastaturlayoutuskonfiguriert. - Hostname: Voreingestellt auf
rke2-node. - Systemd Firstboot: Die Datei
/etc/machine-idwird aufuninitializedgesetzt, um systemd zu signalisieren, dass Firstboot-Presets ausgeführt werden sollen. - Dienste:
sshd,NetworkManager(falls vorhanden) undchronydwerden automatisch aktiviert. - Snapper (nur für
kvm-and-xen): Vorkonfiguriert ohne Timeline-Snapshots (TIMELINE_CREATE="no") und mit optimierten Limits für automatische Aufräumarbeiten. - Speicheroptimierung: Deaktivierung der Installation von Dokumentationen (
rpm.install.excludedocs = yes) sowie Deaktivierung von empfohlenen Paketen (solver.onlyRequires = true) in/etc/zypp/zypp.conf.
Lokales Bauen der Images
Um die Images lokal auf einem Linux-Host zu bauen, wird kiwi-ng benötigt.
Voraussetzungen
- Installiere KIWI-NG auf deinem Host-System:
# Auf openSUSE/SUSE sudo zypper in python3-kiwi - Stelle sicher, dass Virtualisierungsunterstützung und KVM aktiviert sind (KIWI nutzt intern chroot und mountet loop devices).
Build-Befehle
Führe den Build-Befehl im Root-Verzeichnis des Repositories aus:
KVM & Xen Profil (btrfs):
sudo kiwi-ng --profile kvm-and-xen system build \
--description ./opensuse-leap-16-minimal \
--target-dir ./build-kvm
Cloud Profil (xfs):
sudo kiwi-ng --profile Cloud system build \
--description ./opensuse-leap-16-minimal \
--target-dir ./build-cloud
Die fertigen .qcow2-Images und die Metadaten werden im angegebenen --target-dir abgelegt.
CI/CD Pipeline (Gitea Actions)
Das Repository ist für Gitea Actions vorkonfiguriert (.gitea/workflows/kiwi-build.yaml). Der Workflow läuft auf einem Runner mit dem Label kiwi-builder und wird bei Pushes/Pull-Requests auf main oder master sowie bei Tag-Pushes mit dem Muster v* gestartet. Er führt folgende Schritte aus:
- RNG Schema-Validierung (Linting):
Validiert die XML-Struktur von
Minimal.kiwigegen das offizielle KIWI-RNG-Schema (kiwi.rng), um Konfigurationsfehler vor dem Bauen zu vermeiden. - Build:
Baut das Image mit dem Profil
Cloudim privilegierten Docker-Container (registry.opensuse.org/opensuse/bci/kiwi:10). - Bundling: Paketiert die Ergebnisse und benennt sie passend zur kurzen Commit-SHA (Short-SHA).
- Upload Image Artifact: Archiviert das gebaute Image als Gitea-Artefakt mit der Short-SHA im Namen.
- Harvester-Upload:
Lädt das fertige Image über die Harvester REST API direkt in den Ziel-Namespace des Harvester-Clusters hoch. Wenn die Pipeline durch einen Tag-Push gestartet wurde, entspricht der Image-Name dem Tag-Namen (z. B.
leap-16-minimal-v1.0.0), ansonsten wird die Short-SHA verwendet. - Gitea-Release-Erstellung (nur bei Tag-Pushes):
Wenn der Push einen Git-Tag (z. B.
v1.0.0) betrifft, wird automatisch ein Gitea-Release erstellt und das Image-File aus./dist/*als Release-Asset angehängt.
Erforderliche Secrets für die Pipeline:
HARVESTER_TOKEN: API-Token zur Authentifizierung am Harvester-Cluster.
Die Gitea-Release-Erstellung nutzt das standardmäßig bereitgestellte GITHUB_TOKEN. Die Cluster-URL für Harvester ist im Workflow als https://harvester.ui hinterlegt.
Updates & Dependency Management
Dieses Repository verwendet Renovate, um Paketquellen, Basis-Images und GitHub-Aktionen automatisch auf dem neuesten Stand zu halten. Die Steuerung erfolgt über die Datei renovate.json.