認可とS3を使用して独自のPyPIリポジトリを作成しました。 Nginx について

この記事では、Nginx Inc によって開発された Nginx 用の JavaScript インタープリターである NJS についての私の経験を共有し、実際の例を使用してその主な機能について説明したいと思います。 NJS は、Nginx の機能を拡張できる JavaScript のサブセットです。 質問に対して なぜあなた自身の通訳ですか？ ドミトリー・ヴォリンツェフが詳しく答えた。 つまり、NJS は nginx 方式であり、JavaScript はより進歩的で「ネイティブ」であり、Lua とは異なり GC がありません。

昔…

前の仕事で、docker-compose、dind、その他の機能を備えた多数の雑多な CI/CD パイプラインを含む gitlab を継承し、それらは kaniko Rails に転送されました。 以前CIで使用していた画像をそのまま移動しました。 これらは、gitlab IP が変更され、CI がカボチャに変わる日まで、正常に動作していました。 問題は、CI に参加する Docker イメージの XNUMX つが、ssh 経由で Python モジュールをプルする git を持っていたことでした。 SSH の場合は秘密キーが必要ですが、それは known_hosts とともにイメージ内にありました。 また、実際の IP と known_hosts で指定された IP の間の不一致により、CI はキー検証エラーで失敗しました。 新しいイメージが既存の Dockfile からすぐに組み立てられ、オプションが追加されました StrictHostKeyChecking no。 しかし、後味の悪さは依然として残っており、ライブラリをプライベート PyPI リポジトリに移動したいという要望がありました。 プライベート PyPI に切り替えた後の追加のボーナスは、より単純なパイプラインと、requirements.txt の通常の記述でした。

選択は決まりました、諸君！

私たちはすべてをクラウドと Kubernetes で実行しており、最終的には外部ストレージを備えたステートレス コンテナーである小規模なサービスを取得したいと考えていました。 まあ、S3を使っているのでそれを優先しました。 そして、可能であれば、gitlab での認証を使用します (必要に応じて自分で追加できます)。

簡単に検索すると、s3pypi、pypicloud、およびカブ用の HTML ファイルを「手動」で作成するオプションなど、いくつかの結果が得られました。 最後のオプションは自然に消えてしまいました。

s3pypi: これは、S3 ホスティングを使用するための CLI です。 ファイルをアップロードし、HTML を生成して、同じバケットにアップロードします。 家庭での使用に適しています。

pypicloud: 興味深いプロジェクトのように思えましたが、ドキュメントを読んだ後はがっかりしました。 優れたドキュメントとニーズに合わせて拡張できるにもかかわらず、実際には冗長で構成が難しいことが判明しました。 当時の見積もりによれば、タスクに合わせてコードを修正するには 3 ～ 5 日かかったでしょう。 このサービスにはデータベースも必要です。 他に何も見つからなかった場合に備えて、そのままにしておきました。

さらに詳しく検索すると、Nginx のモジュール ngx_aws_auth が見つかりました。 彼のテストの結果は、S3 バケットの内容を示す XML がブラウザに表示されました。 検索時の最後のコミットは XNUMX 年前でした。 リポジトリは放棄されたように見えました。

ソースにアクセスして読むことで、 PEP-503 XML をその場で HTML に変換して pip に渡すことができることに気付きました。 Nginx と S3 についてもう少し詳しく調べたところ、Nginx 用の JS で書かれた S3 での認証の例を見つけました。 それがNJSとの出会いでした。

この例をベースにすると、XNUMX 時間後に ngx_aws_auth モジュールを使用したときと同じ XML がブラウザに表示されましたが、すべてがすでに JS で記述されていました。

nginx ソリューションがとても気に入りました。 第一に、優れたドキュメントと多くの例があり、第二に、ファイルを操作するための Nginx の優れた機能がすべて (すぐに使える) 得られ、第三に、Nginx の構成の書き方を知っている人なら誰でも、何が何であるかを理解できるでしょう。 Nexus は言うまでもなく、Python や Go (ゼロから作成した場合) と比較しても、ミニマリズムは私にとってプラスです。

TL;DR 2 日後、PyPi のテスト バージョンはすでに CI で使用されていました。

それはどのように動作しますか？

