Points clés à retenir
- Importez un objet délimité ou une page d’un préfixe plutôt que de lancer une réécriture sans limites de tout le bucket.
- Écrivez les dérivés sous un préfixe distinct afin que les imports récursifs ne puissent pas traiter leurs propres sorties.
- Utilisez le redimensionnement par ajustement avec une taille maximale explicite pour préserver le rapport largeur/hauteur, et définissez zoom sur false afin de ne pas agrandir les originaux plus petits.
Le traitement rétroactif d’images n’est pas une modification sur place. C’est une migration reproductible d’un objet source connu vers un dérivé versionné dont la qualité, les dimensions, la destination et la référence dans l’application peuvent être vérifiées indépendamment. Garder l’import et l’export dans Google Cloud Storage préserve la responsabilité du stockage tout en déplaçant le traitement des médias hors des serveurs de l’application.
L’essentiel
- Privilégiez des ensembles d’informations d’identification de Template distincts pour la lecture et l’écriture, avec uniquement les droits nécessaires à chaque Step.
- Gardez les sorties privées jusqu’à ce que l’application les vérifie et modifie explicitement les références de diffusion.
- Enregistrez durablement la génération ou l’identité de version de la source, la version du flux de travail et le chemin de destination pour permettre une réexécution sûre.
Traiter la tâche comme un traitement rétroactif versionné
N’écrasez pas une bibliothèque d’images simplement parce qu’un nouveau format ou de nouvelles dimensions semblent meilleurs sur une donnée de test. Définissez d’abord l’ensemble des sources, la version de transformation, l’espace de noms de sortie, les contrôles d’acceptation et la migration des références. L’objet d’origine devrait rester récupérable jusqu’à ce que le dérivé ait été vérifié et que les consommateurs aient migré en toute sécurité.
Utilisez des chemins de sortie propres à chaque version pour que deux politiques de transformation puissent coexister pendant le déploiement et que le retour arrière reste un changement de référence. Le chemin de l’exemple est unique à chaque exécution et non dérivé de l’objet source : l’application doit donc empêcher les traitements répétés en vérifiant son propre enregistrement reliant la source au résultat avant de créer une autre Assembly.
Séparer les espaces de noms d’entrée et de sortie
Un Step récursif utilisant /google/import peut énumérer un préfixe source. Si /google/store écrit sous ce même préfixe, une page ultérieure ou une réexécution peut importer les dérivés générés comme s’il s’agissait d’originaux. Placez les sorties sous un préfixe sans chevauchement ou dans un bucket distinct, et rendez cette distinction évidente dans la configuration et la supervision.
Pour un préfixe volumineux, traitez une page de taille limitée et conservez next_page_token en dehors de l’Assembly pour l’appel suivant. L’exemple définit par défaut fields.next_page_token sur une chaîne vide pour la première page. Un ordonnanceur de confiance fournit le jeton renvoyé dans ce champ pour chaque Assembly suivante, sans déverrouiller les Steps. Le contenu du bucket peut changer pendant une migration : associez donc la pagination à un manifeste d’application ou à un inventaire des sources lorsqu’il est important de traiter chaque objet exactement une fois.
Préfixe source
Contient uniquement les originaux sélectionnés pour la politique de migration actuelle.
Préfixe de sortie
Contient les dérivés versionnés et n’est jamais parcouru par l’import des sources.
Manifeste de migration
Associe l’identité de la source à la version du flux de travail, à l’identifiant d’Assembly et à l’objet de destination.
Créer le Template de traitement d’images Google Storage
Le Step d’import sélectionne un fichier ou un préfixe délimité, /image/resize crée une image WebP dont les dimensions s’inscrivent dans le cadre choisi, et /google/store écrit le dérivé avec un accès privé. Définissez zoom sur false lorsque les petits originaux ne doivent pas être agrandis. Examinez le comportement de la transparence et des couleurs avant de faire de WebP le format contractuel pour chaque famille de sources.
L’exemple utilise des ensembles d’informations d’identification aux noms distincts pour les accès en lecture et en écriture. L’accès en lecture nécessite l’accès aux objets sources ; l’accès en écriture nécessite le droit de créer des objets à destination. Ajoutez le droit de suppression uniquement lorsqu’une politique d’écrasement intentionnel l’exige.
{
"allow_steps_override": false,
"fields": { "next_page_token": "" },
"steps": {
"source_images": {
"robot": "/google/import",
"credentials": "gcs-source-read",
"path": "originals/catalog/",
"recursive": true,
"next_page_token": "${fields.next_page_token}",
"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
}
}
}Valider la qualité des images et le comportement des objets
Utilisez des données de test couvrant l’orientation EXIF, la transparence, les profils colorimétriques intégrés, les très grandes dimensions, les petites sources, l’animation, les fichiers mal formés et les objets de même nom dans des dossiers différents. Comparez l’apparence après rendu ainsi que les dimensions, le format et la taille en octets. Un résultat plus léger qui modifie les couleurs ou supprime une animation requise ne constitue pas une migration réussie.
Définissez l’ACL délibérément. Le schéma de /google/store définit l’ACL sur public-read par défaut ; un flux de travail de révision privé doit donc remplacer cette valeur. Ajoutez une politique de cache uniquement si elle correspond au modèle final de diffusion et d’autorisation.
Déployer avec des points de contrôle et une possibilité de retour arrière
Enregistrez chaque objet source et chaque résultat à destination avant de modifier les références utilisées par les consommateurs. Rapprochez les éléments manquants ou en échec selon l’identité de leur source au lieu de retraiter le préfixe complet. Si le traitement d’une page échoue à mi-parcours, réessayez uniquement les objets sources que l’application n’a pas enregistrés comme terminés. Le chemin de l’exemple est unique à chaque exécution ; retraiter la même source écrit donc un nouvel objet. La déduplication repose sur l’enregistrement de correspondance entre source et résultat dans l’application, vérifié avant la création de l’Assembly.
Dirigez une petite cohorte de trafic vers les nouveaux chemins, comparez les volumes en octets et les métriques visuelles, puis élargissez le déploiement. Conservez les originaux et les anciennes références de l’application jusqu’à la fin de la période de retour arrière. La suppression des objets sources relève d’une décision de conservation distincte et ne devrait jamais être un Step final implicite du traitement des images.
Mesurer la migration comme une charge de travail opérationnelle
Suivez les objets importés, les objets traités, les octets produits, les échecs par catégorie, les nouvelles tentatives et les entrées non résolues du manifeste. Comparez les économies réalisées grâce aux dérivés avec les coûts d’import, de traitement, d’export, de stockage et de diffusion ultérieure. Un traitement rétroactif qui réduit le volume en octets, mais ne peut être ni repris ni audité, n’est pas complet sur le plan opérationnel.
Déclenchez des alertes en cas de pages bloquées, d’identités sources répétées, d’écritures hors du préfixe de destination et d’ACL publiques inattendues. Limitez le nombre de traitements simultanés afin que le traitement et l’activité de l’API Google ne concurrencent pas le trafic habituel de l’application et n’épuisent pas les limites opérationnelles de la destination.
Détails techniques à connaître
- /google/import accepte un chemin de fichier, un chemin de répertoire se terminant par une barre oblique ou un tableau de chemins. Les imports récursifs de répertoires utilisent next_page_token et files_per_page pour la pagination, et le jeton destiné à l’appel suivant est renvoyé dans les métadonnées des fichiers importés. Ce fonctionnement diffère de celui de /supabase/import, qui utilise page_number pour la pagination.
- /image/resize avec resize_strategy défini sur fit préserve le rapport largeur/hauteur et maintient chaque côté dans les limites demandées.
- /image/resize utilise le format d’entrée lorsque format vaut null ; définir format sur webp crée délibérément un dérivé WebP.
- /google/store peut définir le chemin de l’objet, l’ACL, les métadonnées Cache-Control et les modèles d’URL des résultats. Son ACL par défaut documentée est public-read ; private doit donc être défini explicitement pour un flux de travail où la révision précède la publication.
- Les informations d’identification Google limitées à l’écriture nécessitent storage.objects.create ; storage.objects.delete n’est nécessaire que lorsque le flux de travail écrase intentionnellement des chemins existants. La documentation Google sur les informations d’identification accessible via le lien décrit uniquement le rôle d’écriture ; consultez donc la documentation IAM de Google Cloud pour connaître les autorisations nécessaires aux informations d’identification d’import.
- Utiliser le même fournisseur à la source et à la destination n’impose pas le même ensemble d’informations d’identification, le même bucket ou la même clé. Séparer les droits de lecture et d’écriture réduit l’impact de la compromission d’un ensemble d’informations d’identification de Template.
Une approche pratique
- 1
Choisissez un préfixe source représentatif et définissez un espace de noms de sortie sans chevauchement.
- 2
Créez des informations d’identification de lecture et d’écriture au périmètre limité, puis enregistrez le Template d’import, de redimensionnement et de stockage.
- 3
Traitez une page de taille limitée et comparez les dimensions, la couleur, la transparence, le nombre d’octets et les métadonnées des objets.
- 4
Déployez avec des points de contrôle, des enregistrements idempotents et une migration réversible des références.
Quand Transloadit est utile
Utilisez /google/import pour sélectionner un objet ou un préfixe paginé, /image/resize pour créer le dérivé soumis à vérification et /google/store pour écrire une sortie privée. Séparez si possible les informations d’identification de lecture et d’écriture, et ne placez jamais les sorties sous un préfixe que l’import suivant ingérera à nouveau.
Périmètre architectural
Google Cloud Storage reste la source et la destination durables. Transloadit lit les objets sélectionnés, crée des images dérivées et écrit de nouveaux objets, tandis que l’application reste responsable de l’inventaire, du déploiement, de la suppression, de la gestion des versions et de la décision de remplacer les références.
Questions fréquentes
Le flux de travail peut-il écraser l’objet source ?
Vous pouvez lui accorder des droits de suppression et d’écriture, mais une destination versionnée est plus sûre. Elle permet la vérification, le retour arrière et la coexistence pendant la migration des consommateurs.
L’import et le stockage peuvent-ils utiliser les mêmes informations d’identification Google ?
Oui, mais des informations d’identification distinctes pour la lecture et l’écriture réduisent les droits accordés et facilitent l’audit de la séparation entre source et destination.
Pourquoi le préfixe de sortie doit-il être distinct ?
Sans cette séparation, un import récursif peut découvrir des dérivés antérieurs et les traiter à nouveau, ce qui multiplie les objets et dégrade la qualité.
Le redimensionnement par ajustement produit-il toujours la largeur et la hauteur demandées ?
Non. Le redimensionnement par ajustement préserve le rapport largeur/hauteur et maintient chaque côté dans les limites. Des dimensions exactes nécessitent une autre stratégie et une décision explicite de recadrage ou d’ajout de marges.
Les dérivés doivent-ils être publics ?
Gardez-les privés pendant la validation. Choisissez ensuite un accès public ou une couche de diffusion selon le modèle d’autorisation et de mise en cache de l’application.