Nginx ਤੋਂ ਦੂਤ ਪ੍ਰੌਕਸੀ ਤੱਕ ਪ੍ਰਵਾਸ

ਹੈਲੋ, ਹੈਬਰ! ਮੈਂ ਤੁਹਾਡੇ ਧਿਆਨ ਵਿੱਚ ਪੋਸਟ ਦਾ ਅਨੁਵਾਦ ਲਿਆਉਂਦਾ ਹਾਂ: Nginx ਤੋਂ ਦੂਤ ਪ੍ਰੌਕਸੀ ਤੱਕ ਪ੍ਰਵਾਸ.

ਦੂਤ ਇੱਕ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵੰਡਿਆ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਹੈ (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 ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਲਈ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ.

ਸਾਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੂਤ ਪ੍ਰੌਕਸੀ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਸੈਟਿੰਗਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਦੂਤ ਪ੍ਰੌਕਸੀ ਕੋਲ ਹੈ ਚਾਰ ਮੁੱਖ ਕਿਸਮ, ਜੋ ਕਿ NGINX ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਮੁੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਕੋਰ ਹੈ:

• ਸੁਣਨ ਵਾਲੇ: ਉਹ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਦੂਤ ਪ੍ਰੌਕਸੀ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਦੂਤ ਪ੍ਰੌਕਸੀ ਵਰਤਮਾਨ ਵਿੱਚ ਸਿਰਫ਼ TCP-ਅਧਾਰਿਤ ਸਰੋਤਿਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਇਸਨੂੰ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਫਿਲਟਰਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
• ਫਿਲਟਰ: ਉਹ ਪਾਈਪਲਾਈਨ ਆਰਕੀਟੈਕਚਰ ਦਾ ਹਿੱਸਾ ਹਨ ਜੋ ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਫਿਲਟਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜਿਵੇਂ ਕਿ Gzip, ਜੋ ਕਿ ਗਾਹਕ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।
• ਰਾਊਟਰ: ਉਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਲੋੜੀਂਦੇ ਮੰਜ਼ਿਲ 'ਤੇ ਭੇਜਦੇ ਹਨ, ਜਿਸ ਨੂੰ ਕਲੱਸਟਰ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• ਕਲੱਸਟਰ: ਉਹ ਟ੍ਰੈਫਿਕ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਅੰਤਮ ਬਿੰਦੂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਇਹਨਾਂ ਚਾਰ ਹਿੱਸਿਆਂ ਦੀ ਵਰਤੋਂ ਇੱਕ ਖਾਸ NGINX ਸੰਰਚਨਾ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਇੱਕ ਦੂਤ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਬਣਾਉਣ ਲਈ ਕਰਾਂਗੇ। ਦੂਤ ਦਾ ਟੀਚਾ API ਅਤੇ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਬੇਸ ਕੌਂਫਿਗਰੇਸ਼ਨ 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 ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਸਥਾਨ ਬਲਾਕ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਪ੍ਰਕਿਰਿਆ ਕਰਨੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿੱਥੇ ਰੂਟ ਕਰਨਾ ਹੈ। ਹੇਠਲੇ ਹਿੱਸੇ ਵਿੱਚ, ਸਾਈਟ ਦਾ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਇੱਕ ਅੱਪਸਟਰੀਮ (ਅਨੁਵਾਦਕ ਦਾ ਨੋਟ: ਅੱਪਸਟਰੀਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਹੁੰਦਾ ਹੈ) ਨਾਮਕ ਕਲੱਸਟਰ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। targetCluster. ਅੱਪਸਟ੍ਰੀਮ ਕਲੱਸਟਰ ਉਹਨਾਂ ਨੋਡਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਅਗਲੇ ਪੜਾਅ ਵਿੱਚ ਇਸ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ।

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 ਦੂਤ ਪ੍ਰੌਕਸੀ ਵਿੱਚ ਇੱਕ ਬਿਲਟ-ਇਨ ਫਿਲਟਰ ਹੈ। ਹੋਰ ਫਿਲਟਰ ਸ਼ਾਮਲ ਹਨ ਰੇਡਿਸ, ਮੌਗੋ, TCP. ਤੁਸੀਂ ਪੂਰੀ ਸੂਚੀ ਇੱਥੇ ਲੱਭ ਸਕਦੇ ਹੋ ਦਸਤਾਵੇਜ਼.

ਹੋਰ ਲੋਡ ਸੰਤੁਲਨ ਨੀਤੀਆਂ ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਲਈ, ਵੇਖੋ ਰਾਜਦੂਤ ਦਸਤਾਵੇਜ਼.

ਕਦਮ 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