HTTP रिवर्स प्रॉक्सी का चयन करते समय परीक्षण और त्रुटि

सभी को नमस्कार!

आज हम इस बारे में बात करना चाहते हैं कि ओस्ट्रोवोकॉव होटल आरक्षण सेवा टीम ने माइक्रोसेवर विकास की समस्या को कैसे हल किया, जिसका कार्य हमारे आपूर्तिकर्ताओं के साथ सूचना का आदान-प्रदान करना है। अपने अनुभव के बारे में बताता है कि ओड्रोवॉक में देवओप्स टीम लीड।


सबसे पहले, माइक्रोसैस सर्विस छोटा था और निम्नलिखित कार्य करता था:

• स्थानीय सेवा से अनुरोध स्वीकार करें;
• एक साथी से अनुरोध करें;
• प्रतिक्रिया को सामान्य करें;
• क्वेरी सेवा पर परिणाम लौटाएं।

हालांकि, समय बीत गया, सेवा भागीदारों की संख्या और उनके अनुरोधों के साथ-साथ बढ़ती गई।

जैसे-जैसे सेवा बढ़ी, विभिन्न प्रकार की समस्याएं उभरने लगीं। अलग-अलग प्रदाता अपने स्वयं के नियमों को आगे रखते हैं: कोई अधिकतम कनेक्शन की सीमा को सीमित करता है, कोई ग्राहकों को सफेद सूची में प्रतिबंधित करता है।

परिणामस्वरूप, हमें निम्नलिखित समस्याओं को हल करना पड़ा:

• कई निश्चित बाहरी आईपी पते होना वांछनीय है ताकि आप उन्हें सफेद सूची में जोड़ने के लिए भागीदारों को प्रदान कर सकें,
• सभी आपूर्तिकर्ताओं के लिए कनेक्शनों का एक एकल पूल है ताकि जब हमारे माइक्रोसर्विस को स्केल किया जाए तो कनेक्शन की संख्या कम से कम बनी रहे,
• SSL को समाप्त करें और एक स्थान पर रखें, जिससे भागीदारों पर भार कम हो।

उन्होंने लंबे समय तक नहीं सोचा और तुरंत सोचा कि क्या चुनना है: नगनेक्स या हाप्रोसी।
सबसे पहले, पेंडुलम नेग्नेक्स की ओर घूम गया, क्योंकि HTTP / HTTPS I से जुड़ी अधिकांश समस्याएं इसकी मदद से हल हुईं और हमेशा परिणाम से संतुष्ट थीं।

यह योजना सरल थी: Nginx पर हमारे नए प्रॉक्सी सर्वर से अनुरोध किया गया था कि फॉर्म के एक डोमेन के साथ <partner_tag>.domain.local , Nginx में एक map था जहां <partner_tag> साझेदार के पते के अनुरूप था। एक पता map से लिया गया था और proxy_pass को इस पते पर बनाया गया था।

यहां एक उदाहरण map गया है जिसके साथ हम डोमेन को पार्स करते हैं और सूची से अपस्ट्रीम का चयन करते हैं:

 ###     : <tag>.domain.local map $http_host $upstream_prefix { default 0; "~^([^\.]+)\." $1; } ###      map $upstream_prefix $upstream_address { include snippet.d/upstreams_map; default http://127.0.0.1:8080; } ###   upstream_host    upstream_address map $upstream_address $upstream_host { default 0; "~^https?://([^:]+)" $1; } 

और यहाँ " snippet.d/upstreams_map " जैसा दिखता है:

 “one” “http://one.domain.net”; “two” “https://two.domain.org”; 

यहाँ हमारे पास server{} :

 server { listen 80; location / { proxy_http_version 1.1; proxy_pass $upstream_address$request_uri; proxy_set_header Host $upstream_host; proxy_set_header X-Forwarded-For ""; proxy_set_header X-Forwarded-Port ""; proxy_set_header X-Forwarded-Proto ""; } } # service for error handling and logging server { listen 127.0.0.1:8080; location / { return 400; } location /ngx_status/ { stub_status; } } 

सब कुछ शांत है, सब कुछ काम करता है। इस लेख को समाप्त करना संभव है, यदि एक बारीकियों के लिए नहीं।

