Nginx フォワード プロキシとリバース プロキシ、および負荷分散機能の構成コード例

Nginx フォワード プロキシとリバース プロキシ、および負荷分散機能の構成コード例

この記事は主に、Nginx のフォワード プロキシとリバース プロキシ、および負荷分散機能の設定コード例を紹介します。この記事ではサンプル コードを詳細に紹介しており、皆さんの学習や仕事に一定の参考値があります。困っている友人は参考にしてください。

システム環境:

VirtualBox マネージャー

セントロス6.4

nginx1.10.0

IPに対応するマシン名:

IP マシン名 役割名

10.0.0.139 [elk] クライアント

10.0.0.136 [lvs-master] nginx サーバー

10.0.0.137 [kvm] ウェブサーバー1

10.0.0.111 [lvs-backup] ウェブサーバー2

1. フォワードプロキシ

1.1 環境の紹介

1.2 構成の概要

Nginx サーバー: (イントラネット アドレス: 10.0.0.136、外部ネットワーク アドレス: 172.16.27.64)

VirtualBox Manager を使用してデュアル ネットワーク カードを仮想化します。

[root@lvs-master conf.d]# ifconfig 
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:30:56:99 
     inet アドレス:10.0.0.136 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe30:5699/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:891978 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:9509 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:81841095 (78.0 MiB) TX バイト:13339058 (12.7 MiB) 
 
