Nginx မှ Envoy Proxy သို့ ပြောင်းရွှေ့ခြင်း။

မင်္ဂလာပါ Habr။ ပို့စ်ကို ဘာသာပြန်ထားတာကို မင်းသတိထားမိအောင် ငါပြောပြမယ် Nginx မှ Envoy Proxy သို့ ပြောင်းရွှေ့ခြင်း။.

Envoy သည် တစ်ဦးချင်း ဝန်ဆောင်မှုများနှင့် အပလီကေးရှင်းများအတွက် ဒီဇိုင်းထုတ်ထားသော စွမ်းဆောင်ရည်မြင့် ဖြန့်ဝေထားသော ပရောက်စီဆာဗာတစ်ခုဖြစ်ပြီး ကြီးမားသော microservice “service mesh” ဗိသုကာများ အတွက် ဒီဇိုင်းထုတ်ထားသည့် ဆက်သွယ်ရေးဘတ်စ်ကားနှင့် “universal data plane” လည်းဖြစ်သည်။ ၎င်းကိုဖန်တီးသောအခါတွင် NGINX၊ HAProxy၊ hardware load balancers နှင့် cloud load balancers ကဲ့သို့သော ဆာဗာများ ဖွံ့ဖြိုးတိုးတက်လာစဉ်အတွင်း ဖြစ်ပေါ်လာသော ပြဿနာများအတွက် ဖြေရှင်းချက်များကို ထည့်သွင်းစဉ်းစားခဲ့သည်။ Envoy သည် အပလီကေးရှင်းတစ်ခုစီနှင့်အတူ လုပ်ဆောင်ပြီး ပလက်ဖောင်းမခွဲခြားဘဲ ဘုံလုပ်ဆောင်နိုင်စွမ်းကို ပေးဆောင်ရန် ကွန်ရက်ကို သရုပ်ဖော်သည်။ အခြေခံအဆောက်အအုံတစ်ခုရှိ ဝန်ဆောင်မှုအသွားအလာအားလုံးသည် Envoy mesh မှတဆင့် စီးဆင်းလာသောအခါ၊ တသမတ်တည်းကြည့်ရှုနိုင်မှု၊ အလုံးစုံစွမ်းဆောင်ရည်ကို ချိန်ညှိကာ သီးခြားတည်နေရာတစ်ခုတွင် အဓိကလုပ်ဆောင်နိုင်စွမ်းကို ထည့်သွင်းခြင်းဖြင့် ပြဿနာဧရိယာများကို မြင်ယောင်ရန် လွယ်ကူလာသည်။

အခွင့်အလမ်း

• လုပ်ငန်းစဉ်ပြင်ပ ဗိသုကာ- အထူးကိုယ်စားလှယ်သည် RAM ပမာဏအနည်းငယ်ကို ယူဆောင်သည့် ကိုယ်တိုင်ပါရှိသော၊ စွမ်းဆောင်ရည်မြင့် ဆာဗာတစ်ခုဖြစ်သည်။ ၎င်းသည် မည်သည့် application language သို့မဟုတ် framework နှင့်မဆို တွဲဖက်အလုပ်လုပ်သည်။
• http/2 နှင့် grpc ပံ့ပိုးမှု- အထူးကိုယ်စားလှယ်တွင် အဝင်နှင့်အထွက်ချိတ်ဆက်မှုအတွက် ပထမတန်းစား http/2 နှင့် grpc ပံ့ပိုးမှုရှိသည်။ ၎င်းသည် http/1.1 မှ http/2 အထိ ပွင့်လင်းမြင်သာသော ပရောက်စီတစ်ခုဖြစ်သည်။
• အဆင့်မြင့် Load Balancing- အထူးကိုယ်စားလှယ်သည် အလိုအလျောက်ပြန်စမ်းခြင်း၊ ကွင်းဆက်ပြတ်တောက်ခြင်း၊ ကမ္ဘာလုံးဆိုင်ရာနှုန်းကန့်သတ်ခြင်း၊ တောင်းဆိုချက် အရိပ်ပေးခြင်း၊ ဒေသဆိုင်ရာ ဇုန်ဝန်ချိန်ခွင်လျှာ ချိန်ညှိခြင်း စသည်ဖြင့် အဆင့်မြင့် ဝန်ချိန်ခွင်လျှာကို ပံ့ပိုးပေးပါသည်။
• Configuration Management API- သံတမန်သည် သင်၏ဖွဲ့စည်းပုံကို အင်တိုက်အားတိုက် စီမံခန့်ခွဲရန်အတွက် ခိုင်မာသော API ကို ပံ့ပိုးပေးပါသည်။
• ကြည့်ရှုနိုင်မှု- L7 အသွားအလာကို နက်ရှိုင်းစွာ ကြည့်ရှုနိုင်မှု၊ ဖြန့်ဝေမှု ခြေရာခံခြင်းနှင့် mongodb၊ dynamodb နှင့် အခြားသော အပလီကေးရှင်းများစွာ၏ ဖြန့်ဝေမှု ခြေရာခံခြင်းအတွက် မူရင်းပံ့ပိုးမှု။

