Wichtigste Erkenntnisse
- Importieren Sie ein begrenztes Objekt oder eine Seite eines Präfixes, statt ein unbegrenztes, bucketweites Neuschreiben zu starten.
- Schreiben Sie Derivate in ein eigenes Präfix, damit rekursive Importe nicht ihre eigenen Ausgaben verarbeiten können.
- Verwenden Sie die Fit-Größenänderung mit einer ausdrücklichen Maximalgröße, um das Seitenverhältnis zu erhalten, und setzen Sie zoom auf false, damit kleinere Originale nicht vergrößert werden.
Ein Bild-Backfill ist keine In-Place-Bearbeitung. Es ist eine wiederholbare Migration von einem bekannten Quellobjekt zu einem versionierten Derivat, dessen Qualität, Abmessungen, Ziel und Anwendungsreferenz unabhängig überprüft werden können. Indem Import und Export in Google Cloud Storage verbleiben, bleibt die Speicherhoheit erhalten, während die Medienverarbeitung aus den Anwendungsservern ausgelagert wird.
Worauf es besonders ankommt
- Bevorzugen Sie separate Template-Zugangsdaten für Lesen und Schreiben mit den geringsten Berechtigungen, die jeder Step benötigt.
- Halten Sie Ausgaben privat, bis die Anwendung sie überprüft und die Auslieferungsreferenzen bewusst ändert.
- Speichern Sie die Generierungs- oder Versionsidentität der Quelle, die Workflow-Version und den Zielpfad dauerhaft, um ein sicheres Replay zu ermöglichen.
Den Auftrag als versionierten Backfill behandeln
Überschreiben Sie keine Bildbibliothek nur, weil ein neues Format oder eine neue Abmessung bei einem Testobjekt besser aussieht. Definieren Sie zuerst die Quellpopulation, die Transformationsversion, den Ausgabe-Namensraum, die Abnahmeprüfungen und die Referenzmigration. Das Originalobjekt sollte wiederherstellbar bleiben, bis das Derivat verifiziert wurde und andere Systeme sicher umgestellt haben.
Verwenden Sie versionsbezogene Ausgabepfade, damit zwei Transformationsrichtlinien während des Rollouts koexistieren können und ein Rollback lediglich eine Referenzänderung bleibt. Der Beispielpfad ist pro Lauf eindeutig und wird nicht aus dem Quellobjekt abgeleitet, daher muss die Anwendung doppelte Verarbeitung verhindern, indem sie ihren eigenen Datensatz zur Zuordnung von Quelle zu Ergebnis prüft, bevor sie eine weitere Assembly erstellt.
Eingabe- und Ausgabe-Namensräume trennen
Ein rekursiver /google/import-Step kann ein Quellpräfix auflisten. Schreibt /google/store unter dasselbe Präfix, kann eine spätere Seite oder ein erneuter Lauf generierte Derivate so importieren, als wären sie Originale. Platzieren Sie Ausgaben in einem nicht überlappenden Präfix oder einem separaten Bucket, und machen Sie diesen Unterschied in Konfiguration und Überwachung deutlich.
Verarbeiten Sie bei einem großen Präfix eine begrenzte Seite und bewahren Sie next_page_token außerhalb der Assembly für den nächsten Aufruf auf. Der Bucket-Inhalt kann sich während einer Migration ändern, daher sollten Sie die Paginierung mit einem Anwendungsmanifest oder Quellinventar kombinieren, wenn eine exakte Abdeckung wichtig ist, bei der jedes Objekt genau einmal erfasst wird.
Quellpräfix
Enthält nur Originale, die für die aktuelle Migrationsrichtlinie ausgewählt wurden.
Ausgabepräfix
Enthält versionierte Derivate und wird vom Quellimport niemals durchlaufen.
Migrationsmanifest
Ordnet die Quellidentität der Workflow-Version, der Assembly-ID und dem Zielobjekt zu.
Das Google-Storage-Bild-Template erstellen
Der Import-Step wählt eine Datei oder ein begrenztes Präfix aus, /image/resize erstellt ein WebP, dessen Abmessungen in den gewählten Rahmen passen, und /google/store schreibt das Derivat als privat. Setzen Sie zoom auf false, wenn kleine Originale nicht vergrößert werden sollen. Prüfen Sie Transparenz und Farbverhalten, bevor WebP zum Vertrag für jede Quellfamilie wird.
Das Beispiel verwendet unterschiedliche Zugangsdaten für Lese- und Schreibzugriff. Der Leser benötigt Zugriff auf die Quellobjekte, der Schreiber benötigt Objekterstellung im Ziel. Fügen Sie Löschrechte nur hinzu, wenn eine beabsichtigte Überschreibungsrichtlinie dies erfordert.
{
"allow_steps_override": false,
"steps": {
"source_images": {
"robot": "/google/import",
"credentials": "gcs-source-read",
"path": "originals/catalog/",
"recursive": true,
"files_per_page": 100
},
"web_derivatives": {
"use": "source_images",
"robot": "/image/resize",
"width": 1600,
"height": 1200,
"resize_strategy": "fit",
"zoom": false,
"format": "webp"
},
"gcs_output": {
"use": "web_derivatives",
"robot": "/google/store",
"credentials": "gcs-output-write",
"path": "derived/web-v1/${assembly.id}/${unique_prefix}/${file.url_name}",
"acl": "private",
"result": true
}
}
}Bildqualität und Objektverhalten validieren
Verwenden Sie Fixtures, die EXIF-Ausrichtung, Transparenz, eingebettete Farbprofile, sehr große Abmessungen, kleine Quellen, Animation, fehlerhafte Dateien und gleichnamige Objekte in unterschiedlichen Ordnern abdecken. Vergleichen Sie das gerenderte Erscheinungsbild ebenso wie Abmessungen, Format und Byte-Größe. Eine kleinere Ausgabe, die die Farbe verändert oder eine erforderliche Animation entfernt, ist keine erfolgreiche Migration.
Legen Sie die ACL bewusst fest. Das /google/store-Schema setzt die ACL standardmäßig auf public-read, sodass ein privater Prüfworkflow diese explizit überschreiben muss. Fügen Sie eine Cache-Richtlinie nur hinzu, wenn sie zum späteren Auslieferungs- und Autorisierungsmodell passt.
Mit Kontrollpunkten und Rollback ausrollen
Erfassen Sie jedes Quellobjekt und jedes Zielergebnis, bevor Sie Referenzen anderer Systeme ändern. Gleichen Sie fehlende oder fehlgeschlagene Einträge anhand der Quellidentität ab, statt das gesamte Präfix erneut auszuführen. Schlägt die Verarbeitung einer Seite mitten im Ablauf fehl, wiederholen Sie nur die Quellobjekte, die die Anwendung noch nicht als abgeschlossen erfasst hat. Der Beispielpfad ist pro Lauf eindeutig, sodass die erneute Verarbeitung derselben Quelle ein neues Objekt schreibt; die Deduplizierung erfolgt über den Quelle-zu-Ergebnis-Datensatz der Anwendung, der vor Erstellung der Assembly geprüft wird.
Verlagern Sie eine kleine Traffic-Kohorte auf die neuen Pfade, vergleichen Sie Bytes und visuelle Metriken, und weiten Sie dann aus. Bewahren Sie die Originale und die bisherigen Anwendungsreferenzen auf, bis das Rollback-Fenster geschlossen ist. Das Löschen von Quellobjekten ist eine eigene Aufbewahrungsentscheidung und sollte niemals ein impliziter letzter Step der Bildverarbeitung sein.
Die Migration als operative Last messen
Verfolgen Sie importierte Objekte, verarbeitete Objekte, Ausgabe-Bytes, Fehler nach Klasse, Wiederholungsversuche und ungelöste Manifesteinträge. Vergleichen Sie die durch die Derivate erzielten Einsparungen mit den Kosten für Import, Verarbeitung, Export, Speicherung und spätere Auslieferung. Ein Backfill, der die Byte-Größe reduziert, sich aber nicht fortsetzen oder auditieren lässt, ist betrieblich nicht abgeschlossen.
Alarmieren Sie bei stockenden Seiten, wiederholten Quellidentitäten, Schreibvorgängen außerhalb des Zielpräfixes und unerwarteten öffentlichen ACLs. Halten Sie eine begrenzte Nebenläufigkeit ein, damit Verarbeitung und Google-API-Aktivität nicht mit dem gewöhnlichen Anwendungsverkehr konkurrieren oder die operativen Grenzwerte des Ziels erschöpfen.
Wissenswerte technische Details
- /google/import akzeptiert einen Dateipfad, einen mit einem Schrägstrich endenden Verzeichnispfad oder ein Array von Pfaden. Rekursive Verzeichnisimporte paginieren mit next_page_token und files_per_page, wobei das Token für den nächsten Aufruf in den Metadaten der importierten Dateien zurückgegeben wird. Dies unterscheidet sich von /supabase/import, das mit page_number paginiert.
- /image/resize mit resize_strategy auf fit bewahrt das Seitenverhältnis und hält jede Seite innerhalb der angeforderten Grenzen.
- /image/resize verwendet das Eingabeformat, wenn format auf null gesetzt ist; wird format auf webp gesetzt, entsteht bewusst ein WebP-Derivat.
- /google/store kann den Objektpfad, die ACL, Cache-Control-Metadaten und Ergebnis-URL-Vorlagen festlegen. Der dokumentierte Standardwert für die ACL ist public-read, sodass private für einen Workflow, in dem die Prüfung zuerst erfolgt, explizit gesetzt werden muss.
- Nur schreibende Google-Zugangsdaten benötigen storage.objects.create; storage.objects.delete wird nur benötigt, wenn der Workflow bestehende Pfade absichtlich überschreibt. Die verlinkte Google-Zugangsdaten-Dokumentation beschreibt nur die Schreibrolle, prüfen Sie daher die IAM-Dokumentation von Google Cloud auf die vom Import-Zugangsdaten-Eintrag benötigten Berechtigungen.
- Derselbe Anbieter auf beiden Seiten erfordert nicht dieselben Zugangsdaten, denselben Bucket oder denselben Schlüssel. Die Trennung von Lese- und Schreibberechtigung verringert die Auswirkung kompromittierter Template-Zugangsdaten.
Ein praxisnaher Ansatz
- 1
Wählen Sie ein repräsentatives Quellpräfix und definieren Sie einen nicht überlappenden Namensraum für die Ausgabe.
- 2
Erstellen Sie eingeschränkte Zugangsdaten für Lesen und Schreiben und speichern Sie das Template für Import, Größenänderung und Speicherung.
- 3
Verarbeiten Sie eine begrenzte Seite und vergleichen Sie Abmessungen, Farbe, Transparenz, Bytes und Objekt-Metadaten.
- 4
Führen Sie den Rollout mit Kontrollpunkten, idempotenten Datensätzen und einer reversiblen Referenzmigration durch.
Wann Transloadit hilfreich ist
Verwenden Sie /google/import, um ein Objekt oder ein paginiertes Präfix auszuwählen, /image/resize, um das geprüfte Derivat zu erstellen, und /google/store, um eine private Ausgabe zu schreiben. Trennen Sie nach Möglichkeit die Zugangsdaten für Lesen und Schreiben, und platzieren Sie Ausgaben niemals unter einem Präfix, das der nächste Import erneut aufnehmen würde.
Architekturgrenze
Google Cloud Storage bleibt die dauerhafte Quelle und das dauerhafte Ziel. Transloadit liest die ausgewählten Objekte, erstellt Bild-Derivate und schreibt neue Objekte, während die Anwendung für Inventar, Rollout, Löschung, Versionierung und die Entscheidung zum Austausch von Referenzen zuständig bleibt.
Häufig gestellte Fragen
Kann der Workflow das Quellobjekt überschreiben?
Ihm kann die Berechtigung zum Löschen und Schreiben erteilt werden, ein versioniertes Ziel ist jedoch sicherer. Es ermöglicht Überprüfung, Rollback und Koexistenz, während andere Systeme migrieren.
Können Import und Speicherung dieselben Google-Zugangsdaten verwenden?
Das ist möglich, doch separate Zugangsdaten für Lesen und Schreiben reduzieren die Berechtigungen und erleichtern die Prüfung der Grenze zwischen Quelle und Ziel.
Warum muss das Ausgabepräfix separat sein?
Andernfalls kann ein rekursiver Import frühere Derivate entdecken und erneut verarbeiten, wodurch sich Objekte vervielfachen und die Qualität sinkt.
Erzeugt die Fit-Größenänderung immer die angeforderte Breite und Höhe?
Nein. Fit erhält das Seitenverhältnis und hält jede Seite innerhalb der Grenzwerte. Exakte Abmessungen erfordern eine andere Strategie und eine ausdrückliche Entscheidung für Zuschneiden oder Auffüllen.
Sollten die Derivate öffentlich sein?
Halten Sie sie während der Validierung privat. Wählen Sie öffentlichen Zugriff oder eine Auslieferungsebene später entsprechend dem Autorisierungs- und Caching-Modell der Anwendung.