Recibí una advertencia en mi línea de comandos sobre el espacio en disco antes de reconstruir mi contenedor mientras instalaba un complemento de Discourse. Tuve que ejecutar algunos comandos para eliminar versiones más antiguas de Linux en mi droplet de DigitalOcean, pero aún estoy por encima del 50% de la capacidad de mi SSD.
A medida que mi sitio web de Discourse ha crecido, comencé a buscar soluciones de almacenamiento. Actualmente estoy en un droplet de DigitalOcean de 5 $ y he leído sobre el almacenamiento en bloque de DigitalOcean y Amazon S3. Veo la configuración de S3 integrada en la configuración de Discourse, así que supongo que es más fácil de configurar.
¿Qué utiliza usted para su sitio web? ¿Cuál tiene velocidades de carga mejores, S3 o los bloques de DigitalOcean? ¿Qué opción es más barata? ¿No haría que el nivel gratuito de S3 fuera más barato que los bloques de DigitalOcean? ¿Almacena sus imágenes Y respaldos? ¿O recomienda otra opción fuera de DigitalOcean y Amazon?
Hay muchos proveedores que ofrecen soluciones de almacenamiento compatibles con S3. Puedes usar cualquiera de ellos. He usado varios y puedo recomendar que Digital Ocean Spaces funciona muy bien.
Si ya estás alojando en DO, te recomiendo usar Spaces, ya que es rápido y fiable.
Sin embargo, hay algunas preocupaciones relacionadas con su CDN, por lo que es posible que debas considerar una CDN de terceros.
¿Funcionaría el plan gratuito de Cloudflare como CDN frente al bucket? Ya los uso con la configuración de mi dominio para la protección gratuita contra DDoS.
He notado que DigitalOcean promociona que su servicio Spaces es más económico que el de otros proveedores bien conocidos. Eso es definitivamente una ventaja.
Dado que la CDN que incluye DigitalOcean Spaces no funciona correctamente con Discourse, estoy pensando que debería optar por uno de los otros proveedores de tu lista. De esa forma, no tendré que pagar tanto por DigitalOcean Spaces como por un servicio de CDN por separado.
La falta de content-encoding en la implementación del CDN de DO definitivamente es una pena, pero solo ocurre cuando se establecen todos los parámetros de S3 dentro de app.yml. Si esos parámetros se establecen en la configuración del sitio a través de la consola de administración web, DO solo sirve las cargas de S3 a través del CDN, y los activos del sitio aún se sirven desde la fuente.
Parece que esto es intencional, ya que la variable de entorno DISCOURSE_S3_CDN_URL, si se establece en app.yml, anula la configuración del CDN para los activos también, mientras que esta misma configuración, cuando se declara solo en la configuración del sitio, ¿no lo hace?
Esto es un poco inconsistente, pero permite usar el CDN de DO solo para cargas de S3, sin romper el sitio:
Hay dos formas de hacer esto:
declarar todos los ajustes de S3 solo en la configuración del sitio
rails c
SiteSetting.s3_upload_bucket="<bucket_name>/<uploads_folder>"
SiteSetting.s3_backup_bucket="<bucket_name>/<backups_folder>"
SiteSetting.enable_s3_uploads=true
SiteSetting.s3_access_key_id="<key>"
SiteSetting.s3_secret_access_key="<secret_key>"
SiteSetting.s3_endpoint="https://<sfo2>.digitaloceanspaces.com"
SiteSetting.s3_cdn_url="https://<bucket_name>.<sfo2>.cdn.digitaloceanspaces.com/<uploads_folder>"
SiteSetting.backup_location="s3"
replicar todos los ajustes de S3 exceptoDISCOURSE_S3_CDN_URL en app.yml, y declarar el CDN de DO en SiteSetting.s3_cdn_url
Todos los demás proveedores, incluso AWS, requieren una CDN. Que DO ofrezca una gratuita, que además está rota, es simplemente una peculiaridad; podemos ignorarla y tratarla como un servicio estándar de almacenamiento de objetos.
No estoy seguro de que el detalle de implementación de establecer S3 CDN URL en el archivo yml y en la configuración del sitio, lo que resulta en comportamientos diferentes, sea algo que queramos promover, ya que puede solucionarse en cualquier momento.
No lo he probado, pero puedo asegurar que funciona con servicios CDN reales, como KeyCDN, Cloudfront, StackPath, etc.