モジュールがNginxにロードされる ngx_http_js_module、公式の docker イメージに含まれています。 ディレクティブを使用してスクリプトをインポートします js_importNginxの設定に変更します。 関数はディレクティブによって呼び出されます js_content。 ディレクティブは変数を設定するために使用されます js_set、スクリプトに記述されている関数のみを引数として受け取ります。 ただし、NJS でサブクエリを実行できるのは、XMLHttpRequest ではなく、Nginx を使用した場合のみです。 これを行うには、対応する場所を 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 から、特定の種類の文字列が生成され、SECRET_KEY を使用して署名 (HMAC_SHA1) されます。 次は次のような行です 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 へのリクエストを形成する変数です。 「ルート」の内容を取得する必要がある場合は、区切り文字を示す URI リクエストを作成する必要があります。 delimiterこれは、ディレクトリに対応するすべての CommonPrefixes xml 要素のリストを返します (PyPI の場合は、すべてのパッケージのリスト)。 特定のディレクトリ内のコンテンツのリスト (すべてのパッケージ バージョンのリスト) を取得する必要がある場合、uri リクエストには、ディレクトリ (パッケージ) の名前が必ずスラッシュ / で終わるプレフィックス フィールドが含まれている必要があります。 そうしないと、たとえばディレクトリのコンテンツをリクエストするときに衝突が発生する可能性があります。 aiohttp-request および aiohttp-requests ディレクトリがあり、リクエストで /?prefix=aiohttp-requestの場合、応答には両方のディレクトリの内容が含まれます。 末尾にスラッシュがある場合は、 /?prefix=aiohttp-request/の場合、応答には必要なディレクトリのみが含まれます。 ファイルをリクエストした場合、結果として得られる URI は元の 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 を解析し、まず Content-Type ヘッダーを text/html に置き換えて、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="/ja/${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 を返し、パッケージのアップロード/ダウンロードが許可されます。 XNUMX つのサブクエリを使用して、すぐにデータを Gitlab に送信してみてはいかがでしょうか? そうすると、認証に変更を加えるたびに Nginx 設定ファイルを編集する必要があり、これはかなり面倒な作業になるからです。 また、Kubernetes が読み取り専用のルート ファイルシステム ポリシーを使用している場合、configmap を介して nginx.conf を置き換えるときにさらに複雑さが増します。 そして、ボリューム (pvc) と読み取り専用のルート ファイルシステムの接続を禁止するポリシーを同時に使用しながら、configmap を介して Nginx を構成することは絶対に不可能になります (これも発生します)。

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') とすると、S3 認証を使用して「bike」を記述する必要はありません。

短所に移りましょう

私にとって、外部 JS モジュールをインポートできないことは不快ではありますが、期待されていた機能になりました。 上記の例で説明されている require('crypto') は 組み込みモジュール そして、require はそれらに対してのみ機能します。 また、スクリプトからコードを再利用する方法はなく、コードをコピーして別のファイルに貼り付ける必要があります。 いつかこの機能が実装されることを願っています。

Nginx の現在のプロジェクトでも圧縮を無効にする必要があります gzip off;

NJS には gzip モジュールがなく、接続できないため、圧縮データを扱う方法がありません。 確かに、この場合、これは実際にはマイナスではありません。 テキストの量はそれほど多くなく、転送されたファイルはすでに圧縮されており、追加の圧縮はあまり効果がありません。 また、これはコンテンツを数ミリ秒早く配信する必要があるほど負荷の高いサービスや重要なサービスではありません。

スクリプトのデバッグには長い時間がかかり、error.log の「出力」によってのみ可能です。 設定されたログレベル情報、警告またはエラーに応じて、それぞれ r.log、r.warn、r.error の 3 つのメソッドを使用できます。 Chrome (v8) または njs コンソール ツールでいくつかのスクリプトをデバッグしようとしましたが、そこですべてを確認できるわけではありません。 コードをデバッグするとき (別名機能テスト)、履歴は次のようになります。

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

そして、そのようなシーケンスは何百も存在する可能性があります。

サブクエリとその変数を使用してコードを記述すると、複雑なもつれが生じます。 場合によっては、コードの一連の動作を理解しようとして、さまざまな IDE ウィンドウを右往左往し始めることがあります。 難しいことではありませんが、非常に面倒な場合もあります。

ES6 は完全にはサポートされていません。

他にも欠点があるかもしれませんが、それ以外には何もありませんでした。 NJS を使用して否定的な経験がある場合は、情報を共有してください。

まとめ

NJS は、Nginx でさまざまな JavaScript スクリプトを実装できる軽量のオープンソース インタプリタです。 開発にあたっては、パフォーマンスに細心の注意が払われました。 もちろん、まだ足りない部分はたくさんありますが、このプロジェクトは少人数のチームによって開発されており、新機能の追加やバグの修正に積極的に取り組んでいます。 いつか NJS で外部モジュールを接続できるようになり、Nginx の機能がほぼ無制限になることを願っています。 ただし、NGINX Plus があるため、おそらく機能はありません。

記事の完全なコードを含むリポジトリ

AWS Sign v4 をサポートする njs-pypi

ngx_http_js_module モジュールのディレクティブの説明

NJS 公式リポジトリ и ドキュメント

Dmitry Volintsev による NJS の使用例

njs - nginx のネイティブ JavaScript スクリプト / Saint HighLoad++ 2019 でのドミトリー・ヴォルニエフ氏のスピーチ

NJS は実稼働中 / HighLoad++ 2019 でのヴァシリー・ソシニコフ氏のスピーチ

AWS での REST リクエストの署名と認証

出所： habr.com