Nginx થી Envoy Proxy માં સ્થળાંતર

હેલો, હેબ્ર! હું તમારા ધ્યાન પર પોસ્ટનો અનુવાદ લાવું છું: Nginx થી Envoy Proxy માં સ્થળાંતર.

એન્વોય એ એક ઉચ્ચ-પ્રદર્શન વિતરિત પ્રોક્સી સર્વર છે (C++ માં લખાયેલ) વ્યક્તિગત સેવાઓ અને એપ્લિકેશનો માટે રચાયેલ છે, તે એક કોમ્યુનિકેશન બસ અને "યુનિવર્સલ ડેટા પ્લેન" પણ છે જે મોટા માઇક્રોસર્વિસ "સર્વિસ મેશ" આર્કિટેક્ચર્સ માટે રચાયેલ છે. તેને બનાવતી વખતે, NGINX, HAProxy, હાર્ડવેર લોડ બેલેન્સર્સ અને ક્લાઉડ લોડ બેલેન્સર્સ જેવા સર્વર્સના વિકાસ દરમિયાન ઊભી થયેલી સમસ્યાઓના ઉકેલોને ધ્યાનમાં લેવામાં આવ્યા હતા. દૂત દરેક એપ્લિકેશન સાથે કામ કરે છે અને પ્લેટફોર્મને ધ્યાનમાં લીધા વિના સામાન્ય કાર્યક્ષમતા પ્રદાન કરવા માટે નેટવર્કને અમૂર્ત બનાવે છે. જ્યારે ઈન્ફ્રાસ્ટ્રક્ચરમાં તમામ સર્વિસ ટ્રાફિક એન્વોય મેશમાંથી વહે છે, ત્યારે સતત અવલોકનક્ષમતા સાથે સમસ્યાવાળા વિસ્તારોની કલ્પના કરવી, એકંદર પ્રદર્શનને ટ્યુન કરવું અને ચોક્કસ સ્થાનમાં મુખ્ય કાર્યક્ષમતા ઉમેરવાનું સરળ બને છે.

લક્ષણો

• આઉટ-ઓફ-પ્રોસેસ આર્કિટેક્ચર: એન્વોય એ સ્વયં-સમાયેલ, ઉચ્ચ-પ્રદર્શન સર્વર છે જે થોડી માત્રામાં RAM લે છે. તે કોઈપણ એપ્લિકેશન ભાષા અથવા ફ્રેમવર્ક સાથે જોડાણમાં કાર્ય કરે છે.
• http/2 અને grpc સપોર્ટ: દૂત પાસે ફર્સ્ટ-ક્લાસ http/2 અને grpc સપોર્ટ ઇનકમિંગ અને આઉટગોઇંગ કનેક્શન્સ માટે છે. આ http/1.1 થી http/2 સુધીની પારદર્શક પ્રોક્સી છે.
• એડવાન્સ્ડ લોડ બેલેન્સિંગ: દૂત અદ્યતન લોડ બેલેન્સિંગ ફિચર્સનું સમર્થન કરે છે જેમાં ઓટોમેટિક રિટ્રાય્સ, ચેઈન બ્રેકિંગ, ગ્લોબલ રેટ લિમિટિંગ, રિક્વેસ્ટ શેડોઈંગ, લોકલ ઝોન લોડ બેલેન્સિંગ વગેરેનો સમાવેશ થાય છે.
• કન્ફિગરેશન મેનેજમેન્ટ API: દૂત તમારા રૂપરેખાંકનને ગતિશીલ રીતે સંચાલિત કરવા માટે એક મજબૂત API પ્રદાન કરે છે.
• અવલોકનક્ષમતા: L7 ટ્રાફિકની ઊંડી અવલોકનક્ષમતા, વિતરિત ટ્રેસિંગ માટે મૂળ આધાર અને મોંગોડબી, ડાયનામોડબી અને અન્ય ઘણી એપ્લિકેશનોની અવલોકનક્ષમતા.

પગલું 1 - ઉદાહરણ NGINX રૂપરેખા