အဆင့် 1 — ဥပမာ NGINX Config

ဤဇာတ်ညွှန်းသည် အထူးဖန်တီးထားသောဖိုင်ကို အသုံးပြုသည်။ nginx.confဥပမာ အပြည့်အစုံကို အခြေခံ၍ NGINX ဝီကီ. ဖွင့်ခြင်းဖြင့် တည်းဖြတ်သူရှိ ဖွဲ့စည်းမှုပုံစံကို သင်ကြည့်ရှုနိုင်ပါသည်။ nginx.conf

nginx အရင်းအမြစ် config

user  www www;
pid /var/run/nginx.pid;
worker_processes  2;

events {
  worker_connections   2000;
}

http {
  gzip on;
  gzip_min_length  1100;
  gzip_buffers     4 8k;
  gzip_types       text/plain;

  log_format main      '$remote_addr - $remote_user [$time_local]  '
    '"$request" $status $bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '"$gzip_ratio"';

  log_format download  '$remote_addr - $remote_user [$time_local]  '
    '"$request" $status $bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '"$http_range" "$sent_http_content_range"';

  upstream targetCluster {
    172.18.0.3:80;
    172.18.0.4:80;
  }

  server {
    listen        8080;
    server_name   one.example.com  www.one.example.com;

    access_log   /var/log/nginx.access_log  main;
    error_log  /var/log/nginx.error_log  info;

    location / {
      proxy_pass         http://targetCluster/;
      proxy_redirect     off;

      proxy_set_header   Host             $host;
      proxy_set_header   X-Real-IP        $remote_addr;
    }
  }
}

NGINX ဖွဲ့စည်းမှုပုံစံများသည် ပုံမှန်အားဖြင့် အဓိကအချက်သုံးချက်ပါရှိသည်-

1. NGINX ဆာဗာ၊ မှတ်တမ်းဖွဲ့စည်းပုံနှင့် Gzip လုပ်ဆောင်ချက်ကို ပြင်ဆင်သတ်မှတ်ခြင်း။ ဤသည်ကို ကိစ္စရပ်တိုင်းတွင် တစ်ကမ္ဘာလုံးက သတ်မှတ်သည်။
2. အိမ်ရှင်ထံ တောင်းဆိုမှုများကို လက်ခံရန် NGINX ကို ပြင်ဆင်သတ်မှတ်ခြင်း။ one.example.com port 8080 တွင်
3. ပစ်မှတ်တည်နေရာကို သတ်မှတ်ခြင်း၊ URL ၏ မတူညီသော အစိတ်အပိုင်းများအတွက် လမ်းကြောင်းများကို ကိုင်တွယ်နည်း။

ဖွဲ့စည်းမှုအားလုံးကို Envoy Proxy တွင် သက်ရောက်မှုရှိမည်မဟုတ်ပါ၊ အချို့သောဆက်တင်များကို သင် configure လုပ်ရန်မလိုအပ်ပါ။ Envoy Proxy ရှိတယ်။ သော့အမျိုးအစားလေးမျိုးNGINX မှ ပံ့ပိုးပေးသော အခြေခံအဆောက်အဦများကို ပံ့ပိုးပေးသည်။ အဓိကအချက်မှာ-

• နားထောင်သူများ- Envoy Proxy သည် ဝင်လာသော တောင်းဆိုချက်များကို မည်သို့လက်ခံကြောင်း ဆုံးဖြတ်သည်။ Envoy Proxy သည် လက်ရှိတွင် TCP အခြေခံ နားထောင်သူများကိုသာ ပံ့ပိုးပေးသည်။ ချိတ်ဆက်မှုတစ်ခုတည်ဆောက်ပြီးသည်နှင့် ၎င်းကို လုပ်ဆောင်ရန်အတွက် စစ်ထုတ်မှုအစုတစ်ခုသို့ ပေးပို့သည်။
• စစ်ထုတ်မှုများ- ၎င်းတို့သည် အဝင်နှင့်အထွက်ဒေတာကို စီမံဆောင်ရွက်နိုင်သော ပိုက်လိုင်းတည်ဆောက်မှုတစ်ခု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ ဤလုပ်ဆောင်ချက်တွင် သုံးစွဲသူထံ မပေးပို့မီ ဒေတာကို ချုံ့ပေးသည့် Gzip ကဲ့သို့သော စစ်ထုတ်မှုများ ပါဝင်သည်။
• Routers များ- ၎င်းတို့သည် အစုအဝေးတစ်ခုအဖြစ် သတ်မှတ်ထားသော လိုအပ်သော ဦးတည်ရာသို့ အသွားအလာကို ပေးပို့သည်။
• အစုအဖွဲ့များ- ၎င်းတို့သည် အသွားအလာနှင့် ဖွဲ့စည်းမှုဆိုင်ရာ ကန့်သတ်ဘောင်များအတွက် အဆုံးမှတ်ကို သတ်မှတ်သည်။

