ខ្ញុំបង្កើតឃ្លាំង PyPI ផ្ទាល់ខ្លួនរបស់ខ្ញុំដោយមានការអនុញ្ញាត និង S3 ។ នៅលើ Nginx

នៅក្នុងអត្ថបទនេះខ្ញុំចង់ចែករំលែកបទពិសោធន៍របស់ខ្ញុំជាមួយ NJS ដែលជាអ្នកបកប្រែ JavaScript សម្រាប់ Nginx ដែលបង្កើតឡើងដោយ Nginx Inc ដោយពណ៌នាអំពីសមត្ថភាពចម្បងរបស់វាដោយប្រើឧទាហរណ៍ជាក់ស្តែង។ NJS គឺជាសំណុំរងនៃ JavaScript ដែលអនុញ្ញាតឱ្យអ្នកពង្រីកមុខងាររបស់ Nginx ។ ទៅនឹងសំណួរ ហេតុអ្វីអ្នកបកប្រែខ្លួនឯង??? Dmitry Volyntsev បានឆ្លើយយ៉ាងលម្អិត។ និយាយឱ្យខ្លី៖ NJS គឺជាវិធី nginx ហើយ JavaScript កាន់តែរីកចម្រើន "ដើម" និងដោយគ្មាន GC មិនដូច Lua ។

ជា​យូរ​យា​ណាស់​មក​ហើយ…

នៅការងារចុងក្រោយរបស់ខ្ញុំ ខ្ញុំបានទទួលមរតក gitlab ជាមួយនឹងបំពង់ CI/CD motley ជាច្រើនជាមួយនឹង docker-compose, dind និងការរីករាយផ្សេងទៀត ដែលត្រូវបានផ្ទេរទៅ kaniko rails ។ រូបភាព​ដែល​ត្រូវ​បាន​ប្រើ​ពីមុន​ក្នុង CI ត្រូវ​បាន​ផ្លាស់ទី​ក្នុង​ទម្រង់​ដើម​របស់​ពួកគេ។ ពួកគេបានធ្វើការយ៉ាងត្រឹមត្រូវរហូតដល់ថ្ងៃដែល IP gitlab របស់យើងបានផ្លាស់ប្តូរ ហើយ CI ប្រែទៅជាល្ពៅ។ បញ្ហាគឺថារូបភាព docker មួយដែលបានចូលរួមក្នុង CI មាន git ដែលទាញម៉ូឌុល Python តាមរយៈ ssh ។ សម្រាប់ ssh អ្នក​ត្រូវ​ការ​សោឯកជន ហើយ... វា​មាន​នៅ​ក្នុង​រូបភាព​ជាមួយ​នឹង​ know_hosts ។ ហើយ CI ណាមួយបានបរាជ័យជាមួយនឹងកំហុសក្នុងការផ្ទៀងផ្ទាត់គន្លឹះដោយសារតែភាពមិនស៊ីគ្នារវាង IP ពិតប្រាកដ និងមួយដែលបានបញ្ជាក់នៅក្នុង know_hosts ។ រូបភាពថ្មីមួយត្រូវបានប្រមូលផ្តុំយ៉ាងឆាប់រហ័សពី Dockfiles ដែលមានស្រាប់ ហើយជម្រើសត្រូវបានបន្ថែម StrictHostKeyChecking no. ប៉ុន្តែរសជាតិមិនល្អនៅតែមាន ហើយមានបំណងប្រាថ្នាចង់ផ្លាស់ទី libs ទៅឃ្លាំង PyPI ឯកជន។ ប្រាក់រង្វាន់បន្ថែម បន្ទាប់ពីប្តូរទៅ PyPI ឯកជន គឺជាបំពង់ដែលងាយស្រួលជាង និងការពិពណ៌នាធម្មតានៃ requirement.txt

ជម្រើស​បាន​ធ្វើ​ហើយ​សុភាព​នារី!

