Configurer un fournisseur de stockage d'objets compatible S3 pour les téléchargements

[Discourse]

Ce sujet explique comment configurer certains fournisseurs de stockage d’objets compatibles S3 courants (clones S3). Consultez Set up file and image uploads to S3 pour plus de détails sur la configuration d’Amazon AWS S3, qui est officiellement prise en charge et utilisée en interne par Discourse pour nos services d’hébergement.

Fournisseur	Nom du service	Fonctionne avec Discourse ?
Amazon AWS	S3	Oui
Digital Ocean	Spaces	Oui
Linode	Object Storage	Oui
Google Cloud	Storage	Oui
Scaleway	Object Storage	Oui
Vultr	Object Storage	Oui
BackBlaze	Cloud Storage	Oui*
Auto-hébergé	MinIO	Oui
Azure Blob Storage	Flexify.IO	Oui
Oracle Cloud	Object Storage	Non [1]
Wasabi	Object Storage	Peut-être
Cloudflare	R2	Non
Contabo	Object Storage	Non

Si vous avez fait fonctionner un autre service, veuillez l’ajouter à ce wiki.

Configuration

Pour stocker les ressources statiques de Discourse dans votre stockage d’objets, ajoutez cette configuration dans votre fichier app.yml sous la section hooks :

  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

Lors de l’utilisation d’un stockage d’objets, vous avez également besoin d’un CDN pour servir le contenu stocké dans le bucket. J’ai utilisé le CDN StackPath lors de mes tests, et à part la nécessité de définir Dynamic Caching By Header: Accept-Encoding dans leur configuration, cela fonctionne bien.

DISCOURSE_CDN_URL est un CDN qui pointe vers votre nom d’hôte Discourse et met en cache les requêtes. Il sera principalement utilisé pour les ressources téléchargeables : CSS et autres ressources de thème.

DISCOURSE_S3_CDN_URL est un CDN qui pointe vers votre bucket de stockage d’objets et met en cache les requêtes. Il sera principalement utilisé pour les ressources téléversables : JS, images et téléversements d’utilisateurs.

Nous recommandons que ces deux URL soient différentes et que les administrateurs les définissent toutes les deux.

Ne pas utiliser de CDN (ou entrer l’URL du bucket comme URL CDN) est susceptible de causer des problèmes et n’est pas pris en charge.

Dans les exemples suivants, https://falcoland-files-cdn.falco.dev est un CDN configuré pour servir les fichiers du bucket. Le nom du bucket a été défini sur falcoland-files dans mes exemples.

Il est recommandé de configurer ces paramètres dans des variables d’environnement dans votre fichier app.yml, car c’est ainsi que CDCK le fait dans son infrastructure, ce qui garantit une bonne stabilité. De plus, la tâche de téléversement des ressources s’exécute après la compilation des ressources, ce qui se produit lors d’une reconstruction. Si vous souhaitez lancer un Discourse fonctionnant correctement avec un stockage d’objets dès le départ, vous devez définir les variables d’environnement afin que les ressources soient téléversées avant le démarrage du site.

Choisissez votre fournisseur dans la liste ci-dessous et ajoutez ces paramètres à la section env de votre fichier app.yml, en ajustant les valeurs en conséquence :

AWS S3

Ce que nous prenons officiellement en charge et utilisons en interne. Leur offre CDN Cloudfront fonctionne également pour servir les fichiers du bucket. Consultez Set up file and image uploads to S3 pour savoir comment configurer correctement les permissions.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-west-1
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Digital Ocean Spaces

L’offre de DO est bonne et fonctionne immédiatement. Il est acceptable d’activer la restriction de la liste des fichiers. Le seul problème est que leur offre CDN est désespérément défectueuse, vous devez donc utiliser un CDN différent pour les fichiers. De plus, vous ne devez pas installer la règle CORS, car elle est réinstallée à chaque reconstruction.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false 

Linode Object Storage

Un paramètre de configuration supplémentaire, HTTP_CONTINUE_TIMEOUT, est requis pour Linode.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Google Cloud Platform Storage

La liste des fichiers est défectueuse, vous devez donc ajouter une variable d’environnement supplémentaire pour la sauter afin que les ressources fonctionnent. Ignorez également CORS et configurez-le manuellement.

Puisque vous ne pouvez pas lister les fichiers, vous ne pourrez pas lister les sauvegardes, et les sauvegardes automatiques échoueront. Nous ne recommandons pas son utilisation pour les sauvegardes. Cependant, certains suggèrent que si vous changez le rôle de Storage Legacy Object Owner à Storage Legacy Bucket Owner, les sauvegardes fonctionnent correctement. Consultez ce sujet pour une discussion spécifique à Google Cloud.

Il existe un plugin tiers pour améliorer l’intégration à Discourse GCS Helper.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east1
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  FORCE_S3_UPLOADS: 1
  DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  #DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  #DISCOURSE_BACKUP_LOCATION: s3