သီးခြား NGINX ဖွဲ့စည်းမှုပုံစံနှင့် ကိုက်ညီရန် Envoy Proxy ဖွဲ့စည်းမှုပုံစံကို ဖန်တီးရန် ဤအစိတ်အပိုင်းလေးခုကို ကျွန်ုပ်တို့ အသုံးပြုပါမည်။ Envoy ၏ရည်မှန်းချက်မှာ APIs များနှင့် dynamic configuration များဖြင့်အလုပ်လုပ်ရန်ဖြစ်သည်။ ဤကိစ္စတွင်၊ အခြေခံဖွဲ့စည်းမှုပုံစံသည် NGINX မှ တည်ငြိမ်သော၊ ဟာ့ဒ်ကုတ်ဆက်တင်များကို အသုံးပြုမည်ဖြစ်သည်။

အဆင့် 2 - NGINX ဖွဲ့စည်းမှုပုံစံ

ပထမဦးဆုံးအစိတျအပိုငျး nginx.conf Configure လုပ်ရန်လိုအပ်သော NGINX အတွင်းပိုင်းအချို့ကို သတ်မှတ်သည်။

အလုပ်သမားချိတ်ဆက်မှုများ

အောက်ပါဖွဲ့စည်းပုံသည် အလုပ်သမား လုပ်ငန်းစဉ်များနှင့် ချိတ်ဆက်မှုအရေအတွက်ကို ဆုံးဖြတ်ပေးပါသည်။ ၎င်းသည် NGINX သည် ဝယ်လိုအားပြည့်မီရန် မည်ကဲ့သို့ အတိုင်းအတာကို ညွှန်ပြသည်။

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy သည် နည်းလမ်းအမျိုးမျိုးဖြင့် အလုပ်အသွားအလာများနှင့် ချိတ်ဆက်မှုများကို စီမံခန့်ခွဲသည်။

Envoy သည် စနစ်ရှိ hardware thread တစ်ခုစီအတွက် worker thread တစ်ခုကို ဖန်တီးသည်။ အလုပ်သမားချည်မျှင်တစ်ခုစီသည် ပိတ်ဆို့ခြင်းမဟုတ်သော ဖြစ်ရပ်ကွင်းဆက်တစ်ခုကို လုပ်ဆောင်သည်။

1. နားထောင်သူတိုင်း နားထောင်သည်။
2. ချိတ်ဆက်မှုအသစ်များကို လက်ခံခြင်း။
3. ချိတ်ဆက်မှုအတွက် စစ်ထုတ်မှုအစုတစ်ခု ဖန်တီးခြင်း။
4. ချိတ်ဆက်မှုသက်တမ်းတစ်လျှောက် I/O လုပ်ဆောင်ချက်အားလုံးကို လုပ်ဆောင်ပါ။

ထပ်ဆင့်ချိတ်ဆက်မှုလုပ်ဆောင်ခြင်းအားလုံးကို အလုပ်သမားချည်နှောင်မှုတွင် လုံးလုံးလျားလျား ကိုင်တွယ်ဆောင်ရွက်ပါသည်။

Envoy ရှိ အလုပ်သမားချည်မျှင်တစ်ခုစီအတွက် ချိတ်ဆက်မှုရေကန်တစ်ခု ရှိသည်။ ထို့ကြောင့် HTTP/2 ချိတ်ဆက်မှုပေါင်းစုများသည် တစ်ချိန်တည်းတွင် ပြင်ပ host တစ်ခုစီအတွက် ချိတ်ဆက်မှုတစ်ခုသာ ပြုလုပ်ပေးသည်၊ အကယ်၍ အလုပ်သမားလိုင်းလေးခုရှိပါက တည်ငြိမ်သောအခြေအနေတွင် ပြင်ပ host တစ်ခုလျှင် HTTP/2 ချိတ်ဆက်မှုလေးခုရှိမည်ဖြစ်သည်။ အရာအားလုံးကို အလုပ်သမားချည်မျှင်တစ်ခုတည်းတွင် ထားရှိခြင်းဖြင့်၊ ကုဒ်အားလုံးနီးပါးသည် ကြိုးတစ်ချောင်းတည်းပါရှိသကဲ့သို့ ပိတ်ဆို့ခြင်းမရှိဘဲ ရေးသားနိုင်သည်။ အလုပ်သမား လိုင်းများကို လိုအပ်သည်ထက်ပို၍ ခွဲဝေထားပါက၊ ၎င်းသည် မမ်မိုရီကို ဖြုန်းတီးခြင်းသို့ ဦးတည်စေကာ idle ချိတ်ဆက်မှု အများအပြားကို ဖန်တီးကာ ရေကူးကန်သို့ ပြန်ပို့သည့် အကြိမ်အရေအတွက်ကို လျှော့ချနိုင်သည်။