យើងដំណើរការអ្វីគ្រប់យ៉ាងនៅក្នុងពពក និង Kubernetes ហើយនៅទីបញ្ចប់យើងចង់ទទួលបានសេវាកម្មតូចមួយដែលជាកុងតឺន័រដែលគ្មានរដ្ឋជាមួយនឹងកន្លែងផ្ទុកខាងក្រៅ។ ជាការប្រសើរណាស់, ចាប់តាំងពីយើងប្រើ S3, អាទិភាពត្រូវបានផ្តល់ទៅឱ្យវា។ ហើយប្រសិនបើអាចធ្វើទៅបាន ជាមួយនឹងការផ្ទៀងផ្ទាត់នៅក្នុង gitlab (អ្នកអាចបន្ថែមវាដោយខ្លួនឯងប្រសិនបើចាំបាច់) ។

ការស្វែងរករហ័សផ្តល់លទ្ធផលជាច្រើន៖ s3pypi, pypicloud និងជម្រើសជាមួយការបង្កើតឯកសារ html សម្រាប់ turnips "ដោយដៃ" ។ ជម្រើសចុងក្រោយបានបាត់ខ្លួន។

s3pypi៖ នេះគឺជា cli សម្រាប់ប្រើប្រាស់ S3 hosting។ យើងផ្ទុកឡើងឯកសារ បង្កើត html ហើយបង្ហោះវាទៅក្នុងធុងតែមួយ។ សាកសមសម្រាប់ការប្រើប្រាស់នៅផ្ទះ។

pypicloud៖ វាហាក់ដូចជាគម្រោងគួរឱ្យចាប់អារម្មណ៍មួយ ប៉ុន្តែបន្ទាប់ពីបានអានឯកសារ ខ្ញុំមានការខកចិត្ត។ ទោះបីជាមានឯកសារល្អ និងសមត្ថភាពក្នុងការពង្រីកឱ្យសមស្របទៅនឹងតម្រូវការរបស់អ្នកក៏ដោយ ប៉ុន្តែតាមពិតវាប្រែទៅជាលែងត្រូវការតទៅទៀត និងពិបាកក្នុងការកំណត់រចនាសម្ព័ន្ធ។ ការកែកូដឱ្យសមនឹងកិច្ចការរបស់អ្នក យោងទៅតាមការប៉ាន់ស្មាននៅពេលនោះនឹងចំណាយពេល 3-5 ថ្ងៃ។ សេវាកម្មក៏ត្រូវការមូលដ្ឋានទិន្នន័យផងដែរ។ យើងទុកវាចោល ក្នុងករណីដែលយើងរកមិនឃើញអ្វីផ្សេង។

ការស្វែងរកស៊ីជម្រៅបន្ថែមទៀតបានផ្តល់លទ្ធផលម៉ូឌុលសម្រាប់ Nginx, ngx_aws_auth ។ លទ្ធផលនៃការធ្វើតេស្តរបស់គាត់គឺ XML ត្រូវបានបង្ហាញនៅក្នុងកម្មវិធីរុករកដែលបង្ហាញពីមាតិកានៃធុង S3 ។ ការប្តេជ្ញាចិត្តចុងក្រោយនៅពេលនៃការស្វែងរកគឺកាលពីមួយឆ្នាំមុន។ ឃ្លាំងមើលទៅត្រូវគេបោះបង់ចោល។

ដោយចូលទៅកាន់ប្រភពនិងអាន ភី .១ ខ្ញុំបានដឹងថា XML អាចត្រូវបានបំប្លែងទៅជា HTML ភ្លាមៗ ហើយផ្តល់ទៅ pip ។ បន្ទាប់ពី googling បន្តិចបន្ថែមទៀតអំពី Nginx និង S3 ខ្ញុំបានឆ្លងកាត់ឧទាហរណ៍នៃការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៅក្នុង S3 ដែលបានសរសេរនៅក្នុង JS សម្រាប់ Nginx ។ នោះហើយជារបៀបដែលខ្ញុំបានជួប NJS ។

ដោយយកឧទាហរណ៍នេះជាមូលដ្ឋាន មួយម៉ោងក្រោយមកខ្ញុំបានឃើញនៅក្នុងកម្មវិធីរុករករបស់ខ្ញុំនូវ XML ដូចពេលប្រើម៉ូឌុល ngx_aws_auth ប៉ុន្តែអ្វីៗត្រូវបានសរសេររួចហើយនៅក្នុង JS ។

ខ្ញុំពិតជាចូលចិត្តដំណោះស្រាយ nginx ។ ទីមួយ ឯកសារល្អ និងឧទាហរណ៍ជាច្រើន ទីពីរ យើងទទួលបានអត្ថប្រយោជន៍ទាំងអស់របស់ Nginx សម្រាប់ធ្វើការជាមួយឯកសារ (ក្រៅប្រអប់) ទីបីអ្នកណាម្នាក់ដែលដឹងពីរបៀបសរសេរការកំណត់សម្រាប់ Nginx នឹងអាចដឹងថាតើជាអ្វី។ ភាពតូចតាចក៏ជាការបូកមួយសម្រាប់ខ្ញុំដែរ បើប្រៀបធៀបទៅនឹង Python ឬ Go (ប្រសិនបើសរសេរពីដើម) មិនត្រូវនិយាយពី nexus ទេ។

TL;DR បន្ទាប់ពី 2 ថ្ងៃ កំណែសាកល្បងនៃ PyPi ត្រូវបានប្រើប្រាស់រួចហើយនៅក្នុង CI ។

តើវាដំណើរការយ៉ាងដូចម្តេច?

ម៉ូឌុលត្រូវបានផ្ទុកទៅក្នុង Nginx ngx_http_js_moduleរួមបញ្ចូលនៅក្នុងរូបភាព docker ផ្លូវការ។ យើងនាំចូលស្គ្រីបរបស់យើងដោយប្រើការណែនាំ js_importទៅការកំណត់រចនាសម្ព័ន្ធ Nginx ។ មុខងារត្រូវបានហៅដោយការណែនាំ 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៖ នេះគឺជាអថេរដែលអាស្រ័យលើ uri ដំបូងបង្កើតសំណើទៅ S3 ។ ប្រសិនបើអ្នកត្រូវការទទួលបានមាតិកានៃ "root" នោះអ្នកត្រូវបង្កើតសំណើ uri ដែលបង្ហាញពីសញ្ញាកំណត់។ delimiterដែលនឹងត្រឡប់បញ្ជីនៃធាតុ CommonPrefixes xml ទាំងអស់ដែលត្រូវគ្នានឹងថត (ក្នុងករណី PyPI បញ្ជីកញ្ចប់ទាំងអស់)។ ប្រសិនបើអ្នកត្រូវការដើម្បីទទួលបានបញ្ជីនៃមាតិកានៅក្នុងថតជាក់លាក់មួយ (បញ្ជីនៃកំណែកញ្ចប់ទាំងអស់) នោះសំណើ uri ត្រូវតែមានវាលបុព្វបទដែលមានឈ្មោះនៃថត (កញ្ចប់) ចាំបាច់បញ្ចប់ដោយសញ្ញា/។ បើមិនដូច្នោះទេ ការប៉ះទង្គិចអាចធ្វើទៅបាននៅពេលស្នើសុំមាតិកានៃថតឯកសារ។ មានថត aiohttp-request និង aiohttp-requests ហើយប្រសិនបើសំណើបញ្ជាក់ /?prefix=aiohttp-requestបន្ទាប់មក ការឆ្លើយតបនឹងមានមាតិកានៃថតទាំងពីរ។ ប្រសិនបើមានសញ្ញានៅចុងបញ្ចប់។ /?prefix=aiohttp-request/បន្ទាប់មកការឆ្លើយតបនឹងមានតែថតដែលត្រូវការប៉ុណ្ណោះ។ ហើយប្រសិនបើយើងស្នើសុំឯកសារមួយ នោះ uri លទ្ធផលមិនគួរខុសពីឯកសារដើមទេ។

រក្សាទុក និងចាប់ផ្តើម 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 ជាដំបូងជាមួយ text/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="/km/${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

យើងធ្វើម្តងទៀតជាមួយ libs របស់យើង។

# Создаем для тестов новое окружение
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 សម្រាប់ការផ្ទៀងផ្ទាត់/ការអនុញ្ញាតសេវាកម្មខាងក្រៅ។ ដោយប្រើការណែនាំ auth_request នៅក្នុង Nginx យើងនឹងប្តូរទិសទិន្នន័យផ្ទៀងផ្ទាត់ទៅកាន់សំណើរងដែលមានការហៅមុខងារនៅក្នុងស្គ្រីប។ ស្គ្រីបនឹងធ្វើសំណើរងមួយទៀតទៅកាន់ url Gitlab ហើយប្រសិនបើទិន្នន័យផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវត្រូវបានបញ្ជាក់ត្រឹមត្រូវនោះ Gitlab នឹងត្រឡប់លេខកូដ 200 ហើយការបង្ហោះ/ទាញយកកញ្ចប់នឹងត្រូវបានអនុញ្ញាត។ ហេតុអ្វីមិនប្រើ subquery មួយ ហើយផ្ញើទិន្នន័យភ្លាមៗទៅ Gitlab? ដោយសារតែពេលនោះ យើងនឹងត្រូវកែសម្រួលឯកសារកំណត់រចនាសម្ព័ន្ធ Nginx រាល់ពេលដែលយើងធ្វើការផ្លាស់ប្តូរណាមួយក្នុងការអនុញ្ញាត ហើយនេះគឺជាកិច្ចការដ៏គួរឱ្យធុញទ្រាន់។ ផងដែរ ប្រសិនបើ Kubernetes ប្រើគោលការណ៍ប្រព័ន្ធឯកសារឫសបានតែអាន នោះវានឹងបន្ថែមភាពស្មុគស្មាញបន្ថែមទៀតនៅពេលជំនួស 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 = require('aws-sdk') ហើយមិនចាំបាច់សរសេរ “bike” ជាមួយនឹងការផ្ទៀងផ្ទាត់ S3 ទេ!

ចូរយើងបន្តទៅរកគុណវិបត្តិ

សម្រាប់ខ្ញុំ អសមត្ថភាពក្នុងការនាំចូលម៉ូឌុល JS ខាងក្រៅបានក្លាយជាមុខងារមិនសប្បាយចិត្ត ប៉ុន្តែរំពឹងទុក។ បានពិពណ៌នានៅក្នុងឧទាហរណ៍ខាងលើទាមទារ ('crypto') គឺ ម៉ូឌុលសាងសង់ ហើយត្រូវការតែការងារសម្រាប់ពួកគេ។ វាក៏មិនមានវិធីដើម្បីប្រើកូដឡើងវិញពីស្គ្រីបទេ ហើយអ្នកត្រូវចម្លង និងបិទភ្ជាប់វាទៅក្នុងឯកសារផ្សេងៗ។ ខ្ញុំសង្ឃឹមថាថ្ងៃណាមួយមុខងារនេះនឹងត្រូវបានអនុវត្ត។

ការបង្ហាប់ក៏ត្រូវតែបិទសម្រាប់គម្រោងបច្ចុប្បន្ននៅក្នុង Nginx ផងដែរ។ gzip off;

ដោយសារតែមិនមានម៉ូឌុល gzip នៅក្នុង NJS ហើយវាមិនអាចទៅរួចទេក្នុងការតភ្ជាប់វា ដូច្នេះហើយ វាមិនមានវិធីដើម្បីធ្វើការជាមួយទិន្នន័យដែលបានបង្ហាប់នោះទេ។ ពិត នេះមិនមែនជាការដកសម្រាប់ករណីនេះទេ។ មិនមានអត្ថបទច្រើនទេ ហើយឯកសារដែលបានផ្ទេរត្រូវបានបង្ហាប់រួចហើយ ហើយការបង្ហាប់បន្ថែមនឹងមិនជួយពួកគេច្រើនទេ។ ដូចគ្នានេះផងដែរ នេះមិនមែនជាសេវាកម្មដែលផ្ទុក ឬសំខាន់នោះទេ ដែលអ្នកត្រូវរំខានជាមួយនឹងការចែកចាយមាតិកាលឿនជាងពីរបីមិល្លីវិនាទី។

ការបំបាត់កំហុសស្គ្រីបចំណាយពេលយូរ ហើយអាចធ្វើទៅបានតែតាមរយៈ "ការបោះពុម្ព" នៅក្នុង 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

ហើយវាអាចមានរាប់រយលំដាប់។

ការសរសេរកូដដោយប្រើសំណួររង និងអថេរសម្រាប់ពួកវាប្រែទៅជា tangle tangle ។ ពេលខ្លះអ្នកចាប់ផ្តើមប្រញាប់ប្រញាល់ជុំវិញបង្អួច IDE ផ្សេងៗគ្នាដោយព្យាយាមស្វែងរកលំដាប់នៃសកម្មភាពនៃកូដរបស់អ្នក។ វាមិនពិបាកទេ ប៉ុន្តែពេលខ្លះវារំខានខ្លាំងណាស់។

មិនមានការគាំទ្រពេញលេញសម្រាប់ ES6 ទេ។

វា​អាច​នឹង​មាន​ចំណុច​ខ្វះខាត​មួយ​ចំនួន​ផ្សេង​ទៀត ប៉ុន្តែ​ខ្ញុំ​មិន​បាន​ជួប​ប្រទះ​អ្វី​ផ្សេង​ទៀត​ទេ។ ចែករំលែកព័ត៌មាន ប្រសិនបើអ្នកមានបទពិសោធន៍អវិជ្ជមានក្នុងការប្រើប្រាស់ NJS។

សេចក្តីសន្និដ្ឋាន

NJS គឺជាអ្នកបកប្រែប្រភពបើកចំហដែលមានទម្ងន់ស្រាលដែលអនុញ្ញាតឱ្យអ្នកអនុវត្តស្គ្រីប JavaScript ផ្សេងៗនៅក្នុង Nginx ។ ក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍របស់វា ការយកចិត្តទុកដាក់យ៉ាងខ្លាំងត្រូវបានយកចិត្តទុកដាក់ចំពោះការអនុវត្ត។ ជាការពិតណាស់ នៅមានចំណុចខ្វះខាតជាច្រើន ប៉ុន្តែគម្រោងនេះកំពុងត្រូវបានបង្កើតឡើងដោយក្រុមតូចមួយ ហើយពួកគេកំពុងបន្ថែមយ៉ាងសកម្មនូវមុខងារថ្មីៗ និងជួសជុលកំហុស។ ខ្ញុំសង្ឃឹមថាថ្ងៃណាមួយ NJS នឹងអនុញ្ញាតឱ្យអ្នកភ្ជាប់ម៉ូឌុលខាងក្រៅ ដែលនឹងធ្វើឱ្យមុខងារ Nginx ស្ទើរតែគ្មានដែនកំណត់។ ប៉ុន្តែមាន NGINX Plus ហើយទំនងជាមិនមានលក្ខណៈពិសេសទេ!

ឃ្លាំងដែលមានលេខកូដពេញលេញសម្រាប់អត្ថបទ

njs-pypi ជាមួយនឹងការគាំទ្រ AWS Sign v4

ការពិពណ៌នាអំពីការណែនាំនៃម៉ូឌុល ngx_http_js_module

ឃ្លាំង NJS ផ្លូវការ и ឯកសារ

ឧទាហរណ៍នៃការប្រើប្រាស់ NJS ពី Dmitry Volintsev

njs - ស្គ្រីប JavaScript ដើមនៅក្នុង nginx / សុន្ទរកថាដោយ Dmitry Volnyev នៅ Saint HighLoad++ 2019

NJS នៅក្នុងផលិតកម្ម / សុន្ទរកថាដោយ Vasily Soshnikov នៅ HighLoad++ 2019

ការចុះហត្ថលេខា និងផ្ទៀងផ្ទាត់សំណើ REST នៅក្នុង AWS

ប្រភព: www.habr.com