Scaleway の S3 互換オブジェクトストレージの利用

こんにちは、

Scaleway の S3 互換オブジェクトストレージを Discourse で設定しようとしているのですが、うまくいかず、問題の箇所がわかりません。

両方のバケットが aws-cli で動作することを確認し、Scaleway の公式ドキュメントに従って CORS 設定も正しく行っているため、バケット自体に問題はないと考えています。

これが私の Discourse の S3 設定です(バケット名の一部は伏せています):

バックアップタブを開くと「Failed to list backups from S3: Aws::S3::Errors::BadRequest」というエラーが表示されます。
また、画像をアップロードしようとすると、ログに以下のように表示されます:‘Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known)’

最新バージョンの Discourse 2.4.0.beta10 (14ae574bc5) を実行しています。

私の推測では、彼らが思っているほど S3 互換性がないのではないでしょうか?

S3 のリージョン設定もここでの挙動に影響しているようです。

それは可能ですが、エンドポイントを入力した場合、URL に amazonaws.com は含まれないはずです。

その通り、これは変ですね。もしかして、ヒップスターな TLD が原因かもしれません。確認してみましょう。

@dino s3 endpoint から https:// を削除してみてください。

バリデーションにより、その操作が許可されません:‘s3_endpoint: 値が必須の形式と一致しません。’

はい、それは的外れな推測でしたね。

そのコードを読みながら、あなたのようになりで終わる URL を見つける方法が見つかりません:

これはバックアップのみが影響を受けているのでしょうか?アップロードは正常に動作していますか?

さて、それは私が GCP バケットで遭遇した問題とは異なりますが、Trouble with Google Bucket for backup - #4 by pfaffman を参照してみてください。

aws-sdk-s3 gem のどのアップグレードが GCP バケットの使用を不可能にしたかを特定できましたが、私のクライアントが選んだ解決策は AWS バケットへの切り替えでした。

@Falco はい、私も手がかりがありません。
amazonaws を含む URL のエラーは、バックアップではなくファイルのアップロードに固有の問題です。バックアップについては一般的なエラーのみが表示されるため、URL の問題により両方が機能していないと思われます。

他に考えられることはありますか?

@pfaffman 情報ありがとうございます。gem のバージョンを変更することで解決するか確認します。

こんにちは、@dino さん。それで解決しましたか?私も同じ問題に直面しており、もう諦めて Amazon S3 に乗り換えようかと思っています。

@FroggyC さん、こんにちは。
実際にはデバッグする時間がなく、結局 gem のバージョンを変更して試すことはできませんでした。公式ドキュメントに従って Amazon S3 を使うように切り替えたところ、すぐに動作しました。
良いニュースではなく申し訳ありません…

ありがとうございます。私たちも同じことをする必要があるかもしれませんね。ありがとうございます!

同じ問題が発生しています。デバッグに何かお手伝いできることはありますか?

例えば、CLI を介してバケットにアクセスし、ログファイルを送信するなどです。

s3_region は無視されますよね?Scaleway は AWS と 異なる値 を使用しているためです。

Scalewayに問い合わせてみることをお勧めします。互換性の責任は彼らにあります。彼らが完全にAWS S3と互換性がない場合、その点を修正すべきです。

あなたはそれが彼らの責任だと暗示していますが、これまで@dino のコメントを無視し続けていますね:

(改ざんされていない)s3_endpoint の URL をそのまま使用しない限り、Scaleway にエラーが自社の側に起因すると納得させるのは難しいでしょう。特に、他の S3 クライアントが接続できているという事実があるからです。

わかりました、証明してください。それが事実であることを示すドキュメントとログのトレースを示してください。当社の問題に関する実際の証拠を提供いただければ、確認いたします。

はい、私が言いたかったのはそのことです。

では、DiscourseにS3接続の試行をログ出力させるにはどうすればよいでしょうか?接続先URLが何であるかを確認できれば、トラフィックを傍受して結果を共有できます。

S3 アップロード/バックアップが機能しない理由は、fr-par(または nl-ams)に設定する必要があるリージョンを、Discourse の SiteSetting 検証を迂回してのみ設定できるためです。

./launcher enter app を実行し、その後 rails c を実行)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

この変更後、アップロードとバックアップは Scaleway オブジェクトストレージに対して正常に機能します。

Scaleway のオブジェクトストレージ機能に関するドキュメント

もちろん、これは回避策であり、Web 管理者を通じてこのサイト設定をリセットまたは変更すると、再度動作する状態に戻すことができません(Rails コンソールを再度使用する必要がある場合を除く)。

現在の Web 管理者の状態とは異なり、AWS/S3 クライアントは明示的にリージョン文字列を設定できるはずです。

また、Discourse の「EU (Paris)」ドロップダウン値についても、これは AWS の命名規則である eu-west-3(またはそれに類する値)を指しており、Scaleway での期待される値とは異なるため、やや誤解を招く可能性があります。

なるほど。@falco さん、特別な「S3 互換リージョン」の設定フィールドが必要でしょうか?それにより、ユーザーが完全に任意(つまり、Amazon の観点からは「架空」の)のリージョンを入力できるようになります。

それはいりません。

S3 クローンを使用する場合は、S3 エンドポイント環境変数を設定する必要があります。これにより、S3 リージョンが上書きされます。

Digital Ocean の S3 クローンを使った詳しい手順をまとめたガイドを用意しているのですが、Digital Ocean が S3 CDN のバグを修正するのを待っているところです。

Scaleway の方が Digital Ocean より状況が良ければ、試してみようと考えています。その場合、ガイドもそれを基に作成する予定です。

その通りですが、彼らはそれをどうやって知るのでしょうか?既存のサイト設定の説明にはこれが記載されていますか?記載されるべきだと思います。対応可能でしょうか?