प्रॉक्सी_पास का उपयोग करते समय, अनुरोध सीधे एक वांछित पते पर जाता है, एक नियम के रूप में, HTTP / 1.0 प्रोटोकॉल का बिना keepalive और प्रतिक्रिया पूरा होने के तुरंत बाद बंद हो जाता है। यहां तक ​​कि अगर हम proxy_http_version 1.1 , तो भी अपस्ट्रीम ( प्रॉक्सी_http_version ) के बिना कुछ भी नहीं बदलेगा।

क्या करें? पहला विचार सभी आपूर्तिकर्ताओं को अपस्ट्रीम में लाना है, जहां सर्वर को हमारे द्वारा आवश्यक आपूर्तिकर्ता का पता होगा, और map "tag" "upstream_name" ।

योजना को पार्स करने के लिए एक और map जोड़ें:

 ###     : <tag>.domain.local map $http_host $upstream_prefix { default 0; "~^([^\.]+)\." $1; } ###      map $upstream_prefix $upstream_address { include snippet.d/upstreams_map; default http://127.0.0.1:8080; } ###   upstream_host    upstream_address map $upstream_address $upstream_host { default 0; "~^https?://([^:]+)" $1; } ###   ,       https,    ,    -  http map $upstream_address $upstream_scheme { default "http://"; "~(https?://)" $1; } 

और टैग नामों के साथ upstreams बनाएं:

  upstream one { keepalive 64; server one.domain.com; } upstream two { keepalive 64; server two.domain.net; } 

सर्वर को योजना को ध्यान में रखने और पते के बजाय अपस्ट्रीम के नाम का उपयोग करने के लिए थोड़ा संशोधित किया गया है:

 server { listen 80; location / { proxy_http_version 1.1; proxy_pass $upstream_scheme$upstream_prefix$request_uri; proxy_set_header Host $upstream_host; proxy_set_header X-Forwarded-For ""; proxy_set_header X-Forwarded-Port ""; proxy_set_header X-Forwarded-Proto ""; } } # service for error handling and logging server { listen 127.0.0.1:8080; location / { return 400; } location /ngx_status/ { stub_status; } } 

बहुत बढ़िया। समाधान काम करता है, प्रत्येक अपस्ट्रीम में proxy_http_version 1.1 डायरेक्टिव को जोड़ें, proxy_http_version 1.1 सेट करें, - अब हमारे पास एक कनेक्शन पूल है, और सब कुछ उसी तरह काम करता है जैसे यह होना चाहिए।

इस बार, आप निश्चित रूप से लेख समाप्त कर सकते हैं और चाय पी सकते हैं। या नहीं?

दरअसल, जब हम चाय पी रहे होते हैं, तो आपूर्तिकर्ताओं में से कोई एक ही डोमेन (हाय, अमेज़ॅन) के तहत आईपी पते या पते के समूह को बदल सकता है, जिससे आपूर्तिकर्ताओं में से एक हमारी चाय पार्टी की ऊंचाई पर गिर सकता है।

खैर, क्या करना है? नेग्नेक्स में एक दिलचस्प बारीकियों है: पुनः लोड के दौरान, यह ऊपर के सर्वरों को नए पते तक upstream जा सकता है और उन पर ट्रैफ़िक डाल सकता है। सामान्य तौर पर, एक समाधान भी। हर 5 मिनट में cron reload nginx में फेंक दें और चाय पीना जारी रखें।

लेकिन फिर भी यह मुझे एक बहुत ही निर्णय लग रहा था, इसलिए मैंने हाप्रोसी की ओर पूछना शुरू कर दिया।

हाप्रोसी में dns resolvers निर्दिष्ट करने और dns cache कॉन्फ़िगर करने की क्षमता है। इस प्रकार, हाप्रोसी dns cache अपडेट कर देगा यदि इसमें प्रविष्टियां समाप्त हो गई हैं, और अगर वे बदल गए हैं तो अपस्ट्रीम के पते को बदल दें।

बहुत बढ़िया! अब यह सेटिंग्स पर निर्भर है।

