Procesa imágenes de Google Cloud Storage de forma segura

Conclusiones clave

Importa un objeto acotado o una página de un prefijo, en lugar de iniciar una reescritura ilimitada de todo el bucket.
Escribe los derivados en un prefijo distinto para que las importaciones recursivas no procesen sus propias salidas.
Usa el redimensionado fit con un tamaño máximo explícito para conservar la relación de aspecto, y define zoom como false para que los originales más pequeños no se amplíen.

Una migración masiva de imágenes no es una edición in situ. Es una migración repetible desde un objeto de origen conocido hacia un derivado versionado cuya calidad, dimensiones, destino y referencia de la aplicación pueden verificarse de forma independiente. Mantener la importación y la exportación en Google Cloud Storage preserva el control sobre el almacenamiento y a la vez saca el trabajo con contenido multimedia de los servidores de la aplicación.

Trata el trabajo como una migración masiva versionada

No sobrescribas un conjunto de imágenes solo porque un nuevo formato o dimensión se vea mejor en una entrada de prueba preparada. Define primero la población de origen, la versión de la transformación, el espacio de nombres de salida, los controles de aceptación y la migración de referencia. El objeto original debería seguir siendo recuperable hasta que se haya verificado el derivado y los consumidores hayan migrado de forma segura.

Usa rutas de salida con versión para que dos políticas de transformación puedan coexistir durante el despliegue y para que la reversión sea solo un cambio de referencia. La ruta de ejemplo es única por ejecución en lugar de derivarse del objeto de origen, por lo que la aplicación debe evitar el procesamiento duplicado comprobando su propio registro de origen a resultado antes de crear otra Assembly.

Separa los espacios de nombres de entrada y salida

Un Step recursivo de /google/import puede enumerar un prefijo de origen. Si /google/store escribe bajo ese mismo prefijo, una página posterior o una reejecución puede importar los derivados generados como si fueran originales. Coloca las salidas en un prefijo sin solapamiento o en un bucket separado, y haz que la distinción sea evidente en la configuración y en el monitoreo.

Para un prefijo grande, procesa una página acotada y conserva next_page_token fuera de la Assembly para la siguiente llamada. El contenido del bucket puede cambiar durante una migración, así que combina la paginación con un manifiesto de la aplicación o un inventario de origen cuando sea importante que cada objeto quede cubierto exactamente una vez.

Prefijo de origen

Contiene solo los originales seleccionados para la política de migración actual.

Prefijo de salida

Contiene derivados con versión y la importación de origen nunca lo recorre.

Manifiesto de migración

Asigna la identidad de origen a la versión del flujo de trabajo, el ID de la Assembly y el objeto de destino.

Crea el Template de imágenes de Google Storage

El Step de importación selecciona un archivo o un prefijo acotado, /image/resize crea un WebP cuyas dimensiones encajan dentro del cuadro elegido, y /google/store escribe el derivado como privado. Configura zoom en false cuando los originales pequeños no deban ampliarse. Revisa el comportamiento de la transparencia y del color antes de convertir WebP en el contrato para cada familia de origen.

El ejemplo usa nombres de credencial distintos para el acceso de lectura y de escritura. El lector necesita acceso a los objetos de origen; el escritor necesita permiso de creación de objetos en el destino. Agrega el permiso de eliminación solo cuando una política de sobrescritura intencional lo requiera.

Leer originales y escribir derivados WebP con versión en un prefijo separado

{
  "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
    }
  }
}

Valida la calidad de la imagen y el comportamiento de los objetos

Usa datos de prueba que cubran orientación EXIF, transparencia, perfiles de color incrustados, dimensiones muy grandes, orígenes pequeños, animación, archivos malformados y objetos con el mismo nombre en carpetas distintas. Compara la apariencia renderizada además de las dimensiones, el formato y el tamaño en bytes. Una salida más pequeña que cambia el color o elimina una animación requerida no es una migración exitosa.

Define la ACL de forma deliberada. El esquema de /google/store establece la ACL en public-read de forma predeterminada, por lo que un flujo de trabajo de revisión privado debe anularla. Añade una política de caché solo cuando coincida con el modelo de entrega y autorización previsto.

Despliega con puntos de control y reversión

Registra cada objeto de origen y su resultado de destino antes de cambiar las referencias de los consumidores. Concilia los elementos faltantes o fallidos por identidad de origen en lugar de reejecutar todo el prefijo. Si una página falla a medio camino, reintenta solo los objetos de origen que la aplicación no haya registrado como completados. La ruta de ejemplo es única por ejecución, así que procesar de nuevo el mismo origen escribe un objeto nuevo; la deduplicación proviene del registro de origen a resultado de la aplicación, comprobado antes de crear la Assembly.

