JFrog（ジェイフロッグ）は、ArtifactoryがネイティブリポジトリータイプとしてLuaRocksをサポートするようになったと発表した。これにより、チームはプライベートなLuaRocksレジストリーからLuaモジュールをホストおよびプロキシーし、luarocksクライアントをArtifactoryに接続してネイティブなパッケージ管理エクスペリエンスを実現できる。この発表は、公開されているluarocks.orgレジストリーへの依存を回避し、本番環境で使用されるLuaパッケージに対して単一の管理されたエンドポイントを提供する方法として位置付けられた。
同社は、多くのチームが現在、ビルド時にパブリックレジストリーから直接パッケージをインストールしているが、この方法は可用性やパフォーマンスのリスクを招く可能性があると指摘した。よくある問題点として、外部レジストリーの障害や速度低下によるビルドやデプロイの遅延、共有キャッシュがないために各マシンから繰り返し行われる外部ダウンロード、中央リポジトリーではなくアドホックなストレージ場所に分散している内部パッケージやプラグインなどが挙げられる。
ArtifactoryのLuaRocksサポートは、Maven、npm、NuGetで既に採用されているおなじみの3つのリポジトリーモデルを踏襲している。つまり、ファーストパーティーのロックと内部プラグイン用のローカルリポジトリー、luarocks.orgからパッケージをプロキシーしてキャッシュするリモートリポジトリー、そしてローカル コンテンツとリモートコンテンツを単一のURLの下に統合する仮想リポジトリーだ。ドキュメントでは、クライアント設定を簡素化し、ローカルコンテンツとリモートコンテンツ間で異なるアクセス制御を適用するために、仮想リポジトリーの使用を推奨しているとのことだ。
エッジコンピューティングのユースケースが主な受益者として挙げられた。NGINXとOpenRestyのデプロイメントに関して、ブログでは、http、redis、openidcライブラリーなどのlua-resty-*モジュールをArtifactoryにキャッシュすることで、エッジ環境全体でのインストールがより迅速に完了し、一貫性が保たれると説明されている。チームは内部フォークをローカルリポジトリーに公開し、エッジノードをテスト済みのバージョンに固定することで、構成展開時のずれを軽減できるとのことだ。
Kongゲートウェイ環境は、もう一つの明確なユースケースとして説明された。LuaRocksロックとしてパッケージ化されたKongプラグインは、CIでビルドされ、Artifactoryのローカルリポジトリーに公開され、単一のバージョン管理されたソースから各Kongノードにインストールできる。また、OCIでパッケージ化されたKongプラグインはArtifactoryで引き続きサポートされるため、さまざまなパッケージングワークフローの柔軟性が維持され、手動によるファイル配布と比較してトレーサビリティーが向上することも説明された。
発表では、NGINX/OpenRestyおよびKongにおけるリクエストパスロジックでのLuaの役割が増大したことで、レジストリーの可用性とガバナンスの重要性が高まったことが強調された。LuaRocksをプライベートなキャッシュ型レジストリーに統合することで、Luaのパッケージ管理がMaven、npm、NuGet、Dockerで既に一般的になっているプライベートレジストリーの運用方法に合致し、Luaの成果物を単一の統制されたソフトウェアサプライチェーンに統合できるという。
Artifactory仮想リポジトリーからパッケージを解決するためにluarocksクライアントを使い始める方法や設定方法の詳細については、LuaRocksリポジトリーのドキュメントを参照するように推奨されている。
出典：JFrog
この製品の詳細については、JFrog製品ページをご覧ください。