Scaleway Object Storage

L’offre de Scaleway est également très bonne, et tout fonctionne bien dans la plupart des cas.

Les téléversements multipartes de Scaleway ne prennent en charge qu’un maximum de 1 000 parties. Cela ne correspond pas à Amazon S3, qui prend en charge un maximum de 10 000 parties. Pour les instances plus grandes, cela entraînera l’échec des sauvegardes de Discourse et le téléversement incomplet peut devoir être supprimé manuellement avant de nouvelles tentatives. Pour les petites instances, ce n’est pas un problème. Scaleway semble assez ouvert aux retours, donc si vous souhaitez que cette limite soit modifiée, vous devriez les contacter.

Notez que pour le paramètre DISCOURSE_S3_ENDPOINT, Discourse utilise le point de terminaison de toute la région : https://s3.{region}.scw.cloud. Le « Bucket endpoint » trouvé dans votre tableau de bord Scaleway est sous la forme https://{bucketName}.s3.{region}.scw.cloud. Omettez le sous-domaine du nom du bucket pour éviter les erreurs de connexion.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: fr-par
  DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Vultr Object Storage

Un paramètre de configuration supplémentaire, HTTP_CONTINUE_TIMEOUT, est requis pour Vultr.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Backblaze B2 Cloud Storage

Vous devez ignorer CORS et le configurer manuellement.

Il existe des rapports indiquant que le nettoyage des téléversements orphelins ne fonctionne pas correctement avec BackBlaze. Vous devez modifier les règles de cycle de vie de votre bucket pour que le nettoyage des orphelins fonctionne.

Configuration exemple :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: "us-west-002"
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
  DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Note : Lors de la migration initiale vers B2, vous pouvez atteindre la limite quotidienne gratuite de 2 500 transactions de classe C. Vous devrez ajouter un moyen de paiement pour supprimer les plafonds.

MinIO Storage Server

Il y a quelques mises en garde et exigences que vous devez vous assurer de respecter avant d’utiliser le serveur de stockage MinIO comme alternative à S3 :

1. Vous avez une instance de serveur MinIO entièrement configurée
2. Vous avez activé le support de domaine dans la configuration de MinIO pour les URL de buckets basées sur le domaine. Ceci est une exigence de configuration obligatoire pour MinIO et Discourse, car MinIO prend toujours en charge les styles « path » S3 hérités qui ne sont plus pris en charge dans Discourse.
3. Vous avez configuré correctement la configuration DNS pour MinIO afin que les sous-domaines de bucket résolvent correctement vers le serveur MinIO et que le serveur MinIO soit configuré avec un domaine de base (dans ce cas, minio.example.com)
4. Le bucket discourse-data existe sur le serveur MinIO et a une politique « publique » définie sur lui
5. Votre URL CDN S3 pointe vers un CDN correctement configuré pointant vers le bucket et mettant en cache les requêtes, comme indiqué précédemment dans ce document.
6. Vos CDN sont configurés pour utiliser réellement un en-tête « Host » de l’URL S3 principale - par exemple, discourse-data.minio.example.com lorsqu’il récupère des données - sinon cela peut causer des problèmes CORB.

En supposant que les mises en garde et prérequis ci-dessus sont respectés, une configuration exemple serait quelque chose comme ceci :

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: anything
  DISCOURSE_S3_ENDPOINT: https://minio.example.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
  DISCOURSE_S3_BUCKET: discourse-data
  DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

CORS sera toujours activé sur MinIO même si la règle n’est pas installée par le reconstructeur d’application - par défaut, il semble, CORS est activé sur tous les verbes HTTP dans MinIO, et MinIO ne prend pas en charge BucketCORS (API S3) en conséquence.

Azure Blob Storage avec Flexify.IO

Azure Blob Storage n’est pas un service compatible S3, il ne peut donc pas être utilisé avec Discourse. Il existe un plugin, mais il est défectueux.

Le moyen le plus simple d’exposer une interface compatible S3 pour Azure Blob Storage est d’ajouter un serveur Flexify.IO qui traduit le protocole de stockage Azure en S3.

À l’heure actuelle, le service est gratuit sur Azure, et vous n’avez besoin que d’une machine virtuelle (VM) très basique (peu coûteuse) pour commencer à l’exécuter. Cela nécessite cependant un peu de configuration.

