الترحيل من Nginx إلى مبعوث Proxy

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


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


الاحتمالات


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

الخطوة 1 - مثال NGINX Config


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


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


  1. الاستماع إلى كل مستمع
  2. قبول اتصالات جديدة
  3. إنشاء مجموعة مرشح للاتصال
  4. معالجة جميع عمليات الإدخال / الإخراج على مدى عمر الاتصال.

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


لكل سير عمل في 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 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 } 

ليست هناك حاجة لتعريف server_name ، حيث يمكن لعوامل التصفية Envoy Proxy معالجة ذلك.


الخطوة 4 - تكوين الموقع


عندما يصل طلب إلى NGINX ، تحدد كتلة الموقع كيفية معالجة ومكان توجيه حركة المرور. في الجزء التالي ، يتم نقل كل حركة المرور إلى الموقع إلى كتلة upstream (ملاحظة المترجم: upstream عادة ما تكون خادم تطبيقات) تسمى targetCluster . تعرّف الكتلة upstream العقد التي يجب معالجة الطلب. سنناقش هذا في الخطوة التالية.


 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. وتشمل المرشحات الأخرى Redis ، Mongo ، TCP . يمكنك العثور على القائمة الكاملة في الوثائق .


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


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


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


الخطوة 6 - تسجيل الدخول والأخطاء


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


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


التكوين التالي سيعيد توجيه جميع سجلات الوصول إلى stdout (ملاحظة المترجم - 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


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


 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 على https://www.getenvoy.io/


بشكل افتراضي في دورة في الدقيقة ، لا يوجد تكوين خدمة systemd.


أضف تهيئة خدمة 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


لا يدعم Envoy Proxy توزيع المحتوى الثابت. من يمكنه التصويت لصالح: https://github.com/envoyproxy/envoy/issues/378

Source: https://habr.com/ru/post/ar469455/


All Articles