dino
2020 年 2 月 4 日午後 3:54
1
こんにちは、
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 のリージョン設定もここでの挙動に影響しているようです。
dino
2020 年 2 月 4 日午後 4:40
3
それは可能ですが、エンドポイントを入力した場合、URL に amazonaws.com は含まれないはずです。
Falco
(Falco)
2020 年 2 月 4 日午後 4:52
4
その通り、これは変ですね。もしかして、ヒップスターな TLD が原因かもしれません。確認してみましょう。
@dino s3 endpoint から https:// を削除してみてください。
dino
2020 年 2 月 4 日午後 7:23
5
バリデーションにより、その操作が許可されません:‘s3_endpoint: 値が必須の形式と一致しません。’
Falco
(Falco)
2020 年 2 月 4 日午後 8:59
6
はい、それは的外れな推測でしたね。
そのコードを読みながら、あなたのようになりで終わる URL を見つける方法が見つかりません:
これはバックアップのみが影響を受けているのでしょうか?アップロードは正常に動作していますか?
pfaffman
(Jay Pfaffman)
2020 年 2 月 4 日午後 9:06
7
さて、それは私が GCP バケットで遭遇した問題とは異なりますが、Trouble with Google Bucket for backup - #4 by pfaffman を参照してみてください。
aws-sdk-s3 gem のどのアップグレードが GCP バケットの使用を不可能にしたかを特定できましたが、私のクライアントが選んだ解決策は AWS バケットへの切り替えでした。
dino
2020 年 2 月 4 日午後 9:31
8
@Falco はい、私も手がかりがありません。
amazonaws を含む URL のエラーは、バックアップではなくファイルのアップロードに固有の問題です。バックアップについては一般的なエラーのみが表示されるため、URL の問題により両方が機能していないと思われます。
他に考えられることはありますか?
@pfaffman 情報ありがとうございます。gem のバージョンを変更することで解決するか確認します。
こんにちは、@dino さん。それで解決しましたか?私も同じ問題に直面しており、もう諦めて Amazon S3 に乗り換えようかと思っています。
dino
2020 年 2 月 22 日午前 6:31
10
@FroggyC さん、こんにちは。
実際にはデバッグする時間がなく、結局 gem のバージョンを変更して試すことはできませんでした。公式ドキュメントに従って Amazon S3 を使うように切り替えたところ、すぐに動作しました。
良いニュースではなく申し訳ありません…
ありがとうございます。私たちも同じことをする必要があるかもしれませんね。ありがとうございます!
同じ問題が発生しています。デバッグに何かお手伝いできることはありますか?
例えば、CLI を介してバケットにアクセスし、ログファイルを送信するなどです。
s3_region は無視されますよね?Scaleway は AWS と 異なる値 を使用しているためです。
Scalewayに問い合わせてみることをお勧めします。互換性の責任は彼らにあります。彼らが完全にAWS S3と互換性がない場合、その点を修正すべきです。
あなたはそれが彼らの責任だと暗示していますが、これまで@dino のコメントを無視し続けていますね:
That’s possible, but the url shouldn’t include amazonaws.com if I entered the endpoint - right?
(改ざんされていない)s3_endpoint の URL をそのまま使用しない限り、Scaleway にエラーが自社の側に起因すると納得させるのは難しいでしょう。特に、他の S3 クライアントが接続できているという事実があるからです。
わかりました、証明してください。それが事実であることを示すドキュメントとログのトレースを示してください。当社の問題に関する実際の証拠を提供いただければ、確認いたします。
はい、私が言いたかったのはそのことです。
では、DiscourseにS3接続の試行をログ出力させるにはどうすればよいでしょうか?接続先URLが何であるかを確認できれば、トラフィックを傍受して結果を共有できます。
elle
(elle)
2020 年 4 月 10 日午前 10:21
17
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 の観点からは「架空」の)のリージョンを入力できるようになります。
Falco
(Falco)
2020 年 4 月 10 日午後 6:41
19
それはいりません。
S3 クローンを使用する場合は、S3 エンドポイント環境変数を設定する必要があります。これにより、S3 リージョンが上書きされます。
Digital Ocean の S3 クローンを使った詳しい手順をまとめたガイドを用意しているのですが、Digital Ocean が S3 CDN のバグを修正するのを待っているところです。
Scaleway の方が Digital Ocean より状況が良ければ、試してみようと考えています。その場合、ガイドもそれを基に作成する予定です。
その通りですが、彼らはそれをどうやって知るのでしょうか?既存のサイト設定の説明にはこれが記載されていますか?記載されるべきだと思います。対応可能でしょうか?