1. Dans le portail Azure, créez une nouvelle ressource de type Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. Pour une utilisation légère, la configuration minimale de la VM semble fonctionner parfaitement. Vous pouvez accepter la plupart des configurations par défaut. N’oubliez pas de sauvegarder le fichier de clé PEM lorsque vous créez la VM.
3. Accédez au lien de la VM Flexify.IO et entrez dans le système. Suivez les instructions en configurant le fournisseur de données Azure Blob Storage et le point de terminaison S3 généré. Assurez-vous que le paramètre de configuration du point de terminaison Public read access to all objects in virtual buckets est défini sur true. Copiez l’URL du point de terminaison S3 et les clés.
4. Appuyez sur New Virtual Bucket et créez un bucket virtuel. Il peut avoir le même nom que votre conteneur Azure Blob Storage, ou un nom différent. Liez n’importe quel conteneur(s) pour les fusionner dans ce bucket virtuel. Ce bucket virtuel est utilisé pour exposer un bucket lisible publiquement via S3.
5. Par défaut, Flexify.IO installe un certificat SSL auto-signé, tandis qu’un point de terminaison S3 nécessite HTTPS. Connectez-vous en SSH à la VM en utilisant le fichier de clé (le nom d’utilisateur est par défaut azureuser), et remplacez les fichiers suivants par les fichiers corrects :

• /etc/flexify/ssl/cert.pem - remplacez par le fichier de certificat (encodage PEM)

• /etc/flexify/ssl/key.pem - remplacez par le fichier de clé privée (encodage PKCS#8 PEM, celui qui commence par BEGIN PRIVATE KEY et non BEGIN RSA PRIVATE KEY qui est PKCS#1)

  Ces fichiers sont root, vous devez donc utiliser sudo pour les remplacer. Il est préférable de vous assurer que les fichiers de remplacement ont le même propriétaire et les mêmes permissions que les originaux, c’est-à-dire root:root et la permission 600.

6. Par défaut, Flexify.IO crée un service S3 au niveau racine avec plusieurs buckets. Discourse nécessite le support des sous-domaines pour les buckets. Allez à : <your Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1 ce qui ouvrira une page de configuration cachée !
7. Spécifiez le domaine de base S3 (disons s3.mydomain.com) dans le champ Endpoint hostname, qui devrait être vide par défaut. Appuyez sur Save pour enregistrer le paramètre.
8. Redémarrez la VM Flexify.IO dans le portail Azure.
9. Dans votre DNS, mappez s3.mydomain.com et *.s3.mydomain.com vers l’adresse IP de la VM Flexify.IO.
10. Dans Discourse, définissez les paramètres suivants dans la page d’administration (oui, il n’est pas nécessaire que les paramètres soient dans app.yml) :

use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket>  (n'importe quel conteneur conviendra, car il ne nécessite pas d'accès de lecture public et Flexify.IO les exposera automatiquement)
backup location: s3

Il n’est pas recommandé d’utiliser le même bucket pour la production et la préproduction. Si vous le faites quand même, prenez des mesures pour vous assurer que votre site de préproduction ne supprime pas vos ressources de production (définissez s3 disable cleanup au minimum, et surveillez la suppression des sauvegardes de production).

Wasabi

@pfaffman a essayé Wasabi pour les sauvegardes, mais cela semblait échouer de manière intermittente et silencieuse, laissant les sauvegardes sur le disque dur et finissant par remplir le disque. Ni Wasabi ni Meta n’avaient d’indices, donc je ne le recommande pas, bien que vos résultats puissent varier. @pfaffman est maintenant assez certain que ce problème était dû au fait que les sauvegardes et les redémarrages automatiques étaient programmés en même temps ; cela n’était utilisé que pour les sauvegardes, mais semblait fonctionner correctement. Si quelqu’un veut essayer et en faire rapport ici, cela devrait fonctionner, au moins pour les sauvegardes.

Oracle Cloud

Oracle Cloud ne prend pas en charge l’accès de style hôte virtuel aux buckets et ne fonctionnera pas

Cloudflare

L’offre de Cloudflare est incompatible. Lors des tests, @fearlessfrog a ouvert un ticket auprès de Cloudflare et en décembre 2022, ils ont déclaré :

Les fichiers que vous compressez avec gzip ne sont pas actuellement gérés correctement par R2. Vous devez télécharger des fichiers non compressés. Cloudflare a une compression transparente, ils choisissent identity, gzip ou Brotli en fonction de ce que le client peut gérer. C’est une différence avec S3.

Contabo

@tuxed a essayé de faire fonctionner le stockage d’objets Contabo pour les téléversements compatibles S3. Il semble que lors du téléversement, il préfixe le nom du dépôt dans l’URL et il n’a pas réussi à le faire fonctionner.

Téléversements sécurisés

Les téléversements sécurisés ne sont pris en charge que pour AWS S3. Si votre commande rake uploads:migrate_to_s3 échoue, vous devez entrer ces commandes pour d’abord compter, puis marquer comme non sécurisés les téléversements, étant donné que vous savez qu’ils n’ont pas besoin d’être sécurisés, auquel cas, vous devrez utiliser AWS S3.

./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)

---

1. Oracle Cloud ne prend pas en charge l’accès de style hôte virtuel aux buckets et ne fonctionnera pas ↩︎