rsync von Hand

Bevor die Pipeline deployt, machst du es einmal von Hand. So weisst du, dass Server, Schlüssel und Pfade stimmen, und kannst später Pipeline-Fehler von Server-Fehlern unterscheiden.

Ein eigener Schlüssel fürs Deploy

Die Pipeline braucht einen privaten SSH-Schlüssel, um sich am Server anzumelden. Nimm nicht deinen persönlichen Schlüssel. Erzeuge einen eigenen, ohne Passphrase, weil niemand in der Pipeline sie eintippen kann:

ssh-keygen -t ed25519 -f ~/.ssh/plattform_deploy -N "" -C "deploy meine-plattform"
ssh-copy-id -i ~/.ssh/plattform_deploy.pub benutzer@IP-der-VM
ssh -i ~/.ssh/plattform_deploy benutzer@IP-der-VM 'echo Login ok'

Ein Schlüssel, ein Zweck

Ein Schlüssel ohne Passphrase ist nur so sicher wie der Ort, an dem er liegt. Er darf genau eines: auf diesem Server in dieses Verzeichnis schreiben. Wird er kompromittiert, löschst du die Zeile in ~/.ssh/authorized_keys auf dem Server, und er ist wertlos. Dein persönlicher Schlüssel bleibt davon unberührt.

rsync

rsync kennst du aus Linux Grundlagen, Modul 10. Für einen Deploy:

cd ~/meine-plattform
npm run build
rsync -az --delete -e "ssh -i ~/.ssh/plattform_deploy" dist/ benutzer@IP-der-VM:/var/www/html/

Teil	Bedeutung
-a	Archiv: Rechte, Zeiten, Unterordner
-z	Komprimiert übertragen
--delete	Löscht auf dem Server, was in dist/ nicht mehr existiert: alte Seiten, alte Asset-Hashes
-e "ssh -i ..."	SSH mit dem Deploy-Schlüssel
dist/ mit Schrägstrich	Der Inhalt von dist/, nicht der Ordner selbst

Der Schrägstrich hinter dist/ ist entscheidend. Ohne ihn landet die Seite unter /var/www/html/dist/.

--delete auf das richtige Ziel

--delete räumt das Zielverzeichnis auf alles, was nicht in der Quelle ist. Mit falschem Zielpfad löscht es fremde Dateien. Darum zeigt der Deploy dieser Plattform in ein Document Root, in dem nur die Seite liegt, und schliesst mit --exclude='.well-known' den Ordner aus, den der Hoster für Zertifikate braucht.

Öffne http://IP-der-VM/ im Browser: deine Plattform. Prüfe die 404-Seite und schau mit den Entwicklerwerkzeugen (Reiter Network) nach den Cache-Control-Headern.

Was bei jedem Deploy passiert

flowchart LR
    A[npm run build] --> B[dist/]
    B -->|rsync -az --delete| C["/var/www/html/"]
    C --> D[Apache liefert aus]

Weil rsync nur Unterschiede überträgt, dauert ein zweiter Deploy Sekunden, auch wenn die Seite hunderte Dateien hat. Ändere einen Satz, baue, rsync, und zähle in der Ausgabe von rsync -v, wie wenige Dateien tatsächlich übertragen werden.

Aufgabe 7.2 · Manueller Deploy

Veröffentliche deine Plattform von Hand auf deiner VM. Speichere den Befehl und die Ausgabe eines zweiten Durchlaufs mit -v (nach einer kleinen Änderung) in labs/plattform/07-deploy/rsync.txt. Der Schlüssel selbst kommt nicht ins Repository.

Lösung anzeigen

Bei einem zweiten Durchlauf nach einer Textänderung überträgt rsync typischerweise die geänderte HTML-Datei, die Pagefind-Indexdateien der Suche und sonst nichts. Werden jedes Mal alle Dateien übertragen, fehlt meist -a oder die Zeitstempel stimmen nicht, etwa weil dist/ vor dem Build gelöscht wurde.

Selbstcheck · 3 Fragen

1. Warum ein eigener Schlüssel für den Deploy?

Weil ssh-keygen das verlangtDamit er ohne Passphrase sein darf und bei Kompromittierung nur dieser eine Zugang betroffen istWeil rsync nur ed25519 kann

2. Was bewirkt der Schrägstrich in dist/?

NichtsEs wird der Inhalt von dist/ kopiert, nicht der Ordnerrsync löscht dist/

3. Was macht --delete?

Löscht dist/ nach dem KopierenEntfernt auf dem Ziel, was in der Quelle nicht mehr existiertLöscht die alte .htaccess

Antworten prüfen