Limpieza de Espacio en el Social - Alojamiento S3

Hola,

En esta publicación quiero comentar dos temas sobre la instalación de Mastodon que tenemos en Anartist que están relacionadas:

  1. Por un lado, tras años de funcionamiento sin ningún tipo de limpieza hemos acumulado muuuuchos ficheros de publicaciones remotas que hay que limpiar.
  2. Quien montó la instalación lo hizo de forma que usáramos (sin coste) espacio S3 de los servidores de Amazon (de ahí a que no se haya llenado el servidor sin mantenimiento). Esto es muy grave, pero aunque lo detecté hace tiempo, no he tenido tiempo para cambiarlo. Sin embargo, tras hacer limpieza en el punto 1 yo propongo contratar otro servicio de S3 y migrar ahí lo que tenemos. Se me ocurren dos opciones:
    2.1. Usar un proveedor. En este caso propongo Scaleway. No es la panacea, pero los servidores están en EU. Tras un cálculo aproximado, creo que nos sale a unos 2€ al mes.
    2.2. Montar un server S3 en nuestro propio servidor con MinIO.

En cuanto al punto 1, ejecuté en el servidor el siguiente comando:

RAILS_ENV=production ./bin/tootctl media usage

Attachments:    852 GB (960 MB local)
Custom emoji:   1.09 GB (2 MB local)
Preview cards:  43.8 GB
Avatars:        17.8 GB (2.39 MB local)
Headers:        42.5 GB (10.2 MB local)
Backups:        0 Bytes
Imports:        0 Bytes
Settings:       142 KB

Como podéis ver, la cantidad de “attachments” y de “preview cards” es enorme. Hay que recordar que nunca hemos hecho limpieza y el servidor lleva años en marcha.

He ejecutado los siguientes comandos (están en la documentación)

RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove
RAILS_ENV=production /home/mastodon/live/bin/tootctl preview_cards remove

Estos comandos eliminan contenido multimedia remoto (es decir publicado por usuarias de otros nodos) con una anterioridad de 7 y 180 días respectivamente. Hay que aclarar que el contenido se puede volver a acceder si alguna de nuestras usuarias busca la publicación remota de nuevo.

Tras ejecutarlos, he vuelto a comprobar la ocupación de espacio:

Attachments:    15.3 GB (960 MB local)
Custom emoji:   1.09 GB (2 MB local)
Preview cards:  27.2 GB
Avatars:        17.8 GB (2.39 MB local)
Headers:        42.5 GB (10.2 MB local)
Backups:        0 Bytes
Imports:        0 Bytes
Settings:       142 KB

Como veis, hemos hecho una buena limpieza, sobretodo de “attachments”.

Siguiendo la documentación, he añadido las siguientes lineas al cron para que haga una limpieza semanal:

@weekly RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove
@weekly RAILS_ENV=production /home/mastodon/live/bin/tootctl preview_cards remove

En cuanto pueda, me pongo con el punto 2.

6 Me gusta

Tarea imprescindible. Muchísimas gracias.
Respecto de las opciones para el servicio S3, las opciones en precio entre Scaleway y MinIO, ¿dependen del constante mantenimiento-limpieza? Con MinIO se hace un solo pago al año y el precio en dólares es enorme, ¿cierto? ¿Será que la lista de precios-memoria en Scaleway depende de que se limpie regularmente?

1 me gusta

:heart:

Aquí hay dos temas. La opción de MinIO sería para instalarlo en uno de nuestros servidores, así que no habría coste de alojamiento, en principio. La contrapartida es que se tiene que configurar y aunque una configuración sencilla no me pareció muy difícil, no quiere decir que esté optimizada.
Por otro lado, el coste del servicio S3 de Scaleway depende de su uso, así que cuanto más se llene más costará. Respondiendo a tu pregunta, sí: dependen del mantenimiento-limpieza. Hay que decir que he automatizado las limpiezas que comentaba al principio para que se hagan de forma semanal. En ese sentido no hay problema.

1 me gusta

Menuda limpieza! Muchas gracias :rocket:

¿Has probado el comando tootctl media remove-orphans?

