En esta publicación quiero comentar dos temas sobre la instalación de Mastodon que tenemos en Anartist que están relacionadas:
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.
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:
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:
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?
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.
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.
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.
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
}
}
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:
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:
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.
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.
Con @RickyAKA hemos migrado el almacenamiento del servidor externo de MinIO al propio servidor local de Mastodon.
Lo primero ha sido aumentar la capacidad en 150 GB el VPS a través del panel de Virtualizor.
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).
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.
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.
Usando el mismo rclone que usamos para migrar de Amazon, se consigue lo que queremos:
Con @RickyAKA hemos migrado el almacenamiento del servidor externo de MinIO al propio servidor local de Mastodon.
Lo primero ha sido aumentar la capacidad en 150 GB el VPS a través del panel de Virtualizor.
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).
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.
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.
Usando el mismo rclone que usamos para migrar de Amazon, se consigue lo que queremos:
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.
No sé porqué la programación de las limpiezas no funciona…
He añadido esta linea al cron:
40 8 * * * echo "test" > /home/mastodon/test.txt
Y se ha generado el siguiente error:
/usr/lib/ruby/2.7.0/bundler/definition.rb:495:in `validate_ruby!': Your Ruby version is 2.7.0, but your Gemfile specified >= 3.0.0 (Bundler::RubyVersionMismatch)
from /usr/lib/ruby/2.7.0/bundler/definition.rb:470:in `validate_runtime!'
from /usr/lib/ruby/2.7.0/bundler.rb:143:in `setup'
from /usr/lib/ruby/2.7.0/bundler/setup.rb:20:in `block in <top (required)>'
from /usr/lib/ruby/2.7.0/bundler/ui/shell.rb:136:in `with_level'
from /usr/lib/ruby/2.7.0/bundler/ui/shell.rb:88:in `silence'
from /usr/lib/ruby/2.7.0/bundler/setup.rb:20:in `<top (required)>'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require'
from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require'
from /home/mastodon/live/config/boot.rb:10:in `<top (required)>'
from /home/mastodon/live/bin/tootctl:4:in `require_relative'
from /home/mastodon/live/bin/tootctl:4:in `<main>'
Y sin embargo, si ejecuto el comando directamente (usando el mismo user, mastodon) sí que funciona…
