Mover de un bucket S3 a otro

Soporte
1

Continuando la discusión desde ¿Cómo muevo mi bucket de carga de S3 de un proveedor a otro?:

Estoy intentando migrar desde un bucket de GCP a un bucket de AWS S3. El sistema antiguo no utilizaba un CDN de S3 (al parecer, la persona que lo configuró no sabía realmente lo que hacía).

Usé s3cmd para sincronizar el bucket antiguo de GCP con un sistema de archivos local y luego lo usé nuevamente para enviar los recursos al nuevo bucket de S3. El sistema ahora está correctamente configurado con S3 y CDNs del sitio, tal como se describe en Uso de almacenamiento de objetos para cargas (S3 y clones).

El tema vinculado anteriormente sugería usar rake posts:remap para actualizar las publicaciones (supongo que también debería volver a hornear todas las publicaciones, ¿o al menos las que coincidan con el bucket antiguo?).

Cuando ejecuté posts:remap, solo se volvió a mapear una publicación.

 Upload.order(Arel.sql('RANDOM()')).limit(10).pluck(:id, :url)

muestra que todas ellas tienen el bucket antiguo… Ah, ese es el problema. No necesitamos un rake posts:remap, sino un discourse remap, tal como se describe en Change the domain name or rename your Discourse.

Sí, creo que sí.

Voy a ver cómo hacerlo muy pronto. @Falco, en términos generales, es algo como:

  • Crear un nuevo bucket y su CDN, reconstruir el contenedor para usar el nuevo bucket/CDN y asegurarse de que funcione.
  • Configurar s3cmd para el bucket antiguo y sincronizar los datos localmente.
  • Configurar s3cmd para el nuevo bucket y sincronizar los datos hacia arriba al nuevo bucket.
  • Ejecutar discourse remap NOMBRE-DE-DOMINIO-DEL-BUCKET-ANTIGUO NOMBRE-DE-DOMINIO-DEL-BUCKET-NUOVO.
  • Volver a hornear.

¿Parece correcto?

Si usas el mismo CDN para el bucket antiguo y el nuevo, podrías evitar tener que volver a hornear, pero lograr ese timing exactamente parece un poco complicado (no se puede cambiar el origen del CDN hasta que los datos estén en el nuevo bucket, pero necesitarías asegurarte de que nada se cargara en el bucket antiguo durante el proceso de sincronización). Quizás simplemente digamos que es posible.

2 Me gusta
2

¿Quizás sería mejor utilizar la CLI oficial de AWS para una guía?

Usa DbHelper.remap aquí.

No es necesario.

Usa la misma CDN y simplemente cambia el origen de la CDN en el panel de la CDN, o usa una CDN nueva y realiza el remapeo con DbHelper.remap. En ningún caso es necesario hacer un rebake.

2 Me gusta
3

Ah. Vale. Lo revisaré… ¿Es posible hacer que la CLI de AWS funcione con buckets que no son de AWS?

4

¡Hola, Rafael! Estoy cerca. Mi versión actual de este manual apunta a aws cli y gsutil para sincronizar desde el antiguo al local y del local al nuevo (solo enlazo a esas herramientas y proporciono un comando de línea de comandos con los nombres de los buckets rellenados en un marcador de posición). Luego utiliza DbHelper para actualizar las tablas. Para mi sitio de tamaño moderado, funciona bastante rápido. Genial.

El único problema que tengo ahora es que la configuración antigua no tenía un s3_cdn_url, por lo que esas imágenes aún están enlazadas directamente al bucket (no al CDN) en las publicaciones. Volver a hornear (rebake) no ayuda. Las nuevas subidas están correctamente enlazadas al CDN. No puedes solucionar esto estableciendo DISCOURSE_S3_ENDPOINT: '' porque eso no tiene efecto, así que después de restaurar la base de datos, tuve que borrar la configuración del sitio (SiteSetting). No es tan grave, pero me llevó varios reconstrucciones darme cuenta de eso.

La configuración antigua no tenía un CDN de S3 definido. Puedo solucionar esto volviendo a hornear las 1250 publicaciones que tienen la URL o el nombre de host del bucket, pero esto hace que todas esas imágenes se descarguen y optimicen (el servidor antiguo ejecuta la versión 2.7.0.beta5, así que pensé que ya tendría algunas optimizaciones recientes realizadas). Esto satura (promedio de carga de 10-20) a mi pobre servidor de 2 GB (con Postgres y Redis en RDS y ElastiCache) durante bastante tiempo. Supongo que quizás necesite un EC2 más grande para este sitio de todos modos, pero todavía me sorprende un poco que este rebake deje al servidor sin aliento (errores 500 en la interfaz de usuario).

¿Debería en su lugar idear un reemplazo del nombre de host del bucket por la URL del CDN en el campo cooked de esas publicaciones?

5

@pfaffman Gracias por guiarme hasta aquí.
Pero mi problema se complica en los últimos dos pasos.

Problema actual: Algunas de mis imágenes faltan y se muestran pequeños iconos en su lugar. Si paso el puntero sobre ellas, se muestra la dirección ‘olds3bucket’. Sin embargo, al hacer clic en ellas, se muestran correctamente en tamaño completo y ahora la ruta de ‘news3bucket’ aparece en la barra de URL.

  1. Principalmente, me indicaste sincronizar los datos del bucket antiguo con el nuevo, lo cual ya he realizado con éxito.
  2. Luego, configurar la nueva bucket en la interfaz web de Discourse, la cual ya estoy utilizando desde hace un año.
  3. Ahora dices que debo ‘remapear’ la URL del bucket antiguo con la nueva y luego ‘rehornear’. Aquí está el problema. Cuando hago esto (o incluso si solo ‘rehorneo’, o si selecciono ‘Reconstruir HTML’ desde el menú de configuración de la publicación, con o sin realizar primero el paso de ‘remapeo’), aquellas imágenes que solo se mostraban como un icono desaparecen por completo. Solo se muestra un ‘espacio en blanco’ en su lugar. Por lo tanto, debo revertir/restaurar inmediatamente.

Gracias nuevamente.
(Tengo un sitio web muy pequeño, y de igual manera tengo…).

6

rclone es una buena herramienta que puede sincronizar con varios backends. Actualmente lo utilizamos para copias de seguridad.

7

¡Hola Jay!

Lo siento por insistir, pero ¿has avanzado más en la guía? ¡Gracias!