ပိုမိုသိရှိလိုပါကသွားရောက်ကြည့်ရှု Envoy Proxy ဘလော့ဂ်.

HTTP ဖွဲ့စည်းမှု

အောက်ပါ NGINX ဖွဲ့စည်းမှုပိတ်ဆို့ခြင်းသည် HTTP ဆက်တင်များကို သတ်မှတ်သည်-

• ဘယ်လို mime အမျိုးအစားတွေကို ပံ့ပိုးပေးလဲ။
• ပုံသေ အချိန်ကုန်ဆုံးမှုများ
• Gzip ဖွဲ့စည်းမှု

နောက်မှ ဆွေးနွေးပေးမယ့် Envoy Proxy မှာ filters တွေသုံးပြီး ဒီအချက်တွေကို စိတ်ကြိုက်ပြင်ဆင်နိုင်ပါတယ်။

အဆင့် 3 - Server Configuration

HTTP configuration block တွင်၊ NGINX configuration သည် port 8080 တွင် နားထောင်ရန်နှင့် domain များအတွက် ဝင်လာသော တောင်းဆိုမှုများကို တုံ့ပြန်ရန် သတ်မှတ်သည်။ one.example.com и www.one.example.com.

 server {
    listen        8080;
    server_name   one.example.com  www.one.example.com;

Envoy အတွင်းတွင် ၎င်းကို Listeners မှ ထိန်းချုပ်ထားသည်။

အထူးကိုယ်စားလှယ်

Envoy Proxy ဖြင့် စတင်ခြင်း၏ အရေးကြီးဆုံး ကဏ္ဍမှာ သင်၏ နားထောင်သူများကို သတ်မှတ်ခြင်း ဖြစ်သည်။ Envoy instance ကို သင်မည်ကဲ့သို့ လုပ်ဆောင်လိုကြောင်း ဖော်ပြသည့် configuration file တစ်ခုကို ဖန်တီးရန် လိုအပ်ပါသည်။

အောက်ပါအတိုအထွာသည် နားဆင်သူအသစ်ကို ဖန်တီးပြီး ၎င်းကို ဆိပ်ကမ်း 8080 တွင် ချိတ်ပေးမည်ဖြစ်သည်။ ဖွဲ့စည်းမှုစနစ်သည် အဝင်တောင်းဆိုမှုများအတွက် ၎င်းနှင့် ချိတ်ဆက်သင့်သည့် ဆိပ်ကမ်းများကို Envoy Proxy အား ပြောပြသည်။

Envoy Proxy သည် ၎င်း၏ဖွဲ့စည်းပုံအတွက် YAML အမှတ်အသားကို အသုံးပြုသည်။ ဤမှတ်စုအတွက် နိဒါန်းတစ်ခုအတွက်၊ ဤနေရာတွင် ကြည့်ရှုပါ။ link ကို.

Copy to Editorstatic_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }

သတ်မှတ်ရန်မလိုအပ်ပါ။ ဆာဗာအမည်Envoy Proxy စစ်ထုတ်မှုများသည် ၎င်းကို ကိုင်တွယ်မည်ဖြစ်သောကြောင့်၊

အဆင့် 4 - တည်နေရာဖွဲ့စည်းမှု

တောင်းဆိုချက်တစ်ခုသည် NGINX သို့ရောက်လာသောအခါ၊ တည်နေရာပိတ်ဆို့ခြင်းသည် မည်ကဲ့သို့လုပ်ဆောင်ရမည်နှင့် လမ်းကြောင်းလမ်းကြောင်းကို မည်သည့်နေရာမှ ဆုံးဖြတ်ပေးသည်။ အောက်ပါအပိုင်းအစတွင်၊ ဝဘ်ဆိုက်သို့ အသွားအလာအားလုံးကို အထက်ရေစီးကြောင်းသို့ လွှဲပြောင်းသည် (ဘာသာပြန်သူ၏ မှတ်စု- အထက်ရေစီးကြောင်းသည် အများအားဖြင့် အက်ပလီကေးရှင်းဆာဗာတစ်ခုဖြစ်သည်) အမည်ရှိ အစုအဝေး ပစ်မှတ်အုပ်စု. အထက်စီးကြောင်း အစုအဝေးသည် တောင်းဆိုချက်ကို လုပ်ဆောင်သင့်သည့် ဆုံမှတ်များကို သတ်မှတ်သည်။ ဒါကို နောက်တဆင့်မှာ ဆွေးနွေးပါမယ်။

