Einführung
Ein Exportdienst sollte temporäre Downloads entfernen, ohne aufbewahrte Dokumente zu löschen. Sie wenden auf einen neuen privaten Bucket Ablaufregeln nach Präfix, Speicherklassenwechsel und Bereinigungsregeln für unvollständige Uploads an. Anschließend prüfen Sie die tatsächlichen Richtlinien- und Objektmetadaten.
Schließen Sie zuerst die vollständige Objektverwaltung und die Multipart-Bereinigung ab. Diese neue VM verwendet Node.js 22.22.0, Wrangler 4.131.1 und AWS SDK 3.888.0. R2 muss aktiviert sein, und Sie benötigen die Berechtigung, den neuen Bucket zu konfigurieren. Lesen Sie das Verhalten von Lebenszyklusregeln und die Preise, einschließlich der Mindestdauer und Abrufgebühren für Infrequent Access. Die Testdaten bleiben im Speicherstandard und werden während dieser Sitzung ausdrücklich gelöscht. Die Abnahmeprüfung kontrolliert angewendete Regeln und aktuelle Metadaten, nicht die Löschung oder den Speicherklassenwechsel nach Ablauf mehrerer Tage. Eine Domain ist nicht erforderlich.
Privaten Dokument-Bucket erstellen
In diesem Schritt autorisieren Sie diese VM und erstellen einen temporären Bucket. Die Geräteautorisierung bestätigt Ihr Lernkonto. Für die Verwaltung des R2-Buckets wird ein separates API-Token verwendet, das auf dieses Konto beschränkt ist.
Starten Sie Bash für die unten verwendete Befehlssyntax. Wechseln Sie anschließend in das vorbereitete Projekt und prüfen Sie die Tools. Lassen Sie dasselbe Terminal geöffnet, damit die Variablen mit den Ressourcennamen erhalten bleiben:
bash
cd /home/labex/project/r2-lab
export PATH="$PWD/.tools/node-v22.22.0-linux-x64/bin:$PATH"
node --version
npx wrangler --version
Autorisieren Sie den angezeigten Gerätecode in Ihrem eigenen Browser. Prüfen Sie das Lernkonto sowie die angeforderten Lesezugriffe auf Konto und Benutzer, bevor Sie Ihre Zustimmung erteilen:
npx wrangler login --device --browser=false --scopes account:read user:read
npx wrangler whoami --json
Verlangen Sie loggedIn: true. Lesen Sie den Kontonamen auch dann, wenn nur ein Konto aufgeführt ist. Ersetzen Sie YOUR_ACCOUNT_ID unten durch die tatsächliche 32-stellige ID dieses Kontos. openssl rand -hex 6 erzeugt zwölf zufällige Hexadezimalzeichen, sodass dieser Labordurchlauf nicht mit einem vorherigen Durchlauf kollidiert. Das Here-Dokument schreibt eine Standardkonfigurationsdatei; die Shell ersetzt darin Ihre Variablen.
ACCOUNT_ID=YOUR_ACCOUNT_ID
RUN_ID=$(openssl rand -hex 6)
NAME="labex-c05-r07-$RUN_ID"
BUCKET="$NAME-docs"
cat > wrangler.jsonc <<JSON
{"name":"$NAME","account_id":"$ACCOUNT_ID","compatibility_date":"2026-07-30","r2_buckets":[{"binding":"DOCUMENTS","bucket_name":"$BUCKET"}]}
JSON
Öffnen Sie für die Bucket-Verwaltung die Seite API Tokens Ihres Cloudflare-Profils und erstellen Sie ein benutzerdefiniertes Token mit dem Namen dieses Labs. Gewähren Sie Account → Workers R2 Storage → Edit und beschränken Sie Account Resources auf das Lernkonto, dessen ID Sie gespeichert haben. Legen Sie einen kurzen Ablaufzeitraum fest. Nehmen Sie keine anderen Konten und keine themenfremden Berechtigungen auf. Dieses Verwaltungstoken dient der Bucket-Verwaltung, einschließlich Erstellung und Löschung. Später in diesem Schritt erstellen Sie ein separates, auf diesen Bucket beschränktes Objekt-Token für die Objektoperationen des S3-SDKs.
Kopieren Sie das Token einmal in die Eingabeaufforderung dieser ausgeblendeten VM. umask 077 beschränkt den Dateizugriff auf Ihren Benutzer; read -s blendet die Eingabe aus. Die Datei verwendet Wranglers standardmäßige Token-Variable und wird von Git ausgeschlossen.
umask 077
read -r -s -p 'R2 management API token: ' R2_MANAGEMENT_TOKEN; printf '\n'
printf 'CLOUDFLARE_API_TOKEN=%s\n' "$R2_MANAGEMENT_TOKEN" > .env.management
unset R2_MANAGEMENT_TOKEN
Verwenden Sie --env-file=.env.management nur für R2-Verwaltungsbefehle. Der normale Befehl whoami prüft weiterhin die Geräteautorisierung der VM.
Setzen Sie --env-file an das Ende jedes Wrangler-Befehls, damit dessen Liste von Dateiargumenten nicht auch den Befehlsnamen erfasst. Wenn Wrangler nach dem Erstellen eines Buckets anbietet, eine Bindung zur Konfiguration hinzuzufügen, geben Sie n ein und drücken Sie die Eingabetaste. Die vorgesehene Bindung ist bereits konfiguriert.
npx wrangler r2 bucket create "$BUCKET" --env-file=.env.management
Listen Sie Ihre Buckets auf und suchen Sie den exakt erzeugten Namen. Andere Buckets gehören zu anderen Arbeiten; lassen Sie sie unverändert.
npx wrangler r2 bucket list --env-file=.env.management
Öffnen Sie im Dashboard Storage & databases → R2 → Overview, wählen Sie genau diesen Bucket aus und prüfen Sie die leere Objektliste. Lassen Sie in den Einstellungen die öffentliche Entwicklungs-URL und benutzerdefinierte Domains deaktiviert. Ein Bucket-Name im Dashboard bestätigt die Identität. Ob die gespeicherten Bytes korrekt sind, prüfen Sie später mit einem Download.
Die S3-kompatible API ermöglicht Standard-Storage-SDKs den Zugriff auf R2. Sie verwendet ein separates Zugriffsschlüsselpaar statt des Geräte-Tokens von Wrangler. Wählen Sie in R2 → Overview den Pfad Account Details → API Tokens → Manage und erstellen Sie anschließend ein User API token mit dem Namen der erzeugten Ressource dieses Labs. Wählen Sie Object Read & Write, beschränken Sie das Token auf genau diesen neuen Bucket und wählen Sie einen kurzen Ablaufzeitraum, falls das Formular diese Option anbietet. Wählen Sie weder alle Buckets noch den Admin-Zugriff. Lassen Sie diese Token-Seite geöffnet, bis Sie das einmalig angezeigte Geheimnis gespeichert haben.
Verwenden Sie die folgenden Bash-Eingabeaufforderungen in der VM. read -s blendet die Eingabe aus; umask 077 sorgt dafür, dass die Anmeldedatendatei nur von Ihrem Benutzer gelesen werden kann. Diese Namen sind die Standard-Umgebungsvariablen des AWS SDK. Fügen Sie die Access Key ID und den Secret Access Key in die jeweils passende Eingabeaufforderung ein und drücken Sie anschließend die Eingabetaste. Fügen Sie nicht den allgemeinen API-Token-Wert ein.
umask 077
read -r -s -p 'Access Key ID: ' AWS_ACCESS_KEY_ID; printf '\n'
read -r -s -p 'Secret Access Key: ' AWS_SECRET_ACCESS_KEY; printf '\n'
printf 'AWS_ACCESS_KEY_ID=%s\nAWS_SECRET_ACCESS_KEY=%s\n' "$AWS_ACCESS_KEY_ID" "$AWS_SECRET_ACCESS_KEY" > .env.s3
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY
Schreiben Sie einen wiederverwendbaren Standard-SDK-Client. Das SDK benötigt eine Regionszeichenfolge; für R2 lautet sie auto. Durch das Einlesen der vorhandenen Konfiguration richten sich CLI- und SDK-Operationen auf dasselbe Konto und denselben Bucket.
cat > storage.mjs <<'JS'
import { S3Client } from "@aws-sdk/client-s3";
import { readFileSync } from "node:fs";
const config = JSON.parse(readFileSync("wrangler.jsonc", "utf8"));
export const Bucket = config.r2_buckets[0].bucket_name;
export const s3 = new S3Client({
region: "auto",
endpoint: `https://${config.account_id}.r2.cloudflarestorage.com`,
credentials: {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
}
});
JS
Präfixspezifische Lebenszyklusregeln anwenden
In diesem Schritt konfigurieren Sie eine Lebenszyklusregel, also eine Gruppe von Speicheraktionen, die R2 auf alternde Objekte anwendet. Temporäre Exporte sollen ablaufen, während aufbewahrte Handbücher von diesen Regeln nicht erfasst werden. Ein Speicherklassenwechsel ändert die Abrechnungs- und Zugriffsklasse; er löscht das Objekt nicht.
Dieser neue temporäre Bucket verwendet zwei Regeln: Objekte unter temporary/ laufen nach zwei Tagen ab, und unvollständige Uploads unter diesem Präfix werden nach einem Tag abgebrochen. Objekte unter archive/ wechseln nach dreißig Tagen zu Infrequent Access. retained/ wird von keiner Regel erfasst.
Die API gibt Altersangaben in Sekunden an: Ein Tag entspricht 86.400 Sekunden. Schreiben Sie die Richtlinie mit einem quotierten Here-Dokument, damit die JSON-Struktur unverändert bleibt:
cat > lifecycle.json <<'JSON'
{
"rules": [
{
"id": "temporary-exports",
"enabled": true,
"conditions": {
"prefix": "temporary/"
},
"deleteObjectsTransition": {
"condition": {
"type": "Age",
"maxAge": 172800
}
},
"abortMultipartUploadsTransition": {
"condition": {
"type": "Age",
"maxAge": 86400
}
}
},
{
"id": "archive-transition",
"enabled": true,
"conditions": {
"prefix": "archive/"
},
"storageClassTransitions": [
{
"condition": {
"type": "Age",
"maxAge": 2592000
},
"storageClass": "InfrequentAccess"
}
]
}
]
}
JSON
npx wrangler r2 bucket lifecycle set "$BUCKET" --file lifecycle.json --env-file=.env.management
npx wrangler r2 bucket lifecycle list "$BUCKET" --env-file=.env.management
Der Befehl set ersetzt die Richtlinie. Prüfen Sie daher ausschließlich diesen neuen Lab-Bucket. Verlangen Sie genau die beiden Präfixe, den aktivierten Status und die angegebenen Alterswerte. Wenden Sie diese Ersetzung nicht auf einen vorhandenen Anwendungs-Bucket an. Öffnen Sie im Dashboard für denselben Bucket Settings → Object Lifecycle Rules und prüfen Sie die Aktionen, ohne sie zu ändern.
Kostenhinweis: Für Infrequent Access fallen Abrufgebühren und eine Mindestdauer der Speicherung an. In diesem Lab konfigurieren Sie einen zukünftigen Speicherklassenwechsel und entfernen die neuen Objekte im Standard-Speicher während der Bereinigung. Sie warten nicht dreißig Tage, erzwingen keinen Wechsel und behaupten nicht, dass ein Wechsel tatsächlich stattgefunden hat.
Diese echte Dashboard-Ansicht zeigt konfigurierte zukünftige Aktionen: Objekte unter temporary/ nach 2 Tagen löschen, unvollständige Uploads dieses Präfixes nach 1 Tag abbrechen und Objekte unter archive/ nach 30 Tagen nach Infrequent Access verschieben. Sie belegt nicht, dass diese Fristen verstrichen oder die Aktionen ausgeführt sind. Der nächste Schritt prüft aktuelle Objektmetadaten; retained/ liegt außerhalb beider Präfixe.
Metadaten der neu angewendeten Ablaufregeln prüfen
In diesem Schritt laden Sie neue Objekte nach der Anwendung der Richtlinie hoch. Laut R2 enthalten neue Objekte eine passende Ablaufangabe in x-amz-expiration; bei vorhandenen Objekten kann es länger dauern, bis eine geänderte Regel sichtbar wird. Das SDK stellt diesen Header als Expiration bereit.
cat > seed.mjs <<'JS'
import { PutObjectCommand, HeadObjectCommand } from "@aws-sdk/client-s3";
import { readFileSync } from "node:fs";
import { s3, Bucket } from "./storage.mjs";
for (const Key of ["temporary/export.txt", "archive/export.txt"]) {
await s3.send(new PutObjectCommand({ Bucket, Key, Body: readFileSync("document.txt"), ContentType: "text/plain" }));
}
await s3.send(new PutObjectCommand({ Bucket, Key: "retained/handbook.txt", Body: readFileSync("retained.txt"), ContentType: "text/plain" }));
for (const Key of ["temporary/export.txt", "archive/export.txt", "retained/handbook.txt"]) {
const head = await s3.send(new HeadObjectCommand({ Bucket, Key }));
console.log({ key: Key, expiration: head.Expiration || "none", storageClass: head.StorageClass || "STANDARD" });
}
JS
node --env-file=.env.s3 seed.mjs
Verlangen Sie ein Ablaufdatum für temporary/export.txt, aber keinen Löschablauf für das aufbewahrte Handbuch. Das neue Archivobjekt muss weiterhin die Speicherklasse Standard verwenden. Der zukünftige Speicherklassenwechsel wird durch die entfernte Regel nachgewiesen, nicht durch eine aktuelle IA-Speicherklasse. Wenn die erwarteten Ablaufmetadaten für das neue Objekt fehlen, prüfen Sie das angewendete Präfix und die Richtlinie. Werten Sie dies nicht als erfolgreichen Ablaufprüfung.
Laden Sie das aufbewahrte Objekt herunter und vergleichen Sie seine ursprünglichen Bytes:
npx wrangler r2 object get "$BUCKET/retained/handbook.txt" --remote --file retained-download.txt --env-file=.env.management
cmp retained.txt retained-download.txt
Eine erfolgreich gelesene Richtlinie und ein lesbares aufbewahrtes Objekt bilden das begrenzte Ergebnis dieses Labs. Die tatsächliche Löschung durch Lebenszyklusregeln erfolgt asynchron und kann nach dem nominellen Ablaufzeitpunkt stattfinden. Dieses Lab bewertet kein Ereignis, das erst Stunden später eintritt.
Den Laborspeicher ausdrücklich leeren
In diesem Schritt entfernen Sie die drei Testobjekte sofort, statt sich auf deren zukünftige Lebenszyklusaktionen zu verlassen. In diesem Lab wurde kein unvollständiger Upload erstellt. Listen Sie dieses Inventar trotzdem auf, denn eine Objektliste allein beweist nicht, dass ein Bucket keine unvollständigen Teile enthält.
cat > empty.mjs <<'JS'
import { DeleteObjectCommand, ListObjectsV2Command, ListMultipartUploadsCommand } from "@aws-sdk/client-s3";
import { s3, Bucket } from "./storage.mjs";
for (const Key of ["temporary/export.txt", "archive/export.txt", "retained/handbook.txt"]) await s3.send(new DeleteObjectCommand({ Bucket, Key }));
const objects = await s3.send(new ListObjectsV2Command({ Bucket }));
const uploads = await s3.send(new ListMultipartUploadsCommand({ Bucket }));
console.log("Objects:", objects.Contents || []);
console.log("Incomplete uploads:", uploads.Uploads || []);
JS
node --env-file=.env.s3 empty.mjs
Verlangen Sie leere Arrays für Objekte und unvollständige Uploads. Wenn Sie beim Experimentieren eine Multipart-Sitzung erstellt haben, verwenden Sie für genau den betroffenen Schlüssel und die Upload-ID die Abbruchoperation aus dem vorherigen Lab und wiederholen Sie anschließend diese schreibgeschützten Listen. Ignorieren Sie fehlgeschlagene Listenanforderungen niemals stillschweigend.
Den leeren Bucket und seine Richtlinie entfernen
In diesem Schritt löschen Sie den verwalteten Bucket, nachdem die Prüfung von Objekten und Uploads erfolgreich war. Die Richtlinie ist eine Bucket-Konfiguration und verschwindet mit dem Bucket.
npx wrangler r2 bucket delete "$BUCKET" --env-file=.env.management
npx wrangler r2 bucket list --env-file=.env.management
Bestätigen Sie den exakt erzeugten Namen. Verlangen Sie, dass dieser Name in einer erfolgreich authentifizierten Liste nicht mehr vorkommt. Führen Sie die Löschprüfung der Plattform aus, bevor Sie die Verwaltungsanmeldedaten widerrufen.
Die Labork Anmeldedaten widerrufen und abmelden
In diesem Schritt schließen Sie den durch diese Übung hinterlassenen Zugriff. Widerrufen Sie auf der Seite R2 API Tokens nur das Objekt-Token, das nach diesem Lab benannt ist. Widerrufen Sie auf der Seite API Tokens Ihres Profils das separate R2-Verwaltungstoken, das Sie für dieses Lab erstellt haben. Durch das Löschen eines Buckets wird ein Token nicht widerrufen, und wrangler logout widerruft keine S3-Anmeldedaten.
Entfernen Sie nach dem Widerruf die lokale Anmeldedatendatei und melden Sie diese VM ab:
rm .env.s3 .env.management
npx wrangler logout
Prüfen Sie die strukturierte Identität. Beim Abmelden ist ein Status ungleich null zu erwarten:
npx wrangler whoami --json || true
Verlangen Sie loggedIn: false; bleiben Sie im normalen Dashboard angemeldet. Die Plattform prüft, ob die lokalen Anmeldedaten entfernt und Wrangler abgemeldet wurde. Beide Token-Widerrufe sind in diesem Kandidaten manuelle Prüfpunkte im Dashboard und werden nicht aus dem Löschen der Dateien abgeleitet.
Zusammenfassung
Wenden Sie bereichsbezogene Ablaufregeln, zukünftige Speicherklassenwechsel und Bereinigungsregeln für Multipart-Uploads an, prüfen Sie aktuelle Metadaten, bewahren Sie aufbewahrte Daten und bereinigen Sie Ressourcen ausdrücklich.
