Salom, Xabr! E'tiboringizga postning tarjimasini havola etaman: .
Elchi - bu alohida xizmatlar va ilovalar uchun mo'ljallangan yuqori samarali taqsimlangan proksi-server (C++ tilida yozilgan), shuningdek, u katta mikroservis "xizmat tarmog'i" arxitekturalari uchun mo'ljallangan aloqa avtobusi va "universal ma'lumotlar tekisligi" hisoblanadi. Uni yaratishda NGINX, HAProxy, apparat yuk balanslagichlari va bulutli yuk balanslagichlari kabi serverlarni ishlab chiqishda yuzaga kelgan muammolarni hal qilish usullari hisobga olindi. Elchi har bir ilova bilan birga ishlaydi va platformadan qat'iy nazar umumiy funksionallikni ta'minlash uchun tarmoqni abstrakt qiladi. Infratuzilmadagi barcha xizmat trafigi Envoy tarmog‘i orqali oqib o‘tsa, muammoli hududlarni doimiy kuzatuvchanlik bilan tasavvur qilish, umumiy ishlashni sozlash va ma’lum bir joyda asosiy funksiyalarni qo‘shish oson bo‘ladi.
Xususiyatlar
- Jarayondan tashqari arxitektura: elchi o'zini o'zi boshqarishi mumkin bo'lgan yuqori unumdor server bo'lib, oz miqdorda operativ xotirani egallaydi. U har qanday dastur tili yoki ramkasi bilan birgalikda ishlaydi.
- http/2 va grpc yordami: elchi kiruvchi va chiquvchi ulanishlar uchun birinchi darajali http/2 va grpc yordamiga ega. Bu http/1.1 dan http/2 gacha bo'lgan shaffof proksi-server.
- Kengaytirilgan yuk muvozanati: elchi yukni avtomatik qayta urinishlar, zanjirni uzish, global tezlikni cheklash, soʻrovlarni soya qilish, mahalliy zonadagi yukni muvozanatlash va h.k. kabi ilgʻor yuk muvozanatlash xususiyatlarini qoʻllab-quvvatlaydi.
- Konfiguratsiyani boshqarish API: elchi konfiguratsiyangizni dinamik boshqarish uchun mustahkam API taqdim etadi.
- Kuzatish mumkinligi: L7 trafigini chuqur kuzatish, taqsimlangan kuzatuv va mongodb, dynamodb va boshqa ko'plab ilovalarni kuzatish uchun mahalliy yordam.
1-qadam — NGINX konfiguratsiyasiga misol
Ushbu skript maxsus tayyorlangan fayldan foydalanadi nginx.confdan to'liq misol asosida . Ochish orqali muharrirda konfiguratsiyani ko'rishingiz mumkin nginx.conf
nginx manba konfiguratsiyasi
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 konfiguratsiyasi odatda uchta asosiy elementga ega:
- NGINX serverini, jurnal tuzilishini va Gzip funksiyasini sozlash. Bu barcha holatlarda global miqyosda aniqlanadi.
- NGINX hostga so‘rovlarni qabul qilish uchun sozlanmoqda one.example.com 8080 portida.
- Maqsadli manzilni o'rnatish, URLning turli qismlari uchun trafikni qanday boshqarish.
Barcha konfiguratsiyalar Envoy proksi-serveriga qo'llanilmaydi va ba'zi sozlamalarni sozlashingiz shart emas. Elchi proksisi bor to'rtta asosiy turNGINX tomonidan taqdim etilgan asosiy infratuzilmani qo'llab-quvvatlaydi. Asosiysi:
- Tinglovchilar: Ular Envoy Proksi kiruvchi so'rovlarni qanday qabul qilishini aniqlaydi. Envoy Proxy hozirda faqat TCP-ga asoslangan tinglovchilarni qo'llab-quvvatlaydi. Ulanish o'rnatilgandan so'ng, u qayta ishlash uchun filtrlar to'plamiga o'tkaziladi.
- Filtrlar: Ular kiruvchi va chiquvchi ma'lumotlarni qayta ishlay oladigan quvur liniyasi arxitekturasining bir qismidir. Ushbu funksiya Gzip kabi filtrlarni o'z ichiga oladi, ular ma'lumotlarni mijozga yuborishdan oldin siqib chiqaradi.
- Routerlar: Ular trafikni klaster sifatida belgilangan kerakli manzilga yo'naltiradi.
- Klasterlar: Ular trafik va konfiguratsiya parametrlari uchun oxirgi nuqtani belgilaydi.
Muayyan NGINX konfiguratsiyasiga mos keladigan Envoy Proksi konfiguratsiyasini yaratish uchun ushbu to'rtta komponentdan foydalanamiz. Elchining maqsadi - API va dinamik konfiguratsiya bilan ishlash. Bunday holda, asosiy konfiguratsiya NGINX-dan statik, qattiq kodlangan sozlamalardan foydalanadi.
2-qadam - NGINX konfiguratsiyasi
Birinchi qism nginx.conf sozlanishi kerak bo'lgan ba'zi NGINX ichki qismlarini belgilaydi.
Ishchilar aloqalari
Quyidagi konfiguratsiya ishchi jarayonlari va ulanishlar sonini aniqlaydi. Bu NGINX talabni qondirish uchun qanday kengayishini ko'rsatadi.
worker_processes 2;
events {
worker_connections 2000;
}Envoy Proxy ish oqimlari va ulanishlarni turli yo'llar bilan boshqaradi.
Elchi tizimdagi har bir apparat ipi uchun ishchi ipni yaratadi. Har bir ishchi ip mas'ul bo'lgan bloklanmaydigan hodisa tsiklini bajaradi
- Har bir tinglovchini tinglash
- Yangi ulanishlarni qabul qilish
- Ulanish uchun filtrlar to'plamini yaratish
- Ulanish muddati davomida barcha kiritish-chiqarish operatsiyalarini qayta ishlash.
Barcha keyingi ulanishlarni qayta ishlash to'liq ishchi ish zarrachasida, shu jumladan har qanday uzatish harakatida amalga oshiriladi.
Envoy-dagi har bir ishchi ip uchun ulanish hovuzi mavjud. Shunday qilib, HTTP/2 ulanish hovuzlari bir vaqtning o'zida har bir tashqi xost uchun faqat bitta ulanishni o'rnatadi, agar to'rtta ishchi tarmoq mavjud bo'lsa, barqaror holatda har bir tashqi xost uchun to'rtta HTTP/2 ulanishi bo'ladi. Hamma narsani bitta ishchi ipda saqlash orqali deyarli barcha kodlarni blokirovka qilmasdan yozish mumkin, xuddi bitta tishli. Agar kerak bo'lgandan ko'ra ko'proq ishchi iplar ajratilsa, bu behuda xotiraga olib kelishi mumkin, ko'p sonli bo'sh ulanishlar paydo bo'ladi va ulanishlar hovuzga qaytarilishi sonini kamaytiradi.
Qo'shimcha ma'lumot uchun tashrif buyuring .
HTTP konfiguratsiyasi
Quyidagi NGINX konfiguratsiya bloki HTTP sozlamalarini belgilaydi, masalan:
- Qanday mime turlari qo'llab-quvvatlanadi
- Standart vaqt tugashi
- Gzip konfiguratsiyasi
Siz bu jihatlarni Envoy Proxy-dagi filtrlar yordamida sozlashingiz mumkin, biz ularni keyinroq muhokama qilamiz.
3-qadam - Server konfiguratsiyasi
HTTP konfiguratsiya blokida NGINX konfiguratsiyasi 8080 portni tinglashni va domenlar uchun kiruvchi so'rovlarga javob berishni belgilaydi. one.example.com и www.one.example.com.
server {
listen 8080;
server_name one.example.com www.one.example.com;Inside Envoy, uni tinglovchilar boshqaradi.
Elchi tinglovchilar
Envoy Proxy-ni ishga tushirishning eng muhim jihati tinglovchilaringizni aniqlashdir. Envoy misolini qanday ishga tushirishni tavsiflovchi konfiguratsiya faylini yaratishingiz kerak.
Quyidagi parcha yangi tinglovchi yaratadi va uni 8080 portiga bog'laydi. Konfiguratsiya Envoy Proksi-ga kiruvchi so'rovlar uchun qaysi portlarga ulanishi kerakligini aytadi.
Envoy Proxy konfiguratsiyasi uchun YAML notatsiyasidan foydalanadi. Ushbu belgiga kirish uchun bu yerga qarang .
Copy to Editorstatic_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }Ta'riflash kerak emas server_name, chunki Envoy Proksi filtrlari buni hal qiladi.
4-qadam - Joylashuvni sozlash
NGINX-ga so'rov tushganda, joylashuv bloki trafikni qanday qayta ishlash va qayerga yo'naltirishni aniqlaydi. Quyidagi fragmentda saytga barcha trafik yuqori oqim (tarjimonning eslatmasi: yuqori oqim odatda dastur serveri) nomli klasterga uzatiladi. targetCluster. Yuqori oqim klasteri so'rovni qayta ishlash kerak bo'lgan tugunlarni belgilaydi. Buni keyingi bosqichda muhokama qilamiz.
location / {
proxy_pass http://targetCluster/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}Elchida Filtrlar buni amalga oshiradi.
Elchi filtrlari
Statik konfiguratsiya uchun filtrlar kiruvchi so'rovlarni qanday qayta ishlashni aniqlaydi. Bunday holda biz mos keladigan filtrlarni o'rnatamiz server_nomlari oldingi bosqichda. Muayyan domenlar va marshrutlarga mos keladigan kiruvchi so'rovlar kelganda, trafik klasterga yo'naltiriladi. Bu NGINX pastdan yuqoriga konfiguratsiyasining ekvivalenti.
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.routerism elchi.http_connection_manager Envoy Proksi-da o'rnatilgan filtrdir. Boshqa filtrlar o'z ichiga oladi Redis, Mongo, TCP. Toʻliq roʻyxatni quyidagi manzilda topishingiz mumkin .
Boshqa yuklarni muvozanatlash siyosatlari haqida ko'proq ma'lumot olish uchun tashrif buyuring .
5-qadam - Proksi va yuqori oqim konfiguratsiyasi
NGINX-da yuqori oqim konfiguratsiyasi trafikni qayta ishlaydigan maqsadli serverlar to'plamini belgilaydi. Bunday holda, ikkita klaster tayinlangan.
upstream targetCluster {
172.18.0.3:80;
172.18.0.4:80;
}Elchida bu klasterlar tomonidan boshqariladi.
Elchi klasterlari
Yuqori oqim ekvivalenti klasterlar sifatida aniqlanadi. Bunday holda, trafikka xizmat ko'rsatadigan xostlar aniqlangan. Taymerlar kabi xostlarga kirish usuli klaster konfiguratsiyasi sifatida aniqlanadi. Bu kechikish va yukni muvozanatlash kabi jihatlarni batafsil nazorat qilish imkonini beradi.
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 }}
]Xizmat kashfiyotidan foydalanganda STRICT_DNS Elchi ko'rsatilgan DNS maqsadlarini doimiy va asinxron tarzda hal qiladi. DNS natijasidan qaytarilgan har bir IP manzil yuqori oqim klasterida aniq xost hisoblanadi. Bu shuni anglatadiki, agar so'rov ikkita IP-manzilni qaytarsa, Envoy klasterda ikkita xost bor deb hisoblaydi va ikkalasi ham yuk muvozanatli bo'lishi kerak. Agar xost natijadan olib tashlansa, Elchi u endi mavjud emas deb hisoblaydi va mavjud ulanish hovuzlaridan trafikni tortib oladi.
Qo'shimcha ma'lumot olish uchun qarang .
6-qadam - Jurnalga kirish va xatolar
Yakuniy konfiguratsiya - ro'yxatdan o'tish. Xato jurnallarini diskka surish o'rniga, Envoy Proksi bulutga asoslangan yondashuvni qo'llaydi. Barcha ilovalar jurnallari chiqadi stdout и stderr.
Foydalanuvchilar so'rov qilganda, kirish jurnallari ixtiyoriy va sukut bo'yicha o'chirib qo'yiladi. HTTP so'rovlari uchun kirish jurnallarini yoqish uchun konfiguratsiyani yoqing access_log HTTP ulanish menejeri uchun. Yo'l kabi qurilma bo'lishi mumkin stdout, yoki diskdagi fayl, sizning talablaringizga qarab.
Quyidagi konfiguratsiya barcha kirish jurnallarini qayta yo'naltiradi stdout (tarjimonning eslatmasi - docker ichidagi elchidan foydalanish uchun stdout kerak. Agar dockersiz ishlatilsa, /dev/stdout ni oddiy jurnal fayli yo'li bilan almashtiring). Snippetni ulanish menejeri uchun konfiguratsiya bo'limiga nusxalash:
Copy to Clipboardaccess_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"Natijalar quyidagicha ko'rinishi kerak:
- 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:Odatiy bo'lib, Envoy HTTP so'rovi tafsilotlarini o'z ichiga olgan format qatoriga ega:
[%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%"nUshbu format qatorining natijasi:
[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"Format maydonini o'rnatish orqali chiqish tarkibini sozlash mumkin. Masalan:
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"Jurnal qatori maydonni sozlash orqali JSON formatida ham chiqarilishi mumkin json_format. Masalan:
access_log:
- name: envoy.file_access_log
config:
path: "/dev/stdout"
json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}Elchini roʻyxatdan oʻtkazish metodologiyasi haqida qoʻshimcha maʼlumot olish uchun tashrif buyuring
Jurnalga kirish Envoy Proxy bilan ishlashni tushunishning yagona usuli emas. Unda rivojlangan kuzatuv va ko'rsatkichlar o'rnatilgan. Batafsil ma'lumotni quyidagi manzilda bilib olishingiz mumkin yoki orqali .
7-qadam - ishga tushirish
Endi siz konfiguratsiyangizni NGINX dan Envoy proksi-serveriga o‘tkazdingiz. Oxirgi qadam uni sinab ko'rish uchun Envoy Proksi nusxasini ishga tushirishdir.
Foydalanuvchi sifatida ishga tushirish
NGINX konfiguratsiya liniyasining yuqori qismida foydalanuvchi www www; xavfsizlikni yaxshilash uchun NGINXni past imtiyozli foydalanuvchi sifatida ishlatishni belgilaydi.
Elchi proksi-server jarayonga kim egalik qilishini boshqarish uchun bulutga asoslangan yondashuvni qo'llaydi. Konteyner orqali Envoy proksi-serverini ishga tushirganimizda, biz past imtiyozli foydalanuvchini belgilashimiz mumkin.
Elchi proksi ishga tushirilmoqda
Quyidagi buyruq Envoy Proksi-ni xostdagi Docker konteyneri orqali ishga tushiradi. Bu buyruq Envoyga kiruvchi soʻrovlarni 80-portda tinglash imkoniyatini beradi. Biroq, tinglovchi konfiguratsiyasida koʻrsatilganidek, Envoy Proksi 8080-portda kiruvchi trafikni tinglaydi. Bu jarayonni imtiyozli foydalanuvchi sifatida ishlatish imkonini beradi.
docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoyViktorina
Proksi-server ishlayotgan bo'lsa, endi testlarni amalga oshirish va qayta ishlash mumkin. Quyidagi cURL buyrug'i proksi-server konfiguratsiyasida aniqlangan xost sarlavhasi bilan so'rov beradi.
curl -H "Host: one.example.com" localhost -iHTTP so'rovi xatoga olib keladi 503. Buning sababi yuqoridagi ulanishlar ishlamayapti va mavjud emas. Shuning uchun, Elchi proksi-serverida so'rov uchun mavjud manzillar yo'q. Quyidagi buyruq Envoy uchun belgilangan konfiguratsiyaga mos keladigan bir qator HTTP xizmatlarini ishga tushiradi.
docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;Mavjud xizmatlar bilan Envoy trafikni o'z manziliga muvaffaqiyatli proksi-proksi orqali yuborishi mumkin.
curl -H "Host: one.example.com" localhost -iQaysi Docker konteyneri so'rovni qayta ishlaganini ko'rsatadigan javobni ko'rishingiz kerak. Envoy Proksi jurnallarida siz kirish qatori chiqishini ham ko'rishingiz kerak.
Qo'shimcha HTTP javob sarlavhalari
Haqiqiy so'rovning javob sarlavhalarida qo'shimcha HTTP sarlavhalarini ko'rasiz. Sarlavha yuqori oqim hostining so'rovni qayta ishlashga sarflagan vaqtini ko'rsatadi. Millisekundlarda ifodalangan. Agar mijoz tarmoq kechikishi bilan solishtirganda xizmat ko'rsatish vaqtini aniqlamoqchi bo'lsa, bu foydalidir.
x-envoy-upstream-service-time: 0
server: envoyYakuniy konfiguratsiya
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 }Tarjimondan qo'shimcha ma'lumot
Envoy Proxy-ni o'rnatish bo'yicha ko'rsatmalarni veb-saytda topish mumkin
Odatiy bo'lib, rpm tizimli xizmat konfiguratsiyasiga ega emas.
Systemd xizmati konfiguratsiyasini qo'shing /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.targetSiz /etc/envoy/ katalogini yaratishingiz va u erda config.yaml konfiguratsiyasini qo'yishingiz kerak.
Elchi proksi yordamida telegram chati mavjud:
Elchi proksi statik kontentni taqdim etishni qo'llab-quvvatlamaydi. Shunday qilib, xususiyat uchun kim ovoz berishi mumkin:
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Ushbu post sizni elchi proksi-serverni o'rnatish va sinab ko'rishga undadimi?
-
ha
-
yo'q
75 foydalanuvchi ovoz berdi. 18 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com