location / {
    proxy_pass         http://targetCluster/;
    proxy_redirect     off;

    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
}

Envoy တွင် Filters က ဤသို့လုပ်ဆောင်သည်။

သံတမန် စစ်ထုတ်မှုများ

တည်ငြိမ်ဖွဲ့စည်းမှုတစ်ခုအတွက်၊ စစ်ထုတ်မှုများသည် အဝင်တောင်းဆိုမှုများကို မည်သို့လုပ်ဆောင်ရမည်ကို ဆုံးဖြတ်သည်။ ဤကိစ္စတွင်ကျွန်ုပ်တို့သည်ကိုက်ညီသော filter များကိုသတ်မှတ်ထားသည်။ ဆာဗာ_အမည်များ ယခင်အဆင့်တွင်။ အချို့သော ဒိုမိန်းများနှင့် လမ်းကြောင်းများနှင့် ကိုက်ညီသော အဝင်တောင်းဆိုမှုများ ရောက်ရှိလာသောအခါ၊ လမ်းကြောင်းသည် အစုအဝေးသို့ လမ်းကြောင်းပြောင်းသွားပါသည်။ ၎င်းသည် NGINX အောက်ခြေဖွဲ့စည်းမှုပုံစံနှင့် ညီမျှသည်။

Copy to Editor    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
                - "one.example.com"
                - "www.one.example.com"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: targetCluster
          http_filters:
          - name: envoy.router

နာမတျောကို envoy.http_connection_manager Envoy Proxy တွင် built-in filter တစ်ခုဖြစ်သည်။ အခြား filter များပါဝင်သည်။ Redis, Mongo အဘိဓါန်, သည် TCP. စာရင်းအပြည့်အစုံကို တွင် ကြည့်ရှုနိုင်ပါသည်။ စာရွက်စာတမ်း.

အခြား ဝန်ချိန်ခွင်လျှာ မူဝါဒများအကြောင်း နောက်ထပ်အချက်အလက်များအတွက် သွားရောက်ကြည့်ရှုပါ။ သံတမန်မှတ်တမ်း.

အဆင့် 5 - Proxy နှင့် Upstream Configuration

NGINX တွင်၊ အထက်စီးကြောင်းဖွဲ့စည်းမှုပုံစံသည် အသွားအလာကိုလုပ်ဆောင်ပေးမည့် ပစ်မှတ်ဆာဗာအစုအဝေးကို သတ်မှတ်သည်။ ဤကိစ္စတွင် အစုအဖွဲ့ နှစ်ခုကို တာဝန်ပေးအပ်ခဲ့သည်။

  upstream targetCluster {
    172.18.0.3:80;
    172.18.0.4:80;
  }

Envoy တွင်၊ ၎င်းကို အစုအဖွဲ့များဖြင့် စီမံခန့်ခွဲသည်။

အထူးကိုယ်စားလှယ် ပဒေသာပင်

အထက်ပိုင်းညီမျှခြင်းကို အစုအဖွဲ့များအဖြစ် သတ်မှတ်သည်။ ဤကိစ္စတွင်၊ ယာဉ်အသွားအလာကိုထမ်းဆောင်မည့်အိမ်ရှင်များကိုဖော်ထုတ်ခဲ့သည်။ အချိန်ကုန်သွားခြင်းကဲ့သို့သော host များဝင်ရောက်ခြင်းနည်းလမ်းကို cluster configuration တစ်ခုအဖြစ် သတ်မှတ်သည်။ ၎င်းသည် latency နှင့် load balancing ကဲ့သို့သော ကဏ္ဍများကို ပိုမိုအသေးစိတ်ထိန်းချုပ်နိုင်စေပါသည်။

Copy to Editor  clusters:
  - name: targetCluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    hosts: [
      { socket_address: { address: 172.18.0.3, port_value: 80 }},
      { socket_address: { address: 172.18.0.4, port_value: 80 }}
    ]

ဝန်ဆောင်မှုကို အသုံးပြုသည့်အခါ ရှာဖွေတွေ့ရှိခြင်း။ STRICT_DNS အထူးကိုယ်စားလှယ်သည် သတ်မှတ်ထားသော DNS ပစ်မှတ်များကို စဉ်ဆက်မပြတ်နှင့် တပြိုင်နက်တည်း ဖြေရှင်းပါမည်။ DNS ရလဒ်မှ ပြန်ပေးသော IP လိပ်စာတစ်ခုစီကို အထက်ရေစီးကြောင်းအစုအဝေးတွင် တိကျပြတ်သားသော လက်ခံဆောင်ရွက်ပေးသူအဖြစ် သတ်မှတ်မည်ဖြစ်သည်။ ဆိုလိုသည်မှာ တောင်းဆိုချက်တစ်ခုသည် IP လိပ်စာနှစ်ခုကို ပြန်ပေးမည်ဆိုပါက၊ Envoy သည် အစုအဝေးတွင် host နှစ်ခုရှိနေသည်ဟု ယူဆမည်ဖြစ်ပြီး နှစ်ခုစလုံးသည် မျှတနေရမည်ဖြစ်သည်။ အကယ်၍ လက်ခံသူအား ရလဒ်မှ ဖယ်ရှားပါက၊ Envoy သည် ၎င်းကို မရှိတော့ဟု ယူဆမည်ဖြစ်ပြီး လက်ရှိချိတ်ဆက်မှုပေါင်းစုများမှ အသွားအလာများကို ဆွဲထုတ်မည်ဖြစ်သည်။

ပိုမိုသိရှိလိုပါကကြည့်ပါ သံတမန် proxy စာရွက်စာတမ်း.

အဆင့် 6 — မှတ်တမ်းဝင်ရောက်ခြင်းနှင့် အမှားများ

နောက်ဆုံးဖွဲ့စည်းပုံမှာ မှတ်ပုံတင်ခြင်း ဖြစ်သည်။ အမှားအယွင်းမှတ်တမ်းများကို disk သို့တွန်းချမည့်အစား Envoy Proxy သည် cloud-based ချဉ်းကပ်မှုကိုခံယူသည်။ အပလီကေးရှင်းမှတ်တမ်းများအားလုံးကို output သို့ထုတ်ပေးပါသည်။ တကယ и ။ ။ ။.

အသုံးပြုသူများသည် တောင်းဆိုမှုပြုလုပ်သောအခါ၊ ဝင်ရောက်ခွင့်မှတ်တမ်းများကို စိတ်ကြိုက်ရွေးချယ်နိုင်ပြီး ပုံမှန်အားဖြင့် ပိတ်ထားသည်။ HTTP တောင်းဆိုမှုများအတွက် ဝင်ရောက်ခွင့်မှတ်တမ်းများကို ဖွင့်ရန်၊ ဖွဲ့စည်းမှုပုံစံကို ဖွင့်ပါ။ access_log HTTP ချိတ်ဆက်မှုမန်နေဂျာအတွက်။ မဂ် အစရှိတဲ့ ကိရိယာ တစ်ခုခုကို ဖြစ်စေနိုင်ပါတယ်။ တကယသို့မဟုတ် သင့်လိုအပ်ချက်များပေါ်မူတည်၍ ဒစ်ခ်ပေါ်ရှိ ဖိုင်တစ်ခု။

အောက်ပါဖွဲ့စည်းပုံသည် ဝင်ရောက်ခွင့်မှတ်တမ်းများအားလုံးကို ပြန်လည်ညွှန်းပေးပါမည်။ တကယ (ဘာသာပြန်သူ၏မှတ်ချက် - stdout သည် docker အတွင်းရှိ envoy ကိုအသုံးပြုရန် လိုအပ်သည်။ docker မပါဘဲအသုံးပြုပါက၊ ပုံမှန်မှတ်တမ်းဖိုင်သို့လမ်းကြောင်းဖြင့် /dev/stdout ကိုအစားထိုးပါ။) အတိုအထွာကို ချိတ်ဆက်မှုမန်နေဂျာအတွက် ဖွဲ့စည်းမှုကဏ္ဍသို့ ကူးယူပါ-

Copy to Clipboardaccess_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"

ရလဒ်များသည် ဤကဲ့သို့ဖြစ်သင့်သည်-

      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          access_log:
          - name: envoy.file_access_log
            config:
              path: "/dev/stdout"
          route_config:

မူရင်းအားဖြင့်၊ Envoy တွင် HTTP တောင်းဆိုချက်၏ အသေးစိတ်အချက်အလက်များပါဝင်သည့် ဖော်မတ်စာတန်းတစ်ခု ရှိသည်-

[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"n

ဤဖော်မတ်စာတန်း၏ရလဒ်မှာ-

[2018-11-23T04:51:00.281Z] "GET / HTTP/1.1" 200 - 0 58 4 1 "-" "curl/7.47.0" "f21ebd42-6770-4aa5-88d4-e56118165a7d" "one.example.com" "172.18.0.4:80"

ဖော်မတ်အကွက်ကို သတ်မှတ်ခြင်းဖြင့် အထွက်အကြောင်းအရာကို စိတ်ကြိုက်ပြင်ဆင်နိုင်သည်။ ဥပမာအားဖြင့်:

access_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"
    format: "[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"n"

အကွက်ကို သတ်မှတ်ခြင်းဖြင့် မှတ်တမ်းလိုင်းကိုလည်း JSON ဖော်မတ်ဖြင့် ထုတ်နိုင်သည်။ json_format။ ဥပမာ:

access_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"
    json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}

