Introduction
Une version à livrer utile doit être celle qui a réellement réussi ses vérifications. Un rapport indiquant « réussi » est insuffisant si le paquet contient une autre image ou si la préproduction exécute une ancienne version.
Cette base cumulative DeskLite applique déjà les contrôles précédents sur les sources, les identifiants, les dépendances, les conteneurs, la journalisation et la livraison. Vous relierez le commit source actuel, l'image réellement vérifiée, le rapport généré, les octets du paquet et la préproduction locale en cours d'exécution. Les seules nouvelles opérations sont le processus de publication fourni, la création d'une archive tar et la vérification de somme de contrôle.
Examiner la base cumulative fonctionnelle
Dans cette étape, vous identifierez la version source et la base fonctionnelle que vous allez livrer.
cd /home/labex/project/ticket-release
git status
Un arbre de travail propre est attendu. git rev-parse HEAD affiche l'identifiant complet du commit actuel ; HEAD nomme la version actuellement extraite :
git rev-parse HEAD
L'identifiant varie selon la session. Il devra ensuite correspondre au manifeste de publication et à la version de l'application active.
cat Dockerfile
Repérez les copies explicites de fichiers métier, l'installation hors ligne des dépendances et USER nobody. La base Python en cache et les wheels sont préparés. Installer les paquets pendant la construction de l'image est distinct de l'identité non root de l'application finale à l'exécution.
.venv/bin/python -m pip show requests
Le résultat attendu est 2.32.4. Les mêmes versions requises fixées seront installées dans l'image candidate.
bash /srv/ticket-release-client/sender.sh
La réponse attendue est HTTP 200 et le ticket d'origine. Ce client dédié lit déjà son fichier de jeton de remplacement protégé ; l'ancien jeton est révoqué. Ne copiez aucune des deux valeurs dans les métadonnées de publication.
Exécuter le véritable contrôle bloquant et ses témoins négatifs
Dans cette étape, vous établirez que le candidat et le contrôle fonctionnent avant la création du paquet.
bash gate.sh
Les scripts d'encapsulation des étapes préparés exécutent de véritables vérifications de secrets/d'historique, de dépendances et de sources, construisent l'application commitée en une image Docker et démarrent ce véritable candidat. Les tests fonctionnels vérifient sa version source, Requests 2.32.4, le véritable UID non root 65534, le ticket d'origine et les rejets des jetons ancien/absent/erroné.
Le contrôle ne publie pas encore le paquet final. Il n'enregistre un candidat accepté qu'après concordance des vérifications et des tests sur les mêmes sources et la même image.
Exercez maintenant les témoins négatifs de confiance :
course-release gate-test
Cet utilitaire exécute votre même contrôle avec une véritable détection d'identifiant selon la règle fixe, puis avec une véritable erreur de scanner due à une entrée absente. Les deux doivent bloquer avant la construction/les tests, avec les statuts 1 et 2. Il rétablit ensuite le mode de contrôle normal et laisse la préproduction en cours d'exécution inchangée.
Les vérifications couvrent toujours les règles fixes du cours sur les jetons d'exercice/le SQL et deux avis de dépendances sélectionnés ; elles ne constituent pas une revue complète de production.
Générer des métadonnées liées à l'image vérifiée
Dans cette étape, vous générerez les preuves de publication à partir de véritables résultats acceptés au lieu de saisir une déclaration de réussite.
course-release manifest
L'utilitaire exporte la véritable image Docker vérifiée et crée trois fichiers sous release : image.tar, checks.json et manifest.json. Il s'agit d'entrées techniques de livraison, pas d'un rapport d'investigation séparé pour l'apprenant.
cat release/manifest.json
source_commit doit être égal à git rev-parse HEAD. image_id identifie l'image construite exacte plutôt qu'un tag déplaçable. checks_sha256 lie le véritable rapport de vérification dont les valeurs sensibles sont masquées ; image_sha256 lie les octets de l'image exportée. run_id relie l'enregistrement à cette véritable exécution de vérification acceptée.
cat release/checks.json
Le statut 0, les statuts des vérifications individuelles, les versions des outils et le même commit source sont attendus. Aucune valeur d'identifiant n'a sa place ici. Le manifeste est généré automatiquement ; ne modifiez pas les champs pour déclarer qu'un autre artefact a réussi.
Empaqueter et vérifier les octets de la version à livrer
Dans cette étape, vous créerez une véritable archive et sa somme de contrôle.
tar regroupe des fichiers dans une archive. -c en crée une, -f nomme son fichier de sortie et -C release sélectionne le répertoire dont le contenu sera lu. Le . final désigne tout le contenu de ce répertoire :
tar -cf release.tar -C release .
L'archive se trouve hors du répertoire d'entrée : elle ne s'inclut donc pas elle-même. -t liste une archive existante, nommée avec -f :
tar -tf release.tar
Les trois fichiers générés sont attendus, éventuellement préfixés par ./, ainsi qu'une entrée de répertoire.
SHA-256 calcule une empreinte à partir des octets d'un fichier. sha256sum affiche l'empreinte et le nom de fichier. La redirection > déjà connue enregistre ce résultat :
sha256sum release.tar > release.tar.sha256
-c lit l'enregistrement de somme de contrôle sauvegardé et le compare au véritable fichier :
sha256sum -c release.tar.sha256
Le résultat attendu est release.tar: OK. Cela prouve que les octets correspondent à cette empreinte enregistrée. Une somme de contrôle seule ne prouve ni qui a publié le fichier ni si ses vérifications étaient valides.
Vérifier le lien entre rapport et artefact
Dans cette étape, vous vérifierez davantage que la somme de contrôle déclarée pour le paquet.
course-release verify release.tar
L'utilitaire de publication lit la véritable archive, rejette les éléments inattendus/en double, compare le manifeste à son véritable export vérifié, contrôle le rapport d'origine et calcule l'empreinte des octets de l'image contenue. Il exige aussi que le commit source actuel corresponde.
Un PASS liant les sources, le rapport, l'image et l'empreinte du paquet complet est attendu. Cela enregistre l'approbation de ces octets exacts du paquet dans le processus local de publication du cours. Modifier checks.json pour indiquer une réussite ou recalculer une somme de contrôle pour une image modifiée ne créerait pas une exécution de vérification acceptée correspondante.
Il s'agit d'un processus pédagogique avec un enregistrement local protégé. L'accès sudo de l'apprenant signifie que cette VM n'est pas une frontière de confiance de production. Nous testons la procédure de publication fournie, sans prétendre mettre en œuvre des signatures d'éditeur ou une autorité externe.
Déployer ce paquet exact et inspecter l'exécution
Dans cette étape, vous déploierez les octets approuvés et comparerez le comportement actif à l'enregistrement généré.
course-release deploy release.tar
L'utilitaire vérifie à nouveau le paquet, charge l'image qu'il contient et démarre la préproduction locale depuis cet ID d'image exact. Seuls le port du service local et le registre de l'émetteur nécessaire en lecture seule sont exposés ; les identifiants privés ne sont pas intégrés à l'image.
course-release state
L'état contient les mêmes identifiants de sources/d'image et l'empreinte du paquet complet. Inspectez maintenant l'application elle-même :
curl http://127.0.0.1:8080/health
Les valeurs attendues sont le même source_commit, Requests 2.32.4 et l'UID 65534.
bash /srv/ticket-release-client/sender.sh
La réponse attendue est HTTP 200 et le ticket d'origine. Vérifiez l'accès sans authentification :
curl -i http://127.0.0.1:8080/tickets
Le résultat attendu est 401. Le contrôle du candidat a aussi testé les jetons ancien et erroné. Un manifeste correspondant seul n'aurait pas prouvé ce véritable comportement en cours d'exécution.
Rejeter un paquet dont les octets ont changé
Dans cette étape, vous testerez l'application du contrôle d'intégrité sans changer le service en cours d'exécution.
cp copie un fichier. Conservez une sauvegarde octet pour octet du paquet valide :
cp release.tar release-original.tar
printf affiche ce marqueur connu. >> ajoute à la fin d'un fichier, tandis que > le remplacerait. Ajoutez quelques octets uniquement au paquet de l'exercice :
printf 'changed' >> release.tar
sha256sum -c release.tar.sha256
Le résultat attendu est release.tar: FAILED avec un code de sortie non nul. Même si un lecteur tar ignore les données finales, les octets du paquet complet ont changé.
course-release deploy release.tar
Le message attendu est RELEASE BLOCKED, car ces octets exacts n'ont pas été approuvés. Ce résultat non nul est intentionnel. Une nouvelle somme de contrôle écrite par l'utilisateur ne remplacerait pas le lien sources/rapport/image du processus ni son approbation du paquet d'origine.
curl http://127.0.0.1:8080/health
La version précédemment approuvée reste en cours d'exécution. L'étape suivante restaure le paquet valide avant la vérification finale.
Restaurer et confirmer la livraison finale
Dans cette étape, vous laisserez intacts le paquet vérifié d'origine et la préproduction fonctionnelle.
cp release-original.tar release.tar
sha256sum -c release.tar.sha256
Le résultat attendu est à nouveau release.tar: OK.
course-release verify release.tar
course-release state
Le paquet restauré correspond aux véritables sources/image vérifiées et à la préproduction déjà en cours d'exécution. La vérification du cours teste indépendamment les témoins d'échec du contrôle, rejette les octets modifiés, examine les couches réelles de l'image pour les identifiants ciblés et vérifie les comportements positifs/de rejet en direct.
Vous disposez d'une archive de publication, d'une somme de contrôle, d'un manifeste généré et d'un véritable rapport, ainsi que d'une version correspondante en cours d'exécution. Aucune investigation rédigée manuellement n'est requise. La livraison en production nécessiterait aussi des contrôles tels que l'identité de l'éditeur, l'autorisation externe et une couverture de sécurité plus large ; ce cours ne prétend pas les établir à partir d'une somme de contrôle locale.
Résumé
Vous avez lié un véritable commit source vérifié, une image non root testée, le rapport généré d'origine, les octets du paquet de publication et la version active de préproduction locale. Les comportements positifs et de rejet sont restés corrects, tandis que les octets modifiés ont été rejetés. Les sommes de contrôle étayent l'intégrité ; ce processus local ne prétend pas fournir de signatures d'éditeur ni d'autorisation externe de production.
