پرو ہوسٹر > بلاگ > انتظامیہ > Nginx سے ایلچی پراکسی کی طرف ہجرت

Nginx سے ایلچی پراکسی کی طرف ہجرت

ہیلو، حبر! میں آپ کی توجہ اس پوسٹ کا ترجمہ لاتا ہوں: Nginx سے ایلچی پراکسی کی طرف ہجرت.

ایلچی ایک اعلی کارکردگی والا تقسیم شدہ پراکسی سرور ہے (جسے C++ میں لکھا گیا ہے) انفرادی خدمات اور ایپلیکیشنز کے لیے ڈیزائن کیا گیا ہے، یہ ایک کمیونیکیشن بس اور "یونیورسل ڈیٹا پلین" بھی ہے جسے بڑے مائیکرو سروس "سروس میش" آرکیٹیکچرز کے لیے ڈیزائن کیا گیا ہے۔ اسے بناتے وقت، سرورز کی ترقی کے دوران پیدا ہونے والے مسائل کے حل جیسے کہ NGINX، HAProxy، ہارڈویئر لوڈ بیلنسرز اور کلاؤڈ لوڈ بیلنسرز کو مدنظر رکھا گیا۔ ایلچی ہر ایپلیکیشن کے ساتھ کام کرتا ہے اور پلیٹ فارم سے قطع نظر مشترکہ فعالیت فراہم کرنے کے لیے نیٹ ورک کا خلاصہ کرتا ہے۔ جب انفراسٹرکچر میں تمام سروس ٹریفک اینوائے میش سے گزرتی ہے، تو مستقل مشاہدے کے ساتھ مسائل کے علاقوں کا تصور کرنا، مجموعی کارکردگی کو ٹیون کرنا، اور مخصوص جگہ میں بنیادی فعالیت شامل کرنا آسان ہو جاتا ہے۔

صلاحیتوں

  • آؤٹ آف پروسیس فن تعمیر: ایلچی ایک خود ساختہ، اعلی کارکردگی والا سرور ہے جو تھوڑی مقدار میں RAM لیتا ہے۔ یہ کسی بھی درخواست کی زبان یا فریم ورک کے ساتھ مل کر کام کرتا ہے۔
  • http/2 اور grpc سپورٹ: ایلچی کو فرسٹ کلاس http/2 اور آنے والے اور جانے والے کنکشن کے لیے grpc سپورٹ حاصل ہے۔ یہ http/1.1 سے http/2 تک ایک شفاف پراکسی ہے۔
  • ایڈوانسڈ لوڈ بیلنسنگ: ایلچی اعلی درجے کی لوڈ بیلنسنگ خصوصیات کو سپورٹ کرتا ہے جس میں خودکار دوبارہ کوششیں، چین توڑنا، عالمی شرح کو محدود کرنا، درخواست شیڈونگ، مقامی زون لوڈ بیلنسنگ وغیرہ شامل ہیں۔
  • کنفیگریشن مینجمنٹ API: ایلچی آپ کی ترتیب کو متحرک طور پر منظم کرنے کے لیے ایک مضبوط API فراہم کرتا ہے۔
  • آبزرویبلٹی: L7 ٹریفک کی گہرا مشاہدہ، تقسیم شدہ ٹریسنگ کے لیے مقامی مدد اور mongodb، dynamodb اور بہت سی دیگر ایپلی کیشنز کی مشاہداتی صلاحیت۔

مرحلہ 1 - مثال NGINX ترتیب

یہ اسکرپٹ خاص طور پر تیار کردہ فائل کا استعمال کرتا ہے۔ nginx.confسے مکمل مثال کی بنیاد پر NGINX وکی. آپ ایڈیٹر میں کھول کر کنفیگریشن دیکھ سکتے ہیں۔ nginx.conf

nginx سورس کی تشکیل

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 پورٹ 8080 پر۔
  3. ہدف کے مقام کو ترتیب دینا، URL کے مختلف حصوں کے لیے ٹریفک کو کیسے ہینڈل کرنا ہے۔

