Përshëndetje, Habr! Po ju paraqes përkthimin e postit: .
Envoy është një proxy server i shpërndarë me performancë të lartë (i shkruar në C++), i destinuar për shërbime dhe aplikacione të veçanta; gjithashtu është një autobüs komunikimi dhe «universal data plane», i projektuar për arkitekturën e madhe të mikroshërbimeve të quajtur «service mesh». Kur u krijua, u morën parasysh zgjidhjet për problemet që ishin hasur gjatë zhvillimit të serverëve si NGINX, HAProxy, balancuesit e ngarkesës hardware dhe balancuesit e ngarkesës në cloud. Envoy punon së bashku me çdo aplikacion dhe abtron rrjetin, duke ofruar funksionalitete të përbashkëta pavarësisht nga platforma. Kur të gjithë trafiku shërbyes në infrastrukturë kalon përmes rrjetit Envoy, bëhet e lehtë të vizualizosh fushat problematike me anë të vëzhgueshmërisë së konsoliduar, rregullimit të performancës së përbashkët dhe shtimit të funksionaliteteve bazë në një vend të caktuar.
Mundësitë
- Arkitektura jashtë procesit: envoy është një server autonom me performancë të lartë që merr një sasi të vogël memorjeje. Ai punon në bashkëpunim me çdo gjuhë aplikacioni ose framework.
- Mbështetje për http/2 dhe grpc: envoy ofron mbështetje të klasit të parë për http/2 dhe grpc për lidhjet hyrëse dhe dalëse. Ky është një proxy transparent nga http/1.1 në http/2.
- Balancimi i avancuar i ngarkesës: envoy mbështet funksione të avancuara të balancimit të ngarkesës, përfshirë përpjekjet automatikë të riprovimit, ndërprerjen e zinxhirit, kufizimin global të shpejtësisë, errësimin e kërkesave, balancimin lokal të ngarkesës për zona etj.
- API për menaxhimin e konfigurimit: envoy ofron një API të besueshëm për menaxhimin dinamik të konfigurimit të saj.
- Vëzhgueshmëria: vëzhgueshmëri e thellë e trafikëve L7, mbështetje e integruar për gjurmin e shpërndarë dhe vëzhgueshmërinë e mongodb, dynamodb dhe shumë aplikacionesh të tjera.
Hapi 1 — Shembuj konfigurimi NGINX
Në këtë skenar përdoret një skedar i krijuar posaçërisht nginx.conf, i bazuar në një shembull të plotë nga . Mund ta shikoni konfigurimin në redaktor duke hapur nginx.conf
Konfigurimin burimor 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;
}
}
}Konfigurimet e NGINX zakonisht përmbajnë tre elementë kyç:
- Konfigurimi i serverit NGINX, struktura e regjistrave dhe funksionaliteti Gzip. Kjo përcaktohet globalisht në të gjitha rastet.
- Konfigurimi i NGINX për të pranuar kërkesa në hostin one.example.com në portin 8080.
- Konfigurimi i vendndodhjes së targetit, si të trajtohet trafiku për pjesë të ndryshme të URL-së.
Jo të gjithë konfigurimi do të zbatohet në Envoy Proxy, dhe nuk ka nevojë të konfigurosh disa parametra. Envoy Proxy ka katër lloje kyçe, që mbështesin infrastrukturën bazë të ofruar nga NGINX. Nucleus është:
- Dëgjuesit: Ata përcaktojnë se si Envoy Proxy pranon kërkesat e ardhshme. Aktualisht, Envoy Proxy mbështet vetëm dëgjuesit mbi TCP. Pasi që lidhja është krijuar, ajo kalon në një grup filtrash për përpunim.
- Filtrat: Ata janë pjesë e arkitekturës së tubacionit, e cila mund të trajtojë të dhënat e ardhshme dhe dalëse. Kjo funksionalitet përfshin filtra si Gzip, i cili kompreson të dhënat para se t'i dërgojë ato klientit.
- Ruterat: Ata ridrejtojnë trafikun në destinacionin e kërkuar, të kërkuar si grup.
- Grupet: Ata përcaktojnë pikën e fundit për trafikun dhe parametrat e konfigurimit.
Ne do të përdorim këta katër komponentë për të krijuar konfigurimin e Envoy Proxy në përputhje me një konfigurim të caktuar të NGINX. Qëllimi i Envoy është të punojë me API dhe konfigurim dinamik. Në këtë rast, konfigurimi bazë do të përdorë parametra statikë, të ngurtë të vendosur nga NGINX.
Hapi 2 — Konfigurimi NGINX
Pjesa e parë nginx.conf përkufizon disa komponentë të brendshëm të NGINX, të cilët duhet të konfigurohen.
Lidhjet e punës
Konfigurimi më poshtë përcakton numrin e proceseve punuese dhe lidhjeve. Kjo tregon se si NGINX do të përmirësohet për të përmbushur kërkesën.
proceset_punues 2;
events {
lidhjet_punues 2000;
}Envoy Proxy menaxhon ndryshe proceset punuese dhe lidhjet.
Envoy krijon një rrjedhë punuese për çdo rrjedhë harduerike në sistem. Çdo rrjedhë punuese kryen një cikël ngjarjesh jo bllokuese, i cili është përgjegjës për
- Dëgjimin e çdo dëgjuesi (listener)
- Pranimin e lidhjeve të reja
- Krijimin e një seti filtrash për lidhjen
- Këshillimin e të gjitha operacioneve të input-output gjatë gjithë ekzistencës së lidhjes.
Të gjitha përpunimet e mëtejshme të lidhjes kryhen plotësisht në rrjedhën punuese, përfshirë çdo sjellje ridrejtimi.
Për çdo shkarnë pune në Envoy ekziston një lidhje në grup. Kështu, grupet e lidhjeve HTTP/2 vendosin vetëm një lidhje për çdo host të jashtëm në një kohë. Nëse ka katër shkrira pune, do të ketë katër lidhje HTTP/2 për çdo host të jashtëm në një qëndrim stabil. Duke mbajtur gjithçka në një shkrirë pune, pothuajse e gjithë kode mund të shkruhet pa bllokime, sikur të ishte në një njësit të vetme. Nëse është caktuar më shumë se sa është e nevojshme shkrirave pune, kjo mund të çojë në përdorim të paefektshëm të memories, krijimin e një numri të madh të lidhjeve të papërdorura dhe reduktimin e numrit të rikthimeve të lidhjeve në grup.
Për informacion shtesë vizitoni .
Konfigurimi HTTP
Blloku i mëposhtëm i konfigurimit NGINX përcakton cilësimet e HTTP, të tilla si:
- Cilat lloje mime mbështeten
- Kohët e pritjes të paracaktuar
- Konfigurimi Gzip
Ju mund të konfiguroni këto aspekte me anë të filtrave në Proxy-në Envoy, të cilat do t'i diskutojmë më vonë.
Hapi 3 — Konfigurimi i Serverit
Në bllokun e konfigurimit HTTP, konfigurimi NGINX tregon të dëgjojë portin 8080 dhe të përgjigjet ndaj kërkesave të ardhshme për domenet one.example.com dhe www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;Brenda në Envoy kontrollohet nga Dëgjuarësit.
Dëgjuarësit e Envoy
Aspekti më i rëndësishëm për të nisur me Envoy Proxy është përcaktimi i dëgjuarësve. Ju nevojitet të krijoni një skedë konfigurimi që përshkruan si dëshironi të ekzekutoni një instancë të Envoy.
Fragmenti më poshtë do të krijojë një dëgjues të ri dhe do ta lidhë atë me portin 8080. Konfigurimi tregon që Envoy Proxy duhet të lidhet me cilët porte për kërkesat hyrëse.
Envoy Proxy përdor notacionin YAML për konfigurimin e tij. Për një njohje me këtë notacion, shikoni këtu .
Copy to Editorstatic_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }Nuk ka nevojë të përcaktoni server_name, pasi filtrot e Envoy Proxy do t'i trajtojnë ato.
Hapi 4 — Konfigurimi i vendndodhjes
Kur një kërkesë mb arrives në NGINX, blloku i vendndodhjes përcakton si të përpunoni dhe ku të drejtoni trafik. Në fragmentin më poshtë, e gjithë trafiku në faqen e internetit kalon në një grup upstream (shënimi i përkthyesit: upstream zakonisht janë servera aplikacionesh) me emrin targetCluster. Grupi upstream përcakton nyjet që duhet të përpunojnë kërkesën. Ne do ta diskutojmë këtë në hapin tjetër.
lokacioni / {
proxy_pass http://targetCluster/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}Në Envoy, kjo bëhet nga Filters.
Filtrat Envoy
Për konfigurimin statik, filtrat përcaktojnë se si të trajtohen kërkesat e ardhshme. Në këtë rast, ne vendosim filtrat që përputhen server_names në hapin e mëparshëm. Kur vijnë kërkesa të ardhshme që përputhen me domenet dhe rrugët e caktuara, trafiku drejtohet në klaster. Kjo është ekuivalente me konfigurimin ngritës në NGINX.
Kopjo në Redaktor 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.routerEmri envoy.http_connection_manager është një filtr i integruar në Envoy Proxy. Filtra të tjerë përfshijnë Redis, Mongo, TCP. Mund ta gjeni listën e plotë në .
Për më shumë informacion mbi politikat e tjera të balancimit të ngarkesës, vizitoni .
Hapi 5 — Konfigurimi i Proxy dhe Upstream
Në konfigurimin e NGINX, upstream përcakton një grup serverash të shënjestruar që do të përpunojnë trafikun. Në këtë rast, ishin caktuar dy klastera.
upstream targetCluster {
172.18.0.3:80;
172.18.0.4:80;
}Në Envoy, kjo menaxhohet nga klasterat.
Klasterat e Envoy
Ekuivalenti upstream përcaktohet si klastera. Në këtë rast, ishin përcaktuar hostet që do të shërbenin trafikun. Mënyra e aksesit në hoste, siç është koha e pritjes, përcaktohet si konfigurimi i klasterit. Kjo lejon një kontroll më të saktë ndaj aspektëve të tilla si koha e pritjes dhe balancimi i ngarkesës.
Kopjo te Editori klasterat:
- 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 }}
]Në përdorimin e zbulimit të shërbimit STRICT_DNS Envoy do t'ju përgjigjet vazhdimisht dhe asinkronisht objektivave të caktuara DNS. Çdo IP adresë e kthyer si rezultat i DNS do të konsiderohet një host i qartë në klasterin ngritës. Kjo do të thotë se nëse kërkesa kthen dy IP adresa, Envoy do të supozojë se në klaster ka dy hoste dhe të dy duhet të balancohen në ngarkesën. Nëse një host hiqet nga rezultati, Envoy do të supozojë se ai nuk ekziston më dhe do të fillojë të seleksionojë trafik nga çdo grup ekzistues lidhjesh.
Për informacion të mëtejshëm shihni. .
Hapi 6 — Qasja në regjistrin dhe gabimet
Konfigurimi përfundimtar — regjistrimi. Në vend që të kalojë regjistrat e gabimeve në disk, Envoy Proxy përdor një qasje në re. Të gjitha regjistrat e aplikacioneve dalin në stdout dhe stderr.
Kur përdoruesit bëjnë kërkesë, regjistrat e aksesit janë të opsioneve dhe për parazgjedhje janë të çaktivizuar. Për të aktivizuar regjistrat e aksesit për kërkesat HTTP, aktivizoni konfigurimin access_log për menaxherin e lidhjeve HTTP. Rruga mund të jetë ose një pajisje, siç është stdout, ose një skedar në disk, në varësi të kërkesave tuaja.
Konfigurimi i mëposhtëm do të redirektojë të gjitha log-et e aksesit në stdout (shënim përkthyesi — stdout është i nevojshëm për përdorimin e envoy brenda docker. Nëse përdoret pa docker, zëvendësoni /dev/stdout me rrugën e skedarit të zakonshëm të log-ut). Kopjoni këtë fragment në seksionin e konfigurimit për menaxherin e lidhjeve:
Kopj për në Clipboardaccess_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"Rezultatet duhet të duken si:
- 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:Sipas rregullit, Envoy ka një varg formati që përfshin detajet e kërkesës 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%"nRezultati i kësaj string forme:
[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"Përmbajtja e daljes mund të personalizohet duke vendosur fushën e formatit. Për shembull:
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"Një hyrje e regjistrit gjithashtu mund të shfaqet në formatin JSON duke vendosur fushën json_format. Për shembull:
access_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"
json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}Për informacion të mëtejshëm rreth metodologjisë së regjistrimit të Envoy, vizitoni
Regjistrimi nuk është mënyra e vetme për të marrë një pasqyrë të funksionimit të Envoy Proxy. Ai përmban funksionalitete të avancuara të gjurmimit dhe metrike. Mund të mësoni më shumë në ose përmes .
Hapi 7 - Nisi
Tani keni përkthyer konfigurimin nga NGINX në Envoy Proxy. Hapi i fundit është të nisni një shembull të Envoy Proxy për ta testuar.
Nisja nga përdoruesi
Në pjesën e sipërme të konfigurimit të NGINX, rreshti user www www; tregon se NGINX do të niset si një përdorues me privilegje të ulëta për të rritur sigurinë.
Envoy Proxy ndjek një qasje cloud për të menaxhuar se kush është pronar i procesit. Kur nisim Envoy Proxy përmes enëve, mund të përcaktojmë një përdorues me privilegje të ulta.
Nisja e Envoy Proxy
Ekipa më poshtë do të niste Envoy Proxy përmes një kontejneri Docker në host. Kjo komandë i jep mundësinë Envoy të dëgjojë kërkesat e ardhshme përmes portit 80. Megjithatë, siç tregohet në konfigurimin e dëgjuesit, Envoy Proxy dëgjon trafikun e ardhshëm përmes portit 8080. Kjo lejon që procesi të nisë si përdorues me privilegje të ulta.
docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoyTestimi
Me proxy-në e nisur, testet tani mund të kryhen dhe të përpunohen. Komanda e mëposhtme cURL jep një kërkesë me headerin e hostit të përcaktuar në konfigurimin e proxy-së.
curl -H "Host: one.example.com" localhost -iKërkesa HTTP do të rezultojë me një gabim 503. Kjo për shkak se lidhjet e ngjitura nuk funksionojnë dhe ato nuk janë të disponueshme. Kështu, Envoy Proxy nuk ka adresat e disponueshme për kërkesën. Komanda e mëposhtme do të nisë një seri shërbimesh HTTP që përputhen me konfigurimin e përcaktuar për Envoy.
docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;Me shërbimet e disponueshme, Envoy mund të proksojë me sukses trafikun drejt destinacionit.
curl -H "Host: one.example.com" localhost -iDuhet të shihni një përgjigje që tregon se cili kontejner Docker përpunoi kërkesën. Në logjet e Envoy Proxy gjithashtu duhet të shihni rreshtin e aksesit të treguar.
Kryesit e tjerë të përgjigjes HTTP (HTTP Response)
Në kryesit e përgjigjes së kërkesës valide do të shihni kryesia të tjera HTTP. Në kryesë tregohet koha që hosti i sipërm kaloi për të përpunuar kërkesën. Kjo është e shprehur në milisekonda. Kjo është e dobishme nëse klienti dëshiron të përcaktojë kohën e shërbimit në krahasim me vonesën në rrjet.
x-envoy-upstream-service-time: 0
server: envoyKonfigurimi përfundimtar
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 }Informacione shtesë nga përkthyesi
Udhëzimet për instalimin e Envoy Proxy mund t'i gjeni në faqe
Normalisht, në rpm mungon konfigurimi i shërbimit systemd.
Shtoni konfigurimin e shërbimit systemd në /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.targetDuhet të krijoni direktorinë /etc/envoy/ dhe të vendosni aty konfigurimin config.yaml.
Për envoy proxy ka një bisedë në Telegram:
Envoy Proxy nuk ka mbështetje për shpërndarjen e përmbajtjes statike. Prandaj, kush mund të votojë për veçorinë:
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A ka nxitur ky post të instaloni dhe testoni envoy proxy?
po
jo
75 përdorues kanë votuar. 18 përdorues kanë abstenuar.
Burimi: habr.com