આ સ્ક્રિપ્ટ ખાસ રચિત ફાઇલનો ઉપયોગ કરે છે nginx.conf, ના સંપૂર્ણ ઉદાહરણના આધારે NGINX વિકી. તમે એડિટરમાં ખોલીને રૂપરેખાંકન જોઈ શકો છો nginx.conf

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;
    }
  }
}

NGINX રૂપરેખાંકનોમાં સામાન્ય રીતે ત્રણ મુખ્ય ઘટકો હોય છે:

1. NGINX સર્વર, લોગ સ્ટ્રક્ચર અને Gzip કાર્યક્ષમતાને ગોઠવી રહ્યું છે. આ તમામ કેસોમાં વૈશ્વિક સ્તરે વ્યાખ્યાયિત થયેલ છે.
2. હોસ્ટને વિનંતીઓ સ્વીકારવા માટે NGINX ને ગોઠવી રહ્યું છે one.example.com પોર્ટ 8080 પર.
3. લક્ષ્ય સ્થાન સુયોજિત કરી રહ્યા છીએ, URL ના વિવિધ ભાગો માટે ટ્રાફિકને કેવી રીતે હેન્ડલ કરવું.

એન્વોય પ્રોક્સી પર તમામ રૂપરેખાંકન લાગુ થશે નહીં, અને તમારે કેટલીક સેટિંગ્સને ગોઠવવાની જરૂર નથી. રાજદૂત પ્રોક્સી પાસે છે ચાર મુખ્ય પ્રકારો, જે એનજીઆઈએનએક્સ દ્વારા ઓફર કરાયેલા મુખ્ય ઈન્ફ્રાસ્ટ્રક્ચરને સમર્થન આપે છે. મુખ્ય છે:

• શ્રોતાઓ: તેઓ નક્કી કરે છે કે એન્વોય પ્રોક્સી ઇનકમિંગ વિનંતીઓ કેવી રીતે સ્વીકારે છે. એન્વોય પ્રોક્સી હાલમાં ફક્ત TCP-આધારિત શ્રોતાઓને જ સમર્થન આપે છે. એકવાર કનેક્શન સ્થાપિત થઈ જાય, તે પ્રક્રિયા માટે ફિલ્ટર્સના સમૂહમાં પસાર થાય છે.
• ફિલ્ટર્સ: તેઓ પાઇપલાઇન આર્કિટેક્ચરનો ભાગ છે જે ઇનકમિંગ અને આઉટગોઇંગ ડેટા પર પ્રક્રિયા કરી શકે છે. આ કાર્યક્ષમતામાં Gzip જેવા ફિલ્ટર્સનો સમાવેશ થાય છે, જે ક્લાયંટને મોકલતા પહેલા ડેટાને સંકુચિત કરે છે.
• રાઉટર્સ: તેઓ ક્લસ્ટર તરીકે વ્યાખ્યાયિત, આવશ્યક ગંતવ્ય પર ટ્રાફિકને આગળ ધપાવે છે.
• ક્લસ્ટરો: તેઓ ટ્રાફિક અને રૂપરેખાંકન પરિમાણો માટે અંતિમ બિંદુને વ્યાખ્યાયિત કરે છે.

અમે આ ચાર ઘટકોનો ઉપયોગ ચોક્કસ NGINX રૂપરેખાંકન સાથે મેળ કરવા માટે એન્વોય પ્રોક્સી રૂપરેખાંકન બનાવવા માટે કરીશું. દૂતનો ધ્યેય એપીઆઈ અને ગતિશીલ ગોઠવણી સાથે કામ કરવાનો છે. આ કિસ્સામાં, આધાર રૂપરેખાંકન NGINX થી સ્થિર, હાર્ડ-કોડેડ સેટિંગ્સનો ઉપયોગ કરશે.

પગલું 2 - NGINX રૂપરેખાંકન

પ્રથમ ભાગ nginx.conf કેટલાક NGINX ઇન્ટરનલ્સને વ્યાખ્યાયિત કરે છે જેને રૂપરેખાંકિત કરવાની જરૂર છે.

કામદાર જોડાણો

નીચેનું રૂપરેખાંકન કાર્યકર પ્રક્રિયાઓ અને જોડાણોની સંખ્યા નક્કી કરે છે. આ સૂચવે છે કે માંગને પહોંચી વળવા માટે NGINX કેવી રીતે સ્કેલ કરશે.

worker_processes  2;

events {
  worker_connections   2000;
}

એન્વોય પ્રોક્સી વર્કફ્લો અને કનેક્શનને અલગ અલગ રીતે મેનેજ કરે છે.

દૂત સિસ્ટમ પરના દરેક હાર્ડવેર થ્રેડ માટે વર્કર થ્રેડ બનાવે છે. દરેક વર્કર થ્રેડ બિન-અવરોધિત ઇવેન્ટ લૂપ ચલાવે છે જે માટે જવાબદાર છે

1. દરેક શ્રોતાની વાત સાંભળવી
2. નવા જોડાણો સ્વીકારી રહ્યા છીએ
3. કનેક્શન માટે ફિલ્ટર્સનો સમૂહ બનાવવો
4. કનેક્શનના જીવનકાળ દરમિયાન તમામ I/O કામગીરીની પ્રક્રિયા કરો.

આગળની તમામ કનેક્શન પ્રક્રિયાને વર્કર થ્રેડમાં સંપૂર્ણપણે હેન્ડલ કરવામાં આવે છે, જેમાં કોઈપણ ફોરવર્ડિંગ વર્તનનો સમાવેશ થાય છે.

એન્વોયમાં દરેક વર્કર થ્રેડ માટે, કનેક્શન પૂલ છે. તેથી HTTP/2 કનેક્શન પૂલ એક સમયે બાહ્ય હોસ્ટ દીઠ માત્ર એક કનેક્શન સ્થાપિત કરે છે, જો ચાર વર્કર થ્રેડો હોય તો સ્થિર સ્થિતિમાં બાહ્ય હોસ્ટ દીઠ ચાર HTTP/2 કનેક્શન હશે. દરેક વસ્તુને સિંગલ વર્કર થ્રેડમાં રાખીને, લગભગ તમામ કોડ બ્લોક કર્યા વિના લખી શકાય છે, જાણે કે તે સિંગલ થ્રેડેડ હોય. જો જરૂરી કરતાં વધુ વર્કર થ્રેડોની ફાળવણી કરવામાં આવે, તો આનાથી મેમરીનો વ્યય થઈ શકે છે, મોટી સંખ્યામાં નિષ્ક્રિય કનેક્શન્સનું નિર્માણ થઈ શકે છે, અને પુલમાં પાછા ફરતા જોડાણોની સંખ્યામાં ઘટાડો થઈ શકે છે.

વધુ માહિતી માટે મુલાકાત લો દૂત પ્રોક્સી બ્લોગ.

HTTP રૂપરેખાંકન

નીચેના NGINX રૂપરેખાંકન બ્લોક HTTP સેટિંગ્સને વ્યાખ્યાયિત કરે છે જેમ કે:

• કયા માઇમ પ્રકારો સપોર્ટેડ છે
• ડિફૉલ્ટ સમયસમાપ્તિ
• Gzip રૂપરેખાંકન

તમે એન્વોય પ્રોક્સીમાં ફિલ્ટર્સનો ઉપયોગ કરીને આ પાસાઓને કસ્ટમાઇઝ કરી શકો છો, જેની અમે પછીથી ચર્ચા કરીશું.

પગલું 3 - સર્વર રૂપરેખાંકન

HTTP રૂપરેખાંકન બ્લોકમાં, NGINX રૂપરેખાંકન પોર્ટ 8080 પર સાંભળવા અને ડોમેન્સ માટે આવનારી વિનંતીઓનો જવાબ આપવાનો ઉલ્લેખ કરે છે. one.example.com и www.one.example.com.

 server {
    listen        8080;
    server_name   one.example.com  www.one.example.com;

દૂતની અંદર, તે શ્રોતાઓ દ્વારા નિયંત્રિત થાય છે.

દૂત શ્રોતાઓ

એન્વોય પ્રોક્સી સાથે પ્રારંભ કરવાનું સૌથી મહત્વનું પાસું તમારા શ્રોતાઓને વ્યાખ્યાયિત કરવાનું છે. તમારે એક રૂપરેખાંકન ફાઇલ બનાવવાની જરૂર છે જે વર્ણવે છે કે તમે એન્વોય ઇન્સ્ટન્સ કેવી રીતે ચલાવવા માંગો છો.

નીચેનો સ્નિપેટ એક નવો શ્રોતા બનાવશે અને તેને પોર્ટ 8080 સાથે જોડશે. રૂપરેખાંકન એન્વોય પ્રોક્સીને કહે છે કે તેને આવનારી વિનંતીઓ માટે કયા પોર્ટ સાથે જોડવું જોઈએ.

એન્વોય પ્રોક્સી તેની ગોઠવણી માટે YAML નોટેશનનો ઉપયોગ કરે છે. આ નોટેશનના પરિચય માટે, અહીં જુઓ કડી.

Copy to Editorstatic_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }

વ્યાખ્યાયિત કરવાની જરૂર નથી સર્વર_નામ, કારણ કે એન્વોય પ્રોક્સી ફિલ્ટર્સ આને હેન્ડલ કરશે.

પગલું 4 - સ્થાન રૂપરેખાંકન

જ્યારે NGINX માં વિનંતી આવે છે, ત્યારે સ્થાન બ્લોક નક્કી કરે છે કે કેવી રીતે પ્રક્રિયા કરવી અને ટ્રાફિકને ક્યાં રૂટ કરવો. નીચેના ટુકડામાં, સાઇટ પરનો તમામ ટ્રાફિક અપસ્ટ્રીમ (અનુવાદકની નોંધ: અપસ્ટ્રીમ સામાન્ય રીતે એપ્લિકેશન સર્વર છે) નામના ક્લસ્ટરમાં સ્થાનાંતરિત થાય છે. લક્ષ્ય ક્લસ્ટર. અપસ્ટ્રીમ ક્લસ્ટર નોડ્સને વ્યાખ્યાયિત કરે છે જે વિનંતી પર પ્રક્રિયા કરવી જોઈએ. અમે આગળના પગલામાં આની ચર્ચા કરીશું.

location / {
    proxy_pass         http://targetCluster/;
    proxy_redirect     off;

    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
}

દૂત પર, ફિલ્ટર્સ આ કરે છે.

દૂત ફિલ્ટર્સ

સ્થિર રૂપરેખાંકન માટે, ફિલ્ટર્સ ઇનકમિંગ વિનંતીઓ પર કેવી રીતે પ્રક્રિયા કરવી તે નક્કી કરે છે. આ કિસ્સામાં અમે ફિલ્ટર્સ સેટ કરીએ છીએ જે મેચ કરે છે સર્વર_નામો પાછલા પગલામાં. જ્યારે ઇનકમિંગ વિનંતીઓ આવે છે જે ચોક્કસ ડોમેન્સ અને રૂટ્સ સાથે મેળ ખાતી હોય છે, ત્યારે ટ્રાફિકને ક્લસ્ટર તરફ રૂટ કરવામાં આવે છે. આ 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.router

ઇમા envoy.http_connection_manager એન્વોય પ્રોક્સીમાં બિલ્ટ-ઇન ફિલ્ટર છે. અન્ય ફિલ્ટર્સનો સમાવેશ થાય છે Redis, મોગો, ટીસીપી. તમે સંપૂર્ણ સૂચિ અહીં મેળવી શકો છો દસ્તાવેજીકરણ.

અન્ય લોડ બેલેન્સિંગ નીતિઓ વિશે વધુ માહિતી માટે, મુલાકાત લો રાજદૂત દસ્તાવેજીકરણ.

પગલું 5 - પ્રોક્સી અને અપસ્ટ્રીમ રૂપરેખાંકન

NGINX માં, અપસ્ટ્રીમ રૂપરેખાંકન લક્ષ્ય સર્વર્સના સમૂહને વ્યાખ્યાયિત કરે છે જે ટ્રાફિક પર પ્રક્રિયા કરશે. આ કિસ્સામાં, બે ક્લસ્ટર સોંપવામાં આવ્યા હતા.

  upstream targetCluster {
    172.18.0.3:80;
    172.18.0.4:80;
  }

એન્વોયમાં, આ ક્લસ્ટરો દ્વારા સંચાલિત થાય છે.

દૂત ક્લસ્ટરો

અપસ્ટ્રીમ સમકક્ષને ક્લસ્ટર તરીકે વ્યાખ્યાયિત કરવામાં આવે છે. આ કિસ્સામાં, જે યજમાનો ટ્રાફિકને સેવા આપશે તેમની ઓળખ કરવામાં આવી છે. યજમાનો જે રીતે એક્સેસ થાય છે, જેમ કે સમયસમાપ્તિ, ક્લસ્ટર રૂપરેખાંકન તરીકે વ્યાખ્યાયિત થયેલ છે. આ લેટન્સી અને લોડ બેલેન્સિંગ જેવા પાસાઓ પર વધુ દાણાદાર નિયંત્રણ માટે પરવાનગી આપે છે.

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 }}
    ]

સેવા શોધનો ઉપયોગ કરતી વખતે STRICT_DNS દૂત નિર્દિષ્ટ DNS લક્ષ્યાંકોને સતત અને અસુમેળ રીતે ઉકેલશે. DNS પરિણામમાંથી દરેક પરત કરાયેલ IP સરનામું અપસ્ટ્રીમ ક્લસ્ટરમાં સ્પષ્ટ હોસ્ટ તરીકે ગણવામાં આવશે. આનો અર્થ એ છે કે જો વિનંતી બે IP સરનામાઓ પરત કરે છે, તો દૂત ધારે છે કે ક્લસ્ટરમાં બે હોસ્ટ છે, અને બંને લોડ સંતુલિત હોવા જોઈએ. જો પરિણામમાંથી કોઈ યજમાનને દૂર કરવામાં આવે, તો રાજદૂત માની લેશે કે તે હવે અસ્તિત્વમાં નથી અને કોઈપણ હાલના કનેક્શન પૂલમાંથી ટ્રાફિક ખેંચી લેશે.

વધુ માહિતી માટે જુઓ દૂત પ્રોક્સી દસ્તાવેજીકરણ.

પગલું 6 - લોગ એક્સેસ અને ભૂલો

અંતિમ રૂપરેખાંકન નોંધણી છે. એરર લોગ્સને ડિસ્ક પર ધકેલવાને બદલે, એન્વોય પ્રોક્સી ક્લાઉડ-આધારિત અભિગમ અપનાવે છે. બધા એપ્લિકેશન લોગ્સ આઉટપુટ છે stdout и stderr.

જ્યારે વપરાશકર્તાઓ વિનંતી કરે છે, ત્યારે ઍક્સેસ લૉગ્સ વૈકલ્પિક હોય છે અને ડિફૉલ્ટ રૂપે અક્ષમ હોય છે. HTTP વિનંતીઓ માટે ઍક્સેસ લોગને સક્ષમ કરવા માટે, રૂપરેખાંકનને સક્ષમ કરો ઍક્સેસ_લોગ HTTP કનેક્શન મેનેજર માટે. પાથ કાં તો ઉપકરણ હોઈ શકે છે જેમ કે stdout, અથવા તમારી જરૂરિયાતોને આધારે ડિસ્ક પરની ફાઇલ.

નીચેનું રૂપરેખાંકન તમામ એક્સેસ લોગને રીડાયરેક્ટ કરશે stdout (અનુવાદકની નોંધ - ડોકરની અંદર દૂતનો ઉપયોગ કરવા માટે stdout જરૂરી છે. જો ડોકર વિના વપરાય છે, તો પછી /dev/stdout ને નિયમિત લોગ ફાઇલના પાથ સાથે બદલો). કનેક્શન મેનેજર માટે રૂપરેખાંકન વિભાગમાં સ્નિપેટની નકલ કરો:

Copy to Clipboardaccess_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"

પરિણામો આના જેવા દેખાવા જોઈએ:

      - 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:

ડિફૉલ્ટ રૂપે, દૂત પાસે એક ફોર્મેટ સ્ટ્રિંગ છે જેમાં 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

આ ફોર્મેટ સ્ટ્રિંગનું પરિણામ છે:

[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"

ફોર્મેટ ફીલ્ડ સેટ કરીને આઉટપુટ સામગ્રીને કસ્ટમાઇઝ કરી શકાય છે. દાખ્લા તરીકે:

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"

ફીલ્ડ સેટ કરીને લોગ લાઇન JSON ફોર્મેટમાં આઉટપુટ પણ થઈ શકે છે json_format. ઉદાહરણ તરીકે:

access_log:
- name: envoy.file_access_log
  config:
    path: "/dev/stdout"
    json_format: {"protocol": "%PROTOCOL%", "duration": "%DURATION%", "request_method": "%REQ(:METHOD)%"}

દૂત નોંધણી પદ્ધતિ વિશે વધુ માહિતી માટે, મુલાકાત લો

https://www.envoyproxy.io/docs/envoy/latest/configuration/access_log#config-access-log-format-dictionaries

એન્વોય પ્રોક્સી સાથે કામ કરવાની સમજ મેળવવાનો એકમાત્ર રસ્તો લોગિંગ નથી. તેમાં અદ્યતન ટ્રેસીંગ અને મેટ્રિક્સ ક્ષમતાઓ બિલ્ટ છે. તમે અહીં વધુ જાણી શકો છો ટ્રેસીંગ દસ્તાવેજીકરણ અથવા દ્વારા ઇન્ટરેક્ટિવ ટ્રેસિંગ સ્ક્રિપ્ટ.

પગલું 7 - લોંચ કરો

તમે હવે તમારું રૂપરેખાંકન NGINX થી Envoy Proxy માં સ્થાનાંતરિત કર્યું છે. છેલ્લું પગલું એ ચકાસવા માટે એન્વોય પ્રોક્સી દાખલો શરૂ કરવાનું છે.

વપરાશકર્તા તરીકે ચલાવો

NGINX રૂપરેખાંકન રેખાની ટોચ પર વપરાશકર્તા www www; સુરક્ષા સુધારવા માટે NGINX ને ઓછા વિશેષાધિકૃત વપરાશકર્તા તરીકે ચલાવવાનો ઉલ્લેખ કરે છે.

એન્વોય પ્રોક્સી પ્રક્રિયાની માલિકી કોણ છે તેનું સંચાલન કરવા માટે ક્લાઉડ-આધારિત અભિગમ અપનાવે છે. જ્યારે અમે કન્ટેનર દ્વારા એન્વોય પ્રોક્સી ચલાવીએ છીએ, ત્યારે અમે ઓછા વિશેષાધિકૃત વપરાશકર્તાનો ઉલ્લેખ કરી શકીએ છીએ.

એન્વોય પ્રોક્સી લોન્ચ કરી રહ્યું છે

નીચેનો આદેશ હોસ્ટ પર ડોકર કન્ટેનર દ્વારા એન્વોય પ્રોક્સીને ચલાવશે. આ આદેશ એન્વોયને પોર્ટ 80 પર આવનારી વિનંતીઓ સાંભળવાની ક્ષમતા આપે છે. જો કે, લિસનર રૂપરેખાંકનમાં સ્પષ્ટ કર્યા મુજબ, એન્વોય પ્રોક્સી પોર્ટ 8080 પર આવનારા ટ્રાફિકને સાંભળે છે. આ પ્રક્રિયાને ઓછા વિશેષાધિકૃત વપરાશકર્તા તરીકે ચલાવવાની મંજૂરી આપે છે.

docker run --name proxy1 -p 80:8080 --user 1000:1000 -v /root/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy

પરીક્ષણ

પ્રોક્સી ચાલુ હોવાથી, હવે પરીક્ષણો કરી શકાય છે અને પ્રક્રિયા કરી શકાય છે. નીચેનો cURL આદેશ પ્રોક્સી રૂપરેખાંકનમાં વ્યાખ્યાયિત હોસ્ટ હેડર સાથે વિનંતી કરે છે.

curl -H "Host: one.example.com" localhost -i

HTTP વિનંતી ભૂલમાં પરિણમશે 503. આ એટલા માટે છે કારણ કે અપસ્ટ્રીમ જોડાણો કામ કરી રહ્યાં નથી અને ઉપલબ્ધ નથી. તેથી, દૂત પ્રોક્સી પાસે વિનંતી માટે કોઈ ઉપલબ્ધ ગંતવ્ય નથી. નીચેનો આદેશ HTTP સેવાઓની શ્રેણી શરૂ કરશે જે એન્વોય માટે વ્યાખ્યાયિત રૂપરેખાંકન સાથે મેળ ખાય છે.

docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;

ઉપલબ્ધ સેવાઓ સાથે, દૂત સફળતાપૂર્વક તેના ગંતવ્ય સુધી ટ્રાફિકને પ્રોક્સી કરી શકે છે.

curl -H "Host: one.example.com" localhost -i

તમારે એક પ્રતિસાદ જોવો જોઈએ જે દર્શાવે છે કે કયા ડોકર કન્ટેનરએ વિનંતી પર પ્રક્રિયા કરી છે. એન્વોય પ્રોક્સી લોગમાં તમારે એક્સેસ સ્ટ્રિંગ આઉટપુટ પણ જોવું જોઈએ.

વધારાના HTTP પ્રતિભાવ હેડરો

તમે વાસ્તવિક વિનંતીના પ્રતિસાદ હેડરમાં વધારાના HTTP હેડરો જોશો. હેડર અપસ્ટ્રીમ હોસ્ટે વિનંતીની પ્રક્રિયા કરવામાં વિતાવેલો સમય દર્શાવે છે. મિલિસેકંડમાં વ્યક્ત. જો ક્લાયંટ નેટવર્ક લેટન્સીની તુલનામાં સેવાનો સમય નક્કી કરવા માંગે તો આ ઉપયોગી છે.

x-envoy-upstream-service-time: 0
server: envoy

અંતિમ રૂપરેખા

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 }

અનુવાદક પાસેથી વધારાની માહિતી

એન્વોય પ્રોક્સી ઇન્સ્ટોલ કરવા માટેની સૂચનાઓ વેબસાઇટ પર મળી શકે છે https://www.getenvoy.io/

મૂળભૂત રીતે, rpm પાસે systemd સેવા રૂપરેખા નથી.

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

તમારે ડિરેક્ટરી /etc/envoy/ બનાવવાની અને ત્યાં config.yaml રૂપરેખા મૂકવાની જરૂર છે.

દૂત પ્રોક્સીનો ઉપયોગ કરીને ટેલિગ્રામ ચેટ છે: https://t.me/envoyproxy_ru

દૂત પ્રોક્સી સ્ટેટિક કન્ટેન્ટને સેવા આપવાનું સમર્થન કરતું નથી. તેથી, આ સુવિધા માટે કોણ મત આપી શકે છે: https://github.com/envoyproxy/envoy/issues/378

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું આ પોસ્ટે તમને દૂત પ્રોક્સી ઇન્સ્ટોલ કરવા અને પરીક્ષણ કરવા માટે પ્રોત્સાહિત કર્યા છે?

• હા

• કોઈ

75 વપરાશકર્તાઓએ મતદાન કર્યું. 18 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com