¿Cómo se usa S3 sin coste alguno? Y ¿en qué sentido es muy grave hacerlo?

1 me gusta

Gracias por la sugerencia!

Lo he ejecutado y ha eliminado unos 800 MB de archivos. Aunque no sea mucho, lo incorporo al cron.

1 me gusta

Hola,

Estoy haciendo la migración del espacio con objetos S3. De momento no acaba de funcionar y las imágenes dan error. Intento solucionarlo en cuanto pueda.

Disculpad las molestias!

Ya funciona bien con las nuevas imágenes. Parece que hemos conseguido librarnos de Amazon! No sé si conseguiré las que se han perdido, pero bueno. No son muchas.

Cuando pueda publicaré los pasos que he seguido para instalar el MiniO en un VPS de anartist, migrar toda los ficheros y configurarlo todo.

3 Me gusta

Hola,

Documento aquí el proceso de instalación y configuración de MinIO y la migración de los ficheros.


Recursos consultados

https://min.io/docs/minio/linux/operations/network-encryption.html

Instalación de MinIO

Tras crear un nuevo VPS y actualizarlo a la versión de Ubuntu 22.04, instalo MinIO:

wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio_20240326221045.0.0_amd64.deb -O minio.deb
sudo dpkg -i minio.deb

Creación de un usuario específico:

sudo groupadd -r minio-user
sudo useradd -M -r -g minio-user minio-user

Creación de la ubicación de los ficheros:

sudo vim /etc/default/minio
sudo mkdir /opt/s3.social
sudo chown minio-user:minio-user /opt/s3.social

Edito el fichero de configuración de minio para incorporar esta última ubicación:

sudo vim /etc/default/minio

Inicio del servicio de minio para que se ejecute cada vez que se encienda el servidor:

sudo systemctl start minio.service 
sudo journalctl -f -u minio.service
sudo systemctl enable minio.service

Instalación y configuración de Nginx:

sudo apt install nginx
sudo vim /etc/nginx/sites-available/minio

Fichero nginx:

upstream minio {
    server 127.0.0.1:9000;
}

server {
    listen 80;
    listen [::]:80;

    # regex: Make bucket subdomains work
    server_name ~^([^.]+).s3.anartist.org s3.anartist.org;

    # Allow special characters in headers
    ignore_invalid_headers off;
    # Allow any size file to be uploaded.
    # Set to a value such as 1000m; to restrict file size to a specific value
    client_max_body_size 0;
    # Disable buffering
    proxy_buffering off;
    proxy_request_buffering off;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 300;
        # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        chunked_transfer_encoding off;

        proxy_pass http://minio; # This uses the upstream directive definition to load balance
    }
}
sudo ln -s /etc/nginx/sites-available/minio /etc/nginx/sites-enabled/
sudo rm /etc/nginx/sites-enabled/default

Instalación de certificado de Let’s Encrypt:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d s3.anartist.org

Creación de Bucket para el social