تمام کنفیگریشن Envoy Proxy پر لاگو نہیں ہوگی، اور آپ کو کچھ سیٹنگز کنفیگر کرنے کی ضرورت نہیں ہے۔ ایلچی پراکسی کے پاس ہے۔ چار اہم اقسام، جو NGINX کی طرف سے پیش کردہ بنیادی انفراسٹرکچر کی حمایت کرتا ہے۔ بنیادی ہے:

  • سننے والے: وہ طے کرتے ہیں کہ ایلچی پراکسی آنے والی درخواستوں کو کیسے قبول کرتا ہے۔ ایلچی پراکسی فی الحال صرف TCP پر مبنی سامعین کی حمایت کرتا ہے۔ ایک بار کنکشن قائم ہوجانے کے بعد، اسے پروسیسنگ کے لیے فلٹرز کے ایک سیٹ تک پہنچا دیا جاتا ہے۔
  • فلٹرز: وہ ایک پائپ لائن فن تعمیر کا حصہ ہیں جو آنے والے اور جانے والے ڈیٹا پر کارروائی کر سکتے ہیں۔ اس فعالیت میں Gzip جیسے فلٹرز شامل ہیں، جو کلائنٹ کو بھیجنے سے پہلے ڈیٹا کو کمپریس کرتے ہیں۔
  • راؤٹرز: وہ ٹریفک کو مطلوبہ منزل تک پہنچاتے ہیں، جسے کلسٹر کے طور پر بیان کیا گیا ہے۔
  • کلسٹرز: وہ ٹریفک اور کنفیگریشن پیرامیٹرز کے لیے اختتامی نقطہ کی وضاحت کرتے ہیں۔

ہم ان چار اجزاء کو ایک مخصوص NGINX کنفیگریشن سے ملنے کے لیے Envoy Proxy کنفیگریشن بنانے کے لیے استعمال کریں گے۔ ایلچی کا مقصد APIs اور متحرک کنفیگریشن کے ساتھ کام کرنا ہے۔ اس صورت میں، بیس کنفیگریشن NGINX سے جامد، ہارڈ کوڈ والی ترتیبات کا استعمال کرے گی۔

مرحلہ 2 - NGINX کنفیگریشن

پہلا حصہ nginx.conf کچھ NGINX انٹرنلز کی وضاحت کرتا ہے جن کو ترتیب دینے کی ضرورت ہے۔

ورکر کنکشنز

نیچے دی گئی ترتیب کارکن کے عمل اور کنکشن کی تعداد کا تعین کرتی ہے۔ یہ بتاتا ہے کہ کس طرح NGINX مانگ کو پورا کرنے کے لیے پیمانہ بنائے گا۔

worker_processes  2;

events {
  worker_connections   2000;
}

Envoy Proxy مختلف طریقوں سے ورک فلو اور کنکشن کا انتظام کرتا ہے۔

ایلچی سسٹم میں ہر ہارڈویئر تھریڈ کے لیے ورکر تھریڈ بناتا ہے۔ ہر ورکر تھریڈ ایک نان بلاکنگ ایونٹ لوپ کو چلاتا ہے جس کے لیے ذمہ دار ہے۔

  1. ہر سننے والے کو سننا
  2. نئے رابطوں کو قبول کرنا
  3. کنکشن کے لیے فلٹرز کا ایک سیٹ بنانا
  4. کنکشن کی زندگی کے دوران تمام I/O آپریشنز پر کارروائی کریں۔

تمام مزید کنکشن پروسیسنگ کو مکمل طور پر ورکر تھریڈ میں ہینڈل کیا جاتا ہے، بشمول فارورڈنگ کا کوئی بھی رویہ۔

ایلچی میں ہر ورکر تھریڈ کے لیے، ایک کنکشن پول ہے۔ لہذا HTTP/2 کنکشن پول ایک وقت میں ہر بیرونی میزبان کے لیے صرف ایک کنکشن قائم کرتے ہیں، اگر چار ورکر تھریڈز ہیں تو ایک مستحکم حالت میں ہر بیرونی میزبان کے لیے چار HTTP/2 کنکشنز ہوں گے۔ ہر چیز کو ایک ورکر تھریڈ میں رکھ کر، تقریباً تمام کوڈ کو بلاک کیے بغیر لکھا جا سکتا ہے، جیسے کہ یہ سنگل تھریڈڈ ہو۔ اگر ضرورت سے زیادہ ورکر تھریڈز مختص کیے جاتے ہیں، تو یہ میموری کو ضائع کرنے کا باعث بن سکتا ہے، بڑی تعداد میں بیکار کنکشنز بن سکتے ہیں، اور پول میں کنکشنز کی واپسی کی تعداد کو کم کر سکتے ہیں۔

