Dobrý den, Habr! Upozorňuji na překlad příspěvku:
Envoy je vysoce výkonný distribuovaný proxy server (napsaný v C++) určený pro jednotlivé služby a aplikace, dále je to komunikační sběrnice a „univerzální datová rovina“ určená pro rozsáhlé architektury „service mesh“ mikroslužeb. Při jeho tvorbě byla zohledněna řešení problémů, které vznikly při vývoji serverů jako NGINX, HAProxy, hardwarové load balancery a cloud load balancery. Envoy pracuje vedle každé aplikace a abstrahuje síť, aby poskytoval společné funkce bez ohledu na platformu. Když veškerý provoz služeb v infrastruktuře prochází sítí Envoy, je snadné vizualizovat problémové oblasti s konzistentní pozorovatelností, vyladit celkový výkon a přidat základní funkce na konkrétním místě.
Možnosti
- Architektura mimo proces: envoy je samostatný, vysoce výkonný server, který zabírá malé množství paměti RAM. Funguje ve spojení s jakýmkoliv aplikačním jazykem nebo frameworkem.
- Podpora http/2 a grpc: envoy má prvotřídní podporu http/2 a grpc pro příchozí a odchozí připojení. Toto je transparentní proxy z http/1.1 na http/2.
- Pokročilé vyvažování zátěže: Envoy podporuje pokročilé funkce vyvažování zátěže včetně automatického opakování, přerušení řetězu, globálního omezení rychlosti, stínování požadavků, vyrovnávání zátěže lokální zóny atd.
- Configuration Management API: Envoy poskytuje robustní API pro dynamickou správu vaší konfigurace.
- Pozorovatelnost: Hluboká pozorovatelnost provozu L7, nativní podpora distribuovaného trasování a pozorovatelnost mongodb, dynamodb a mnoha dalších aplikací.
Krok 1 — Příklad NGINX Config
Tento skript používá speciálně vytvořený soubor nginx.conf, na základě úplného příkladu z
zdrojová konfigurace 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;
}
}
}
Konfigurace NGINX mají obvykle tři klíčové prvky:
- Konfigurace serveru NGINX, struktura protokolu a funkce Gzip. To je definováno globálně ve všech případech.
- Konfigurace NGINX pro přijímání požadavků na hostitele one.example.com na portu 8080.
- Nastavení cílového umístění, jak zvládnout provoz pro různé části URL.
Ne všechny konfigurace se budou vztahovat na Envoy Proxy a některá nastavení konfigurovat nemusíte. Envoy Proxy má čtyři typy klíčů, které podporují základní infrastrukturu nabízenou NGINX. Jádro je:
- Posluchači: Určují, jak Envoy Proxy přijímá příchozí požadavky. Envoy Proxy aktuálně podporuje pouze posluchače založené na TCP. Jakmile je spojení navázáno, je předáno sadě filtrů ke zpracování.
- Filtry: Jsou součástí architektury potrubí, která dokáže zpracovávat příchozí a odchozí data. Tato funkce zahrnuje filtry, jako je Gzip, který komprimuje data před jejich odesláním klientovi.
- Směrovače: Přesměrují provoz do požadovaného cíle definovaného jako cluster.
- Shluky: Definují koncový bod pro provoz a konfigurační parametry.
Tyto čtyři komponenty použijeme k vytvoření konfigurace Envoy Proxy, která bude odpovídat konkrétní konfiguraci NGINX. Cílem Envoy je práce s API a dynamickou konfigurací. V tomto případě bude základní konfigurace používat statická, pevně zakódovaná nastavení z NGINX.
Krok 2 – Konfigurace NGINX
První část nginx.conf definuje některé interní prvky NGINX, které je třeba nakonfigurovat.
Pracovní připojení
Níže uvedená konfigurace určuje počet pracovních procesů a připojení. To ukazuje, jak se bude NGINX přizpůsobovat poptávce.
worker_processes 2;
events {
worker_connections 2000;
}
Envoy Proxy spravuje pracovní postupy a připojení různými způsoby.
Envoy vytvoří pracovní vlákno pro každé hardwarové vlákno v systému. Každé pracovní vlákno spustí neblokující smyčku událostí, která je zodpovědná
- Naslouchání každému posluchači
- Přijímání nových spojení
- Vytvoření sady filtrů pro připojení
- Zpracujte všechny I/O operace během životnosti připojení.
Veškeré další zpracování připojení je řešeno výhradně v pracovním vláknu, včetně jakéhokoli chování při předávání.
Pro každé pracovní vlákno v Envoy existuje fond připojení. Fondy připojení HTTP/2 tedy navazují pouze jedno připojení na externího hostitele najednou, pokud existují čtyři pracovní vlákna, budou ve stabilním stavu čtyři připojení HTTP/2 na externího hostitele. Udržením všeho v jednom pracovním vláknu lze téměř veškerý kód zapsat bez blokování, jako by byl jednovláknový. Pokud je přiděleno více pracovních vláken, než je nutné, může to vést k plýtvání pamětí, vytváření velkého počtu nečinných připojení a snížení počtu připojení vracených zpět do fondu.
Pro více informací navštivte
Konfigurace HTTP
Následující konfigurační blok NGINX definuje nastavení HTTP, jako například:
- Jaké typy mime jsou podporovány
- Výchozí časové limity
- Konfigurace Gzip
Tyto aspekty si můžete přizpůsobit pomocí filtrů v Envoy Proxy, o kterých si povíme později.
Krok 3 – Konfigurace serveru
V konfiguračním bloku HTTP konfigurace NGINX určuje, že má naslouchat na portu 8080 a reagovat na příchozí požadavky na domény one.example.com и www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;
Uvnitř Envoy ji ovládají posluchači.
Vyslanci posluchači
Nejdůležitějším aspektem, jak začít s Envoy Proxy, je definovat své posluchače. Musíte vytvořit konfigurační soubor, který popisuje, jak chcete spustit instanci Envoy.
Níže uvedený úryvek vytvoří nový posluchač a připojí jej k portu 8080. Konfigurace říká Envoy Proxy, na které porty se má vázat pro příchozí požadavky.
Envoy Proxy používá pro svou konfiguraci notaci YAML. Úvod do tohoto zápisu naleznete zde
Copy to Editorstatic_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
Není třeba definovat název_serveru, protože to zvládnou filtry Envoy Proxy.
Krok 4 – Konfigurace umístění
Když požadavek přijde do NGINX, blok umístění určuje, jak zpracovat a kam směrovat provoz. V následujícím fragmentu je veškerý provoz na webu přenesen do upstreamu (poznámka překladatele: upstream je obvykle aplikační server) clusteru s názvem targetCluster. Upstream cluster definuje uzly, které by měly zpracovat požadavek. Probereme to v dalším kroku.
location / {
proxy_pass http://targetCluster/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
Ve společnosti Envoy to dělá Filters.
Filtry vyslanců
U statické konfigurace určují filtry, jak zpracovat příchozí požadavky. V tomto případě nastavíme filtry, které se shodují názvy_serverů v předchozím kroku. Když dorazí příchozí požadavky, které odpovídají určitým doménám a trasám, je provoz směrován do clusteru. Toto je ekvivalent konfigurace NGINX zdola nahoru.
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
název vyslanec.http_connection_manager je vestavěný filtr v Envoy Proxy. Mezi další filtry patří Redestilát, Mongo, TCP. Kompletní seznam najdete na
Další informace o dalších zásadách vyrovnávání zátěže naleznete na adrese
Krok 5 – Konfigurace proxy a Upstream
V NGINX definuje upstream konfigurace sadu cílových serverů, které budou zpracovávat provoz. V tomto případě byly přiřazeny dva shluky.
upstream targetCluster {
172.18.0.3:80;
172.18.0.4:80;
}
V Envoy je to řízeno clustery.
Shluky vyslanců
Upstream ekvivalent je definován jako shluky. V tomto případě byli identifikováni hostitelé, kteří budou provoz obsluhovat. Způsob přístupu k hostitelům, jako jsou časové limity, je definován jako konfigurace clusteru. To umožňuje podrobnější kontrolu nad aspekty, jako je latence a vyrovnávání zátěže.
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 }}
]
Při použití zjišťování služeb STRICT_DNS Envoy bude průběžně a asynchronně řešit zadané cíle DNS. Každá vrácená IP adresa z výsledku DNS bude považována za explicitního hostitele v upstreamovém clusteru. To znamená, že pokud požadavek vrátí dvě IP adresy, Envoy bude předpokládat, že v clusteru jsou dva hostitelé a oba musí být vyváženi zatížením. Pokud je hostitel z výsledku odebrán, Envoy bude předpokládat, že již neexistuje, a bude stahovat provoz ze všech existujících fondů připojení.
Další informace viz
Krok 6 — Log Access and Errors
Poslední konfigurací je registrace. Místo odesílání chybových protokolů na disk využívá Envoy Proxy cloudový přístup. Všechny aplikační protokoly se vypisují do stdout и stderr.
Když uživatelé zadají požadavek, protokoly přístupu jsou volitelné a ve výchozím nastavení jsou zakázány. Chcete-li povolit protokoly přístupu pro požadavky HTTP, povolte konfiguraci přístupový_log pro správce připojení HTTP. Cestou může být buď zařízení jako např stdout, nebo soubor na disku, v závislosti na vašich požadavcích.
Následující konfigurace přesměruje všechny přístupové protokoly na stdout (poznámka překladatele - pro použití envoy uvnitř dockeru je vyžadován stdout. Pokud je použit bez dockeru, nahraďte /dev/stdout cestou k běžnému souboru protokolu). Zkopírujte úryvek do sekce konfigurace pro správce připojení:
Copy to Clipboardaccess_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"
Výsledky by měly vypadat takto:
- 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:
Ve výchozím nastavení má Envoy formátovací řetězec, který obsahuje podrobnosti požadavku 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
Výsledkem tohoto formátovacího řetězce je:
[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"
Výstupní obsah lze upravit nastavením pole formátu. Například:
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"
Řádek protokolu lze také nastavit na výstup ve formátu JSON nastavením pole json_format. Například:
access_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"
json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}
Pro více informací o Metodice registrace vyslanců navštivte
Protokolování není jediný způsob, jak získat přehled o práci s Envoy Proxy. Má v sobě zabudované pokročilé možnosti sledování a metrik. Více se můžete dozvědět na
Krok 7 – Spuštění
Nyní jste migrovali svou konfiguraci z NGINX na Envoy Proxy. Posledním krokem je spuštění instance Envoy Proxy za účelem jejího otestování.
Spustit jako uživatel
Na vrcholu konfigurační řady NGINX uživatel www www; určuje spuštění NGINX jako nízkoprivilegovaného uživatele pro zlepšení zabezpečení.
Envoy Proxy využívá cloudový přístup ke správě toho, kdo vlastní proces. Když spustíme Envoy Proxy prostřednictvím kontejneru, můžeme zadat uživatele s nízkým oprávněním.
Spuštění Envoy Proxy
Níže uvedený příkaz spustí Envoy Proxy prostřednictvím kontejneru Docker na hostiteli. Tento příkaz dává Envoy schopnost naslouchat příchozím požadavkům na portu 80. Jak je však uvedeno v konfiguraci listeneru, Envoy Proxy naslouchá příchozímu provozu na portu 8080. To umožňuje, aby proces běžel jako uživatel s nízkými oprávněními.
docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy
Testování
Se spuštěným proxy lze nyní provádět a zpracovávat testy. Následující příkaz cURL vydá požadavek s hlavičkou hostitele definovanou v konfiguraci serveru proxy.
curl -H "Host: one.example.com" localhost -i
Požadavek HTTP bude mít za následek chybu 503. Důvodem je, že proti proudu připojení nefungují a nejsou k dispozici. Envoy Proxy proto nemá žádné dostupné cíle pro požadavek. Následující příkaz spustí řadu HTTP služeb, které odpovídají konfiguraci definované pro Envoy.
docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;
S dostupnými službami může Envoy úspěšně proxy provozovat do svého cíle.
curl -H "Host: one.example.com" localhost -i
Měli byste vidět odpověď označující, který kontejner Docker požadavek zpracoval. V protokolech Envoy Proxy byste také měli vidět výstup přístupového řetězce.
Další záhlaví odezvy HTTP
V záhlavích odpovědí skutečného požadavku uvidíte další záhlaví HTTP. Záhlaví zobrazuje čas, který upstream hostitel strávil zpracováním požadavku. Vyjádřeno v milisekundách. To je užitečné, pokud chce klient určit dobu služby ve srovnání s latencí sítě.
x-envoy-upstream-service-time: 0
server: envoy
Konečná konfigurace
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 }
Další informace od překladatele
Pokyny pro instalaci Envoy Proxy naleznete na webu
Ve výchozím nastavení rpm nemá konfiguraci služby systemd.
Přidejte konfiguraci služby 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
Musíte vytvořit adresář /etc/envoy/ a vložit tam konfiguraci config.yaml.
Existuje telegramový chat pomocí zástupce proxy:
Envoy Proxy nepodporuje poskytování statického obsahu. Kdo tedy může pro funkci hlasovat:
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé.
Vyzval vás tento příspěvek k instalaci a testování proxy serveru?
-
ano
-
ne
Hlasovalo 75 uživatelů. 18 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com