హలో, హబ్ర్! నేను పోస్ట్ యొక్క అనువాదాన్ని మీ దృష్టికి తీసుకువస్తున్నాను:
ఎన్వోయ్ అనేది వ్యక్తిగత సేవలు మరియు అప్లికేషన్ల కోసం రూపొందించబడిన అధిక-పనితీరు గల డిస్ట్రిబ్యూట్ ప్రాక్సీ సర్వర్ (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 సోర్స్ కాన్ఫిగర్
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లోని వివిధ భాగాల కోసం ట్రాఫిక్ని ఎలా నిర్వహించాలి.
ఎన్వోయ్ ప్రాక్సీకి అన్ని కాన్ఫిగరేషన్ వర్తించదు మరియు మీరు కొన్ని సెట్టింగ్లను కాన్ఫిగర్ చేయవలసిన అవసరం లేదు. ఎన్వోయ్ ప్రాక్సీ ఉంది నాలుగు కీలక రకాలు, ఇది NGINX అందించే కోర్ ఇన్ఫ్రాస్ట్రక్చర్కు మద్దతు ఇస్తుంది. కోర్ ఉంది:
- శ్రోతలు: ఎన్వాయ్ ప్రాక్సీ ఇన్కమింగ్ అభ్యర్థనలను ఎలా అంగీకరిస్తుందో వారు నిర్ణయిస్తారు. ఎన్వోయ్ ప్రాక్సీ ప్రస్తుతం TCP-ఆధారిత శ్రోతలకు మాత్రమే మద్దతు ఇస్తుంది. కనెక్షన్ స్థాపించబడిన తర్వాత, అది ప్రాసెసింగ్ కోసం ఫిల్టర్ల సమితికి పంపబడుతుంది.
- ఫిల్టర్లు: అవి ఇన్కమింగ్ మరియు అవుట్గోయింగ్ డేటాను ప్రాసెస్ చేయగల పైప్లైన్ ఆర్కిటెక్చర్లో భాగం. ఈ ఫంక్షనాలిటీ Gzip వంటి ఫిల్టర్లను కలిగి ఉంటుంది, ఇది క్లయింట్కు పంపే ముందు డేటాను కుదిస్తుంది.
- రూటర్లు: వారు క్లస్టర్గా నిర్వచించబడిన అవసరమైన గమ్యస్థానానికి ట్రాఫిక్ను ఫార్వార్డ్ చేస్తారు.
- సమూహాలు: వారు ట్రాఫిక్ మరియు కాన్ఫిగరేషన్ పారామితుల కోసం ముగింపు బిందువును నిర్వచిస్తారు.
నిర్దిష్ట NGINX కాన్ఫిగరేషన్తో సరిపోలడానికి ఎన్వోయ్ ప్రాక్సీ కాన్ఫిగరేషన్ను రూపొందించడానికి మేము ఈ నాలుగు భాగాలను ఉపయోగిస్తాము. APIలు మరియు డైనమిక్ కాన్ఫిగరేషన్తో పనిచేయడం రాయబారి లక్ష్యం. ఈ సందర్భంలో, బేస్ కాన్ఫిగరేషన్ NGINX నుండి స్టాటిక్, హార్డ్-కోడెడ్ సెట్టింగ్లను ఉపయోగిస్తుంది.
దశ 2 - NGINX కాన్ఫిగరేషన్
మొదటి భాగం nginx.conf కాన్ఫిగర్ చేయవలసిన కొన్ని NGINX ఇంటర్నల్లను నిర్వచిస్తుంది.
కార్మికుల కనెక్షన్లు
దిగువ కాన్ఫిగరేషన్ వర్కర్ ప్రాసెస్లు మరియు కనెక్షన్ల సంఖ్యను నిర్ణయిస్తుంది. డిమాండ్ను తీర్చడానికి NGINX ఎలా స్కేల్ చేస్తుందో ఇది సూచిస్తుంది.
worker_processes 2;
events {
worker_connections 2000;
}
ఎన్వోయ్ ప్రాక్సీ వివిధ మార్గాల్లో వర్క్ఫ్లోలు మరియు కనెక్షన్లను నిర్వహిస్తుంది.
సిస్టమ్లోని ప్రతి హార్డ్వేర్ థ్రెడ్ కోసం ఎన్వోయ్ వర్కర్ థ్రెడ్ను సృష్టిస్తాడు. ప్రతి వర్కర్ థ్రెడ్ బాధ్యత వహించే నాన్-బ్లాకింగ్ ఈవెంట్ లూప్ను అమలు చేస్తుంది
- ప్రతి శ్రోతని వినడం
- కొత్త కనెక్షన్లను అంగీకరించడం
- కనెక్షన్ కోసం ఫిల్టర్ల సమితిని సృష్టిస్తోంది
- కనెక్షన్ జీవితకాలంలో అన్ని I/O కార్యకలాపాలను ప్రాసెస్ చేయండి.
ఏదైనా ఫార్వార్డింగ్ ప్రవర్తనతో సహా అన్ని తదుపరి కనెక్షన్ ప్రాసెసింగ్ పూర్తిగా వర్కర్ థ్రెడ్లో నిర్వహించబడుతుంది.
ఎన్వోయ్లోని ప్రతి వర్కర్ థ్రెడ్ కోసం, కనెక్షన్ పూల్ ఉంది. కాబట్టి HTTP/2 కనెక్షన్ పూల్లు ఒక్కోసారి బాహ్య హోస్ట్కి ఒక కనెక్షన్ని మాత్రమే ఏర్పాటు చేస్తాయి, నాలుగు వర్కర్ థ్రెడ్లు ఉంటే స్థిరమైన స్థితిలో ఒక్కో బాహ్య హోస్ట్కు నాలుగు HTTP/2 కనెక్షన్లు ఉంటాయి. అన్నింటినీ ఒకే వర్కర్ థ్రెడ్లో ఉంచడం ద్వారా, దాదాపు అన్ని కోడ్లు ఒకే థ్రెడ్లాగా బ్లాక్ చేయకుండా వ్రాయవచ్చు. అవసరమైన దానికంటే ఎక్కువ వర్కర్ థ్రెడ్లు కేటాయించబడితే, ఇది మెమరీని వృధా చేస్తుంది, పెద్ద సంఖ్యలో నిష్క్రియ కనెక్షన్లను సృష్టించడం మరియు పూల్కి తిరిగి వచ్చే కనెక్షన్ల సంఖ్యను తగ్గించడం.
మరింత సమాచారం కోసం సందర్శించండి
HTTP కాన్ఫిగరేషన్
కింది NGINX కాన్ఫిగరేషన్ బ్లాక్ HTTP సెట్టింగ్లను నిర్వచిస్తుంది:
- ఏ మైమ్ రకాలు మద్దతిస్తున్నాయి
- డిఫాల్ట్ గడువు ముగిసింది
- Gzip కాన్ఫిగరేషన్
మీరు ఎన్వోయ్ ప్రాక్సీలోని ఫిల్టర్లను ఉపయోగించి ఈ అంశాలను అనుకూలీకరించవచ్చు, వీటిని మేము తర్వాత చర్చిస్తాము.
దశ 3 - సర్వర్ కాన్ఫిగరేషన్
HTTP కాన్ఫిగరేషన్ బ్లాక్లో, NGINX కాన్ఫిగరేషన్ పోర్ట్ 8080లో వినడానికి మరియు డొమైన్ల కోసం వచ్చే అభ్యర్థనలకు ప్రతిస్పందించడానికి నిర్దేశిస్తుంది. one.example.com и www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;
ఎన్వోయ్ లోపల, ఇది శ్రోతలచే నియంత్రించబడుతుంది.
శ్రోతలు రాయండి
ఎన్వోయ్ ప్రాక్సీతో ప్రారంభించడంలో అత్యంత ముఖ్యమైన అంశం మీ శ్రోతలను నిర్వచించడం. మీరు ఎన్వోయ్ ఉదాహరణను ఎలా అమలు చేయాలనుకుంటున్నారో వివరించే కాన్ఫిగరేషన్ ఫైల్ను మీరు సృష్టించాలి.
దిగువన ఉన్న స్నిప్పెట్ కొత్త శ్రోతని సృష్టిస్తుంది మరియు దానిని పోర్ట్ 8080కి బంధిస్తుంది. ఇన్కమింగ్ అభ్యర్థనల కోసం ఏ పోర్ట్లకు కట్టుబడి ఉండాలో కాన్ఫిగరేషన్ ఎన్వోయ్ ప్రాక్సీకి తెలియజేస్తుంది.
ఎన్వోయ్ ప్రాక్సీ దాని కాన్ఫిగరేషన్ కోసం YAML సంజ్ఞామానాన్ని ఉపయోగిస్తుంది. ఈ సంజ్ఞామానానికి పరిచయం కోసం, ఇక్కడ చూడండి
Copy to Editorstatic_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
నిర్వచించాల్సిన అవసరం లేదు సర్వర్కు, ఎన్వోయ్ ప్రాక్సీ ఫిల్టర్లు దీన్ని నిర్వహిస్తాయి కాబట్టి.
దశ 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
పేరు రాయబారి.http_connection_manager ఎన్వోయ్ ప్రాక్సీలో అంతర్నిర్మిత ఫిల్టర్. ఇతర ఫిల్టర్లు ఉన్నాయి Redis, మొంగో, 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 రాయబారి పేర్కొన్న DNS లక్ష్యాలను నిరంతరం మరియు అసమకాలికంగా పరిష్కరిస్తారు. DNS ఫలితం నుండి అందించబడిన ప్రతి IP చిరునామా అప్స్ట్రీమ్ క్లస్టర్లో స్పష్టమైన హోస్ట్గా పరిగణించబడుతుంది. దీనర్థం ఒక అభ్యర్థన రెండు IP చిరునామాలను తిరిగి ఇస్తే, క్లస్టర్లో రెండు హోస్ట్లు ఉన్నాయని ఎన్వోయ్ ఊహిస్తాడు మరియు రెండూ లోడ్ బ్యాలెన్స్గా ఉండాలి. ఫలితం నుండి హోస్ట్ తీసివేయబడితే, అది ఉనికిలో లేదని రాయబారి ఊహిస్తారు మరియు ఇప్పటికే ఉన్న ఏవైనా కనెక్షన్ పూల్స్ నుండి ట్రాఫిక్ను లాగుతారు.
మరింత సమాచారం కోసం చూడండి
దశ 6 — లాగ్ యాక్సెస్ మరియు లోపాలు
చివరి కాన్ఫిగరేషన్ రిజిస్ట్రేషన్. లోపం లాగ్లను డిస్క్కి నెట్టడానికి బదులుగా, ఎన్వాయ్ ప్రాక్సీ క్లౌడ్-ఆధారిత విధానాన్ని తీసుకుంటుంది. అన్ని అప్లికేషన్ లాగ్లు అవుట్పుట్ చేయబడ్డాయి stdout и stderr.
వినియోగదారులు అభ్యర్థన చేసినప్పుడు, యాక్సెస్ లాగ్లు ఐచ్ఛికం మరియు డిఫాల్ట్గా నిలిపివేయబడతాయి. HTTP అభ్యర్థనల కోసం యాక్సెస్ లాగ్లను ప్రారంభించడానికి, కాన్ఫిగరేషన్ను ప్రారంభించండి యాక్సెస్_లాగ్ HTTP కనెక్షన్ మేనేజర్ కోసం. మార్గం వంటి పరికరం కావచ్చు 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:
డిఫాల్ట్గా, 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)%"}
ఎన్వోయ్ రిజిస్ట్రేషన్ మెథడాలజీ గురించి మరింత సమాచారం కోసం, సందర్శించండి
ఎన్వాయ్ ప్రాక్సీతో పని చేయడంలో అంతర్దృష్టిని పొందడానికి లాగింగ్ మాత్రమే మార్గం కాదు. ఇది అధునాతన ట్రేసింగ్ మరియు మెట్రిక్స్ సామర్థ్యాలను కలిగి ఉంది. మీరు ఇక్కడ మరింత తెలుసుకోవచ్చు
దశ 7 - ప్రారంభించండి
మీరు ఇప్పుడు మీ కాన్ఫిగరేషన్ను NGINX నుండి ఎన్వోయ్ ప్రాక్సీకి మార్చారు. దీన్ని పరీక్షించడానికి ఎన్వాయ్ ప్రాక్సీ ఉదాహరణను ప్రారంభించడం చివరి దశ.
వినియోగదారుగా అమలు చేయండి
NGINX కాన్ఫిగరేషన్ లైన్ ఎగువన వినియోగదారు www www; భద్రతను మెరుగుపరచడానికి NGINXని తక్కువ-ప్రత్యేకమైన వినియోగదారుగా అమలు చేయాలని నిర్దేశిస్తుంది.
ఎన్వోయ్ ప్రాక్సీ ప్రాసెస్ను ఎవరు కలిగి ఉన్నారో నిర్వహించడానికి క్లౌడ్-ఆధారిత విధానాన్ని తీసుకుంటుంది. మేము ఒక కంటైనర్ ద్వారా ఎన్వోయ్ ప్రాక్సీని అమలు చేసినప్పుడు, మేము తక్కువ ప్రాధాన్యత కలిగిన వినియోగదారుని పేర్కొనవచ్చు.
ఎన్వోయ్ ప్రాక్సీని ప్రారంభిస్తోంది
దిగువ ఆదేశం హోస్ట్లోని డాకర్ కంటైనర్ ద్వారా ఎన్వాయ్ ప్రాక్సీని అమలు చేస్తుంది. ఈ ఆదేశం పోర్ట్ 80లో ఇన్కమింగ్ అభ్యర్థనలను వినగలిగే సామర్థ్యాన్ని ఎన్వాయ్కి ఇస్తుంది. అయితే, లిజనర్ కాన్ఫిగరేషన్లో పేర్కొన్నట్లుగా, ఎన్వాయ్ ప్రాక్సీ పోర్ట్ 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. అప్స్ట్రీమ్ కనెక్షన్లు పని చేయకపోవడమే మరియు అందుబాటులో ఉండకపోవడమే దీనికి కారణం. అందువల్ల, అభ్యర్థన కోసం ఎన్వాయ్ ప్రాక్సీకి ఎటువంటి గమ్యస్థానాలు అందుబాటులో లేవు. కింది ఆదేశం ఎన్వోయ్ కోసం నిర్వచించిన కాన్ఫిగరేషన్తో సరిపోలే HTTP సేవల శ్రేణిని ప్రారంభిస్తుంది.
docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;
అందుబాటులో ఉన్న సేవలతో, ఎన్వోయ్ తన గమ్యస్థానానికి ట్రాఫిక్ని విజయవంతంగా ప్రాక్సీ చేయగలడు.
curl -H "Host: one.example.com" localhost -i
ఏ డాకర్ కంటైనర్ అభ్యర్థనను ప్రాసెస్ చేసిందో సూచించే ప్రతిస్పందన మీకు కనిపిస్తుంది. ఎన్వోయ్ ప్రాక్సీ లాగ్లలో మీరు యాక్సెస్ స్ట్రింగ్ అవుట్పుట్ను కూడా చూడాలి.
అదనపు 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 }
అనువాదకుని నుండి అదనపు సమాచారం
ఎన్వోయ్ ప్రాక్సీని ఇన్స్టాల్ చేయడానికి సూచనలను వెబ్సైట్లో చూడవచ్చు
డిఫాల్ట్గా, rpmకి systemd సర్వీస్ కాన్ఫిగరేషన్ లేదు.
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ని ఉంచాలి.
ఎన్వోయ్ ప్రాక్సీని ఉపయోగించి టెలిగ్రామ్ చాట్ ఉంది:
ఎన్వాయ్ ప్రాక్సీ స్టాటిక్ కంటెంట్ను అందించడానికి మద్దతు ఇవ్వదు. కాబట్టి, ఫీచర్ కోసం ఎవరు ఓటు వేయగలరు:
నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు.
ఈ పోస్ట్ రాయబారి ప్రాక్సీని ఇన్స్టాల్ చేసి పరీక్షించమని మిమ్మల్ని ప్రోత్సహించిందా?
-
అవును
-
ఏ
75 మంది వినియోగదారులు ఓటు వేశారు. 18 మంది వినియోగదారులు దూరంగా ఉన్నారు.
మూలం: www.habr.com