Erstellen eines Ubuntu-Kernels mit GitHub & Actions

Es ist für jeden DevOps-Experten wichtig, auf dem neuesten Stand der Kernel-Entwicklung zu sein. Canonical, das Kraftpaket hinter Ubuntu, verfolgt die Entwicklung des Mainline-Kernels über das Mainline-Crack Git-Repository. In diesem Blogbeitrag untersuchen wir den Aufbau einer effizienten GitHub-Actions-Pipeline, die den Build-Prozess und die Verteilung von Ubuntu-Kernel-Deb-Paketen automatisiert.

Canonical bietet ein praktisches Debian/Rules-Makefile, das die Erstellung des Ubuntu-Kernels vereinfacht. Dieses Makefile ist das wichtigste Tool, das wir in unserem Beispiel verwenden. Um mehr über debian/rules zu erfahren, lesen Sie die debmake-doc.

Überblick über die CI-Pipeline

Die Pipeline umfasst zwei Hauptaufgaben: Einen Build erstellen und diesen veröffentlichen. Der Build-Job wird in einem benutzerdefinierten Docker-Container mit dem Namen custom-linux-builder-jammy:latest ausgeführt, der auf Ubuntu 22.04 basiert und mit allen notwendigen Abhängigkeiten für die Ubuntu-Kernelkompilierung ausgestattet ist. Der Publish-Job, der vom Build-Job abhängt, ist für die Bereitstellung der erzeugten Pakete in einem Repository verantwortlich.

Beginnen wir mit dem Überblick über die gesamte CI-Pipeline:

Name: CI on: [push, workflow_dispatch]   jobs:   build: 	runs-on: [ubuntu-22-04, x64, heavy, self-hosted] 	container: custom-linux-builder-jammy:latest 	steps:   	- uses: actions/checkout@v3     	- name: Cleanup     	run: |       	debian/rules clean       	rm -rf ../*.deb /packages     	- name: Dependencies     	run: |       	apt-get update && \       	mk-build-deps \         	--tool 'apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends --yes' \         	--install --remove debian/control     	- name: Build     	run: |       	debian/rules do_tools=true binary-generic binary       	mkdir /packages && cp -f ../*deb /packages/.     	- uses: actions/upload-artifact@v3     	with:       	name: linux_package       	path: /packages/     publish: 	runs-on: [self-hosted, ubuntu-22-04] 	needs: [build] 	steps:   	- name: Get Secrets     	uses: hashicorp/vault-action@v2.4.1     	id: secrets     	with:       	url: <VAULT_INSTANCE_URL>       	token: ${{ secrets.VAULT_TOKEN }}       	secrets: |         	<PATH_TO_PRIVATE_KEY>| key ;     	- uses: actions/download-artifact@v3     	with:       	name: linux_package     	- name: Send to Repo     	uses: appleboy/scp-action@master     	with:       	host: <REPOSITORY_URL>       	username: <REPOSITORY_USERNAME>       	key: ${{ steps.secrets.outputs.key }}       	port: <PORT_NUMBER>       	source: "*.deb"       	target: <PATH_IN_REPOSITORY>

Im Detail

Lassen Sie uns in die Tiefe gehen und die GitHub-Actions-Pipeline im Detail betrachten.

Build-Phase

Die Build-Phase ist das Herzstück der Pipeline und ist für die Kompilierung und Verpackung des Ubuntu-Kernels verantwortlich. Die Pipeline verwendet das Docker-Image custom-linux-builder-jammy:latest, das auf Ubuntu 22.04 basiert und alle notwendigen Abhängigkeiten für die Erstellung des Ubuntu-Kernels enthält.

Checkout

Der Schritt actions/checkout@v3 sorgt dafür, dass die Pipeline mit der neuesten Version der Codebasis arbeitet. Das bedeutet, dass alle aktuellen Überarbeitungen in den Build eingearbeitet werden.

Cleanup (Bereinigung)

Der Cleanup-Schritt entfernt alle Reste aus früheren Arbeitsabläufen. Er bereinigt den Quellbaum und entfernt alle übrig gebliebenen .deb-Pakete aus früheren Builds, sodass Sie ganz neu beginnen können. Hier sind die relevanten Befehle:

debian/rules clean rm -rf ../*.deb

Dependencies (Abhängigkeiten)

Der Dependencies-Schritt bereitet die in debian/control aufgeführten Abhängigkeiten vor und installiert sie. Es sorgt dafür, dass die Build-Umgebung über alle benötigten Tools und Abhängigkeiten verfügt, bevor sie mit der Kernelkompilierung beginnt. Der Code für diesen Schritt lautet wie folgt:

apt-get update && \ mk-build-deps \   --tool 'apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends --yes' \   --install --remove debian/control

Build

debian/rules do_tools=true binary-generic binary mkdir /packages && cp -f ../*deb /packages/.

Der Build-Schritt umfasst die eigentliche Kompilierung und Verpackung des Ubuntu-Kernels. Er führt das Skript mit den angegebenen Parametern aus, einschließlich , und .

Die Reihenfolge dieser Ziele ist wichtig. Der Parameter aktiviert die Erstellung der gängigen Linux-Tools (bpftool, cpupower, perf, etc.) wird zuerst ausgeführt, sodass das binary-Ziel die Ergebnisse von nutzen kann.

Sobald der Build abgeschlossen ist, werden die resultierenden Debian-Pakete im übergeordneten Verzeichnis (../) gespeichert und dann zur späteren Verwendung in das Verzeichnis /packages kopiert.

Upload Artifact (Artefakt-Upload)

Nachdem der Build erfolgreich abgeschlossen wurde, übernimmt der Schritt actions/upload-artifact@v3 und lädt die neu generierten Debian-Pakete als Artefakt namens „linux_package“ hoch. Damit ist die letzte Phase eingeleitet, der Publish-Job.

Publish (Veröffentlichen)

Die letzte Stufe in unserer Pipeline ist der Publish-Job. Dieser Job lädt die zuvor erstellten Kernel-Pakete in das Repository hoch. Die Schritte sind relativ einfach:

1. Secrets sichern: Zunächst verwenden wir , um Secrets aus einer HashiCorp-Vault-Instanz zu holen. So erhalten Sie sicheren Zugriff auf die Ressourcen, die Sie für die nächsten Schritte dieses Jobs benötigen.
2. Artefakt abrufen: Dieser Schritt ruft das Artefakt ab, das durch den vorherigen Build-Job über erzeugt wurde.
3. Deployment ins Repository: Dieser Schritt verwendet , um die Debian-Pakete sicher in das gewünschte entfernte Repository zu übertragen.

Mit diesen Schritten im Publish-Job werden die Ubuntu-Kernel-Deb-Pakete erfolgreich in das angegebene Repository hochgeladen, was einen einfachen Zugriff und eine effiziente Verteilung gewährleistet.

Fazit

Mit dieser einfachen GitHub-Actions-Pipeline wird das Erstellen (Build) und Veröffentlichen (Publish) von Ubuntu-Kerneln zu einem automatisierten und effizienten Prozess, bei dem das Risiko menschlicher Fehler geringer ist. Wir hoffen, dass dieser Leitfaden Ihnen hilft, Ihre DevOps-Prozesse zu rationalisieren und Ihre Produktivität zu steigern!