Einführung
Eine brauchbare Veröffentlichung muss die Version sein, die ihre Prüfungen tatsächlich bestanden hat. Ein Bericht mit der Aussage „bestanden“ reicht nicht aus, wenn das Paket ein anderes Image enthält oder in Staging eine ältere Version läuft.
Dieser auf den bisherigen Schritten aufbauende DeskLite-Ausgangszustand wendet die früheren Maßnahmen zu Quellcode, Zugangsdaten, Abhängigkeiten, Containern, Protokollierung und Freigabe bereits an. Du verknüpfst den aktuellen Quellcode-Commit, das tatsächlich geprüfte Image, den erzeugten Bericht, die Paketbytes und die laufende lokale Staging-Version. Neu sind nur der bereitgestellte Veröffentlichungsablauf, die tar-Paketierung und die Prüfsummenprüfung.
Den funktionierenden bisherigen Ausgangszustand prüfen
In diesem Schritt ermittelst du die Quellcodeversion und den funktionierenden Ausgangszustand, die du veröffentlichen wirst.
cd /home/labex/project/ticket-release
git status
Erwartet wird ein sauberes Arbeitsverzeichnis. git rev-parse HEAD gibt die vollständige Kennung des aktuellen Commits aus; HEAD bezeichnet die derzeit ausgecheckte Version:
git rev-parse HEAD
Die Kennung variiert je nach Sitzung. Später muss sie mit dem Veröffentlichungsmanifest und der Version der laufenden Anwendung übereinstimmen.
cat Dockerfile
Suche nach dem ausdrücklichen Kopieren von Geschäftsdateien, der Offline-Abhängigkeitsinstallation und USER nobody. Das zwischengespeicherte Python-Basisimage und die Wheels sind vorbereitet. Pakete während des Image-Builds zu bauen ist von der Laufzeitidentität der endgültigen Anwendung ohne Root-Rechte getrennt.
.venv/bin/python -m pip show requests
Erwartet wird 2.32.4. Dieselben festgelegten Anforderungen werden im Kandidatenimage installiert.
bash /srv/ticket-release-client/sender.sh
Erwartet werden HTTP 200 und das ursprüngliche Ticket. Dieser dedizierte Client liest bereits seine geschützte Ersatztokendatei; das alte Token ist widerrufen. Kopiere keinen der beiden Werte in Veröffentlichungsmetadaten.
Die tatsächliche Freigabeprüfung und ihre negativen Vergleichsfälle ausführen
In diesem Schritt stellst du vor der Paketierung fest, dass sowohl Kandidat als auch Freigabeprüfung funktionieren.
bash gate.sh
Die vorbereiteten Phasenskripte führen echte Prüfungen auf Geheimnisse/in der Historie, auf Abhängigkeiten und auf Quellcode aus, bauen die committete Anwendung in ein Docker-Image und starten diesen tatsächlichen Kandidaten. Funktionstests prüfen seine Quellcodeversion, Requests 2.32.4, die echte Nicht-Root-UID 65534, das ursprüngliche Ticket und die Ablehnung alter/fehlender/falscher Tokens.
Die Freigabeprüfung veröffentlicht das endgültige Paket noch nicht. Sie vermerkt erst dann einen akzeptierten Kandidaten, wenn Prüfungen und Tests für denselben Quellcode und dasselbe Image übereinstimmen.
Teste jetzt vertrauenswürdige negative Vergleichsfälle:
course-release gate-test
Dieses Hilfsprogramm führt dieselbe Freigabeprüfung mit einem echten Zugangsdatenfund unter fester Regel und anschließend einem tatsächlichen Scannerfehler wegen fehlender Eingabe aus. Erwartet wird, dass beide vor Build/Test blockieren, mit den Statuswerten 1 und 2. Danach stellt es den normalen Steuerungsmodus wieder her und lässt die laufende Staging-Version unverändert.
Die Prüfungen decken weiterhin die festen Übungstoken-/SQL-Regeln des Kurses und zwei ausgewählte Sicherheitsmeldungen zu Abhängigkeiten ab; sie sind keine vollständige Prüfung für den Produktivbetrieb.
An das geprüfte Image gebundene Metadaten erzeugen
In diesem Schritt erzeugst du Veröffentlichungsnachweise aus tatsächlichen akzeptierten Ergebnissen, statt eine Erfolgsbehauptung einzutippen.
course-release manifest
Das Hilfsprogramm exportiert das tatsächlich geprüfte Docker-Image und erstellt drei Dateien unter release: image.tar, checks.json und manifest.json. Dies sind technische Auslieferungseingaben, kein separater Untersuchungsbericht für Lernende.
cat release/manifest.json
source_commit muss git rev-parse HEAD entsprechen. image_id bezeichnet das exakt gebaute Image statt eines verschiebbaren Tags. checks_sha256 bindet den tatsächlichen maskierten Prüfbericht ein; image_sha256 bindet die exportierten Image-Bytes ein. run_id verknüpft die Aufzeichnung mit diesem echten akzeptierten Prüflauf.
cat release/checks.json
Erwartet werden Status 0, einzelne Prüfstatus, Werkzeugversionen und derselbe Quellcode-Commit. Hierher gehören keine Zugangsdatenwerte. Das Manifest wird automatisch erzeugt; bearbeite keine Felder, um zu behaupten, ein anderes Artefakt habe bestanden.
Die Veröffentlichungsbytes paketieren und prüfen
In diesem Schritt erstellst du ein echtes Archiv und seine Prüfsumme.
tar fasst Dateien zu einem Archiv zusammen. -c erstellt eines, -f benennt seine Ausgabedatei, und -C release wählt das Verzeichnis aus, dessen Inhalt gelesen wird. Der abschließende Punkt . bedeutet den gesamten Inhalt dieses Verzeichnisses:
tar -cf release.tar -C release .
Das Archiv liegt außerhalb des Eingabeverzeichnisses und nimmt sich daher nicht selbst auf. -t listet ein vorhandenes Archiv auf, das mit -f benannt wird:
tar -tf release.tar
Erwartet werden die drei erzeugten Dateien, möglicherweise mit vorangestelltem ./, sowie ein Verzeichniseintrag.
SHA-256 berechnet einen Hashwert aus Dateibytes. sha256sum gibt den Hashwert und Dateinamen aus. Die vertraute Umleitung > speichert dieses Ergebnis:
sha256sum release.tar > release.tar.sha256
-c liest die gespeicherte Prüfsummenaufzeichnung und vergleicht die tatsächliche Datei:
sha256sum -c release.tar.sha256
Erwartet wird release.tar: OK. Das beweist, dass die Bytes diesem aufgezeichneten Hashwert entsprechen. Eine Prüfsumme allein beweist nicht, wer die Datei veröffentlicht hat oder ob ihre Prüfungen gültig waren.
Die Bindung zwischen Bericht und Artefakt prüfen
In diesem Schritt prüfst du mehr als die vom Paket selbst angegebene Prüfsumme.
course-release verify release.tar
Das Veröffentlichungshilfsprogramm liest das tatsächliche Archiv, weist unerwartete/doppelte Einträge zurück, vergleicht das Manifest mit seinem echten geprüften Export, prüft den ursprünglichen Bericht und hasht die enthaltenen Image-Bytes. Es verlangt außerdem die Übereinstimmung des aktuellen Quellcode-Commits.
Erwartet wird ein PASS, das Quellcode, Bericht, Image und den vollständigen Paket-Hashwert miteinander verbindet. Das registriert im lokalen Veröffentlichungsablauf des Kurses eine Freigabe für genau diese Paketbytes. checks.json auf „bestanden“ zu ändern oder eine Prüfsumme für ein verändertes Image neu zu berechnen würde keinen passenden akzeptierten Prüflauf erzeugen.
Dies ist ein Lehrablauf mit einer geschützten lokalen Aufzeichnung. Der sudo-Zugriff der Lernenden bedeutet, dass diese VM keine Vertrauensgrenze für den Produktivbetrieb ist. Wir testen das bereitgestellte Veröffentlichungsverfahren, ohne zu behaupten, Herausgebersignaturen oder eine externe Autorität umzusetzen.
Genau dieses Paket bereitstellen und die Laufzeit untersuchen
In diesem Schritt stellst du die freigegebenen Bytes bereit und vergleichst das laufende Verhalten mit der erzeugten Aufzeichnung.
course-release deploy release.tar
Das Hilfsprogramm prüft das Paket erneut, lädt sein enthaltenes Image und startet lokales Staging mit genau dieser Image-ID. Nur der lokale Dienstport und das erforderliche schreibgeschützte Register der ausstellenden Instanz werden zugänglich gemacht; private Zugangsdaten werden nicht in das Image eingebaut.
course-release state
Der Zustand enthält dieselben Quellcode-/Image-Kennungen und den vollständigen Paket-Hashwert. Untersuche nun die Anwendung selbst:
curl http://127.0.0.1:8080/health
Erwartet werden derselbe source_commit, Requests 2.32.4 und UID 65534.
bash /srv/ticket-release-client/sender.sh
Erwartet werden HTTP 200 und das ursprüngliche Ticket. Prüfe nicht authentifizierten Zugriff:
curl -i http://127.0.0.1:8080/tickets
Erwartet wird 401. Die Kandidaten-Freigabeprüfung hat auch alte und falsche Tokens getestet. Ein passendes Manifest allein hätte dieses echte laufende Verhalten nicht nachgewiesen.
Ein Paket mit veränderten Bytes zurückweisen
In diesem Schritt testest du die Durchsetzung der Integrität, ohne den laufenden Dienst zu ändern.
cp kopiert eine Datei. Behalte eine bytegenaue Sicherung des gültigen Pakets:
cp release.tar release-original.tar
printf gibt diese bekannte Markierung aus. >> hängt an eine Datei an, während > sie ersetzen würde. Hänge nur an das Paket dieser Übung einige Bytes an:
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
Erwartet werden release.tar: FAILED und ein Exit-Status ungleich null. Selbst wenn ein tar-Leseprogramm angehängte Daten ignoriert, haben sich die vollständigen Paketbytes verändert.
course-release deploy release.tar
Erwartet wird RELEASE BLOCKED, weil genau diese Bytes nicht freigegeben wurden. Dieses Ergebnis ungleich null ist beabsichtigt. Eine neue vom Benutzer geschriebene Prüfsumme würde weder die Quellcode-/Bericht-/Image-Bindung des Ablaufs noch seine Freigabe des ursprünglichen Pakets ersetzen.
curl http://127.0.0.1:8080/health
Die zuvor freigegebene Version läuft weiter. Der nächste Schritt stellt das gültige Paket vor der abschließenden Prüfung wieder her.
Die abschließende Auslieferung wiederherstellen und bestätigen
In diesem Schritt hinterlässt du das ursprüngliche geprüfte Paket und die funktionierende Staging-Version unverändert.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
Erwartet wird erneut release.tar: OK.
course-release verify release.tar
course-release state
Das wiederhergestellte Paket entspricht dem echten geprüften Quellcode/Image und der bereits laufenden Staging-Version. Die Kursprüfung testet unabhängig die Fehlervergleichsfälle der Freigabeprüfung, weist veränderte Bytes zurück, prüft tatsächliche Imageschichten auf die Zielzugangsdaten und verifiziert positives Verhalten und Ablehnungen am laufenden Dienst.
Du hast ein Veröffentlichungsarchiv, eine Prüfsumme, ein erzeugtes Manifest mit echtem Bericht und eine passende laufende Version. Eine manuell geschriebene Untersuchung ist nicht erforderlich. Produktive Auslieferung würde zusätzliche Maßnahmen wie Herausgeberidentität, externe Autorisierung und breitere Sicherheitsabdeckung benötigen; dieser Kurs leitet solche Zusicherungen nicht aus einer lokalen Prüfsumme ab.
Zusammenfassung
Du hast einen tatsächlich geprüften Quellcode-Commit, ein getestetes Image ohne Root-Rechte, den ursprünglich erzeugten Bericht, die Bytes des Veröffentlichungspakets und die laufende lokale Staging-Version miteinander verknüpft. Positives Verhalten und Ablehnungen blieben korrekt, während veränderte Bytes zurückgewiesen wurden. Prüfsummen unterstützen die Integrität; dieser lokale Ablauf beansprucht weder Herausgebersignaturen noch externe Produktionsautorisierung.
