მე გავაკეთე ჩემი PyPI საცავი ავტორიზაციით და S3. Nginx-ზე

ამ სტატიაში მინდა გავუზიარო ჩემი გამოცდილება NJS-ს, JavaScript-ის თარჯიმანს Nginx-ისთვის, რომელიც შემუშავებულია Nginx Inc-ის მიერ და აღწერს მის ძირითად შესაძლებლობებს რეალური მაგალითის გამოყენებით. NJS არის JavaScript-ის ქვეჯგუფი, რომელიც საშუალებას გაძლევთ გააფართოვოთ Nginx-ის ფუნქციონირება. კითხვაზე რატომ შენი საკუთარი თარჯიმანი??? დიმიტრი ვოლინცევმა დეტალურად უპასუხა. მოკლედ: NJS არის nginx-way, ხოლო JavaScript უფრო პროგრესული, „მშობლიური“ და GC-ის გარეშე, ლუასგან განსხვავებით.

Დიდი ხნის წინ…

ჩემს ბოლო სამუშაოზე მე მემკვიდრეობით მივიღე გიტლაბი მრავალი ჭრელი CI/CD მილსადენებით დოკერ-კომპოზით, დინდით და სხვა სიამოვნებით, რომლებიც გადავიდა კანიკოს რელსებზე. სურათები, რომლებიც ადრე გამოიყენებოდა CI-ში, გადავიდა თავდაპირველ ფორმაში. ისინი გამართულად მუშაობდნენ იმ დღემდე, როდესაც ჩვენი gitlab IP შეიცვალა და CI გოგრად გადაიქცა. პრობლემა ის იყო, რომ ერთ-ერთ დოკერ სურათს, რომელიც მონაწილეობდა CI-ში, გააჩნდა git, რომელმაც გაიყვანა Python მოდულები ssh-ის საშუალებით. ssh-სთვის გჭირდებათ პირადი გასაღები და... ეს იყო სურათზე ცნობილი_მასპინძლებთან ერთად. და ნებისმიერი CI ვერ მოხერხდა გასაღების გადამოწმების შეცდომით რეალურ IP-სა და ცნობილი_მასპინძლებში მითითებულს შორის შეუსაბამობის გამო. ახალი სურათი სწრაფად შეიკრიბა არსებული Dockfiles-დან და დაემატა ვარიანტი StrictHostKeyChecking no. მაგრამ ცუდი გემო დარჩა და გაჩნდა სურვილი, გადაეტანა ლიბები პირად PyPI საცავში. დამატებითი ბონუსი, პირად PyPI-ზე გადასვლის შემდეგ, იყო უფრო მარტივი მილსადენი და მოთხოვნების ნორმალური აღწერა.txt

არჩევანი გაკეთებულია, ბატონებო!

ჩვენ ყველაფერს ვაწარმოებთ ღრუბლებში და კუბერნეტებში და საბოლოოდ გვინდოდა მიგვეღო პატარა სერვისი, რომელიც იყო მოქალაქეობის არმქონე კონტეინერი გარე საცავებით. კარგი, რადგან ჩვენ ვიყენებთ S3-ს, პრიორიტეტი მას მიენიჭა. და, თუ შესაძლებელია, ავთენტიფიკაციით gitlab-ში (საჭიროების შემთხვევაში შეგიძლიათ თავად დაამატოთ).

სწრაფმა ძიებამ რამდენიმე შედეგი გამოიღო: s3pypi, pypicloud და ვარიანტი ტურნიკისთვის html ფაილების „ხელით“ შექმნით. ბოლო ვარიანტი თავისთავად გაქრა.

s3pypi: ეს არის კლიპი S3 ჰოსტინგის გამოყენებისთვის. ჩვენ ავტვირთავთ ფაილებს, ვაგენერირებთ html-ს და ვტვირთავთ იმავე თაიგულში. გამოდგება სახლის გამოყენებისთვის.

pypicloud: საინტერესო პროექტი ჩანდა, მაგრამ დოკუმენტაციის წაკითხვის შემდეგ იმედგაცრუებული დავრჩი. მიუხედავად კარგი დოკუმენტაციისა და თქვენი საჭიროებების შესაბამისად გაფართოების შესაძლებლობისა, სინამდვილეში აღმოჩნდა ზედმეტი და რთული კონფიგურაცია. თქვენი ამოცანების შესასრულებლად კოდის კორექტირება, იმდროინდელი შეფასებით, 3-5 დღე დასჭირდებოდა. სერვისს ასევე სჭირდება მონაცემთა ბაზა. სხვა რომ ვერაფერი ვიპოვნეთ, დავტოვეთ.

უფრო სიღრმისეული ძიებამ გამოიღო მოდული Nginx-ისთვის, ngx_aws_auth. მისი ტესტირების შედეგი იყო ბრაუზერში ნაჩვენები XML, რომელიც აჩვენებდა S3 თაიგულის შიგთავსს. ჩხრეკის დროს ბოლო ჩადენა ერთი წლის წინ იყო. საცავი მიტოვებული ჩანდა.

წყაროსთან მისვლით და წაკითხვით PEP-503 მივხვდი, რომ XML შეიძლება გადაიზარდოს HTML-ში და გადასცეს პიპს. Nginx-ისა და S3-ის შესახებ ცოტა მეტი გუგლის შემდეგ, შევხვდი S3-ში ავთენტიფიკაციის მაგალითს, რომელიც დაწერილია JS-ში Nginx-ისთვის. ასე გავიცანი NJS.

ამ მაგალითის საფუძველზე, ერთი საათის შემდეგ ჩემს ბრაუზერში ვნახე იგივე XML, როგორც ngx_aws_auth მოდულის გამოყენებისას, მაგრამ ყველაფერი უკვე დაწერილი იყო JS-ში.

ძალიან მომეწონა ნგინქსის ხსნარი. ჯერ ერთი, კარგი დოკუმენტაცია და მრავალი მაგალითი, მეორეც, ჩვენ ვიღებთ Nginx-ის ყველა სიკეთეს ფაილებთან მუშაობისთვის (გარემოდან), მესამე, ვინც იცის როგორ დაწეროს კონფიგურაციები Nginx-ისთვის, შეძლებს გაარკვიოს რა არის რა. მინიმალიზმი ჩემთვისაც პლიუსია პითონთან ან გოსთან შედარებით (თუ ნულიდან წერია), რომ აღარაფერი ვთქვათ ნექსუსზე.

TL;DR 2 დღის შემდეგ, PyPi-ს სატესტო ვერსია უკვე გამოიყენებოდა CI-ში.

როგორ მუშაობს იგი?

მოდული ჩატვირთულია Nginx-ში ngx_http_js_module, ჩართულია დოკერის ოფიციალურ სურათში. ჩვენ იმპორტირებს ჩვენს სკრიპტს დირექტივის გამოყენებით js_importNginx კონფიგურაციამდე. ფუნქციას ეწოდება დირექტივა js_content. დირექტივა გამოიყენება ცვლადების დასაყენებლად js_set, რომელიც არგუმენტად იღებს მხოლოდ სკრიპტში აღწერილ ფუნქციას. მაგრამ ჩვენ შეგვიძლია შევასრულოთ ქვემოკითხვები NJS-ში მხოლოდ Nginx-ის გამოყენებით და არა XMLHttpRequest-ის გამოყენებით. ამისათვის შესაბამისი მდებარეობა უნდა დაემატოს Nginx-ის კონფიგურაციას. და სკრიპტმა უნდა აღწეროს ქვემოთხოვნა ამ მდებარეობისთვის. Nginx კონფიგურაციიდან ფუნქციაზე წვდომისთვის, ფუნქციის სახელი უნდა იყოს ექსპორტირებული თავად სკრიპტში export default.

nginx.conf

load_module modules/ngx_http_js_module.so;
http {
  js_import   imported_name  from script.js;

server {
  listen 8080;
  ...
  location = /sub-query {
    internal;

    proxy_pass http://upstream;
  }

  location / {
    js_content imported_name.request;
  }
}

script.js

function request(r) {
  function call_back(resp) {
    // handler's code
    r.return(resp.status, resp.responseBody);
  }

  r.subrequest('/sub-query', { method: r.method }, call_back);
}

export default {request}

ბრაუზერში მოთხოვნისას http://localhost:8080/ შევდივართ location /რომელშიც დირექტივა js_content იძახებს ფუნქციას request აღწერილია ჩვენს სკრიპტში script.js. თავის მხრივ, ფუნქციაში request კეთდება ქვემოკითხვა location = /sub-query, არგუმენტიდან მიღებული მეთოდით (მიმდინარე მაგალითში GET). (r)ამ ფუნქციის გამოძახებისას ირიბად გავიდა. ქვემოთხოვნის პასუხი დამუშავდება ფუნქციაში call_back.

ვცდილობ S3-ს

პირადი S3 საცავისთვის მოთხოვნის გასაკეთებლად, ჩვენ გვჭირდება:

ACCESS_KEY

SECRET_KEY

S3_BUCKET

გამოყენებული http მეთოდიდან, მიმდინარე თარიღი/დრო, S3_NAME და URI, წარმოიქმნება გარკვეული ტიპის სტრიქონი, რომელიც ხელმოწერილია (HMAC_SHA1) SECRET_KEY-ის გამოყენებით. შემდეგი არის ხაზი მსგავსი AWS $ACCESS_KEY:$HASH, შეიძლება გამოყენებულ იქნას ავტორიზაციის სათაურში. იგივე თარიღი/დრო, რომელიც გამოყენებული იყო წინა ეტაპზე სტრიქონის გენერირებისთვის, უნდა დაემატოს სათაურს X-amz-date. კოდში ასე გამოიყურება:

nginx.conf

load_module modules/ngx_http_js_module.so;
http {
  js_import   s3      from     s3.js;

  js_set      $s3_datetime     s3.date_now;
  js_set      $s3_auth         s3.s3_sign;

server {
  listen 8080;
  ...
  location ~* /s3-query/(?<s3_path>.*) {
    internal;

    proxy_set_header    X-amz-date     $s3_datetime;
    proxy_set_header    Authorization  $s3_auth;

    proxy_pass          $s3_endpoint/$s3_path;
  }

  location ~ "^/(?<prefix>[w-]*)[/]?(?<postfix>[w-.]*)$" {
    js_content s3.request;
  }
}

s3.js(AWS Sign v2 ავტორიზაციის მაგალითი, შეიცვალა მოძველებული სტატუსით)

var crypt = require('crypto');

var s3_bucket = process.env.S3_BUCKET;
var s3_access_key = process.env.S3_ACCESS_KEY;
var s3_secret_key = process.env.S3_SECRET_KEY;
var _datetime = new Date().toISOString().replace(/[:-]|.d{3}/g, '');

function date_now() {
  return _datetime
}

function s3_sign(r) {
  var s2s = r.method + 'nnnn';

  s2s += `x-amz-date:${date_now()}n`;
  s2s += '/' + s3_bucket;
  s2s += r.uri.endsWith('/') ? '/' : r.variables.s3_path;

  return `AWS ${s3_access_key}:${crypt.createHmac('sha1', s3_secret_key).update(s2s).digest('base64')}`;
}

function request(r) {
  var v = r.variables;

  function call_back(resp) {
    r.return(resp.status, resp.responseBody);
  }

  var _subrequest_uri = r.uri;
  if (r.uri === '/') {
    // root
    _subrequest_uri = '/?delimiter=/';

  } else if (v.prefix !== '' && v.postfix === '') {
    // directory
    var slash = v.prefix.endsWith('/') ? '' : '/';
    _subrequest_uri = '/?prefix=' + v.prefix + slash;
  }

  r.subrequest(`/s3-query${_subrequest_uri}`, { method: r.method }, call_back);
}

export default {request, s3_sign, date_now}

ცოტა ახსნა იმის შესახებ _subrequest_uri: ეს არის ცვლადი, რომელიც, საწყისი ურიდან გამომდინარე, ქმნის მოთხოვნას S3-ზე. თუ თქვენ გჭირდებათ "root"-ის შინაარსის მიღება, მაშინ უნდა შექმნათ uri მოთხოვნა, რომელიც მიუთითებს დელიმიტერზე. delimiter, რომელიც დააბრუნებს ყველა CommonPrefixes xml ელემენტების სიას, რომელიც შეესაბამება დირექტორიაებს (PyPI-ს შემთხვევაში, ყველა პაკეტის სიას). თუ თქვენ გჭირდებათ შიგთავსების სიის მიღება კონკრეტულ დირექტორიაში (პაკეტის ყველა ვერსიის სია), მაშინ uri მოთხოვნა უნდა შეიცავდეს პრეფიქსის ველს დირექტორიის (პაკეტის) სახელწოდებით, რომელიც აუცილებლად მთავრდება ხაზებით /. წინააღმდეგ შემთხვევაში, შეჯახება შესაძლებელია, მაგალითად, დირექტორიაში შიგთავსის მოთხოვნისას. არის დირექტორიები aiohttp-მოთხოვნა და aiohttp-მოთხოვნები და თუ მოთხოვნა განსაზღვრავს /?prefix=aiohttp-request, მაშინ პასუხი შეიცავს ორივე დირექტორიის შინაარსს. თუ ბოლოში არის ხაზგასმა, /?prefix=aiohttp-request/, მაშინ პასუხი შეიცავს მხოლოდ საჭირო დირექტორიას. და თუ მოვითხოვთ ფაილს, მაშინ მიღებული ური არ უნდა განსხვავდებოდეს ორიგინალისგან.

შეინახეთ და გადატვირთეთ Nginx. ბრაუზერში ჩვენ ვწერთ ჩვენი Nginx-ის მისამართს, მოთხოვნის შედეგი იქნება XML, მაგალითად:

დირექტორიების სია

<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Name>myback-space</Name>
  <Prefix></Prefix>
  <Marker></Marker>
  <MaxKeys>10000</MaxKeys>
  <Delimiter>/</Delimiter>
  <IsTruncated>false</IsTruncated>
  <CommonPrefixes>
    <Prefix>new/</Prefix>
  </CommonPrefixes>
  <CommonPrefixes>
    <Prefix>old/</Prefix>
  </CommonPrefixes>
</ListBucketResult>

დირექტორიების სიიდან დაგჭირდებათ მხოლოდ ელემენტები CommonPrefixes.

ბრაუზერში ჩვენს მისამართზე საჭირო დირექტორიას დამატებით, ჩვენ ასევე მივიღებთ მის შიგთავსს XML სახით:

ფაილების სია დირექტორიაში

<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Name> myback-space</Name>
  <Prefix>old/</Prefix>
  <Marker></Marker>
  <MaxKeys>10000</MaxKeys>
  <Delimiter></Delimiter>
  <IsTruncated>false</IsTruncated>
  <Contents>
    <Key>old/giphy.mp4</Key>
    <LastModified>2020-08-21T20:27:46.000Z</LastModified>
    <ETag>&#34;00000000000000000000000000000000-1&#34;</ETag>
    <Size>1350084</Size>
    <Owner>
      <ID>02d6176db174dc93cb1b899f7c6078f08654445fe8cf1b6ce98d8855f66bdbf4</ID>
      <DisplayName></DisplayName>
    </Owner>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
  <Contents>
    <Key>old/hsd-k8s.jpg</Key>
    <LastModified>2020-08-31T16:40:01.000Z</LastModified>
    <ETag>&#34;b2d76df4aeb4493c5456366748218093&#34;</ETag>
    <Size>93183</Size>
    <Owner>
      <ID>02d6176db174dc93cb1b899f7c6078f08654445fe8cf1b6ce98d8855f66bdbf4</ID>
      <DisplayName></DisplayName>
    </Owner>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
</ListBucketResult>

ფაილების სიიდან ჩვენ ავიღებთ მხოლოდ ელემენტებს Key.

რჩება მხოლოდ მიღებული XML-ის გაანალიზება და HTML სახით გაგზავნა, მას შემდეგ, რაც ჯერ Content-Type სათაური ტექსტით/html-ით შეიცვალა.

function request(r) {
  var v = r.variables;

  function call_back(resp) {
    var body = resp.responseBody;

    if (r.method !== 'PUT' && resp.status < 400 && v.postfix === '') {
      r.headersOut['Content-Type'] = "text/html; charset=utf-8";
      body = toHTML(body);
    }

    r.return(resp.status, body);
  }
  
  var _subrequest_uri = r.uri;
  ...
}

function toHTML(xml_str) {
  var keysMap = {
    'CommonPrefixes': 'Prefix',
    'Contents': 'Key',
  };

  var pattern = `<k>(?<v>.*?)</k>`;
  var out = [];

  for(var group_key in keysMap) {
    var reS;
    var reGroup = new RegExp(pattern.replace(/k/g, group_key), 'g');

    while(reS = reGroup.exec(xml_str)) {
      var data = new RegExp(pattern.replace(/k/g, keysMap[group_key]), 'g');
      var reValue = data.exec(reS);
      var a_text = '';

      if (group_key === 'CommonPrefixes') {
        a_text = reValue.groups.v.replace(///g, '');
      } else {
        a_text = reValue.groups.v.split('/').slice(-1);
      }

      out.push(`<a href="/ka/${reValue.groups.v}">${a_text}</a>`);
    }
  }

  return '<html><body>n' + out.join('</br>n') + 'n</html></body>'
}

PyPI-ს მცდელობა

ჩვენ ვამოწმებთ, რომ არაფერი იშლება არსად იმ პაკეტებზე, რომლებიც ცნობილია, რომ მუშაობს.

# Создаем для тестов новое окружение
python3 -m venv venv
. ./venv/bin/activate

# Скачиваем рабочие пакеты.
pip download aiohttp

# Загружаем в приватную репу
for wheel in *.whl; do curl -T $wheel http://localhost:8080/${wheel%%-*}/$wheel; done

rm -f *.whl

# Устанавливаем из приватной репы
pip install aiohttp -i http://localhost:8080

ჩვენ ვიმეორებთ ჩვენი ლიბით.

# Создаем для тестов новое окружение
python3 -m venv venv
. ./venv/bin/activate

pip install setuptools wheel
python setup.py bdist_wheel
for wheel in dist/*.whl; do curl -T $wheel http://localhost:8080/${wheel%%-*}/$wheel; done

pip install our_pkg --extra-index-url http://localhost:8080

CI-ში პაკეტის შექმნა და ჩატვირთვა ასე გამოიყურება:

pip install setuptools wheel
python setup.py bdist_wheel

curl -sSfT dist/*.whl -u "gitlab-ci-token:${CI_JOB_TOKEN}" "https://pypi.our-domain.com/${CI_PROJECT_NAME}"

ავთენტიფიკაცია

Gitlab-ში შესაძლებელია JWT-ის გამოყენება გარე სერვისების ავთენტიფიკაციის/ავტორიზაციისთვის. Nginx-ში auth_request დირექტივის გამოყენებით, ჩვენ გადავიყვანთ ავთენტიფიკაციის მონაცემებს ქვემოთხოვნაზე, რომელიც შეიცავს ფუნქციის გამოძახებას სკრიპტში. სკრიპტი კიდევ ერთ ქვემოთხოვნას გაუკეთებს Gitlab url-ს და თუ ავთენტიფიკაციის მონაცემები სწორად იყო მითითებული, მაშინ Gitlab დააბრუნებს კოდს 200 და ნებადართული იქნება პაკეტის ატვირთვა/ჩამოტვირთვა. რატომ არ გამოიყენოთ ერთი ქვემოთხოვნა და დაუყოვნებლივ გაგზავნოთ მონაცემები Gitlab-ში? იმის გამო, რომ მაშინ ჩვენ მოგვიწევს Nginx-ის კონფიგურაციის ფაილის რედაქტირება ყოველ ჯერზე, როცა რაიმე ცვლილებას შევიტანთ ავტორიზაციაში და ეს საკმაოდ დამღლელი ამოცანაა. ასევე, თუ Kubernetes იყენებს მხოლოდ წასაკითხად root ფაილური სისტემის პოლიტიკას, მაშინ ეს კიდევ უფრო მეტ სირთულეს მატებს nginx.conf-ის ჩანაცვლებისას configmap-ით. და აბსოლუტურად შეუძლებელი ხდება Nginx-ის კონფიგურაცია configmap-ის საშუალებით, იმავდროულად, პოლიტიკის გამოყენებისას, რომელიც კრძალავს ტომების (pvc) და მხოლოდ წაკითხვადი root ფაილური სისტემის დაკავშირებას (ეს ასევე ხდება).

NJS შუალედურის გამოყენებით, ჩვენ ვიღებთ შესაძლებლობას შევცვალოთ მითითებული პარამეტრები nginx კონფიგურაციაში გარემოს ცვლადების გამოყენებით და გავაკეთოთ გარკვეული შემოწმება სკრიპტში (მაგალითად, არასწორად მითითებული URL).

nginx.conf

location = /auth-provider {
  internal;

  proxy_pass $auth_url;
}

location = /auth {
  internal;

  proxy_set_header Content-Length "";
  proxy_pass_request_body off;
  js_content auth.auth;
}

location ~ "^/(?<prefix>[w-]*)[/]?(?<postfix>[w-.]*)$" {
  auth_request /auth;

  js_content s3.request;
}

s3.js

var env = process.env;
var env_bool = new RegExp(/[Tt]rue|[Yy]es|[Oo]n|[TtYy]|1/);
var auth_disabled  = env_bool.test(env.DISABLE_AUTH);
var gitlab_url = env.AUTH_URL;

function url() {
  return `${gitlab_url}/jwt/auth?service=container_registry`
}

function auth(r) {
  if (auth_disabled) {
    r.return(202, '{"auth": "disabled"}');
    return null
  }

  r.subrequest('/auth-provider',
                {method: 'GET', body: ''},
                function(res) {
                  r.return(res.status, "");
                });
}

export default {auth, url}

დიდი ალბათობით ჩნდება კითხვა: -რატომ არ გამოიყენოთ მზა მოდულები? იქ უკვე ყველაფერი გაკეთდა! მაგალითად, var AWS = მოითხოვს ('aws-sdk') და არ არის საჭირო „ველოსიპედის“ დაწერა S3 ავთენტიფიკაციით!

მოდით გადავიდეთ მინუსებზე

ჩემთვის გარე JS მოდულების იმპორტის შეუძლებლობა გახდა უსიამოვნო, მაგრამ მოსალოდნელი ფუნქცია. ზემოთ მოყვანილ მაგალითში აღწერილი მოთხოვნა('კრიპტო') არის ჩაშენებული მოდულები და მოითხოვს მხოლოდ სამუშაოებს მათთვის. ასევე არ არსებობს სკრიპტებიდან კოდის ხელახლა გამოყენების საშუალება და თქვენ უნდა დააკოპიროთ და ჩასვათ იგი სხვადასხვა ფაილში. ვიმედოვნებ, რომ ოდესმე ეს ფუნქცია განხორციელდება.

შეკუმშვა ასევე უნდა იყოს გამორთული Nginx-ის მიმდინარე პროექტისთვის gzip off;

იმის გამო, რომ NJS-ში არ არის gzip მოდული და მისი დაკავშირება შეუძლებელია, შესაბამისად, შეკუმშულ მონაცემებთან მუშაობა არ არსებობს. მართალია, ეს ამ საქმის მინუსი ნამდვილად არ არის. ბევრი ტექსტი არ არის და გადაცემული ფაილები უკვე შეკუმშულია და დამატებითი შეკუმშვა მათ დიდად არ დაეხმარება. ასევე, ეს არ არის ისეთი დატვირთული ან კრიტიკული სერვისი, რომ მოგიწიოთ შეწუხება შინაარსის რამდენიმე მილიწამით სწრაფად მიწოდებით.

სკრიპტის გამართვას დიდი დრო სჭირდება და შესაძლებელია მხოლოდ error.log-ში „ბეჭდვის“ საშუალებით. დაყენებული ჟურნალის დონის ინფორმაციის, გაფრთხილების ან შეცდომის მიხედვით, შესაძლებელია გამოიყენოთ 3 მეთოდი, შესაბამისად, r.log, r.warn, r.error. ვცდილობ ზოგიერთი სკრიპტის გამართვას Chrome (v8) ან njs კონსოლის ხელსაწყოში, მაგრამ იქ ყველაფრის შემოწმება არ შეიძლება. კოდის გამართვისას, ანუ ფუნქციური ტესტირებისას, ისტორია ასე გამოიყურება:

docker-compose restart nginx
curl localhost:8080/
docker-compose logs --tail 10 nginx

და შეიძლება იყოს ასობით ასეთი თანმიმდევრობა.

მათთვის ქვემოკითხვებისა და ცვლადების გამოყენებით კოდის დაწერა ჩახლართულ აურზაურში იქცევა. ხანდახან იწყებ ჩქარობას სხვადასხვა IDE ფანჯრების გარშემო, რათა გაარკვიო შენი კოდის მოქმედებების თანმიმდევრობა. ეს არ არის რთული, მაგრამ ზოგჯერ ძალიან გამაღიზიანებელია.

ES6-ის სრული მხარდაჭერა არ არსებობს.

შეიძლება სხვა ხარვეზებიც იყოს, მაგრამ სხვა არაფერი შემხვედრია. გააზიარეთ ინფორმაცია, თუ გაქვთ NJS-ის გამოყენების უარყოფითი გამოცდილება.

დასკვნა

NJS არის მსუბუქი ღია კოდის თარჯიმანი, რომელიც საშუალებას გაძლევთ განახორციელოთ სხვადასხვა JavaScript სკრიპტები Nginx-ში. მისი განვითარების დროს დიდი ყურადღება დაეთმო შესრულებას. რა თქმა უნდა, ჯერ კიდევ ბევრი აკლია, მაგრამ პროექტს მცირე გუნდი ამუშავებს და აქტიურად ამატებენ ახალ ფუნქციებს და ასწორებენ შეცდომებს. ვიმედოვნებ, რომ ოდესმე NJS მოგცემთ საშუალებას დააკავშიროთ გარე მოდულები, რაც Nginx-ის ფუნქციონირებას თითქმის შეუზღუდავი გახდის. მაგრამ არსებობს NGINX Plus და, სავარაუდოდ, არ იქნება ფუნქციები!

საცავი სტატიის სრული კოდით

njs-pypi AWS Sign v4 მხარდაჭერით

ngx_http_js_module მოდულის დირექტივების აღწერა

ოფიციალური NJS საცავი и დოკუმენტაცია

NJS-ის გამოყენების მაგალითები დიმიტრი ვოლინცევისგან

njs - მშობლიური JavaScript სკრიპტირება nginx-ში / დიმიტრი ვოლნიევის გამოსვლა Saint HighLoad++ 2019 წელს

NJS წარმოებაში / ვასილი სოშნიკოვის გამოსვლა HighLoad++ 2019-ზე

REST მოთხოვნების ხელმოწერა და ავთენტიფიკაცია AWS-ში

წყარო: www.habr.com