Përshëndetje, Habr! Po ju ofroj përkthimin e një posti: .
Envoy është një proxy i distribuar me performancë të lartë (i shkruar në C++) që është projektuar për shërbime dhe aplikacione të veçanta, gjithashtu është një autobus komunikimi dhe 'plani universal i të dhënave', i zhvilluar për arkitektura të mëdha mikroshërbimesh 'mesh shërbimi'. Gjatë krijimit të tij janë marrë parasysh zgjidhjet e problemeve që kanë lindur gjatë zhvillimit të proxy-ve të tillë si NGINX, HAProxy, balancuesit e ngarkesës në harduer dhe balancuesit e ngarkesës në re. Envoy punon së bashku me çdo aplikacion dhe abstragjon rrjetin, duke ofruar funksione të përbashkëta pa marrë parasysh platformën. Kur gjithtrafiku i shërbimit në infrastrukturë kalon përmes rrjetit Envoy, bëhet e lehtë të vizualizosh fushat problematike me anë të vëzhgimit të qartë, rregullimit të performancës së përgjithshme dhe shtimit të funksioneve kryesore në një vend të caktuar.
Mundësitë
- Arkitektura jashtë procesit: envoy është një server autonom me performancë të lartë që zë një hapësirë të vogël memorjeje. Ai punon në bashkëpunim me çdo gjuhë ose framework aplikacioni.
- Mbështetje për http/2 dhe grpc: envoy ka mbështetje të parë për http/2 dhe grpc për lidhjet hyrëse dhe dalëse. Ky është një proxy i transparencës nga http/1.1 në http/2.
- Balancimi i zgjeruar i ngarkesës: envoy mbështet funksione të zgjeruara të balancimit të ngarkesës, përfshirë përpjekje automatike, thyerje të zinxhirit, kufizim global të shpejtësisë, hijësimin e kërkesave, balancimin e ngarkesës lokale dhe të tjera.
- API për menaxhimin e konfiguracionit: envoy ofron një API të besueshëm për menaxhimin dinamik të konfigurimit të tij.
- Vëzhgimi: vëzhgim i thellë i trafikut L7, mbështetje e integruar për gjurmimin e shpërndarë dhe vëzhgimin e mongodb, dynamodb dhe shumë aplikacione të tjera.
Hapi 1 - Shembulli i konfigurimit NGINX
Në këtë skenar përdoret një skedar i krijuar posaçërisht nginx.conf, duke u bazuar në një shembull të plotë nga . Ju mund të shikoni konfigurimin në redaktues duke hapur nginx.conf
Konfigurat origjinal të 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 kanë tre elementë kyç:
- Ndërsa konfigurimi i serverit NGINX, struktura e regjistrave dhe funksionaliteti Gzip 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ë qëllimit, si të trajtohet trafiku për pjesë të ndryshme të URL-së.
Jo çdo konfigurim do të aplikohet te Envoy Proxy, dhe nuk keni nevojë të konfiguroni disa parametra. Envoy Proxy ka katër lloje kyç, të cilat mbështesin infrastrukturën bazë të ofruar nga NGINX. Baza është:
- Dëgjuesit: Ata përcaktojnë se si Envoy Proxy pranon kërkesat e ardhshme. Aktualisht, Envoy Proxy mbështet vetëm dëgjues bazuar në TCP. Pasi të vendoset lidhja, ajo kalon në një grup filtrash për përpunim.
- Filters: Ata janë pjesë e arkitekturës së tubacioneve, e cila mund të trajtojë të dhëna të ardhshme dhe të dalë. Kjo funksionalitet përfshin filtra, siç është Gzip, i cili kompreson të dhënat para se t'i dërgojë ato klientit.
- Routuesit: Ata riorientojnë trafikun në destinacionin e kërkuar, të përcaktuar si një grup.
- Grupet: Ata përcaktojnë pikën finale për trafikun dhe parametrat e konfigurimit.
Ne do të përdorim këta katër komponente për të krijuar një konfigurim të Envoy Proxy që përputhet 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ë vendosur nga NGINX.
Hapi 2 — Konfigurimi i NGINX
Pjesa e parë nginx.conf përcakton disa komponente të brendshme të NGINX që duhet të konfigurohen.
Worker Connections (Këto janë lidhjet e punës)
Konfigurimi i dhënë më poshtë përcakton numrin e proceseve të punës dhe lidhjeve. Kjo tregon se si NGINX do të shkallëzohet për të përmbushur kërkesën.
worker_processes 2;
events {
worker_connections 2000;
}Envoy Proxy menaxhon ndryshe proceset e punës dhe lidhjet.
Envoy krijon një rrjedhë pune për çdo mori burimesh në sistem. Çdo rrjedhë pune realizon një cikël ngjarjesh jo-bllokues, i cili përgjigjet për
- Dëgjimi i çdo dëgjuesi (listener)
- Pranimin e lidhjeve të reja
- Krijimin e një grupi filtrash për lidhjen
- Përpunimin e të gjitha operacioneve të hyrjes-daljes gjatë kohës së ekzistencës së lidhjes.
Të gjitha përpunimet e mëtejshme të lidhjes trajtohen plotësisht në rrjedhën e punës, duke përfshirë çdo sjellje ridrejtuese.
Për çdo rrjedhë pune në Envoy ekziston një lidhje në pool. Kështu, pool-et e lidhjeve HTTP/2 krijojnë vetëm një lidhje për çdo host të jashtëm në çdo kohë, me katër rrjedha pune do të ketë katër lidhje HTTP/2 për çdo host të jashtëm në një gjendje të qëndrueshme. Duke mbajtur gjithçka në një rrjedhë pune, gati gjithçka mund të shkruhet pa bllokime, si nëse do të ishte një-pajtim. Nëse rrjedhat e punës janë ndarë më shumë se sa nevoja, kjo mund të sjellë një përdorim të paefektshëm të memories, krijimin e një numri të madh lidhjesh të papërdorura dhe reduktimin e numrit të rikthimeve të lidhjeve përsëri në pool.
Për më shumë informacion, vizitoni .
Konfigurimi HTTP
Blloku i ardhshëm i konfigurimit NGINX përcakton parametrat e HTTP, siç janë:
- Cilat mime tipo janë të mbështetura
- Koha standarde e skadimit
- Konfigurimi Gzip
Mund të konfigurosh këto aspekte nëpërmjet filtrave në Envoy Proxy, që 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 për kërkesat e ardhshme për domainet one.example.com dhe www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;Brenda Envoy, kjo menaxhohet nga Dëgjuesit.
Dëgjuesit e Envoy
Aspekti më i rëndësishëm për të filluar me Envoy Proxy është përcaktimi i dëgjuesve. Duhet të krijoni një skedar konfigurimi që përshkruan si dëshiron të nisni një instancë të Envoy.
Fraksioni i mëposhtëm do të krijojë një dëgjues të ri dhe do ta lidhë atë me portin 8080. Konfigurimi tregon Envoy Proxy se në cilat porte duhet të lidhet për kërkesat hyrëse.
Envoy Proxy përdor notacionin YAML për konfigurimin e tij. Për të njohur 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 filtrat e Envoy Proxy do të kujdesen për këtë.
Hapi 4 — Konfigurimi i vendndodhjes
Kur një kërkesë arrin në NGINX, blloku i vendndodhjes përcakton se si duhet të përpunohen dhe ku duhet të drejtohet trafiku. Në fraksionin e mëposhtëm, e gjithë trafiku në sit dërgohet në klasterin upstream me emrin targetCluster. Klasteri upstream përcakton nyjet që duhet të përpunojnë kërkesën. Ne do ta diskutojmë këtë në hapin tjetër.
location / {
proxy_pass http://targetCluster/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}Në Envoy, kjo merret nga Filters.
Envoy Filters
Për konfigurimin statik, filtrat përcaktojnë se si të përpunohen kërkesat hyrëse. Në këtë rast, ne vendosim filtrat që përputhen me server_names në hapin paraprak. Kur arrijnë kërkesat hyrëse që përputhen me domenet dhe rrugët e caktuara, trafiku dërgohet në klaster. Kjo është ekuivalent me konfigurimin upstream të 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.routerEmri envoy.http_connection_manager është një filtr i integruar në Envoy Proxy. Filtra të tjerë përfshijnë Redis, Mongo, TCP. Mund ta gjeni një listë të plotë në .
Për më shumë informacion mbi politika të tjera të balancimit të ngarkesës, vizitoni .
Hapi 5 — Konfigurimi i Proxy dhe Upstream
Në NGINX, konfigurimi upstream përcakton një grup serverash target që do të përpunojnë trafikun. Në këtë rast, dy klastere janë emëruar.
upstream targetCluster {
172.18.0.3:80;
172.18.0.4:80;
}Në Envoy, kjo menaxhohet nga klasteret.
Envoy Clusters
Ekuivalenti upstream përcaktohet si klastere. Në këtë rast, janë përcaktuar hostet që do të shërbejnë trafikun. Mënyra e qasjes në hoste, si p.sh. koha e pritjes, përcaktohet si konfigurim i klasterit. Kjo lejon kontroll më të saktë mbi hollësitë e aspekteve si koha e pritjes dhe balancimi i ngarkesës.
Kopjo në Editor klastere:
- emri: targetCluster
connect_timeout: 0.25s
lloji: STRICT_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
hostet: [
{ socket_address: { address: 172.18.0.3, port_value: 80 }},
{ socket_address: { address: 172.18.0.4, port_value: 80 }}
]Kur përdoret zbulimi i shërbimeve STRICT_DNS Envoy do të zgjidhë në vazhdimësi dhe në mënyrë asinkrone destinacionet e specifikuara DNS. Çdo IP e kthyer nga DNS do të konsiderohet si një host i qartë në klasterin upstream. Kjo do të thotë se nëse një kërkesë kthen dy adresa IP, Envoy do të supozojë se në klaster ka dy hoste dhe të dy duhet të jenë të balancuar në ngarkesë. Nëse një host hiqet nga rezultati, Envoy supozon se ai nuk ekziston më dhe do të drejtojë trafikun nga çdo grup ekzistues lidhjesh.
Për informacion të mëtejshëm shih. .
Hapi 6 — Qasja në jurnal dhe gabimet
Konfigurimi përfundimtar — regjistrimi. Në vend që të kalojë regjistrat e gabimeve në disk, Envoy Proxy përdor një qasje cloud. Të gjithë regjistrat e aplikacioneve dalin në stdout dhe stderr.
Kur përdoruesit bëjnë një kërkesë, regjistrat e qasjes janë të opsionalshëm dhe sipas parazgjedhjes janë të çaktivizuar. Për të aktivizuar regjistrat e qasjes 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ë drejtojë të gjithë regjistrat e qasjes në stdout (shënim i përkthyesit — stdout është e nevojshme për të përdorur envoy brenda docker. Nëse përdoret pa docker, atëherë zëvendësoni /dev/stdout me rrugën ndaj një skedari të zakonshëm regjistrimi). Kopjoni fragmentin në seksionin e konfigurimit për menaxherin e lidhjeve:
Kopjo në Clipboard access_log:
- emri: envoy.file_access_log
konfigurimi:
rruga: "/dev/stdout"Rezultatet duhet të duken kështu:
- emri: envoy.http_connection_manager
konfigurimi:
codec_type: auto
stat_prefix: ingress_http
access_log:
- emri: envoy.file_access_log
konfigurimi:
rruga: "/dev/stdout"
route_config:Sipërfaqësisht, 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ëtij rreshti formati:
[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"Rreshti i logut gjithashtu mund të dalë në format 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 mbi metodologjinë e regjistrimit të dërguesit, vizitoni
Regjistrimi nuk është mënyra e vetme për të marrë një përfaqësim të funksionimit të Envoy Proxy. Ai përfshin mundësi të avancuara të ndjekjes dhe metrikave. Mund të mësoni më shumë në ose përmes .
Hapi 7 — Nisja
Tani keni sistemuar konfigurimin nga NGINX në Envoy Proxy. Hapi i fundit është të nisni një ekzemplar të Envoy Proxy për ta testuar.
Nisja nga përdoruesi
Në krye të konfigurimit NGINX, rreshti user www www; tregon të nisë NGINX si një përdorues me privilegje të ulëta për të rritur sigurinë.
Envoy Proxy përdor një qasje cloud për të menaxhuar se kush është pronari i procesit. Kur e nisim Envoy Proxy përmes një kontejneri, mund të specifikojmë një përdorues me privilegje të ulëta.
Nisja e Envoy Proxy
Komanda më poshtë do të nisë Envoy Proxy përmes një kontejneri Docker në host. Kjo komandë i jep Envoy mundësinë të dëgjojë kërkesat që vijnë përmes portit 80. Megjithatë, siç është specifikuar në konfigurimin e dëgjuesit, Envoy Proxy dëgjon trafikun që vjen përmes portit 8080. Kjo lejon procesin të niset si një përdorues me privilegje të ulëta.
docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoyTestimi
Me proxy të nisur, testet tani mund të kryhen dhe të përpunohen. Komanda e mëposhtme cURL dërgon një kërkesë me një titull të hostit të përcaktuar në konfigurimin e proxy.
curl -H "Host: one.example.com" localhost -iKërkesa HTTP do të çojë në një gabim 503. Kjo është për shkak se lidhjet në ngritje nuk funksionojnë dhe ato nuk janë të disponueshme. Kështu, Envoy Proxy nuk ka të dhëna të mundshme për të adresuar kërkesën. Komanda e mëposhtme do të nisë një sërë shërbimesh HTTP që përputhen me konfigurimin e caktuar 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ë prokurojë me sukses trafikun drejt destinacionit.
curl -H "Host: one.example.com" localhost -iDuhet të shihni një përgjigje që tregon se cili kontejner Docker trajtoi kërkesën. Në regjistrat e Envoy Proxy gjithashtu duhet të shihni rreshtin e aksesit të shfaqur.
Kryesore të tjera të përgjigjes HTTP (HTTP Response)
Në kryesore të përgjigjes së kërkesës së vlefshme do të shihni kryesore të tjera HTTP. Në kryesore tregohet koha që hosti në ngritje ka kaluar për të trajtuar kërkesën. Shprehet në milisekonda. Kjo është e dobishme, nëse klienti dëshiron të përcaktojë kohën e shërbimit krahas vonesës në rrjet.
x-envoy-upstream-service-time: 0
server: envoyKonfiguro i fundit
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 }Informacion shtesë nga përkthyesi
Udhëzimet për instalimin e Envoy Proxy mund t'i gjeni në faqen
Sipas parazgjedhjes, rpm nuk ka konfigurimin e shërbimit systemd.
Shtoni konfigurimin e shërbimit 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.targetDuhet të krijoni një dosje \/etc\/envoy\/ dhe të vendosni atje konfigurimin config.yaml.
Për envoy proxy ka një grup në Telegram:
Envoy Proxy nuk ka mbështetje për shpërndarjen e përmbajtjeve statike. Prandaj, kush mund të votojë për këtë veçori:
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
A e frymëzoi ky post të instaloni dhe testoni envoy proxy?
po
jo
75 përdorues votuan. 18 përdorues abstenuan.
Burimi: habr.com