посетите получения дополнительной информации посетите ایلچی پراکسی بلاگ.

HTTP کنفیگریشن

درج ذیل NGINX کنفیگریشن بلاک HTTP ترتیبات کی وضاحت کرتا ہے جیسے:

  • کون سی مائم اقسام کی حمایت کی جاتی ہے۔
  • ڈیفالٹ ٹائم آؤٹ
  • Gzip کنفیگریشن

آپ Envoy Proxy میں فلٹرز کا استعمال کرتے ہوئے ان پہلوؤں کو اپنی مرضی کے مطابق بنا سکتے ہیں، جس پر ہم بعد میں بات کریں گے۔

مرحلہ 3 - سرور کی ترتیب

HTTP کنفیگریشن بلاک میں، NGINX کنفیگریشن پورٹ 8080 پر سننے اور ڈومینز کے لیے آنے والی درخواستوں کا جواب دینے کی وضاحت کرتی ہے۔ one.example.com и www.one.example.com.

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

ایلچی کے اندر، اسے سننے والوں کے ذریعے کنٹرول کیا جاتا ہے۔

ایلچی سننے والے

Envoy Proxy کے ساتھ شروع کرنے کا سب سے اہم پہلو آپ کے سامعین کی تعریف کرنا ہے۔ آپ کو ایک کنفیگریشن فائل بنانے کی ضرورت ہے جو یہ بتاتی ہو کہ آپ Envoy مثال کو کیسے چلانا چاہتے ہیں۔

ذیل کا ٹکڑا ایک نیا سننے والا بنائے گا اور اسے پورٹ 8080 سے منسلک کرے گا۔ کنفیگریشن ایلچی پراکسی کو بتاتی ہے کہ آنے والی درخواستوں کے لیے اسے کن بندرگاہوں کا پابند ہونا چاہیے۔

Envoy Proxy اپنی ترتیب کے لیے YAML اشارے استعمال کرتا ہے۔ اس اشارے کے تعارف کے لیے، یہاں دیکھیں لنک.

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;
}

ایلچی میں، فلٹرز یہ کرتے ہیں۔

ایلچی فلٹرز

ایک جامد ترتیب کے لیے، فلٹرز طے کرتے ہیں کہ آنے والی درخواستوں پر کیسے عمل کیا جائے۔ اس صورت میں ہم فلٹرز سیٹ کرتے ہیں جو میچ کرتے ہیں۔ سرور_نام پچھلے مرحلے میں جب آنے والی درخواستیں کچھ مخصوص ڈومینز اور روٹس سے ملتی ہیں، تو ٹریفک کو کلسٹر کی طرف روانہ کیا جاتا ہے۔ یہ 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 میں ایک بلٹ ان فلٹر ہے۔ دیگر فلٹرز میں شامل ہیں۔ ریڈس, منگو, ٹی سی پی. آپ کو مکمل فہرست پر مل سکتی ہے۔ دستاویزات.

لوڈ بیلنسنگ کی دیگر پالیسیوں کے بارے میں مزید معلومات کے لیے، ملاحظہ کریں۔ ایلچی دستاویزات.

مرحلہ 5 - پراکسی اور اپ اسٹریم کنفیگریشن

NGINX میں، اپ اسٹریم کنفیگریشن ٹارگٹ سرورز کے ایک سیٹ کی وضاحت کرتی ہے جو ٹریفک پر کارروائی کرے گی۔ اس معاملے میں، دو کلسٹرز تفویض کیے گئے تھے۔

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

ایلچی میں، اس کا انتظام کلسٹرز کے ذریعے کیا جاتا ہے۔

ایلچی کلسٹرز

اپ اسٹریم کے مساوی کو کلسٹرز کے طور پر بیان کیا گیا ہے۔ اس صورت میں، ٹریفک کی خدمت کرنے والے میزبانوں کی شناخت کر لی گئی ہے۔ میزبانوں تک رسائی کا طریقہ، جیسے ٹائم آؤٹ، کلسٹر کنفیگریشن کے طور پر بیان کیا جاتا ہے۔ یہ تاخیر اور بوجھ کے توازن جیسے پہلوؤں پر مزید دانے دار کنٹرول کی اجازت دیتا ہے۔

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 پتے واپس کرتی ہے، تو ایلچی سمجھے گا کہ کلسٹر میں دو میزبان ہیں، اور دونوں کا بوجھ متوازن ہونا چاہیے۔ اگر کسی میزبان کو نتیجہ سے ہٹا دیا جاتا ہے، تو ایلچی سمجھے گا کہ یہ اب موجود نہیں ہے اور کسی بھی موجودہ کنکشن پول سے ٹریفک کھینچ لے گا۔

