Deploy-Job

Geheimnisse gehören nicht ins Repository

Der Deploy-Job braucht den privaten Schlüssel, den Hostnamen, Benutzer und Pfad. Nichts davon darf in .gitlab-ci.yml stehen, die Datei ist für alle lesbar. GitLab hat dafür CI-Variablen: Werte, die der Runner dem Job als Umgebungsvariablen oder als Dateien mitgibt.

Unter Settings → CI/CD → Variables legst du an:

Variable	Typ	Inhalt
SITE_URL	Variable	Öffentliche URL, zum Beispiel http://10.0.0.42
DEPLOY_HOST	Variable	Hostname oder IP der VM
DEPLOY_USER	Variable	SSH-Benutzer
DEPLOY_PATH	Variable	/var/www/html/, mit Schrägstrich am Ende
DEPLOY_SSH_KEY	File	Inhalt von ~/.ssh/plattform_deploy
DEPLOY_KNOWN_HOSTS	File	Ausgabe von ssh-keyscan DEPLOY_HOST

Zwei Typen: Bei Variable steht der Wert in der Umgebungsvariable. Bei File schreibt der Runner den Wert in eine temporäre Datei und die Umgebungsvariable enthält deren Pfad. Für Schlüssel ist File richtig, weil sie mehrzeilig sind und als Datei gebraucht werden.

Dazu zwei Häkchen:

• Protected: Die Variable wird nur an Pipelines auf geschützten Branches übergeben. Für alles, was deployen kann, Pflicht. Sonst könnte jemand auf einem Branch test einen Job schreiben, der den Schlüssel ausgibt.
• Masked: GitLab ersetzt den Wert im Job-Log durch [MASKED]. Funktioniert nur für einzeilige Werte ohne Leerzeichen, also für Host, User, Pfad, nicht für den Schlüssel.

known_hosts mit vollem Hostnamen

ssh-keyscan muss mit genau dem Namen laufen, der in DEPLOY_HOST steht. ssh-keyscan server und DEPLOY_HOST=server.example.ch passen nicht zusammen, und ssh meldet «Host key verification failed». Also:

ssh-keyscan server.example.ch 2>/dev/null

Die Ausgabe hat drei Zeilen, eine pro Schlüsseltyp. Alle drei in die Variable.

Der Job

.gitlab-ci.yml

deploy:
  stage: deploy
  image: alpine:3.21
  needs:
    - build
  before_script:
    - apk add --no-cache rsync openssh-client
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    # Das GitLab-Formular schneidet beim Einfügen gern den letzten Zeilenumbruch ab und
    # Windows-Zeilenenden schleichen sich ein; beides macht den Schlüssel unlesbar
    # («error in libcrypto»). Darum CR entfernen und einen Zeilenumbruch am Ende sicherstellen.
    - '{ tr -d "\r" < "$DEPLOY_SSH_KEY"; echo; } | sed "/^$/d" > ~/.ssh/id_ed25519 && chmod 600 ~/.ssh/id_ed25519'
    - '{ tr -d "\r" < "$DEPLOY_KNOWN_HOSTS"; echo; } | sed "/^$/d" > ~/.ssh/known_hosts && chmod 644 ~/.ssh/known_hosts'
    - ssh-keygen -y -f ~/.ssh/id_ed25519 > /dev/null || { echo "DEPLOY_SSH_KEY ist kein gültiger privater Schlüssel."; exit 1; }
  script:
    - rsync -az --delete --exclude='.well-known' dist/ "$DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH"
  environment:
    name: production
    url: $SITE_URL
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Zeile für Zeile:

• needs: [build]: Der Job bekommt das Artefakt dist/ des Build-Jobs und startet, sobald der fertig ist.
• apk add: Alpine hat weder rsync noch ssh. Jeder Job fängt bei null an.
• Schlüssel und known_hosts werden aus den File-Variablen nach ~/.ssh/ geschrieben, mit den Rechten, die ssh verlangt (600 für den Schlüssel, sonst verweigert ssh ihn). Die etwas umständliche Zeile mit tr und sed ist eine Lehre aus dem ersten Deploy dieser Plattform, siehe Fehlersuche.
• ssh-keygen -y liest den privaten Schlüssel und gibt den öffentlichen aus. Scheitert das, ist der Schlüssel kaputt, und der Job bricht mit einer klaren Meldung ab statt später mit einem kryptischen rsync-Fehler.
• rsync wie von Hand, nur dass ssh den Schlüssel unter dem Standardnamen ~/.ssh/id_ed25519 findet und kein -e nötig ist.
• environment: GitLab merkt sich unter Operate → Environments, welcher Commit wann auf «production» deployt wurde, mit Link auf die Seite.
• rules: Nur auf main. Merge-Request-Pipelines und andere Branches bauen, deployen aber nicht.

Die Variable SITE_URL wird ausserdem von astro.config.mjs gelesen (site: process.env.SITE_URL), damit Sitemap und kanonische URLs die öffentliche Adresse tragen.

1. Die sechs Variablen anlegen, alle DEPLOY_* als Protected, die einzeiligen zusätzlich als Masked.
2. Prüfen, dass main ein Protected Branch ist (Modul 4).
3. Den Job in .gitlab-ci.yml ergänzen, über einen Merge Request auf main bringen.
4. Die Pipeline auf main hat jetzt drei Jobs. Im Deploy-Log die rsync-Zeile suchen.
5. Seite im Browser prüfen, Operate → Environments zeigt «production».

Aufgabe 7.3 · Automatischer Deploy

Dein Projekt deployt bei jedem Merge auf main automatisch auf deine VM. Ändere danach einen Satz über einen Merge Request und zeige mit einem Screenshot oder einer Kopie des Deploy-Logs, dass die Änderung ohne dein Zutun online ging. Speichere .gitlab-ci.yml und das Log unter labs/plattform/07-deploy/.

Lösung anzeigen

Wenn die Pipeline grün ist, die Seite aber alt aussieht: Browser-Cache. HTML hat no-cache, aber ein harter Reload (Shift+Reload) schliesst das aus. Zweiter Verdächtiger: DEPLOY_PATH zeigt nicht auf das Document Root, das Apache ausliefert.

Selbstcheck · 3 Fragen

1. Was enthält die Umgebungsvariable einer CI-Variable vom Typ File?

Den InhaltDen Pfad zu einer temporären Datei mit dem InhaltNichts, File-Variablen sind nur im Web sichtbar

2. Warum sind alle DEPLOY_*-Variablen Protected?

Damit sie nur in Pipelines auf geschützten Branches verfügbar sind und niemand sie über einen Test-Branch auslesen kannWeil GitLab das für File-Variablen verlangtDamit sie im Log maskiert werden

3. Warum installiert der Job rsync und ssh selbst?

Weil der Runner sie nicht hatWeil jeder Job in einem frischen Container aus dem Image startet und alpine sie nicht enthältAus Sicherheitsgründen

Antworten prüfen