Nginx リバースプロキシから go-fastdfs へのケースの説明

背景

go-fastdfs は、http プロトコルをサポートする分散ファイルシステムです。一般的なプロジェクトでは、ファイルシステムのアドレスが直接公開されることはほとんどありません。ほとんどは、nginx などのソフトウェアを介して逆変換されます。当社の比較的特殊なビジネスおよびネットワーク環境シナリオのため、ハイブリッドクラウドネットワークシステムは、パブリックネットワーク部分 (パブリッククラウド) とイントラネット部分 (プライベートクラウド) で構成されています。パブリッククラウドは主に出入り口として機能し、いくつかの監査および認証アプリケーションを実行して上流の要求を処理し、プライベートクラウドの処理回数を減らしてパフォーマンスを向上させます。そのため、パブリックネットワーク環境では、プライベートクラウドによって提供されるサービスにアクセスするには、リバースプロキシを使用する必要があります。ファイルシステムへのアクセスについても同様です。外部ネットワーク要求を go-fastdfs にリバースプロキシできるように nginx を構成するにはどうすればよいでしょうか?この記事では、手順ごとに説明します。

一般的な構成

一般的に、nginx に精通している友人は、リバースプロキシを構成する必要がある場合は、ロケーションコンテキストとプロキシモジュールを直接記述できることを知っています。カスタムプレフィックスが必要な場合は、書き換えモジュールを使用できます。簡単な例は次のとおりです。

場所 ~ /dfs/group([0-9]) {
	proxy_pass http://localhost:8080;
	^/dfs/(.*)$ /$1 を書き換えて、break;
	proxy_set_header ホスト $host:$server_port;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

この時点では、一般的な反生成構成は問題ありませんが、go-fastdfs では問題ないでしょうか? go-fastdfs の場合、一般的なアップロードは問題ありませんが、tus を使用したブレークポイントの再開にはまだ不十分です。なぜでしょうか? tus サーバーは 301 リダイレクトを返し、特定のリクエストヘッダーを伝送する必要があるため、特別な設定が必要です。

Tus反生成構成をサポート

TUS 逆生成、301 リダイレクトロケーション書き換え、および特定のリクエストヘッダー転送をサポートする必要がある場合、どのように構成すればよいでしょうか?以下の設定を参照してください

場所 ~ /dfs1/group([0-9]) {
	access_log ログ/dfs/access.log メイン;
	error_log ログ/dfs/error.log エラー;
	^/dfs1/(.*)$ /$1 を書き換えて、break;
	proxy_pass http://localhost:8051;
	# リクエストとレスポンスのバッファリングを無効にする
	proxy_request_buffering をオフ;
	proxy_buffering をオフ;
	プロキシ_http_バージョン 1.1;
	proxy_set_header ホスト $host:$server_port;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	# server_nameがパブリックドメイン名でない場合は、この場所をipに設定できます
	proxy_set_header X-Forwarded-Host $hostname;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header アップグレード $http_upgrade;
	proxy_set_header 接続「アップグレード」;
	# プレフィックスと書き換えが使用されるため、返される Location を変更してリバース プロキシのプレフィックスを追加する必要があります。proxy_redirect ~^(.*)/group([0-9])/big/upload/(.*) /dfs/group$2/big/upload/$3;
	クライアントの最大ボディサイズ 0;
}

上記の 2 つの構成は proxy_redirect と client_max_body_size であることに注意してください。最初の構成は、tus サーバーによって返されるリダイレクトロケーションにカスタムプレフィックスが付いていないため、カスタムプレフィックスを自分で追加する必要があるためです。ここでは /dfs を使用します。他の場合は変更してください。 2 つ目は client_max_body_size です。これを 0 に設定すると、アップロードされたファイルのサイズに関係なく、リクエストが大きすぎる問題は報告されず、直接転送されます。設定する必要がある場合は、chunkSize 以上の数値を設定してください。 chunkSize とは何ですか? tus クライアントがチャンクでアップロードする際の各チャンクのサイズを指します。詳細については、公式ドキュメントを参照してください。

負荷分散構成

クラスターサーバーが構成されている場合、アップロードまたはダウンロードの負荷を分散するにはどうすればよいですか?逆生成を行うには nginx を使用します。これは、upstream モジュールで実現できます。詳細については、次の構成を参照してください。

アップストリームdfs_stream {
	サーバー ホスト1:ポート;
	サーバー ホスト2:ポート;
	ip_ハッシュ;
}

上記の設定は一般的な負荷分散と変わりません。注意する必要があるのは、ip_hash の設定だけです。なぜでしょうか?ブレークポイントレジュームを使用する場合、ファイルはブロック単位でアップロードされるため、ip_hash でない場合は、最初の数個がサーバー A にアップロードされ、最後の数個がサーバー B にアップロードされる可能性があります。この場合、ファイルは完全ではないため、この問題に注意する必要があります。

これで、Nginx リバースプロキシから go-fastdfs へのケーススタディに関するこの記事は終了です。Nginx リバースプロキシから go-fastdfs への関連コンテンツの詳細については、123WORDPRESS.COM で以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: