🥇 الهجرة من Nginx إلى Envoy Proxy

يا هبر! هذه ترجمة للمنشور: الترحيل من Nginx إلى Envoy Proxy.

Envoy هو خادم وكيل موزع عالي الأداء (مكتوب بلغة C ++) مصمم للخدمات والتطبيقات الفردية ، وهو أيضًا ناقل اتصال و "مستوى بيانات عالمي" مصمم لبنى الخدمات المصغرة "شبكة الخدمة" الكبيرة. عندما تم إنشاؤه ، تم أخذ حلول المشكلات التي نشأت أثناء تطوير الخوادم مثل NGINX و HAProxy وموازنات تحميل الأجهزة وموازن التحميل السحابي في الاعتبار. يعمل Envoy مع كل تطبيق ويلخص الشبكة لتوفير وظائف مشتركة بغض النظر عن النظام الأساسي. عندما تمر جميع حركة مرور الخدمات في البنية التحتية عبر شبكة Envoy ، يصبح من السهل تصور مناطق المشكلات من خلال إمكانية المراقبة المتسقة وضبط الأداء العام وإضافة الوظائف الأساسية في موقع معين.

قدرات

بنية خارج العملية: المبعوث هو خادم مستقل عالي الأداء يستهلك القليل من ذاكرة الوصول العشوائي. إنه يعمل جنبًا إلى جنب مع أي لغة أو إطار عمل للتطبيق.
دعم http / 2 و grpc: يمتلك المبعوث http / 2 من الدرجة الأولى ودعم grpc لكل من الاتصالات الواردة والصادرة. وهو وكيل شفاف من http / 1.1 إلى http / 2.
موازنة الحمل المتقدمة: يدعم المبعوث ميزات موازنة الحمل المتقدمة ، بما في ذلك عمليات إعادة المحاولة التلقائية ، وإنهاء السلسلة ، وتحديد المعدل العام ، وتظليل الاستعلام ، وموازنة التحميل المحلي للمنطقة ، وما إلى ذلك.
واجهة برمجة تطبيقات إدارة التكوين: يوفر envoy واجهة برمجة تطبيقات قوية لإدارة التكوين بشكل ديناميكي.
قابلية الملاحظة: إمكانية الملاحظة العميقة لحركة مرور L7 ، ودعم مدمج للتتبع الموزع ، وإمكانية ملاحظة mongodb و dynamodb والعديد من التطبيقات الأخرى.

الخطوة 1 - مثال تكوين NGINX

يستخدم هذا البرنامج النصي ملفًا تم إنشاؤه خصيصًا nginx.conf، بناءً على المثال الكامل من ويكي. يمكنك عرض التكوين في المحرر من خلال فتح 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 عادةً على ثلاثة عناصر رئيسية:

إعداد خادم NGINX وهيكل التسجيل ووظيفة Gzip. يتم تعريف هذا عالميًا في جميع الحالات.
تكوين NGINX لقبول الطلبات إلى المضيف one.example.com على المنفذ 8080.
إعداد الموقع المستهدف ، كيفية التعامل مع حركة المرور لأجزاء مختلفة من عنوان URL.

لن يتم تطبيق جميع التكوينات على Envoy Proxy ولا تحتاج إلى تهيئة بعض الإعدادات. Envoy Proxy يمتلك أربعة أنواع رئيسية، والتي تدعم البنية التحتية الأساسية التي تقدمها NGINX. النواة هي:

المستمعون: وهي تحدد كيفية قبول Envoy Proxy للطلبات الواردة. لا يدعم Envoy Proxy حاليًا سوى المستمعين المعتمدين على بروتوكول TCP. بمجرد إنشاء الاتصال ، يتم تمريره إلى مجموعة المرشح للمعالجة.
المرشحات: إنها جزء من بنية خطوط الأنابيب التي يمكنها معالجة البيانات الواردة والصادرة. تتضمن هذه الوظيفة عوامل تصفية مثل Gzip ، والتي تضغط البيانات قبل إرسالها إلى العميل.
الموجهات: يعيدون توجيه حركة المرور إلى الوجهة المرغوبة ، المعرفة على أنها كتلة.
عناقيد المجموعات: هم يحددون نقطة النهاية لحركة المرور وخيارات التكوين.

سنستخدم هذه المكونات الأربعة لإنشاء تكوين Envoy Proxy لمطابقة تكوين NGINX المحدد. الغرض من Envoy هو عمل API والتكوين الديناميكي. في هذه الحالة ، سيستخدم التكوين الأساسي الخيارات الثابتة المشفرة من NGINX.

الخطوة 2 - تكوين NGINX

الجزء الأول nginx.conf يحدد بعض مكونات NGINX الداخلية التي يجب تكوينها.

اتصالات العمال

يحدد التكوين أدناه عدد عمليات واتصالات العاملين. يشير هذا إلى كيفية توسيع NGINX لتلبية الطلب.

worker_processes  2;

events {
  worker_connections   2000;
}

يدير Envoy Proxy سير العمل والاتصالات بطرق مختلفة.

يقوم Envoy بإنشاء مؤشر ترابط عامل لكل مؤشر ترابط للأجهزة في النظام. ينفذ كل مؤشر ترابط عامل حلقة حدث غير قابلة للحظر تكون مسؤولة عن

الاستماع لكل مستمع (مستمع)
قبول اتصالات جديدة
قم بإنشاء مجموعة عوامل تصفية للاتصال
معالجة جميع عمليات الإدخال / الإخراج خلال عمر الاتصال.

تتم معالجة كافة عمليات المعالجة الإضافية للاتصال بشكل كامل في مؤشر ترابط العامل ، بما في ذلك أي سلوك إعادة توجيه.

لكل مؤشر ترابط عامل في Envoy ، يوجد اتصال في التجمع. لذلك ، تنشئ تجمعات اتصال HTTP / 2 اتصالًا واحدًا فقط لكل مضيف خارجي في كل مرة ، مع أربعة سلاسل عمليات عاملة ، سيكون هناك أربعة اتصالات HTTP / 2 لكل مضيف خارجي في حالة مستقرة. من خلال الاحتفاظ بكل شيء في مؤشر ترابط عامل واحد ، يمكن كتابة جميع التعليمات البرمجية تقريبًا خالية من الكتل كما لو كانت ذات سلسلة واحدة. إذا تم تخصيص المزيد من مؤشرات الترابط العاملة أكثر من اللازم ، فقد يؤدي ذلك إلى إهدار الذاكرة ، وإنشاء عدد كبير من الاتصالات الخاملة ، وتقليل عدد عودة الاتصال إلى التجمع.

للمزيد من المعلومات قم بزيارة مدونة Envoy Proxy.

تكوين 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 ، يدير المستمعون ذلك.

مبعوث المستمعين

أهم جانب في بدء استخدام Envoy Proxy هو تحديد المستمعين. تحتاج إلى إنشاء ملف تكوين يصف كيف تريد تشغيل مثيل Envoy.

سينشئ المقتطف أدناه مستمعًا جديدًا وربطه بالمنفذ 8080. يخبر التكوين Envoy Proxy بالمنافذ التي يجب ربطه بها للطلبات الواردة.

يستخدم 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;
}

في Envoy ، هذا ما يفعله Filters.

مرشحات المبعوث

بالنسبة للتكوين الثابت ، تحدد عوامل التصفية كيفية معالجة الطلبات الواردة. في هذه الحالة ، نضع فلاتر مطابقة أسماء_الخوادم في الخطوة السابقة. عندما تأتي الطلبات الواردة التي تتطابق مع مجالات وطرق معينة ، يتم توجيه حركة المرور إلى الكتلة. هذا هو المكافئ لتكوين المنبع 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

اسم المبعوث. http_connection_manager هو عامل تصفية مدمج في Envoy Proxy. تشمل الفلاتر الأخرى رديس, مونغو, TCP. يمكنك العثور على القائمة الكاملة على توثيق.

لمزيد من المعلومات حول سياسات موازنة التحميل الأخرى ، قم بزيارة وثائق المبعوث.

الخطوة 5 - تكوين الوكيل والتحميل

في NGINX ، يحدد التكوين الرئيسي مجموعة من الخوادم المستهدفة التي ستقوم بمعالجة حركة المرور. في هذه الحالة ، تم تعيين مجموعتين.

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

في Envoy يتم إدارة هذا بواسطة المجموعات.

مجموعات المبعوث

يتم تعريف المكافئ المنبع على أنه مجموعات. في هذه الحالة ، تم تحديد المضيفين الذين سيخدمون حركة المرور. يتم تعريف كيفية الوصول إلى الأجهزة المضيفة ، مثل timeout ، على أنها تكوين نظام مجموعة. يتيح ذلك إمكانية التحكم بشكل أفضل في تفاصيل الجوانب مثل زمن الانتقال وموازنة الحمل.

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 سيعمل Envoy بشكل مستمر وغير متزامن على حل أهداف DNS المحددة. سيتم اعتبار كل عنوان IP معاد من نتيجة DNS مضيفًا صريحًا في الكتلة الأولية. هذا يعني أنه إذا قام الاستعلام بإرجاع عنواني IP ، فسوف يفترض Envoy أن هناك مضيفين في الكتلة ويجب أن يكون كلاهما متوازناً. إذا تمت إزالة مضيف من النتيجة ، يفترض Envoy أنه لم يعد موجودًا وسيسحب حركة المرور من أي تجمعات اتصال موجودة.

لمزيد من المعلومات، راجع وثائق الوكيل المبعوث.

الخطوة 6 - الوصول إلى السجل والأخطاء

التكوين النهائي هو التسجيل. بدلاً من دفع سجلات الأخطاء إلى القرص ، يتخذ Envoy Proxy نهجًا قائمًا على السحابة. يتم إخراج جميع سجلات التطبيق إلى المعياري и ستدير.

عندما يقدم المستخدمون طلبًا ، تكون سجلات الوصول اختيارية ويتم تعطيلها افتراضيًا. لتمكين سجلات الوصول لطلبات HTTP ، قم بتمكين التكوين access_log لمدير اتصال HTTP. يمكن أن يكون المسار جهازًا مثل المعياري، أو ملف على القرص ، حسب متطلباتك.

سيعيد التكوين التالي توجيه جميع سجلات الوصول إلى المعياري (ملاحظة المترجم - مطلوب stdout لاستخدام المبعوث داخل عامل الإرساء. إذا تم استخدامه بدون عامل عامل إرساء ، فاستبدل / 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 نهجًا قائمًا على السحابة لإدارة من يملك العملية. عندما نقوم بتشغيل Envoy Proxy من خلال حاوية ، يمكننا تحديد مستخدم ذي امتياز منخفض.

قم بتشغيل Envoy Proxy

سيؤدي الأمر أدناه إلى تشغيل Envoy Proxy من خلال حاوية Docker على المضيف. يمنح هذا الأمر Envoy القدرة على الاستماع للطلبات الواردة على المنفذ 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 التي تطابق التكوين المحدد لـ Envoy.

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

من خلال الخدمات المتاحة ، يمكن لـ Envoy أن يقوم بتوكيل حركة المرور إلى وجهتها بنجاح.

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

يجب أن ترى ردًا يشير إلى حاوية Docker التي تعاملت مع الطلب. في سجلات Envoy Proxy ، يجب أن ترى أيضًا سلسلة الوصول مطبوعة.

رؤوس استجابة HTTP إضافية (استجابة 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/

لا يوجد تكوين خدمة systemd في rpm افتراضيًا.

أضف تهيئة خدمة النظام إلى /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 مستخدما عن التصويت.

المصدر: www.habr.com

الترحيل من Nginx إلى Envoy Proxy