Cześć, Habr! Oferuję wam tłumaczenie posta: .
Envoy to wydajny, rozproszony serwer proxy (napisany w C++), przeznaczony dla pojedynczych usług i aplikacji, a także jako magistrala komunikacyjna i „uniwersalna płaszczyzna danych”, zaprojektowana dla dużych architektur mikrousług „service mesh”. Podczas jego tworzenia uwzględniono rozwiązania problemów, które pojawiały się przy tworzeniu takich serwerów jak NGINX, HAProxy, sprzętowe balancery obciążenia oraz balancery obciążenia w chmurze. Envoy działa wraz z każdą aplikacją i abstrahuje sieć, oferując wspólne funkcje niezależnie od platformy. Gdy cały ruch serwisowy w infrastrukturze przechodzi przez sieć Envoy, łatwo można wizualizować problematyczne obszary za pomocą spójnej obserwowalności, dostosowywania ogólnej wydajności i dodawania podstawowych funkcji w określonym miejscu.
Możliwości
- Architektura poza procesem: envoy to autonomiczny, wysoce wydajny serwer zajmujący niewielką ilość pamięci operacyjnej. Działa w połączeniu z dowolnym językiem aplikacji lub frameworkiem.
- Wsparcie dla http/2 i grpc: envoy ma doskonałe wsparcie dla http/2 i grpc dla przychodzących i wychodzących połączeń. To przezroczysty proxy od http/1.1 do http/2.
- Zaawansowane balansowanie obciążenia: envoy wspiera zaawansowane funkcje balansowania obciążenia, w tym automatyczne powtórki, przerwanie łańcucha, globalne ograniczenie prędkości, cieniowanie zapytań, lokalne balansowanie obciążenia strefy itd.
- API do zarządzania konfiguracją: envoy zapewnia niezawodne API do dynamicznego zarządzania swoją konfiguracją.
- Obserwowalność: głęboka obserwowalność ruchu L7, wbudowane wsparcie dla rozproszonego śledzenia i obserwowalność mongodb, dynamodb i wielu innych aplikacji.
Krok 1 — Przykład konfiguracji NGINX
W tym scenariuszu wykorzystano specjalnie stworzony plik nginx.conf, oparty na pełnym przykładzie z . Możesz przeglądać konfigurację w edytorze, otwierając nginx.conf
Oryginalny config 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;
}
}
}Konfiguracje NGINX zazwyczaj mają trzy kluczowe elementy:
- Konfiguracja serwera NGINX, struktura dzienników oraz funkcjonalność Gzip. Te elementy są definiowane globalnie w każdym przypadku.
- Konfiguracja NGINX do odbierania zapytań na hoście one.example.com na porcie 8080.
- Konfiguracja docelowa lokalizacji, jak obsługiwać ruch dla różnych części URL.
Nie cała konfiguracja będzie miała zastosowanie do Envoy Proxy, a niektóre parametry nie muszą być konfigurowane. Envoy Proxy ma cztery kluczowe typy, które wspierają podstawową infrastrukturę oferowaną przez NGINX. Jądro to:
- Słuchacze: Określają, jak Envoy Proxy przyjmuje nadchodzące zapytania. W chwili obecnej Envoy Proxy wspiera jedynie słuchaczy opartych na TCP. Gdy połączenie jest nawiązane, jest przekazywane do zestawu filtrów do przetworzenia.
- Filtry: Są częścią architektury potokowej, która może przetwarzać nadchodzące i wychodzące dane. Ta funkcjonalność obejmuje filtry, takie jak Gzip, który kompresuje dane przed ich wysłaniem do klienta.
- Routery: Przekierowują ruch do wymaganego punktu docelowego, określonego jako klaster.
- Klastry: Określają punkt końcowy dla ruchu oraz parametry konfiguracji.
Będziemy używać tych czterech komponentów do stworzenia konfiguracji Envoy Proxy, aby odpowiadała określonej konfiguracji NGINX. Celem Envoy jest praca z API i dynamiczna konfiguracja. W tym przypadku podstawowa konfiguracja będzie korzystać ze statycznych, sztywno określonych parametrów z NGINX.
Krok 2 — Konfiguracja NGINX
Pierwsza część nginx.conf określa niektóre wewnętrzne komponenty NGINX, które należy skonfigurować.
Worker Connections (Połączenia robocze)
Poniższa konfiguracja określa liczbę procesów roboczych i połączeń. Wskazuje to, jak NGINX będzie skalować się w celu zaspokojenia popytu.
worker_processes 2;
events {
worker_connections 2000;
}Envoy Proxy w różny sposób zarządza procesami roboczymi i połączeniami.
Envoy tworzy proces roboczy dla każdego wątku sprzętowego w systemie. Każdy proces roboczy wykonuje nieblokującą pętlę zdarzeń, która odpowiada za
- Słuchanie każdego słuchacza (listener)
- Akceptowanie nowych połączeń
- Tworzenie zestawu filtrów dla połączenia
- Przetwarzanie wszystkich operacji wejścia-wyjścia w czasie trwania połączenia.
Całe dalsze przetwarzanie połączenia jest całkowicie obsługiwane w procesie roboczym, w tym wszelkie działanie przekierowania.
Dla każdego procesu roboczego w Envoy istnieje połączenie w puli. W ten sposób pule połączeń HTTP/2 nawiązują tylko jedno połączenie dla każdego zewnętrznego hosta w danym czasie, przy czterech procesach roboczych będą cztery połączenia HTTP/2 dla każdego zewnętrznego hosta w stanie stabilnym. Przechowując wszystko w jednym procesie roboczym, prawie cały kod może być napisany bez blokad, jakby był jednowątkowy. Jeśli przydzielono więcej procesów roboczych niż jest to konieczne, może to prowadzić do nieefektywnego wykorzystania pamięci, tworzenia dużej liczby bezczynnych połączeń oraz zmniejszenia liczby powrotów połączeń do puli.
26 marca 2020, Apache Software Foundation oraz ochotnicy-deweloperzy, stewardzi, .
Konfiguracja HTTP
Poniższy blok konfiguracji NGINX określa ustawienia HTTP, takie jak:
- Jakie typy mime są obsługiwane
- Domyślne czasy oczekiwania
- Konfiguracja Gzip
Możesz konfigurować te aspekty za pomocą filtrów w Envoy Proxy, co omówimy później.
Krok 3 — Konfiguracja serwera
W bloku konfiguracji HTTP, NGINX określa, aby odsłuchiwać port 8080 i odpowiadać na przychodzące żądania dla domen one.example.com i www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;Wewnątrz Envoy zarządzają tym Słuchacze.
Słuchacze Envoy
Najważniejszym aspektem rozpoczęcia pracy z Envoy Proxy jest określenie słuchaczy. Musisz stworzyć plik konfiguracyjny, który opisuje, jak chcesz uruchomić instancję Envoy.
Poniższy fragment stworzy nowego nasłuchiwacza i połączy go z portem 8080. Konfiguracja wskazuje, do których portów Envoy Proxy powinno być przypisane dla przychodzących żądań.
Envoy Proxy używa notacji YAML do swojej konfiguracji. Aby zapoznać się z tą notacją, zobacz tutaj. .
Copy to Editorstatic_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }Nie ma potrzeby definiować server_name, ponieważ filtry Envoy Proxy poradzą sobie z tym.
Krok 4 — Konfiguracja lokalizacji
Kiedy żądanie dociera do NGINX, blok lokalizacji określa, jak przetwarzać i dokąd kierować ruch. W następującym fragmencie cały ruch do witryny jest kierowany do klastra upstream (przypisanie do tłumacza: upstream — zazwyczaj są to serwery aplikacji) o nazwie targetCluster. Klastr upstream określa węzły, które powinny przetwarzać żądanie. Omówimy to w następnym kroku.
location / {
proxy_pass http://targetCluster/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}W Envoy zajmują się tym filtry.
Filtry Envoy
Dla statycznej konfiguracji filtry określają, jak przetwarzać przychodzące żądania. W tym przypadku ustawiamy filtry, które odpowiadają server_names z poprzedniego kroku. Gdy przychodzą żądania, które odpowiadają określonym domenom i trasom, ruch jest kierowany do klastra. Jest to równoważne konfiguracji upstream w 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.routerNazwa envoy.http_connection_manager jest wbudowanym filtrem w Envoy Proxy. Inne filtry obejmują Redis, Mongo, TCP. Możesz znaleźć pełną listę w .
Aby uzyskać więcej informacji na temat innych polityk równoważenia obciążenia, odwiedź .
Krok 5 — Konfiguracja proksy i upstream
W NGINX konfiguracja upstream określa zestaw serwerów docelowych, które będą przetwarzać ruch. W tym przypadku przypisano dwa klastry.
upstream targetCluster {
172.18.0.3:80;
172.18.0.4:80;
}W Envoy zarządzają tym klastry.
Klastry Envoy
Odpowiednik upstream definiowany jest jako klastry. W tym przypadku zdefiniowano hosty, które będą obsługiwać ruch. Sposób dostępu do hostów, na przykład czas oczekiwania, definiowany jest jako konfiguracja klastra. Umożliwia to dokładniejsze kontrolowanie szczegółów takich jak czas oczekiwania i równoważenie obciążenia.
Skopiuj do edytora klastry:
- nazwa: 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 }}
]Podczas korzystania z wykrywania usług STRICT_DNS Envoy będzie nieprzerwanie i asynchronicznie rozwiązywać wskazane cele DNS. Każdy zwrócony adres IP w wyniku DNS będzie uważany za wyraźny host w klastrze upstream. Oznacza to, że jeśli zapytanie zwraca dwa adresy IP, Envoy założy, że w klastrze znajdują się dwa hosty, które powinny być równoważone obciążeniem. Jeśli host zostanie usunięty z wyniku, Envoy zakłada, że już nie istnieje, i będzie selekcjonował ruch z dowolnych istniejących pul połączeń.
Aby uzyskać więcej informacji, zobacz .
Krok 6 – Dostęp do logu i błędów
Ostateczna konfiguracja – rejestrowanie. Zamiast przekazywać logi błędów na dysk, Envoy Proxy stosuje podejście chmurowe. Wszystkie logi aplikacji są wyprowadzane do stdout i stderr.
Gdy użytkownicy wykonują zapytanie, logi dostępu są opcjonalne i domyślnie wyłączone. Aby włączyć logi dostępu dla zapytań HTTP, włącz konfigurację access_log dla menedżera połączeń HTTP. Ścieżka może być albo urządzeniem, takim jak stdout, albo plikiem na dysku, w zależności od Twoich potrzeb.
Następna konfiguracja przekieruje wszystkie logi dostępu do stdout (uwaga tłumacza – stdout jest wymagany do użycia envoy w dockerze. Jeśli używasz bez dockera, zamień /dev/stdout na ścieżkę do zwykłego pliku logów). Skopiuj fragment do sekcji konfiguracji dla menedżera połączeń:
Skopiuj do schowka access_log:
- nazwa: envoy.file_access_log
config:
path: "/dev/stdout"Wyniki powinny wyglądać tak:
- nazwa: envoy.http_connection_manager
config:
codec_type: auto
stat_prefix: ingress_http
access_log:
- nazwa: envoy.file_access_log
config:
path: "/dev/stdout"
route_config:Domyślnie Envoy ma ciąg formatu, który zawiera szczegóły żądania 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%"nWynik tej linii formatu:
[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"Zawartość wyjścia można dostosować, ustawiając pole formatu. Na przykład:
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"Linia dziennika może być również wyjściem w formacie JSON, ustawiając pole json_format. Na przykład:
access_log:
- name: envoy.file_access_log
config:
path: "\/dev\/stdout"
json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}Aby uzyskać więcej informacji o metodzie rejestracji Envoy, odwiedź
Rejestrowanie to nie jedyny sposób na uzyskanie wglądu w działanie Envoy Proxy. Wbudowane są zaawansowane możliwości śledzenia i metryk. Możesz dowiedzieć się więcej w lub poprzez .
Krok 7 — Uruchamianie
Teraz skonfigurowałeś Envoy Proxy. Ostatnim krokiem jest uruchomienie instancji Envoy Proxy w celu przetestowania.
Uruchamianie jako użytkownik
Na górze konfiguracji NGINX znajduje się linia user www www; która wskazuje, że NGINX działa jako użytkownik z ograniczonymi uprawnieniami dla zwiększenia bezpieczeństwa.
Envoy Proxy stosuje podejście chmurowe do zarządzania tym, kto jest właścicielem procesu. Kiedy uruchamiamy Envoy Proxy w kontenerze, możemy określić użytkownika z ograniczonymi uprawnieniami.
Uruchomienie Envoy Proxy
Poniższe polecenie uruchomi Envoy Proxy w kontenerze Docker na hoście. Komenda ta pozwala Envoy nasłuchiwać przychodzące zapytania na porcie 80. Jednak jak wynika z konfiguracji słuchacza, Envoy Proxy nasłuchuje przychodzący ruch przez port 8080. To pozwala na działanie procesu jako użytkownik z ograniczonymi uprawnieniami.
docker run --name proxy1 -p 80:8080 --user 1000:1000 -v \/root\/envoy.yaml:\/etc\/envoy\/envoy.yaml envoyproxy\/envoyTestowanie
Z uruchomionym proxy, teraz można przeprowadzić i przetworzyć testy. Następujące polecenie cURL generuje zapytanie z nagłówkiem hosta określonym w konfiguracji proxy.
curl -H "Host: one.example.com" localhost -iZapytanie HTTP zakończy się błędem. 503To są z tym związane, że połączenia wychodzące nie działają i są niedostępne. W ten sposób Envoy Proxy nie ma dostępnych docelowych adresów dla żądania. Następna komenda uruchomi serię usług HTTP, które odpowiadają konfiguracji zdefiniowanej dla Envoy.
docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;Dzięki dostępnym usługom Envoy może skutecznie proxy'ować ruch do miejsca docelowego.
curl -H "Host: one.example.com" localhost -iPowinieneś zobaczyć odpowiedź wskazującą, który kontener Docker obsłużył żądanie. W dziennikach Envoy Proxy powinieneś również zobaczyć wypisaną linię dostępu.
Dodatkowe nagłówki odpowiedzi HTTP (HTTP Response)
W nagłówkach odpowiedzi rzeczywistego żądania zobaczysz dodatkowe nagłówki HTTP. W nagłówku widać czas, który host nadrzędny spędził na przetwarzaniu żądania. Wyraża się w milisekundach. Jest to przydatne, gdy klient chce określić czas obsługi w porównaniu z opóźnieniem w sieci.
x-envoy-upstream-service-time: 0
server: envoyKońcowa konfiguracja
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 }Dodatkowe informacje od tłumacza
Instrukcje dotyczące instalacji Envoy Proxy można znaleźć na stronie
Domyślnie w rpm brakuje konfiguracji usługi systemd.
Dodaj konfigurację usługi systemd do \/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.targetMusisz utworzyć katalog \/etc\/envoy\/ i umieścić tam konfigurację config.yaml.
O Envoy Proxy jest czat na Telegramie:
Envoy Proxy nie ma wsparcia dla serwowania zawartości statycznej. Dlatego kto może, proszę zagłosować na funkcję:
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czy ten post skłonił cię do zainstalowania i przetestowania Envoy Proxy?
tak
nie
75 użytkowników zagłosowało. 18 użytkowników wstrzymało się.
Źródło: habr.com