eth1 リンク カプセル化:イーサネット HWaddr 08:00:27:55:4C:72 
     inet アドレス:172.16.27.64 Bcast:172.16.27.255 マスク:255.255.255.0 
     inet6 アドレス: fe80::a00:27ff:fe55:4c72/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:913671 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:22712 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:109369858 (104.3 MiB) TX バイト:1903855 (1.8 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:36222 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:36222 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:3899937 (3.7 MiB) TX バイト:3899937 (3.7 MiB)
[root@lvs-master conf.d]# cat zxproxy.conf 
サーバー{ 
  listen 80; #リッスンポート server_name 10.0.0.136; #クライアントリゾルバとのネットワーク通信を必要とするサーバーコンテンツアドレス 172.16.5.1; #DNS、これはDNS、外部ネットワークロケーションへのアクセス / { 
      proxy_pass http://$http_host$request_uri; #$http_host と $request_uri は nginx のシステム変数なので、置き換える必要はなく、そのままにしておきます}

Nginx クライアント:

イントラネットネットワークカードは1枚だけあり、Nginxサーバーにアクセスすることでインターネットにアクセスします。実際、「壁登り」や「ゾンビチキン」などの一般的な名前はこの原理に基づいています。

[root@kvm ~]# ifconfig 
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:72:8C:3B 
     inet アドレス:10.0.0.137 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe72:8c3b/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:1462448 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TXパケット:21130 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:145119904 (138.3 MiB) TX バイト:2814635 (2.6 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:60800 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TXパケット:60800 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:4831102 (4.6 MiB) TX バイト:4831102 (4.6 MiB) 
 
[root@kvm ~]# wget www.baidu.com 
--2016-06-08 13:02:08-- http://www.baidu.com/ 
ホスト www.baidu.com を解決しています... 失敗: ドメイン名の解決が一時的に失敗しました。 #Baidu wget にアクセスできません: ホスト アドレス "www.baidu.com" を解決できません 
 
[root@kvm ~]# export http_proxy=http://10.0.0.136:80 #環境変数を設定し、プロキシサーバーの IP とポートを指定します [root@kvm ~]# wget www.baidu.com #Baidu に正常にアクセスできます--2016-06-08 13:08:15-- http://www.baidu.com/ 
10.0.0.136:80 に接続しています...接続されました。 
プロキシ要求が送信されました。応答を待機しています... 200 OK 
長さ: 未指定 [text/html] 
保存先: "index.html.1" 
 
  [ <=> ] 0.07秒で99,762 --.-K/s 
 
2016-06-08 13:08:16 (1.36 MB/秒) - 「index.html.1」が保存されました [99762]

2. リバースプロキシ

フォワードプロキシの紹介記事

2.1 環境の紹介

1. テストページを見てみましょう:

[root@kvm ~]# yum install httpd 
[root@kvm ~]# echo "<html>10.0.0.137</html>" > /var/www/html/index.html 
[root@lvs-backup ~]# yum install httpd 
[root@lvs-backup~]# echo "<html>10.0.0.111</html>" > /var/www/html/index.html

2. 効果を見てみましょう:

[root@lvs-backup html]# curl 10.0.0.111 
<html> 
10.0.0.111 
</html> 
[root@lvs-backup html]# curl 10.0.0.137 
<html> 
10.0.0.137 
</html>  
##すべて成功しました。次のステップに進みましょう。

2.2 構成の概要

[root@lvs-master conf.d]# ls #nginxディレクトリ内の設定ファイルzxproxy.conf 
[root@lvs-master conf.d]# cp zxproxy.conf fxproxy.conf #コピーを作成します。以前はフォワードプロキシでしたが、現在はリバースプロキシです。 [root@lvs-master conf.d]# mv zxproxy.conf zxproxy.conf.bak
[root@lvs-master conf.d]# cat fxproxy.conf  
サーバー{ 
  聞く 80; 
  server_name 10.0.0.136; #環境紹介によると、nginxサーバのIP 
 
  位置 / { 
      proxy_pass http://10.0.0.137; #プロキシされるサーバーのIP 
        } 
 
#proxy_pass: プロキシパス URL 
#デフォルト値: NO 
# フィールドを使用: location (location にフィールドがある場合) # このパラメータは、プロキシされたサーバーのアドレスとマップされた URL を設定します。アドレスは、ホスト名、ドメイン名、IP とポート モードのいずれかになります。例: 
#プロキシパス http://192.168.1.6:8099/linuxtone/; 
 
[root@lvs-master conf.d]# service nginx restart #再起動して設定をロードします

結果を見てみましょう:

#まず、実験環境のクライアントマシンにログインします。IP は次のとおりです。 
[root@elk ~]# ifconfig              
eth0 リンク カプセル化:イーサネット HWaddr 08:00:27:3D:40:40 
     inet アドレス:10.0.0.139 Bcast:10.255.255.255 マスク:255.0.0.0 
     inet6 アドレス: fe80::a00:27ff:fe3d:4040/64 スコープ:リンク 
     アップブロードキャスト 実行中マルチキャスト MTU:1500 メトリック:1 
     RXパケット:2618345 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:247926 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 トランザクションキュー数:1000 
     RX バイト:336182790 (320.6 MiB) TX バイト:35145157 (33.5 MiB) 
 
lo リンクカプセル化:ローカルループバック 
     inet アドレス:127.0.0.1 マスク:255.0.0.0 
     inet6 アドレス: ::1/128 スコープ:ホスト 
     アップループバック実行中 MTU:16436 メトリック:1 
     RXパケット:177352 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 
     TX パケット:177352 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 
     衝突:0 送信キュー:0 
     RX バイト:26547640 (25.3 MiB) TX バイト:26547640 (25.3 MiB) 
 
[root@elk ~]# curl 10.0.0.136 #リバースプロキシサーバーにアクセス <html> 
10.0.0.137          
</html> 
#プロキシサーバーにアクセスし、結果がWebサーバー1に転送されていることがわかります。 
 
#次に、nginx-server と web-server1 のログをそれぞれ見てみましょう。 
nginx サーバー: 
[root@lvs-master ~]# /var/log/nginx/access.log の末尾を表示します 
10.0.0.139- - [2016年6月8日:15:35:43 +0800] "GET / HTTP/1.1" 200 26 "-" "curl/7.19.7  
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" "-" 
 
ウェブサーバー: 
[root@kvm httpd]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:15:21:12 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7  
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
 
##nginx-server 上の nginx ログを見ると、アクセスされたユーザーは 10.0.0.139 であり、これが私たちの環境のクライアントであることが分かります。 
#Web サーバーに表示される IP は 10.0.0.136 で、これは nginx-server です。 
#簡単に言うと、リバース プロキシとは、nginx-server が顧客にとっての実際のサーバーであることを意味します。実際には、ユーザーが nginx-server にアクセスすると、リクエストは #web-server1 に転送され、次に web-server1 はリクエストの結果を nginx-server に送信し、次に ngin small-server がリクエストの結果をユーザーに転送します。 
 
#Web サーバーでは、プロキシ IP のみが表示されます。実際のユーザー IP も表示されますか? 
 
[root@lvs-master conf.d]# cat fxproxy.conf         
サーバー{ 
  聞く 80; 
  server_name 10.0.0.136; #環境紹介によると、nginxサーバのIP 
 
  位置 / { 
      proxy_pass http://10.0.0.137; #プロキシされるサーバーのIP 
      proxy_set_header X-Real-IP $remote_addr; #この行が追加されます}
[root@lvs-master conf.d]# サービスnginxを再起動します 
[root@kvm ~]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:16:10:53 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
 
# 変更後もプロキシサーバーの IP アドレスは表示されます。Web サーバーの設定を変更します [root@kvm ~]# vim /etc/httpd/conf/httpd.conf 
ログフォーマット "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" の組み合わせ 
ログフォーマット "%h %l %u %t \"%r\" %>s %b" 共通 
LogFormat "%{Referer}i -> %U" リファラー 
LogFormat "%{User-agent}i" エージェント 
 
# 変更後: (%h はアクセスされているホストを参照しますが、アクセスされている実際のホスト IP に変更されました) 
ログフォーマット "%{X-Real-IP}i</span> %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" の組み合わせ 
ログフォーマット "%h %l %u %t \"%r\" %>s %b" 共通 
LogFormat "%{Referer}i -> %U" リファラー 
LogFormat "%{User-agent}i" エージェント
[root@kvm ~]# サービス httpd を再起動します 
httpdを停止しています: [ OK ] 
httpdを起動しています: [ OK ] 
 
[root@kvm ~]# /var/log/httpd/access_log の末尾 
10.0.0.136 - - [2016年6月8日:16:10:53 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
<span style="color:#FF0000;">10.0.0.139</span> - - [2016/06/08:16:16:01 +0800] "GET / HTTP/1.0" 200 26 "-" "curl/7.19.7 
(x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 基本 ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" 
#実際のアクセスアドレスになりました

複数の Web サーバーをプロキシします。

[root@lvs-master conf.d]# cat fxproxy.conf 
サーバー{ 
  聞く 80; 
  サーバー名 10.0.0.136; 
 
  位置 / { 
      プロキシパス http://10.0.0.137; 
      proxy_set_header X-Real-IP $remote_addr; 
        } 
  location /web2 { #別の場所を追加 
      プロキシパス http://10.0.0.111; 
      proxy_set_header X-Real-IP $remote_addr;   
        } 
 
[root@lvs-backup ~]# cd /var/www/html/ # 10.0.0.111 の web-server2 に入ります 
[root@lvs-backup html]# mkdir web 
[root@lvs-backup html]# echo "<html>10.0.0.111</html>" > index.html 
# クライアント側でアクセスしてみましょう: 
[root@elk ~]# curl 10.0.0.136/web2/ 
<html> 
10.0.0.111 
</html> 
#アクセス成功

3. 負荷分散

負荷分散を実装する方法は多数あります。一般的に使用されている LVS は 4 層の負荷分散であり、nginx は 7 層の負荷分散です。関連情報はオンラインで検索できます。

3.1 環境の紹介

3.2 構成の概要

1. アップストリームは、Nginx の HTTP アップストリーム モジュールです。このモジュールは、シンプルなスケジューリング アルゴリズムを使用して、クライアント IP からバックエンド サーバーへの負荷分散を実現します。上記の設定では、upstream ディレクティブを通じてロードバランサー名 1.2.3.4 が指定されています。この名前は任意に指定でき、後で必要になったときに直接呼び出すことができます。

2. Nginx の負荷分散モジュールは現在、以下で紹介する 4 つのスケジューリング アルゴリズムをサポートしています。最後の 2 つはサードパーティのスケジューリング アルゴリズムです。

  • ポーリング(デフォルト)。各リクエストは時系列順に 1 つずつ異なるバックエンド サーバーに割り当てられます。バックエンド サーバーがダウンした場合、障害のあるシステムは自動的に排除されるため、ユーザー アクセスには影響しません。 Weight はポーリングの重みを指定します。Weight 値が大きいほどアクセスされる確率が高くなります。主に各バックエンド サーバーのパフォーマンスにばらつきがある場合に使用されます。
  • ip_ハッシュ。各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、同じ IP アドレスからの訪問者は固定のバックエンド サーバーにアクセスし、動的 ​​Web ページのセッション共有の問題を効果的に解決します。
  • 公平。これは、上記の 2 つよりもスマートな負荷分散アルゴリズムです。このアルゴリズムは、ページ サイズと読み込み時間に基づいてインテリジェントに負荷分散を実行できます。つまり、バックエンド サーバーの応答時間に基づいて要求を分散し、応答時間が短い要求を優先します。 Nginx 自体は fair をサポートしていません。このスケジューリング アルゴリズムを使用する必要がある場合は、Nginx の upload_fair モジュールをダウンロードする必要があります。
  • url_ハッシュ。この方法では、アクセスされた URL のハッシュ結果に応じてリクエストが分散されるため、各 URL が同じバックエンド サーバーに送信されるようになり、バックエンド キャッシュ サーバーの効率がさらに向上します。 Nginx 自体は url_hash をサポートしていません。このスケジューリング アルゴリズムを使用する必要がある場合は、Nginx ハッシュ ソフトウェア パッケージをインストールする必要があります。

3. アップストリームでサポートされるステータスパラメータ

HTTP Upstream モジュールでは、server ディレクティブを通じてバックエンド サーバーの IP アドレスとポートを指定できるほか、負荷分散スケジュールで各バックエンド サーバーのステータスを設定することもできます。よく使用される状態は次のとおりです。

  • down: 現在のサーバーが一時的に負荷分散に参加していないことを示します。
  • バックアップ、予約済みのバックアップ マシン。バックアップ マシンは、他のすべての非バックアップ マシンが故障しているかビジー状態の場合にのみ要求されるため、このマシンにかかる負荷は最も軽くなります。
  • max_fails は、許容されるリクエスト失敗の数です。デフォルトは 1 です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。
  • fail_timeout、max_fails 回の失敗後にサービスを一時停止するまでの時間。 max_fails は fail_timeout と一緒に使用できます。

注意: 負荷スケジューリング アルゴリズムが ip_hash の場合、負荷分散スケジューリングにおけるバックエンド サーバーのステータスは、重み付けまたはバックアップにすることはできません。
具体的な構成を見てみましょう。

[root@lvs-master conf.d]# cat ../nginx.conf 
http { 
  /etc/nginx/mime.types を含めます。 
  デフォルトタイプ アプリケーション/オクテットストリーム; 
 
  log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
           '$status $body_bytes_sent "$http_referer" ' 
           '"$http_user_agent" "$http_x_forwarded_for"'; 
 
  access_log /var/log/nginx/access.log メイン; 
 
  ファイル送信オン; 
  #tcp_nopush オン; 
 
  キープアライブタイムアウト65; 
 
  #gzip オン; 
アップストリーム 1.2.3.4 { 
  サーバー 10.0.0.111:80; 
  サーバー 10.0.0.137:80; 
  } 
  /etc/nginx/conf.d/*.conf を含めます。 
} 
 
[root@lvs-master conf.d]# cat slb.confserver  
{  
位置 / {  
   proxy_pass http://1.2.3.4; proxy_set_header X-Real-IP $remote_addr;  
      } 
#注: アップストリームは server{ } の外部で定義され、server{ } 内では定義できません。アップストリームを定義したら、proxy_pass を使用してそれを参照するだけです。

4. テスト結果

[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
#結果として、server1 と 2 が交互に表示され、デフォルトの負荷分散方法がポーリングであることを示します。

5. 健康チェック

通常、ヘルスチェックには keepalived が必要ですが、nginx にも設定できる対応するパラメータがあります。

max_fails は、許容されるリクエスト失敗の数です。デフォルトは 1 です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。

fail_timeout、max_fails 回の失敗後にサービスを一時停止するまでの時間。 max_fails はヘルスチェックのために fail_timeout と一緒に使用できます。

[root@lvs-master conf.d]# cat ../nginx.conf 
http {   
  /etc/nginx/mime.types を含めます。 
  デフォルトタイプ アプリケーション/オクテットストリーム; 
 
  log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
           '$status $body_bytes_sent "$http_referer" ' 
           '"$http_user_agent" "$http_x_forwarded_for"'; 
 
  access_log /var/log/nginx/access.log メイン; 
 
  ファイル送信オン; 
  #tcp_nopush オン; 
 
  キープアライブタイムアウト65; 
 
  #gzip オン; 
  アップストリーム 1.2.3.4 { 
  サーバー 10.0.0.111:80 重み=1 max_fails=2 fail_timeout=2; 
  サーバー 10.0.0.137:80 重み=1 max_fails=2 fail_timeout=2; 
  } 
  /etc/nginx/conf.d/*.conf を含めます。 
  } 
[root@lvs-master conf.d]# サービスnginxを再起動します

6. 結果をテストする

[root@kvm httpd]# service httpd stop #web-server1 サービスをシャットダウンします [root@elk ~]# curl 10.0.0.136 
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html> 
#現在、web-server2 のみにアクセスできます。 
 
[root@kvm httpd]# service httpd start #web-server1 サービスを開く [root@elk ~]# curl 10.0.0.136       
<html> 
10.0.0.111 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.111 
</html>

7. ip_hashの負荷分散

[root@lvs-master conf.d]# cat ../nginx.conf 
アップストリーム 1.2.3.4 { 
  ip_ハッシュ; 
  サーバー 10.0.0.111:80 重み=1 max_fails=2 fail_timeout=2; 
  サーバー 10.0.0.137:80 重み=1 max_fails=2 fail_timeout=2; 
  } 
[root@lvs-master conf.d]# サービスnginxを再起動します 
nginxを停止: [OK] 
nginx を起動しています: [OK] 
 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
[root@elk ~]# カール 10.0.0.136 
<html> 
10.0.0.137 
</html> 
#この負荷分散を構成すると、各リクエストはアクセス IP のハッシュ結果に従って分散され、同じ IP アドレスからの訪問者は固定のバックエンド サーバーにアクセスするようになります。 
#動的 Web ページのセッション共有問題を効果的に解決します。 (一般的には、電子商取引のウェブサイトで多く使用されています)

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません:
  • Nginx リバース プロキシ構成の完全なプロセス記録
  • 中国語でのNginx設定パラメータの詳細な説明(負荷分散とリバースプロキシ)
  • SSL で Nginx リバース プロキシを構成する簡単な手順
  • Nginxリバースプロキシ設定でプレフィックスが削除される
  • nginxリバースプロキシのyum設定の詳細な手順
  • nginxリバースプロキシwebSocket設定の詳細な説明
  • リバースプロキシ設定を実装するためのユニバーサルnginxインターフェース
  • プレフィックスケースを削除する Nginx リバース プロキシ構成のチュートリアル

<<:  MycliはMySQLコマンドライン愛好家にとって必須のツールです

>>:  Websocket に基づくシンプルなチャットルームダイアログの実装

推薦する

element.style インライン スタイルを変更する方法のチュートリアル

序文上記の Web ページ スタイルを記述しているときに、スタイルの値をどのように変更しても、ページ...

VMware仮想マシンブリッジによるインターネット相互接続を実現する方法

VMware をインストールして新しい仮想マシンを作成したら、オプション バーの [編集] - [仮...

MySQLテーブル構造を変更するコマンドを表示する

簡単な説明エディターはデータベースのエンコードが間違っているために問題に遭遇することが多く、これは頭...

Vite+ElectronでVUE3デスクトップアプリケーションを素早く構築

目次1. はじめに2. Viteプロジェクトを作成する1. viteをインストールする2. プロジェ...

Dockerとiptablesとブリッジモードのネットワーク分離と通信操作の実装

Docker は、ブリッジ、ホスト、オーバーレイなどの複数のネットワークを提供します。同じ Dock...

Docker で Rancher をデプロイする方法 (落とし穴なし)

操作前に必ずお読みください:注意:管理に rancher を使用する場合は、k8s クラスターが構築...

Linuxシステムのログの詳細な紹介

目次1. ログ関連サービス2. システム内の共通ログファイル1. ログ関連サービスCentOS 6....

MySQL で遅い SQL 文を見つける方法

MySQL で遅い SQL ステートメントを見つけるにはどうすればよいでしょうか?これは、多くの人を...

MySQL データ型 DECIMAL の詳細な分析

序文:金額の保存など、小数点数を保存し、精度要件がある場合、通常は DECIMAL フィールド タイ...

HTML スペースコードの簡単な分析

HTML についてどれくらい知っていますか? 現在、基本的な HTML コードを学習している場合は、...

プロフェッショナルなMySQL開発設計仕様とSQL記述仕様

チーム開発のプロセスでは、プロジェクトの安定性、コードの効率性、管理の利便性のために、内部開発および...

特定のシンボルで複数の行と列に分割するMySQLの例

一部の障害コード テーブルでは、履歴またはパフォーマンス上の理由から、次の設計パターンが使用されます...

MySQL 5.7.9 バージョンの sql_mode=only_full_group_by 問題を解決する

MySQL 5.7.9 バージョンの sql_mode=only_full_group_by の問題...

MySQLスレーブのメンテナンスに関する経験の共有

序文: MySQL マスター/スレーブ アーキテクチャは、最も一般的に使用されるアーキテクチャ セッ...