Jenkins lokal aus dem Hetzner-Snapshot

01 Wo alles steht

Der Ist-Zustand nach dem Umzug – damit die restlichen Abschnitte konkret sind.

02 Warum lokal

Ein zweiter Server für ein Projekt mit gelegentlichen Deploys ist Overhead.

Auf Hetzner lief ein cpx42 (~0,10 €/h) plus die Firewall-Choreografie, die der Pipeline Zugriff auf die OKD-API verschafft (jenkins.ps1 trägt die Server-IP bei jedem up in okd-sno-fw:6443 ein und bei down wieder aus). Für den aktuellen Bedarf reicht ein Jenkins in der ohnehin laufenden podman-machine.

Der Hetzner-Weg bleibt erhalten: jenkins.ps1 up baut den Server aus dem Snapshot in ~95 s wieder auf. Der Snapshot ist die Rückfahrkarte, jenkins.ps1 destroy verbrennt sie.

03 Wie der Stand rüberkam

„Weg B“: den laufenden Stand aus dem Server ziehen statt neu aufzusetzen. Nachbaubar, falls es nochmal nötig wird.

1. Container stoppen für eine konsistente Kopie.

ssh root@<jenkins-ip> "podman stop -t 30 jenkins"

2. /opt/jenkins-home als Tar ziehen – 750 MB roh, 333 MB gepackt.

ssh root@<jenkins-ip> "tar -C /opt/jenkins-home --numeric-owner -czf - ." \
  > jenkins-home.tar.gz

3. jenkins.ps1 down – Snapshot 426664299, Server gelöscht, die jenkins-auto-Regel in okd-sno-fw entfernt.
4. Tar ins Volume shared-infra_jenkins-data entpacken über einen Helfer-Container – altes lokales jenkins_home vorher weg.

find /dest -mindepth 1 -delete
tar -C /dest -xzf /src/jenkins-home.tar.gz
chown -R 1000:1000 /dest

5. Starten.

cd shared-infra
podman compose up -d jenkins

Ergebnis: 4 Jobs, Build-Historie library-platform-pipeline #1–17, alle drei Credentials. credentials.xml + secret.key + secrets/ kommen im Tar mit, deshalb bleiben die verschlüsselten Credentials benutzbar.

04 Der podman-compose-Trick

Der einzige echte Umbau: den Podman-Socket der podman-machine in den Jenkins-Container bekommen, damit die podman build-Stufen laufen.

podman compose nutzt hier podman-compose 1.6.0 (Python, via scoop). Das schreibt unter Windows in assert_volume() jeden absoluten Bind-Mount-Pfad über os.path.abspath(os.path.join(basedir, src)) auf C:\… um – auch die Langform mit type: bind – und legt dort per os.makedirs leere Ordner an.

Gebunden wird das Verzeichnis /run/user/1000/podman – die Socket-Datei selbst lässt sich nicht auf das _data-Dir des Volumes mounten. Gemountet nach /run/podman-host. Ein zweiter Mount desselben Volumes auf /var/run/docker.sock verdrängt den kaputten Basis-Mount aus docker-compose.yml.

volumes:
  podman-sock:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /run/user/1000/podman

services:
  jenkins:
    ports:
      - "8080:8080"          # UI direkt - Traefik bindet rootless kein :80
      - "50000:50000"
    restart: unless-stopped
    environment:
      CONTAINER_HOST: unix:///run/podman-host/podman.sock
      DOCKER_HOST:    unix:///run/podman-host/podman.sock
    volumes:
      - podman-sock:/run/podman-host
      - podman-sock:/var/run/docker.sock   # verdraengt den Basis-Mount

05 Dateien & Maschine

Was neu ist – und was in der podman-machine gesetzt werden musste.

Neu in shared-infra/ (dort kein Git-Repo)

Einmalig in der podman-machine

Per podman machine ssh. Verschwindet bei podman machine rm und muss dann neu gesetzt werden.

# shared-jenkins nach `podman machine start` selbst hochfahren
sudo systemctl enable podman-restart.service
sudo chown -R user:user ~/.config/systemd
systemctl --user enable podman-restart.service

# `podman build -v` loest die -v-Quelle in der VM auf
sudo mkdir -p /opt/m2cache && sudo chmod 777 /opt/m2cache

Und einmalig im Container, weil workspace/ mit kaputtem @script/.git im Tar lag:

podman exec shared-jenkins rm -rf /var/jenkins_home/workspace/*

06 Täglicher Betrieb

Start, Stop, und der Weg zurück auf Hetzner.

# nach `podman machine start` kommt Jenkins per podman-restart.service selbst;
# explizit:
cd shared-infra && podman compose up -d jenkins

# stoppen - Daten bleiben im Volume jenkins-data
podman compose stop jenkins

• UI: http://localhost:8080 – admin / admin. CASC setzt das Passwort bei jedem Boot neu aus JENKINS_ADMIN_PASSWORD, egal was im wiederhergestellten users/ steht.
• Zurück auf Hetzner: .\scripts\jenkins.ps1 up – Server aus Snapshot, gleiche Firewall-Automatik.
• Snapshot endgültig weg: .\scripts\jenkins.ps1 destroy.

07 Deploy auslösen

DEPLOY_ONLY=true überspringt Test-, Lint- und Frontend-Stufen und geht direkt Build → Push in die OKD-Registry → helm upgrade.

Der Crumb muss über einen Cookie-Jar mit – sonst HTTP 403 (Falle 11 der OKD-Deploy-Anleitung).

J='http://admin:admin@localhost:8080'
CRUMB=$(curl -s -c cj "$J/crumbIssuer/api/json" \
  | python -c "import sys,json;print(json.load(sys.stdin)['crumb'])")

curl -s -b cj -H "Jenkins-Crumb:$CRUMB" -X POST \
  "$J/job/library-platform-pipeline/buildWithParameters" \
  --data-urlencode "DEPLOY_ONLY=true"

Oder in der UI: library-platform-pipeline → „Build mit Parametern“. OKD muss laufen (sno.ps1 up).

08 Stolpersteine (#18–#22)

Was in den ersten lokalen Läufen hochkam – und der Fix.

09 Verifikation

Zwei komplette Läufe vom lokalen Jenkins nach OKD.

+ Was noch aussteht

• Jenkinsfile: retry-Block auf Push- und Deploy-Stage, um die SNO-Blips abzufangen – Änderung im Ziel-Repo LAB-WIP-MAVEN-Bibliothek-Enterprise.
• okd.kubeconfig / okd.token im jenkins_home sind auf die OKD-IP zum Snapshot-Zeitpunkt gebacken. Nach einem sno.ps1 install (neue IP) erneuern – 10-okd-creds.groovy legt die Credentials daraus bei jedem Boot neu an.
• Traefik lokal ungelöst (rootless kein Port 80). Der direkte :8080 reicht für den Jenkins-Betrieb.

+ Bezug zu den Skripten