Направих моето PyPI хранилище с разрешение и S3. На Nginx

В тази статия бих искал да споделя опита си с NJS, JavaScript интерпретатор за Nginx, разработен от Nginx Inc, описвайки основните му възможности с помощта на реален пример. NJS е подмножество на JavaScript, което ви позволява да разширите функционалността на Nginx. На въпроса защо собствен преводач??? Дмитрий Волинцев отговори подробно. Накратко: NJS е nginx-way, а JavaScript е по-прогресивен, „роден“ и без GC, за разлика от Lua.

Преди много време…

На последната ми работа наследих gitlab с редица пъстри CI/CD конвейери с docker-compose, dind и други изкушения, които бяха прехвърлени към kaniko rails. Изображенията, използвани преди това в CI, бяха преместени в оригиналната им форма. Те работеха правилно до деня, когато нашият IP адрес на gitlab се промени и CI се превърна в тиква. Проблемът беше, че едно от докер изображенията, които участваха в CI, имаше git, който изтегля Python модули чрез ssh. За ssh ви трябва частен ключ и... беше в изображението заедно с unknown_hosts. И всеки CI се провали с грешка при проверка на ключ поради несъответствие между реалния IP и този, посочен в unknown_hosts. Ново изображение беше бързо сглобено от съществуващите Dockfiles и опцията беше добавена StrictHostKeyChecking no. Но лошият вкус остана и имаше желание библиотеките да се преместят в частно PyPI хранилище. Допълнителен бонус, след преминаване към частен PyPI, беше по-опростен конвейер и нормално описание на requirements.txt

Изборът е направен, господа!

Изпълняваме всичко в облаците и Kubernetes и в крайна сметка искахме да получим малка услуга, която беше контейнер без състояние с външно хранилище. Е, тъй като използваме S3, беше даден приоритет на него. И, ако е възможно, с удостоверяване в gitlab (можете да го добавите сами, ако е необходимо).

Бързо търсене даде няколко резултата: s3pypi, pypicloud и опция с „ръчно“ създаване на html файлове за ряпа. Последната опция изчезна от само себе си.

s3pypi: Това е cli за използване на S3 хостинг. Качваме файловете, генерираме html и го качваме в същата кофа. Подходящ за домашна употреба.

pypicloud: Изглеждаше като интересен проект, но след като прочетох документацията бях разочарован. Въпреки добрата документация и възможността за разширяване според вашите нужди, в действителност се оказа излишен и труден за конфигуриране. Коригирането на кода, за да отговаря на вашите задачи, според тогавашните оценки, би отнело 3-5 дни. Услугата се нуждае и от база данни. Оставихме го, в случай че не намерим нищо друго.

По-задълбочено търсене даде модул за Nginx, ngx_aws_auth. Резултатът от неговото тестване беше XML, показан в браузъра, който показваше съдържанието на кофата S3. Последният ангажимент по време на търсенето беше преди година. Хранилището изглеждаше изоставено.

Като отидете до източника и прочетете РЕР-503 Разбрах, че XML може да се конвертира в HTML в движение и да се даде на pip. След като потърсих в Google малко повече за 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, включен в официалния докер образ. Ние импортираме нашия скрипт с помощта на директивата 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="/bg/${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 за удостоверяване/упълномощаване на външни услуги. Използвайки директивата auth_request в Nginx, ще пренасочим данните за удостоверяване към подзаявка, съдържаща извикване на функция в скрипта. Скриптът ще направи друга подзаявка към URL адреса на Gitlab и ако данните за удостоверяване са посочени правилно, тогава Gitlab ще върне код 200 и качването/изтеглянето на пакета ще бъде разрешено. Защо не използвате една подзаявка и незабавно изпратите данните на 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 модули стана неприятна, но очаквана функция. Описаното в примера по-горе require('crypto') е вградени модули и изискват само произведения за тях. Също така няма начин да използвате повторно код от скриптове и трябва да го копирате и поставите в различни файлове. Надявам се, че някой ден тази функционалност ще бъде внедрена.

Компресията също трябва да бъде деактивирана за текущия проект в 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