Git in CI/CD: Verständnis für angehende Linux Sysadmins

Inhaltsverzeichnis

Warum du Git in CI/CD als angehender Sysadmin kennen solltest

Als angehender Systemadministrator auf Linux-Systemen lernst du schnell, dass Softwarebetreibung – also das Verwalten, Aktualisieren und Bereitstellen von Anwendungen – nicht mehr manuell erfolgt, sondern automatisiert werden muss. Git ist ein Versionskontrollsystem, das die Historie von Dateien wie Code oder Konfigurationsdateien trackt, und es spielt eine zentrale Rolle in CI/CD, was für Continuous Integration/Continuous Delivery steht: Continuous Integration bedeutet, dass Code-Änderungen häufig in einen gemeinsamen Codebestand integriert werden, um Konflikte früh zu erkennen, während Continuous Delivery den automatisierten Prozess bis zur Bereitstellung für den Produktionsbetrieb beschreibt. Du solltest das wissen, weil in der Softwarebetreibung Git als Auslöser für automatisierte Tests und Deploys dient, was auf Linux-Servern läuft und deine täglichen Aufgaben wie Paket-Management oder Service-Neustarts revolutioniert – genau die Skills, die du in RHCSA-Umgebungen brauchst, um von manueller Wartung zu DevOps zu wechseln.

Grundlagen von Git: Dein Einstieg in die Versionskontrolle

Git ist ein dezentrales Versionskontrollsystem, das von Linus Torvalds für die Linux-Kernel-Entwicklung entwickelt wurde und lokal auf deinem Linux-System installierst du es mit einem Paketmanager wie dnf oder apt. Es speichert Änderungen in einem Repository (Repo), einer Ordnerstruktur mit versteckten .git-Unterordnern, die die gesamte Historie inklusive Commits – das sind Snapshots von Änderungen mit Nachrichten – halten. Branches sind parallele Versionen des Codes, z. B. main für stabile Software und feature-branch für neue Funktionen, die du mit git checkout erstellst und mergst, um Konflikte zu lösen.

In der Softwarebetreibung nutzt du Git, um Konfigurationsdateien wie /etc/nginx.conf zu versionieren: Jede Änderung wird committed, getaggt für Releases und remote auf Servern wie GitHub oder GitLab gepusht. Pull Requests (PRs) sind Anfragen, Code zu überprüfen, bevor er integriert wird – essenziell, um Fehler in der Produktion zu vermeiden. Das macht Git zur Basis für reproduzierbare Deployments auf Linux, wo du als Sysadmin Repos klonst und ziehst.

Wie Git nahtlos mit CI/CD-Pipelines zusammenarbeitet

CI/CD-Pipelines sind automatisierte Workflows, die in Dateien wie .gitlab-ci.yml oder .github/workflows/ci.yml definiert werden und im selben Git-Repo liegen – Git triggert sie also selbst. Bei einem git push oder PR wird ein Webhook, eine HTTP-Benachrichtigung, an den CI/CD-Server gesendet, der den Code klont (git clone), baut (z. B. mit make oder npm build), testet (Unit-Tests prüfen Funktionen, Integrationstests simulieren Umgebungen) und Artefakte wie Docker-Images speichert.

Stages gliedern den Prozess: Build erstellt Binaries, Test führt automatisierte Skripte aus, Deploy rollt auf Staging- oder Prod-Server aus – alles idempotent, d. h. wiederholbar ohne Nebenwirkungen. Tools wie Jenkins (Java-basiert, läuft als Service auf Linux), GitLab CI (integriert) oder GitHub Actions (cloudbasiert) interpretieren YAML-Dateien aus Git und führen Jobs auf Runners aus, virtuellen Maschinen oder Containern. In der Softwarebetreibung bedeutet das: Du pusht eine Konfig-Änderung, Git löst Tests aus, und bei Erfolg deployt es automatisch.

Als Beispiel: Du erstellst einen Branch git checkout -b fix-bug, änderst Code, committest git commit -m "Fix nginx config", pusht und öffnest einen PR. Der Pipeline-Runner testet auf Linux mit docker run und merged automatisch in main, wenn grün.

Die entscheidende Rolle von Linux und Sysadmins in diesem Ökosystem

Linux ist die dominante Plattform für CI/CD, weil es open-source, ressourcenschonend und mit Tools wie Bash (Shell-Skripting für Automatisierung), systemd (Service-Management) und iptables/firewalld (Netzwerksicherheit) ausgestattet ist. Container wie Docker – leichte VMs, die Anwendungen isolieren – und Orchestratoren wie Kubernetes (K8s, managt Container-Clusters) laufen nativ auf Linux-Kernel-Features wie cgroups und namespaces, die Ressourcen und Isolation handhaben.

Als angehender Linux Sysadmin managst du die Infrastruktur: Du provisionierst Runner mit Ansible (Konfigurationsmanagement-Tool, pusht YAML-Playbooks via Git), skalierst mit systemd-timesyncd für Zeit-Sync und monitorst mit Prometheus/Grafana. Secrets wie API-Keys speicherst du verschlüsselt in Git (mit git-crypt oder Tools wie Vault), und RBAC (Role-Based Access Control) schützt Zugriffe. Deine RHCSA-Skills in User-Management (useradd, sudo), Storage (LVM, ext4) und Networking (ss, ip route) machen dich zum DevOps-Enabler: Du sicherst Pipelines gegen Injection-Angriffe und optimierst CPU/Memory für schnelle Builds.

In der Praxis hostest du Jenkins auf einem RHEL-Server: Installierst via dnf, konfigurierst Plugins aus Git, und lässt Pipelines Docker-Images bauen, die du mit podman (rootless Docker-Alternative) pusht – alles git-triggered.

Zusammenfassung

Git versioniert Code und Konfigurationen in Repos mit Branches und Commits, triggert via Webhooks CI/CD-Pipelines, die auf Linux-Runners Builds, Tests und Deploys automatisieren, und wandelt Softwarebetreibung von manuellen Schritten in reproduzierbare Workflows um. Als angehender Sysadmin bringst du Linux-Kenntnisse in Scripting, Container, Security und Automatisierung ein, um diese Pipelines zu hosten, zu skalieren und zu sichern, was dich von klassischem Admin zu DevOps-Profi macht. Mit Tools wie Docker, Kubernetes und Ansible aus Git-Repos wird dein Alltag effizienter, fehlerresistenter und zukunftssicher.

Fediverse reactions

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Andreas Moor
Andreas Moor
@blog@andreas-moor.de

Hallo Fediverse, ich bin Andy!

Hier und auf meiner Website findest du mein akkumuliertes Linux-Sysadmin-Wissen, meine kleinen und größeren Projekte und die Tools, die ich nutze.

Viel Spaß beim stöbern, lesen und lernen! 🧑‍💻

217 Beiträge
10 Folgende