Traslada una pequeña cohorte de tráfico a las rutas nuevas, compara bytes y métricas visuales, y luego amplía. Conserva los originales y las referencias anteriores de la aplicación hasta que se cierre la ventana de reversión. Eliminar los objetos de origen es una decisión de retención separada y nunca debería ser un Step final implícito del procesamiento de imágenes.

Mide la migración como una carga de trabajo operativa

Registra los objetos importados, los objetos procesados, los bytes de salida, los fallos por clase, los reintentos y las entradas del manifiesto sin resolver. Compara el ahorro en derivados con los costos de importación, procesamiento, exportación, almacenamiento y entrega final. Una migración masiva que reduce bytes pero no se puede reanudar ni auditar no está operativamente completa.

Configura alertas para páginas estancadas, identidades de origen repetidas, escrituras fuera del prefijo de destino y ACL públicas inesperadas. Mantén un nivel de concurrencia acotado para que el procesamiento y la actividad de la API de Google no compitan con el tráfico ordinario de la aplicación ni agoten los límites operativos del destino.

Detalles técnicos que conviene conocer

/google/import acepta una ruta de archivo, una ruta de directorio que termina en barra, o un array de rutas. Las importaciones recursivas de directorios se paginan con next_page_token y files_per_page, y el token para la siguiente llamada se devuelve en los metadatos de los archivos importados. Esto difiere de /supabase/import, que se pagina con page_number.
/image/resize con resize_strategy configurado en fit conserva la relación de aspecto y mantiene cada lado dentro de los límites solicitados.
/image/resize usa el formato de entrada cuando format es null; configurar format en webp crea deliberadamente un derivado WebP.
/google/store puede definir la ruta del objeto, la ACL, los metadatos de Cache-Control y las plantillas de URL del resultado. Su ACL predeterminada documentada es public-read, por lo que private debe establecerse explícitamente en un flujo de trabajo centrado en la revisión previa.
Las credenciales de Google de solo escritura necesitan storage.objects.create; storage.objects.delete solo es necesario cuando el flujo de trabajo sobrescribe rutas existentes de forma intencional. La documentación de la credencial de Google enlazada describe únicamente el rol de escritura, así que consulta la documentación de IAM de Google Cloud para conocer los permisos que necesita la credencial de importación.
Usar el mismo proveedor en ambos extremos no exige la misma credencial, el mismo bucket ni la misma clave. Separar la autoridad de lectura y de escritura reduce el impacto de una credencial de Template comprometida.

Un enfoque práctico

1
Elige un prefijo de origen representativo y define un espacio de nombres de salida sin superposiciones.
2
Crea credenciales de lectura y escritura de alcance limitado y guarda el Template de importar, redimensionar y guardar.
3
Procesa una página delimitada y compara dimensiones, color, transparencia, bytes y metadatos del objeto.
4
Realiza el despliegue con puntos de control, registros idempotentes y una migración de referencias reversible.

Un flujo de trabajo multimedia de cuatro etapas

Cuándo resulta útil Transloadit

Usa /google/import para seleccionar un objeto o un prefijo paginado, /image/resize para crear el derivado revisado y /google/store para escribir una salida privada. Separa las credenciales de lectura y escritura cuando sea posible, y nunca coloques las salidas bajo un prefijo que la siguiente importación vuelva a recibir.

Límite de la arquitectura

Google Cloud Storage sigue siendo la fuente y el destino duraderos. Transloadit lee los objetos seleccionados, crea derivados de imagen y escribe nuevos objetos, mientras que la aplicación es responsable del inventario, el despliegue, la eliminación, el versionado y la decisión de reemplazar referencias.

Preguntas frecuentes

¿Puede el flujo de trabajo sobrescribir el objeto de origen?

Se le puede otorgar autoridad para eliminar y escribir, pero un destino versionado es más seguro. Permite revisión, reversión y coexistencia mientras los consumidores migran.

¿Pueden la importación y el almacenamiento usar las mismas credenciales de Google?

Pueden hacerlo, pero usar credenciales de lectura y escritura separadas reduce la autoridad y facilita auditar el límite entre la fuente y el destino.

¿Por qué el prefijo de salida debe ser independiente?

De lo contrario, una importación recursiva puede descubrir derivados anteriores y procesarlos de nuevo, multiplicando los objetos y degradando la calidad.

¿El redimensionado con fit siempre crea el ancho y el alto solicitados?

No. Fit conserva la relación de aspecto y mantiene cada lado dentro de los límites. Obtener dimensiones exactas requiere una estrategia diferente y una decisión explícita de recorte o relleno.

¿Deberían los derivados ser públicos?

Mantenlos privados durante la validación. Elige el acceso público o una capa de entrega más adelante según el modelo de autorización y caché de la aplicación.

Procesa imágenes de Google Cloud Storage y vuelve a escribirlas de forma segura