Accedo al panel a través de http://95.217.142.136:9001.
Creo un Bucket con el nombre socialdata.
Configuro la access policy a custom con el siguiente código:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": {
           "AWS": "*"
         },
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::socialdata/*"
      }
   ]
}

Creación de mastodon-readwrite policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::socialdata/*"
        }
    ]
}

Creación de usuario mastodon y asignación de política mastodon-readwrite. `

Creación de un Acceso API a través del panel con los siguientes permisos:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::socialdata"
            ]
            },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::socialdata/*"
            ]
        }
    ]
}`

Migración de los datos de Amazon a MinIO

Para ello voy a usar la herramienta rclone:

sudo apt install rclone
rclone config

Esto genera el fichero .config/rclone/rclone.conf

[amazon]
type = s3
provider = Amazon
env_auth = false
access_key_id = XXXXXXXXX
secret_access_key = XXXXXXXXX
region = eu-central-1
endpoint = s3-eu-central-1.amazonaws.com
acl = public-read
storage_class = STANDARD

[minio]
type = s3
provider = Minio
env_auth = false
access_key_id = XXXXXXXXX
secret_access_key = XXXXXXXXX
region = eu-central-1
endpoint = https://s3.anartist.org
acl = public-read

Con esto ya puedo copiar los ficheros del s3 de Amazon al de MinIO:

rclone copy --progress --transfers=8 amazon:anartist2/custom_emojis/ minio:socialdata/custom_emojis/
rclone copy --progress --transfers=8 amazon:anartist2/accounts/ minio:socialdata/accounts/
rclone copy --progress --transfers=8 amazon:anartist2/site_uploads/ minio:socialdata/site_uploads/
rclone copy --progress --transfers=8 amazon:anartist2/media_attachments/ minio:socialdata/media_attachments/
rclone copy --progress --transfers=8 amazon:anartist2/imports/ minio:socialdata/imports/
rclone copy --progress --transfers=8 amazon:anartist2/cache/accounts/ minio:socialdata/cache/accounts/
rclone copy --progress --transfers=8 amazon:anartist2/cache/custom_emojis/ minio:socialdata/cache/custom_emojis/
rclone copy --progress --transfers=8 amazon:anartist2/cache/preview_cards/ minio:socialdata/cache/preview_cards/
rclone copy --progress --transfers=8 amazon:anartist2/cache/media_attachments/ minio:socialdata/cache/media_attachments/

Esto tarda mucho, lo que hace que durante la transferencia se publique alguna imagen que no sea transferida. Por suerte no son muchas y no es muy grave.

Finalmente, hace falta cambiar la configuración del fichero .env.production de mastodon (hago una copia antes de modificarlo) cambiando la parte de S3:

S3_ENABLED=true
S3_BUCKET=socialdata
AWS_ACCESS_KEY_ID=XXXXXXXX
AWS_SECRET_ACCESS_KEY=XXXXXXXX
S3_REGION=eu-central-1
S3_PROTOCOL=https
S3_HOSTNAME=s3.anartist.org
S3_ENDPOINT=https://s3.anartist.org

Y reinicio los servicios de mastodon:

sudo systemctl restart mastodon-sidekiq
sudo systemctl reload mastodon-web
sudo systemctl restart mastodon-streaming
2 Me gusta

Tras preguntar un poco por internet (lo podría haber hecho antes), creo que lo mejor es volver a ponerlo en espacio local (como estaría al principio, aunque hacía años que el espacio estaba en Amazon), será más eficiente.

En cuanto pueda lo hago.

¡Menudo curri!
Gracias :heart:

Voy a hacer la migración de los ficheros a local el próximo sábado 6 de Abril a las 10h horario español en la península ibérica. Por si alguien quiere ver/acompañar.

Un saludo!

Yo me apunto!

1 me gusta

Voy a conectarme a https://meet.exo.cat/anartist

Hola!

Con @RickyAKA hemos migrado el almacenamiento del servidor externo de MinIO al propio servidor local de Mastodon.

  1. Lo primero ha sido aumentar la capacidad en 150 GB el VPS a través del panel de Virtualizor.
  2. Tras parar los servicios de mastodon he copiado mediante scp las carpetas del bucket excepto las de caché (accounts,custom_emojis, site_uploads y media_attachments).
  3. Tras hacer una copia de seguridad del fichero, he cambiado la variable S3_ENABLED del fichero de configuración .env.production a false y he eliminado el resto de variables S3.
  4. Tras reiniciar los servicios hemos visto que no estaba pudiendo acceder a los ficheros. Ahí nos hemos dado cuenta que no se pueden copiar los ficheros del bucket directamente porque los almacena de forma diferente. Tenemos que usar una herramienta que antes de copiar los ficheros los transforme al fichero real.
  5. Usando el mismo rclone que usamos para migrar de Amazon, se consigue lo que queremos:
mkdir teststorage
rclone copy --progress --transfers=8 minio:socialdata/cache/accounts/ teststorage/accounts/
rclone copy --progress --transfers=8 minio:socialdata/cache/custom_emojis/ teststorage/custom_emojis/
rclone copy --progress --transfers=8 minio:socialdata/cache/site_uploads/ teststorage/site_uploads/
rclone copy --progress --transfers=8 minio:socialdata/cache/media_attachments/ teststorage/media_attachments/
  1. Lo copiamos a la carpeta a dónde por defecto mastodon busca ficheros locales (public/system/):
sudo cp -r teststorage/* /home/mastodon/live/public/system/
sudo chown -R mastodon:mastodon /home/mastodon/live/public/system/*
  1. Volvemos a levantar los servicios de mastodon:
sudo systemctl restart mastodon-sidekiq
sudo systemctl reload mastodon-web
  1. Ahora nos queda volver a descargar el contenido de cuentas remotas (ficheros, avatares, etc.) que se almacenan en la carpeta cache con este comando:
RAILS_ENV=production ./bin/tootctl accounts refresh --all

Y ya está. Ahora está en ello, descargando contenido remoto.

Buen fin de semana!

1 me gusta

Hola!

Con @RickyAKA hemos migrado el almacenamiento del servidor externo de MinIO al propio servidor local de Mastodon.

  1. Lo primero ha sido aumentar la capacidad en 150 GB el VPS a través del panel de Virtualizor.
  2. Tras parar los servicios de mastodon he copiado mediante scp las carpetas del bucket excepto las de caché (accounts,custom_emojis, site_uploads y media_attachments).
  3. Tras hacer una copia de seguridad del fichero, he cambiado la variable S3_ENABLED del fichero de configuración .env.production a false y he eliminado el resto de variables S3.
  4. Tras reiniciar los servicios hemos visto que no estaba pudiendo acceder a los ficheros. Ahí nos hemos dado cuenta que no se pueden copiar los ficheros del bucket directamente porque los almacena de forma diferente. Tenemos que usar una herramienta que antes de copiar los ficheros los transforme al fichero real.
  5. Usando el mismo rclone que usamos para migrar de Amazon, se consigue lo que queremos:
mkdir teststorage
rclone copy --progress --transfers=8 minio:socialdata/cache/accounts/ teststorage/accounts/
rclone copy --progress --transfers=8 minio:socialdata/cache/custom_emojis/ teststorage/custom_emojis/
rclone copy --progress --transfers=8 minio:socialdata/cache/site_uploads/ teststorage/site_uploads/
rclone copy --progress --transfers=8 minio:socialdata/cache/media_attachments/ teststorage/media_attachments/
  1. Lo copiamos a la carpeta a dónde por defecto mastodon busca ficheros locales (public/system/):
sudo cp -r teststorage/* /home/mastodon/live/public/system/
sudo chown -R mastodon:mastodon /home/mastodon/live/public/system/*
  1. Volvemos a levantar los servicios de mastodon:
sudo systemctl restart mastodon-sidekiq
sudo systemctl reload mastodon-web
  1. Ahora nos queda volver a descargar el contenido de cuentas remotas (ficheros, avatares, etc.) que se almacenan en la carpeta cache con este comando:
RAILS_ENV=production ./bin/tootctl accounts refresh --all

Y ya está. Ahora está en ello, descargando contenido remoto.

Buen fin de semana!

1 me gusta

Hola!

He dado más espacio al servidor del social (mastodon), ahora que tenemos todo en local. Le he dado 500 GB.

1 me gusta

No sé si esto se está ejecutando bien, el espacio del VPS se va llenando día a día (lo veo en el Report diario que me mando por correo). Cuando pueda lo reviso. Si no, aún tenemos margen de más espacio, pero igual habrá que reducir el margen de días que el contenido remoto se mantiene.

1 me gusta

Bueno, es evidente que no se estaba ejecutando. Tras ejecutar los comandos, ha bajado la ocupación de disco del 74% al 31%.

He sustituido la programación del cron al sistema clásico (lo de “@weekly” lo ponía en la documentación de mastodon, pero igual no funciona siempre).

# m h  dom mon dow   command
1 1 * * 1 RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove
1 1 * * 1 RAILS_ENV=production /home/mastodon/live/bin/tootctl preview_cards remove
1 1 * * 1 RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove-orphans
3 Me gusta

¡Gracias, apreciado Marcel!

1 me gusta