यहाँ Haproxy के लिए एक छोटा विन्यास उदाहरण है:

 frontend http bind *:80 http-request del-header X-Forwarded-For http-request del-header X-Forwarded-Port http-request del-header X-Forwarded-Proto capture request header Host len 32 capture request header Referer len 128 capture request header User-Agent len 128 acl host_present hdr(host) -m len gt 0 use_backend %[req.hdr(host),lower,field(1,'.')] if host_present default_backend default resolvers dns hold valid 1s timeout retry 100ms nameserver dns1 1.1.1.1:53 backend one http-request set-header Host one.domain.com server one--one.domain.com one.domain.com:80 resolvers dns check backend two http-request set-header Host two.domain.net server two--two.domain.net two.domain.net:443 resolvers dns check ssl verify none check-sni two.domain.net sni str(two.domain.net) 

सब कुछ काम करने लगता है जैसा कि इस बार होना चाहिए। केवल एक चीज जो मुझे हाप्रोसी के बारे में पसंद नहीं है वह कॉन्फ़िगरेशन विवरण की जटिलता है। एक काम करने वाले अपस्ट्रीम को जोड़ने के लिए आपको बहुत सारे टेक्स्ट बनाने की आवश्यकता है लेकिन आलस्य प्रगति का इंजन है: यदि आप एक ही बात लिखना नहीं चाहते हैं, तो एक जनरेटर लिखें।

मेरे पास पहले से ही नग्नेक्स से एक प्रारूप था "tag" "upstream" प्रारूप के साथ, इसलिए मैंने इसे आधार के रूप में लेने, पार्स करने और इन मूल्यों के आधार पर एक हाइप्रोयो बैकएंड उत्पन्न करने का निर्णय लिया।

 #! /usr/bin/env bash haproxy_backend_map_file=./root/etc/haproxy/snippet.d/name_domain_map haproxy_backends_file=./root/etc/haproxy/99_backends.cfg nginx_map_file=./nginx_map while getopts 'n:b:m:' OPT;do case ${OPT} in n) nginx_map_file=${OPTARG} ;; b) haproxy_backends_file=${OPTARG} ;; m) haproxy_backend_map_file=${OPTARG} ;; *) echo 'Usage: ${0} -n [nginx_map_file] -b [haproxy_backends_file] -m [haproxy_backend_map_file]' exit esac done function write_backend(){ local tag=$1 local domain=$2 local port=$3 local server_options="resolvers dns check" [ -n "${4}" ] && local ssl_options="ssl verify none check-sni ${domain} sni str(${domain})" [ -n "${4}" ] && server_options+=" ${ssl_options}" cat >> ${haproxy_backends_file} <<EOF backend ${tag} http-request set-header Host ${domain} server ${tag}--${domain} ${domain}:${port} ${server_options} EOF } :> ${haproxy_backends_file} :> ${haproxy_backend_map_file} while read tag addr;do tag=${tag//\"/} [ -z "${tag:0}" ] && continue [ "${tag:0:1}" == "#" ] && continue IFS=":" read scheme domain port <<<${addr//;} unset IFS domain=${domain//\/} case ${scheme} in http) port=${port:-80} write_backend ${tag} ${domain} ${port} ;; https) port=${port:-443} write_backend ${tag} ${domain} ${port} 1 esac done < <(sort -V ${nginx_map_file}) 

अब हम सभी को nginx_map में एक नया होस्ट जोड़ना है, जनरेटर शुरू करें और तैयार हैप्रोक्सी कॉन्फिगर प्राप्त करें।

आज के लिए बस इतना ही। यह लेख अधिक परिचयात्मक है और एक समाधान चुनने और वर्तमान परिवेश में इसके एकीकरण की समस्या पर केंद्रित है।

अगले लेख में मैं आपको बताऊंगा कि हाप्रॉक्सी का उपयोग करते समय हमें क्या नुकसान हुए, जो कि निगरानी के लिए मेट्रिक्स उपयोगी साबित हुए, और सर्वर से अधिकतम प्रदर्शन प्राप्त करने के लिए सिस्टम में वास्तव में क्या अनुकूलित होना चाहिए।

ध्यान देने के लिए आप सभी का धन्यवाद, देखिये!