Ir a producción

La lista

• secret largo y aleatorio (openssl rand -hex 32), el mismo en cada proceso, desde el entorno, nunca en el código.
• identify desde tu sesión, y authorize con byRoles o reglas tuyas: nunca everyone().
• La regla de orígenes del bucket solo con tus dominios, ETag expuesto (Almacenamiento).
• maxSize y la quota de cada persona en los ajustes; trashDays para que la papelera se vacíe sola.
• Al menos inspect: checkType(), y ClamAV para archivos de gente que no conoces (Revisar las subidas).
• Postgres para más de un proceso (Metadatos), con sus copias.
• Una regla de ciclo de vida en el bucket, como la de abajo.
• clientIp detrás de tu proxy, y un limiter de Redis para más de un proceso (Ganchos, registros y límites).
• HTTP/2 delante: cada pestaña que escucha ocupa una conexión, y por HTTP/1.1 un navegador tiene seis por host. Una pestaña que no se ve suelta la suya.
• derive: deriveAll() con sharp y pdf.js instalados, para las imágenes y el texto de lo que ninguna página hizo (Vistas previas).

Subidas a medias

Una página cerrada a mitad de una subida deja sus partes en el bucket, que ocupan espacio y no aparecen en ningún sitio. El servidor las barre solo cada diez minutos, según llegan peticiones: las más viejas que la vida de sus tokens (un día) se abortan, solo bajo su prefix, y en el disco se quitan sus partes. Una regla de ciclo de vida del bucket hace lo mismo sin él:

{
  "Rules": [
    { "ID": "abort-unfinished", "Status": "Enabled", "Filter": { "Prefix": "" },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 2 } }
  ]
}

Copias de seguridad

Las entradas son lo que dice qué bytes son qué archivo: sin ellas, el bucket es un montón de ids. Cópialas como tu base de datos: pg_dump para Postgres, o para SQLite sqlite3 drive.sqlite ".backup backup.sqlite", que es seguro mientras el servidor escribe.

Los bytes nunca se cambian en su sitio: una versión es una clave nueva. Así que el versionado del bucket no hace falta para el drive, y una copia del bucket (R2 a S3, rclone) es una copia que solo crece. Borra en ella solo lo que borró el drive.

Rotar claves

• La clave del bucket: haz una nueva, dásela a cada proceso, y revoca la vieja pasadas dos horas: una dirección de descarga dura quince minutos, una para mostrar una imagen dos horas.
• El secret: uno nuevo termina las subidas en curso (sus tokens) y cambia las direcciones de los enlaces. Los enlaces hechos antes dejan de funcionar, porque se firman con él: hazlo a una hora tranquila, y avisa a quienes compartieron enlaces.

Detrás de un proxy

location /api/files/ {
  proxy_pass http://app;
  proxy_request_buffering off;   # the disk storage carries the bytes through the server
  client_max_body_size 64m;      # a part is 8 MiB, more for a file of over 80 GB
  proxy_read_timeout 1h;         # the events go on as long as the page watches
}

Con un bucket, los bytes no pasan por el proxy: solo las peticiones del drive, que son pequeñas, y los eventos, que duran.

Qué vigilar

El servidor escribe en la consola lo que no pudo hacer y no respondió: una actividad no guardada, onShare fallido, subidas sin barrer, un archivo que no se pudo revisar. Cada uno con su error. Un 500 no le dice nada de dentro a la página; la consola lo dice todo.