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はその良い例になるのではないか。(開発でガンガンプロキシを使う場合は右肩上がりになりやすい)
クラウドの『気軽にスケールアップ・ダウンしやすい』メリットがあるのかどうかは再考する余地がある。