Sonatype Nexus Repository Managerのインストールをやってみた（2019年5月編）

Mavenやyum、npmなどのレポジトリマネージャーとして有名な『Sonatype Nexus Repository Manager』の導入方法についてやってみたので記載してみます。主にJavaなどのプロキシサーバとして利用することによって高速化を目的として設置する他、ビルド環境などとしても用いられる場合があります。（後者のほうが本来の用途ですが…）

今回、私が構築する理由は、最近プライベートでNode.jsを使った開発を行っているため、プロキシサーバ的な目的で利用してみます。利用した環境はVultrサービス上に構築した仮想マシン（CentOS 7）で、RAM2GBプラン（月額10ドルのもの）を利用しています。

手順

CentOS 7系のインスタンス（サーバ）を作成する
※ RAMが2GB未満である場合、動作しないため気をつける。Swap領域などでメモリの拡張はNG
※ 許容値を図っていないが、SonaType Nexus Repository Managerのみであれば1.2GBであるが、OSなど考えると2GB以上あったほうが良い。
サーバにログインし、ソフトウェアのインストール
Sonatype Nexus Repository Managerの展開・起動確認
サービスの登録

※ 慣れていればサービス化まで1時間程度で終わる

1. CentOS 7系のインストール（サーバ）を作成する

各種サービスから作成する。動作させるだけであれば、メモリ2GBで十分だが、人数など使用頻度によっては容量をアップする必要がある。

2. サーバにログインし、ソフトウェアのインストール

今回、サーバのセキュリティ設定などは割愛しますが、ある程度網羅しているのではないかと思っています。。（SSHの設定やファイアウォールの設定など）

1. epelレポジトリの追加

足りないモジュールなどがあったら行けないので、Epelレポジトリを追加します。（ある意味儀式的なものです）

$ sudo yum install -y epel-release

2. 開発者向けパッケージの追加

他の用途で利用することも踏まえ、developmentグループのパッケージを導入します。（これも儀式的なものです）

$ sudo yum group install -y development

3. OpenJDK 1.8.0 JREのインストール

今回はyumでもインストールができるOpenJDKを利用します。JDKインストール後、認識しているかjavaコマンドで確認します。

$ sudo yum install -y java-1.8.0-openjdk
$ java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
$

3. Sonatype Nexus Repository Managerの展開・起動確認

ソフトウェアの展開先は/opt以下を前提に説明を進める。また、本文書作成時の最新版（3.16.1-02）を前提に説明するが、バージョンが変更になった場合は読み替えてください。

1. Sonatype Nexus Repository Managerの取得

$ cd /opt
$ sudo wget https://download.sonatype.com/nexus/3/latest-unix.tar.gz

※ URLが利用できない場合はDownloadページを確認してください。

2. 展開

$ sudo tar -xzvf latest-unix.tar.gz
$ ls
nexus-3.16.1-02  sonatype-work

3. Sonatype Nexus Repository Managerを実行するユーザの追加・権限付与

ユーザの追加と権限の確認を行い、実行ユーザの設定を行う。その後、実際のサービスを起動します。
runでインストール完了したメッセージが表示された後に[IP]:8081で起動できているか確認を行います。（[IP]はホスト名でも可能）

$ sudo useradd nexus
$ sudo chown nexus.nexus -R nexus-3.16.1-02  sonatype-work
$ ls -la
drwxr-xr-x.  4 root  root  4096  5月 18 00:58 .
dr-xr-xr-x. 18 root  root  4096  5月 18 00:57 ..
drwxr-xr-x   9 nexus nexus 4096  5月 18 00:56 nexus-3.16.1-02
drwxr-xr-x   3 nexus nexus 4096  5月 18 00:56 sonatype-work
$ vi /opt/nexus-3.16.1-02/bin/nexus.rc
run_as_user="nexus"
cd /opt/nexus-3.16.1-02/bin
$ sudo ./nexus run
$ cd /opt

4. サービスの登録

バージョンアップにも耐えうる基盤にするため、シンボリックリンクを貼る。

$ sudo ln -s /opt/nexus-3.16.1-02 /opt/nexus

その上で、/etc/systemd/system/nexus.serviceを新規作成し、以下の内容を記述します。

 [Unit]
Description=nexus service
After=network.target

[Service]
Type=forking
ExecStart=/opt/nexus/bin/nexus start
ExecStop=/opt/nexus/bin/nexus stop
User=nexus
Restart=on-abort

[Install]
WantedBy=multi-user.target

実際にサービスとして動作しているか確認を行う。

$ sudo systemctl start nexus
$ sudo systemctl status nexus

まとめ

推奨スペックとして、RAM4GBなど記載されていたが、実際はシングルコア・RAM 2Gあれば動く模様。Vultr東京リージョンで確認済み。人数によっては性能を拡張する必要があるかもしれない。
- インストール失敗時の挙動がつかめないが、インストールが進まない場合は環境をリセットして実行したほうがはやい（かもしれない）
実際にJava実行環境を作成しようとすると苦しくなるのは事実であるが、OpenJDKなどパッケージマネージャーからインストールを行うことができれば苦労するポイントはそんなになさそう。（英語の読解力と慣れていれば）
そもそも個人でSonatype Nexus Repository ManagerをVPS上に構築するメリットはあまりないような気がするが、『メモリ不足でうまくいかない』事例に遭遇した。今までもRAM 1GBだと処理能力の限界があったことは薄々知っていたが、インストールや実行でコケるとは想定外であった。チューニングすればよいのかもしれないが、そこまでの読解する力（情熱）が足りず、デフォルト値での運用。
実運用を始める場合、AWSやAzureなど『データ転送量に比例して従量課金』のサービスでは金額が肥大化する恐れあり。このようなサービスの場合、ある程度利用者が把握できている場合はVPSやデータ転送量のしきい値があるサービスを利用すると安上がりなパターンが多い。今回利用したVultrはその良い例になるのではないか。（開発でガンガンプロキシを使う場合は右肩上がりになりやすい）
クラウドの『気軽にスケールアップ・ダウンしやすい』メリットがあるのかどうかは再考する余地がある。