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!