Envoy Registration Methodology ဆိုင်ရာ နောက်ထပ်အချက်အလက်များအတွက်၊ သွားရောက်ကြည့်ရှုပါ။

https://www.envoyproxy.io/docs/envoy/latest/configuration/access_log#config-access-log-format-dictionaries

သစ်ခိုးထုတ်ခြင်းသည် Envoy Proxy နှင့် လုပ်ဆောင်ခြင်းအတွက် ထိုးထွင်းသိမြင်နိုင်သော တစ်ခုတည်းသောနည်းလမ်းမဟုတ်ပါ။ ၎င်းတွင် အဆင့်မြင့်ခြေရာခံခြင်းနှင့် တိုင်းတာမှုစွမ်းရည်များပါရှိသည်။ တွင်ပိုမိုရှာဖွေနိုင်ပါသည်။ ခြေရာခံစာရွက်စာတမ်း သို့မဟုတ်တဆင့် အပြန်အလှန် ခြေရာခံခြင်း ဇာတ်ညွှန်း.

အဆင့် 7 - စတင်ပါ။

သင်သည် ယခု သင်၏ဖွဲ့စည်းပုံကို NGINX မှ Envoy Proxy သို့ ပြောင်းရွှေ့လိုက်ပါပြီ။ နောက်ဆုံးအဆင့်မှာ ၎င်းကိုစမ်းသပ်ရန်အတွက် Envoy Proxy ဥပမာတစ်ခုဖွင့်ရန်ဖြစ်သည်။

အသုံးပြုသူအဖြစ် လုပ်ဆောင်ပါ။

NGINX ဖွဲ့စည်းမှုလိုင်း၏ထိပ်တွင် အသုံးပြုသူ www www; လုံခြုံရေးတိုးတက်ကောင်းမွန်လာစေရန် NGINX ကို အခွင့်ထူးခံနည်းသောအသုံးပြုသူအဖြစ် သတ်မှတ်သည်။

Envoy Proxy သည် လုပ်ငန်းစဉ်တစ်ခုကို ပိုင်ဆိုင်သူအား စီမံခန့်ခွဲရန်အတွက် cloud-based ချဉ်းကပ်မှုတစ်ခုကို ရယူသည်။ ကျွန်ုပ်တို့သည် Envoy Proxy ကို ကွန်တိန်နာတစ်ခုမှတစ်ဆင့် လုပ်ဆောင်သောအခါ၊ အခွင့်ထူးခံနည်းသော အသုံးပြုသူအား သတ်မှတ်နိုင်သည်။

Envoy Proxy ကိုဖွင့်နေပါသည်။

အောက်ပါ command သည် host ရှိ Docker container မှတဆင့် Envoy Proxy ကို run လိမ့်မည်။ ဤ command သည် Envoy အား port 80 တွင် အဝင်တောင်းဆိုမှုများကို နားဆင်နိုင်စေပါသည်။ သို့ရာတွင်၊ နားဆင်သူဖွဲ့စည်းပုံတွင် သတ်မှတ်ထားသည့်အတိုင်း Envoy Proxy သည် port 8080 တွင် အဝင်အသွားအလာအတွက် နားထောင်ပါသည်။ ၎င်းသည် လုပ်ငန်းစဉ်ကို အခွင့်ထူးခံနည်းသောအသုံးပြုသူအဖြစ် လုပ်ဆောင်နိုင်စေပါသည်။

docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy

စမ်းသပ်ခြင်း

ပရောက်စီကို လုပ်ဆောင်ခြင်းဖြင့် စမ်းသပ်မှုများကို ယခုပြုလုပ်နိုင်ပြီး စီမံဆောင်ရွက်နိုင်ပါသည်။ အောက်ဖော်ပြပါ cURL ညွှန်ကြားချက်သည် ပရောက်စီဖွဲ့စည်းပုံတွင် သတ်မှတ်ထားသော လက်ခံဆောင်ရွက်ပေးသူ ခေါင်းစီးဖြင့် တောင်းဆိုချက်တစ်ခုထုတ်ပေးသည်။

curl -H "Host: one.example.com" localhost -i

HTTP တောင်းဆိုချက်သည် အမှားအယွင်းဖြစ်သွားလိမ့်မည်။ 503. အကြောင်းမှာ အထက်စီးကြောင်း ချိတ်ဆက်မှုများ အလုပ်မလုပ်ဘဲ မရရှိနိုင်သောကြောင့် ဖြစ်သည်။ ထို့ကြောင့် Envoy Proxy တွင် တောင်းဆိုချက်အတွက် ရနိုင်သောနေရာများ မရှိပါ။ အောက်ပါ command သည် Envoy အတွက် သတ်မှတ်ထားသော ဖွဲ့စည်းမှုပုံစံနှင့် ကိုက်ညီသော HTTP ဝန်ဆောင်မှုများ စီးရီးများကို စတင်ပါမည်။

docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;

ရရှိနိုင်သောဝန်ဆောင်မှုများနှင့်အတူ Envoy သည် ၎င်း၏ဦးတည်ရာသို့ အသွားအလာကို အောင်မြင်စွာ proxy လုပ်နိုင်မည်ဖြစ်သည်။

curl -H "Host: one.example.com" localhost -i

Docker ကွန်တိန်နာသည် တောင်းဆိုချက်ကို ဆောင်ရွက်ပေးကြောင်း ညွှန်ပြသည့် တုံ့ပြန်ချက်ကို သင်တွေ့ရပါမည်။ Envoy Proxy မှတ်တမ်းများတွင် ဝင်ရောက်အသုံးပြုနိုင်သည့် စာကြောင်းအထွက်ကိုလည်း တွေ့မြင်ရပါမည်။

နောက်ထပ် HTTP တုံ့ပြန်မှု ခေါင်းစီးများ

အမှန်တကယ်တောင်းဆိုမှု၏ တုံ့ပြန်မှုခေါင်းစီးများတွင် နောက်ထပ် HTTP ခေါင်းစီးများကို သင်တွေ့ရပါမည်။ ခေါင်းစီးသည် တောင်းဆိုချက်ကို လုပ်ဆောင်နေသည့် အထက်ရေစီးကြောင်း လက်ခံဆောင်ရွက်ပေးသည့် အချိန်ကို ပြသသည်။ မီလီစက္ကန့်များဖြင့် ဖော်ပြသည်။ သုံးစွဲသူသည် ကွန်ရက် latency နှင့် နှိုင်းယှဉ်ပါက ဝန်ဆောင်မှုအချိန်ကို ဆုံးဖြတ်လိုပါက ၎င်းသည် အသုံးဝင်သည်။

x-envoy-upstream-service-time: 0
server: envoy

နောက်ဆုံးပုံစံ

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
                - "one.example.com"
                - "www.one.example.com"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: targetCluster
          http_filters:
          - name: envoy.router
          clusters:
  - name: targetCluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    hosts: [
      { socket_address: { address: 172.18.0.3, port_value: 80 }},
      { socket_address: { address: 172.18.0.4, port_value: 80 }}
    ]

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 0.0.0.0, port_value: 9090 }

ဘာသာပြန်သူထံမှ နောက်ထပ်အချက်အလက်များ

Envoy Proxy တပ်ဆင်ခြင်းအတွက် လမ်းညွှန်ချက်များကို ဝဘ်ဆိုက်ပေါ်တွင် တွေ့ရှိနိုင်ပါသည်။ https://www.getenvoy.io/

ပုံမှန်အားဖြင့်၊ rpm တွင် systemd service config မရှိပါ။

systemd ဝန်ဆောင်မှု config ထည့်ပါ /etc/systemd/system/envoy.service-

[Unit]
Description=Envoy Proxy
Documentation=https://www.envoyproxy.io/
After=network-online.target
Requires=envoy-auth-server.service
Wants=nginx.service

[Service]
User=root
Restart=on-failure
ExecStart=/usr/bin/envoy --config-path /etc/envoy/config.yaml
[Install]
WantedBy=multi-user.target

သင် /etc/envoy/ လမ်းညွှန်တစ်ခုဖန်တီးပြီး config.yaml config ကို ထိုနေရာတွင် ထားရန်လိုအပ်သည်။

သံတမန် ပရောက်စီကို အသုံးပြု၍ တယ်လီဂရမ် စကားပြောခန်းတစ်ခု ရှိသည်- https://t.me/envoyproxy_ru

Envoy Proxy သည် တည်ငြိမ်သောအကြောင်းအရာကို ပံ့ပိုးမထားပါ။ ထို့ကြောင့်၊ အင်္ဂါရပ်ကို မဲပေးနိုင်သူ- https://github.com/envoyproxy/envoy/issues/378

စာရင်းသွင်းအသုံးပြုသူများသာ စစ်တမ်းတွင် ပါဝင်နိုင်ပါသည်။ ဆိုင်းအင်လုပ်ခြင်း, ကျေးဇူးပြု။

ဤပို့စ်သည် သင့်အား အထူးကိုယ်စားလှယ်ပရောက်စီကို ထည့်သွင်းပြီး စမ်းသပ်ရန် အားပေးပါသလား။

• ဟုတ်ကဲ့

• အဘယ်သူမျှမ

အသုံးပြုသူ 75 ဦး မဲပေးခဲ့သည်။ အသုံးပြုသူ 18 ရှောင်နေခဲ့ပါတယ်။

source: www.habr.com