см получения дополнительной информации см. ایلچی پراکسی دستاویزات.

مرحلہ 6 - لاگ رسائی اور غلطیاں

آخری ترتیب رجسٹریشن ہے۔ غلطی کے نوشتہ جات کو ڈسک پر دھکیلنے کے بجائے، Envoy Proxy کلاؤڈ پر مبنی طریقہ اختیار کرتا ہے۔ تمام ایپلیکیشن لاگز آؤٹ پٹ ہیں۔ stdout и سٹڈرر.

جب صارفین کوئی درخواست کرتے ہیں تو رسائی کے لاگز اختیاری ہوتے ہیں اور بطور ڈیفالٹ غیر فعال ہوتے ہیں۔ HTTP درخواستوں کے لیے رسائی لاگز کو فعال کرنے کے لیے، کنفیگریشن کو فعال کریں۔ رسائی_لاگ HTTP کنکشن مینیجر کے لیے۔ راستہ یا تو ایک آلہ ہوسکتا ہے جیسے stdout، یا آپ کی ضروریات پر منحصر ڈسک پر فائل۔

درج ذیل کنفیگریشن تمام رسائی لاگز کو ری ڈائریکٹ کرے گی۔ stdout (مترجم کا نوٹ - ڈوکر کے اندر ایلچی استعمال کرنے کے لیے stdout کی ضرورت ہوتی ہے۔ اگر 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)%"}

ایلچی رجسٹریشن کے طریقہ کار کے بارے میں مزید معلومات کے لیے، ملاحظہ کریں۔

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 چلاتے ہیں، تو ہم ایک کم مراعات یافتہ صارف کی وضاحت کر سکتے ہیں۔

ایلچی پراکسی لانچ کرنا

نیچے دی گئی کمانڈ میزبان پر ڈوکر کنٹینر کے ذریعے ایلچی پراکسی چلائے گی۔ یہ کمانڈ ایلچی کو پورٹ 80 پر آنے والی درخواستوں کو سننے کی صلاحیت فراہم کرتی ہے۔ تاہم، جیسا کہ سننے والے کی ترتیب میں بیان کیا گیا ہے، Envoy Proxy پورٹ 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 کے پاس درخواست کے لیے کوئی منزلیں دستیاب نہیں ہیں۔ درج ذیل کمانڈ HTTP خدمات کا ایک سلسلہ شروع کرے گی جو ایلچی کے لیے بیان کردہ ترتیب سے میل کھاتی ہے۔

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

دستیاب خدمات کے ساتھ، ایلچی کامیابی سے ٹریفک کو اپنی منزل تک پہنچا سکتا ہے۔

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

آپ کو ایک جواب دیکھنا چاہئے جس سے ظاہر ہوتا ہے کہ کون سے ڈوکر کنٹینر نے درخواست پر کارروائی کی ہے۔ Envoy Proxy لاگز میں آپ کو ایکسیس سٹرنگ آؤٹ پٹ بھی نظر آنا چاہیے۔

اضافی HTTP رسپانس ہیڈر

آپ کو اصل درخواست کے جوابی ہیڈر میں اضافی HTTP ہیڈر نظر آئیں گے۔ ہیڈر وہ وقت دکھاتا ہے جب اپ اسٹریم ہوسٹ نے درخواست پر کارروائی کرنے میں صرف کیا تھا۔ ملی سیکنڈ میں بیان کیا گیا۔ یہ مفید ہے اگر کلائنٹ نیٹ ورک لیٹنسی کے مقابلے سروس کے وقت کا تعین کرنا چاہتا ہے۔

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 سروس کی تشکیل شامل کریں /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

ایلچی پراکسی جامد مواد پیش کرنے کی حمایت نہیں کرتا ہے۔ لہذا، کون اس خصوصیت کو ووٹ دے سکتا ہے: https://github.com/envoyproxy/envoy/issues/378

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

کیا اس پوسٹ نے آپ کو ایلچی پراکسی انسٹال کرنے اور جانچنے کی ترغیب دی؟

  • جی ہاں

  • нет

75 صارفین نے ووٹ دیا۔ 18 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں