まえがき
私の所属する aslead DevOps チームでは GitLab や Nexus Repository Manager(以下、Nexusと記載する)、SonarQube を統合的にユーザへ提供することで、ユーザ(主に開発者)にとって高品質で生産性の高い開発を実現できるような基盤サービスを実現しています。
本記事では Sonatype 社の Nexus を多段構成にする取り組み を取り上げ
- なぜ多段構成にしたのか(背景)
- 多段構成にすることで何が得られたのか(効果)
を紹介します。
前提
環境情報
製品： Nexus Repository Manager (Sonatype 社が提供する Nexus Platform の一つの製品)
バージョン： 3.18.1
aslead DevOpsにおける Nexus の提供形態
- 利用する プロジェクト毎に Nexus 1インスタンス を提供している。(下図: nexus repository for Project A/B )
- プロジェクト毎にインスタンスを分けることで認証認可の範囲を明確にし、管理するリポジトリの参照を最小限に抑えている。
- プロジェクト毎にインスタンスを分けることで認証認可の範囲を明確にし、管理するリポジトリの参照を最小限に抑えている。
- プロジェクトのユーザ(開発者)は自分が所属するプロジェクトの Nexus にビルド成果物を格納したり、利用するモジュールをインターネットからダウンロードし参照したりすることで開発資材を管理する。基本的には GitLab CIの処理によって格納や参照を行う 。(下図: Direct CRUD modules or CRUD modules via GitLab CI )
今回の取り組み
背景
前提にて示した仕組みを用いてサービスを提供するなかでいくつかのプロジェクトから業務課題が共有されました。
その業務課題の一例を以下に示します。
- 業務課題
- セキュリティ要件が高いプロジェクトではインターネットから直接モジュールを取得することを禁止しており、プロジェクト支援者は担当する プロジェクトが変わるたびに手動でプロジェクト用の Nexus にモジュールを格納 している。
- 利用しているモジュールのバージョンが消去された場合に 開発しているシステムが依存解決できなくなり正常動作しなくなるリスク がある。
- 開発フレームワークの部品やサンプルアプリの ユーザ提供に社内ファイルサーバを利用しており、提供にリードタイム がある。
これらの課題を解決するために Nexus を多段構成にして提供することにしました。
多段構成の仕組み
Nexusを多段構成にする仕組みについてネットワーク構成と認可制御の2点に分けて説明します。
ネットワーク構成
多段構成では前提で示した図の構成とは異なり、下図に示すように各プロジェクトの Nexus から更に共通的な Nexus に接続する方式にしています。(下図: nexus repository for all projects )
我々はこの Nexus を Nexus社内共通リポジトリ と呼んでいます。
認可制御
Nexus社内共通リポジトリに各プロジェクト用のユーザを作成し、接続するリポジトリ(maven, npm, dockerなど)毎に どのプロジェクトがどのリポジトリにアクセス可能か を制御する。(下図: Project A User 及び Project B User )
たとえば、Project A の Nexus には docker リポジトリのアクセスを許可せず、maven や npm のみアクセスを許可する といった認可制御を Nexus社内共通リポジトリ 上のユーザへのロール付与によってコントロールする。
設定方法
上記の多段構成の仕組みを具体的に設定手順にすると以下の通りとなります。
- Nexus社内共通リポジトリ 側の対象リポジトリの Remote storage をインターネット上のリポジトリのURLにする。
- Nexus社内共通リポジトリ 側にプロジェクト用ユーザを作成し、手順1で設定した対象リポジトリの参照ロールを付与する。
- プロジェクト側の Nexus の対象リポジトリの Remote storage を Nexus社内共通リポジトリ側の対象リポジトリのURLにする。
- プロジェクト側の Nexus の対象リポジトリの HTTP Authentication に Nexus社内共通リポジトリ 上のプロジェクト用ユーザの認証情報を設定する。
多段構成により何が得られたのか
Nexus社内共通リポジトリを導入したことにより、以下の恩恵を受けることができました。
（１）プロジェクト支援者の負担減
業務課題1で挙げた通り、各プロジェクトの開発支援担当のライブラリ管理業務において 手動でインターネットから必要なモジュールを取得してプロジェクトの Nexus に格納していた業務を改善 し、Nexus社内共通リポジトリ 経由でモジュールを取得することが可能になりました。
（２）古いバージョンのモジュールを一時的に保持し、依存解決不可となるリスクを低減
古いバージョンのモジュールがインターネット上から削除されることにより、開発中のシステムがそのバージョンを利用していた場合、システム動作に影響するリスクがありました。これに対して Nexus社内共通リポジトリ を設けることで 一時的に古いバージョンのモジュールを保持し、安心して本格対応を検討できる ようになりました。
（３）開発フレームワーク(OWX)の部品やサンプルアプリを提供できる基盤を整備した
共通的に参照可能な Nexus を設けることで社内で多く利用される OWXという自社製開発フレームワークの部品やサンプルアプリを提供する基盤としても Nexus社内共通リポジトリ が利用できます 。（下図: OWX User の Upload および Project A, B User の Download ）
権限制御も可能であるため、Nexus社内共通リポジトリ のプロジェクト用ユーザの権限を制御することで開発フレームワークを利用するプロジェクトのみアクセス権限を付与することも可能になりました。
まとめ
今回、aslead DevOps が提供しているリポジトリ管理ツール Nexus の業務課題に対して、多段構成にすることで以下の通り課題を解消しました。
- (課題) セキュリティ要件が高いプロジェクトではインターネットから直接モジュールを取得することを禁止しており、プロジェクト支援者は担当する プロジェクトが変わるたびに手動でプロジェクト用の Nexus にモジュールを格納 している。
- (効果) 多段構成により Nexus社内共通リポジトリ に高頻度で利用するモジュールが格納されているため、セキュリティ要件の高いプロジェクトにおいても Nexus社内共通リポジトリ からモジュールを取得できるようになり、手動でプロジェクト用の Nexus に格納する手間が減った。
- (課題) 利用しているモジュールのバージョンが消去された場合に 開発しているシステムが依存解決できなくなり正常動作しなくなるリスク がある。
- (効果) Nexus社内共通リポジトリ経由でモジュールを取得することで、インターネット上から利用しているバージョンが削除されてもNexus社内共通リポジトリには残り続け、本格対応するためのワークアラウンドとして処置した。
- (課題) 開発フレームワークの部品やサンプルアプリの ユーザ提供に社内ファイルサーバを利用しており、提供にリードタイム がある。
- (効果) Nexus社内共通リポジトリ を用いることで、開発フレームワークの部品やサンプルアプリをユーザがファイルサーバにアクセスして取得する手間を省き、GitLab CI契機で取得できる環境を整備できた。
今後もユーザの業務課題に着目し、解決できるよう取り組んでいきます！
補足
- Nexus Platform には repository 以外にも lifecycle や firewall、auditor などのエコシステムがあります。