4 Archiva Mavenリポジトリ・マネージャのインストールおよび構成
Mavenリポジトリ・マネージャまたはアーティファクト・リポジトリについて精通していない場合は、Archivaを使用したリポジトリ管理を参照してください。
Archiva(この章で説明)およびMaven(「ビルド自動化と依存性管理のためのMavenのインストールおよび構成」で説明)のインストールおよび構成を完了した後で、Oracle提供のアーティファクトをArchivaリポジトリに移入します。詳細は、Mavenリポジトリ・マネージャへの移入を参照してください。
トピック:
- Archivaの概要
Archivaは、スタンドアロン・インストールとしてJettyにバンドルされて配布されます。WARファイル配布も提供されるため、Archivaを既存のアプリケーション・サーバーにインストールできます。 - Archivaのダウンロード
スタンドアロンArchivaの最新リリースは、.zip
ファイルかtar.gz
ファイルの形式でダウンロードできます。 - Archivaのインストール
Archivaをインストールするには、配布をターゲット・インストール・ディレクトリに解凍します。この場所は、プリファレンスおよびターゲット・オペレーテイング・システムによって異なります。 - Archivaの構成
この項では、Archivaの構成方法について、一般的な説明だけでなく、Oracle Fusion Middleware環境で使用するための具体的な構成についてもいくつか説明します。 - Archivaの詳細
Archivaユーザー・ガイドには、Archivaの詳細な情報が掲載されています。 - Mavenリポジトリ・マネージャ管理について
Mavenリポジトリ・マネージャを管理するには、スナップショット・オプションを理解して使用し、保存オプションを設定して、Archivaをバックアップする必要があります
Archivaの概要
Archivaは、スタンドアロン・インストールとしてJettyにバンドルされて配布されます。WARファイル配布も提供されるため、Archivaを既存のアプリケーション・サーバーにインストールできます。
この章では、スタンドアロン・バージョンのインストール・プロセスについて説明します。WARファイルのインストールおよび構成に関する指示は、次の場所にある公式Archivaドキュメントで提供されています。
Archivaのインストール
Archivaをインストールするには、配布をターゲット・インストール・ディレクトリに解凍します。この場所は、プリファレンスおよびターゲット・オペレーテイング・システムによって異なります。
継続的インテグレーション関連のワークスペース用に共通の場所を作成することをお薦めします。たとえば、次の場所に配布を解凍します。
/ciroot/archiva
-
Linuxの場合
次のコマンドを実行します。
sudo mkdir -p /ciroot/archiva ; sudo tar xzvf apache-archiva-1.3.6-bin.tar.gz --strip-components 1 -C /ciroot/archiva
コマンドを実行した後、自分のユーザーおよびグループに一致するようにファイルの所有者を変更する必要があります。たとえば、
oracle
をユーザーIDとして使用し、oracle
をグループ名として使用している場合は、次のコマンドを実行します。chown -R oracle:oracle /ciroot/archiva
-
Windowsの場合
次のように、Archivaインストール・ファイルを作成するためのディレクトリを作成します。
mkdir c:\ciroot\archiva
ダウンロードしたArchiva zipファイルを新しいディレクトリに抽出します。
Archivaの構成
この項では、Archivaの構成方法について、一般的な説明だけでなく、Oracle Fusion Middleware環境で使用するための具体的な構成についてもいくつか説明します。
この項では、次の項目について説明します。
サーバーの構成
Archiva Jettyインスタンスは、デフォルトHTTPポートの8080
で起動します。ポートを変更する場合は、/ciroot/archiva/conf/jetty.xml
を変更します。次のように、jetty.port
のコネクタ構成のSystemProperty
値を異なる値(8081など)に変更します。
<Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="host"> <SystemProperty name="jetty.host"/> </Set> <Set name="port"> <SystemProperty name="jetty.port" default="8081"/> </Set>
親トピック: Archivaの構成
サーバーの起動
サーバーを構成した後は、そのサーバーをコマンドライン・インタフェースから起動できます。
起動タスクが完了すると、Archivaサーバーは次の場所で使用可能になります。
http://localhost:8081
親トピック: Archivaの構成
管理者ユーザーの作成
Archivaホーム・ページに最初にアクセスすると、管理者パスワードを設定するよう求められます。管理者ユーザーのフルネーム、電子メール・アドレスおよびパスワードを指定します。
親トピック: Archivaの構成
内部リポジトリおよびスナップショット・リポジトリについて
Archivaは、ホストされている構成済の次の2つのリポジトリで起動します。
-
内部
内部リポジトリは、組織によってデプロイされた固定バージョンのリリース・アーティファクトを保持するリポジトリであり、完了バージョンのアーティファクト、開発されなくなったバージョン、およびリリース済のバージョンが含まれます。同じアーティファクトの開発中バージョンがスナップショット・リポジトリに今後存在する可能性があることに注意してください。
-
スナップショット
スナップショット・リポジトリでは、接尾辞
SNAPSHOT
が付いたバージョンとして示される作業中のアーティファクト、およびまだリリースされていないアーティファクトが保持されます。
親トピック: Archivaの構成
プロキシ・リポジトリについて
内部リポジトリは、内部的にデプロイされたアーティファクトのホスティングに加えて、パブリックMaven中央リポジトリとして機能するようにデフォルトで構成されます。プロキシ・リポジトリは、サード・パーティのリポジトリを直接参照するかわりに使用できます。プロキシでは、前に要求されたアーティファクトがローカルにキャッシュされます。これにより、共有サーバーでの負荷が軽減されるため、空のリポジトリからビルドを実行する場合は特に推奨される方法です。共有サーバーに負荷をかけすぎると、ホストからの追加要求が抑制されたり禁止される場合があります。ビルド・パフォーマンスを大幅に向上させるには、負荷が少ない近接のプロキシ・サーバーから依存性をフェッチします。
他のパブリック・リポジトリからのサード・パーティ・アーティファクトが必要な場合は、それらを追加のプロキシ・コネクタとして自分のリポジトリに追加します。
親トピック: Archivaの構成
ミラー・リポジトリの構成
通常はキャッシュされたサード・パーティのプロキシ・アーティファクトを複数のリポジトリ間で共有する必要があるため、キャッシュされたアーティファクトを個別のリポジトリに移動して、プロジェクト・アーティファクトから分離します。
ミラー・リポジトリを作成および構成するには:
-
プロキシ接続を内部リポジトリから削除します。
-
「Administration」メニューで、「Proxy Connections」をクリックします。
-
各エントリの赤いXをクリックして、「Central Repository」および「maven2-repository.dev.java.net」プロキシ・コネクタを削除します。
-
-
新しいミラー・リポジトリを追加します。
-
「Administration」メニューで、「Repositories」をクリックします。
-
右上隅にある「Add」をクリックします。
-
「Admin: Add Managed Repository」ダイアログ・ボックスで、次の情報を指定します。
-
Identifier: mirror
-
Name: Mirror
-
Directory:
/ciroot/archiva/data/repositories/mirror
-
「Releases Included」、「Block Re-deployment of Released Artifacts」および「Scannable」を選択します。
-
-
「Add Repository」をクリックします。
-
-
プロキシ・コネクタをミラー・リポジトリに追加します。
-
「Administration」メニューで、「Proxy Connections」をクリックします。
-
「Add」をクリックします。
-
「Managed Repository」で「mirror」を選択します。
-
「Remote Repository」で「central」を選択します。
-
「Add Proxy Connector」をクリックします。
これらのステップを完了すると、次のように表示されます。
-
-
新しいリポジトリの読取り権限を付与するように匿名ゲスト・ユーザーを構成するには:
-
「Management」メニューで、「User Management」をクリックします。
-
「Guest」をクリックします。
-
「Edit Roles」をクリックします。
-
「mirror」の横の「Repository Observer」ロールを選択します。
-
「送信」をクリックして変更を保存します。
-
ミラー・リポジトリをリモート・リポジトリに構成する場合は、ステップ1から3を完了します。ただし、ステップ1-bでは「maven2-repository.dev.java.net」を選択します。
親トピック: Archivaの構成
開発、本番、品質保証およびテストのリポジトリの作成
Mavenビルドで対象とするOracle Fusion Middleware環境ごとに個別のリポジトリを作成する必要があります。Oracleによる個別パッチ適用(パッチ適用の予備知識を参照)のサポートとは、バージョンが同じであるが、適用されている個別パッチが異なるため一部のファイルが異なるという、2つの異なる環境(本番とテストなど)を使用できることを意味します。
Mavenビルドで適切なバージョンのファイルを使用するには、各ターゲット環境にグループMavenリポジトリを作成および構成します。
-
次のようにリポジトリを作成します。
-
「Administration」メニューで、「Repositories」をクリックします。
-
新しいリポジトリを追加するには、右上隅にある「Add」をクリックします。
-
「Admin: Add Managed Repository」ダイアログ・ボックスで、次の詳細情報を指定します。
-
Identifier:
dev
、prod
、qa
、test
などの識別子を指定します。 -
Name: 名前を指定します。
-
Directory:
/ciroot/archiva/data/repositories/${
IDENTIFIER
}
などのディレクトリ・パスを追加します(ここで、${
IDENTIFIER
}
は、「Identifier」で指定した文字列と一致します)。 -
「Block Re-deployment of Released Artifacts」を選択解除します。
-
「Releases Included」および「Scannable」を選択します。
-
-
「Add Repository」をクリックします。
-
-
新しいリポジトリの読取り権限を付与するように匿名ゲスト・ユーザーを構成するには:
-
「Manage」で、「User Management」をクリックします。
-
「guest」を選択します。
-
「Edit Roles」を選択します。
-
該当するリポジトリ・エントリの横にある「Repository Observer」ロールを選択します。
-
「送信」をクリックして変更を保存します。
-
-
新しいリポジトリに対応するグループを作成するには:
-
「Administration」メニューから、「Repository Groups」をクリックします。
-
右上隅にある「Add Group」をクリックします。
-
「Identifier」フィールドで、作成したリポジトリと一致する名前に-groupを付けて(dev-groupなど)指定します。
-
「Add Group」をクリックします。
-
「Add Repository」の横にあるドロップダウン・メニューから新しいリポジトリ(devなど)を選択し、「Add Repository」をクリックします。
ステップ3-aから3-dまでを繰り返し、mirrorおよびsnapshotsを追加します。
次の図は、「Repository Groups」ページを示しています。
-
-
リポジトリとグループの作成ステップ1から3を、リポジトリ・タイプ(test、qaおよびprod)ごとに繰り返します。
親トピック: Archivaの構成
デプロイメント可能ユーザーの作成
内部リポジトリへのデプロイメントをサポートするには、適切な権限を持つユーザーを少なくとも1人は追加する必要があります。
- 「Management」で、「User Management」をクリックします。
- 「Create New User」をクリックして、ユーザーを追加します。次に、名前、メール・アドレス、パスワードなどの必要な詳細を指定します。ユーザーが追加されると、そのユーザーの「Role Administration」ダイアログ・ボックスが表示されます。
- 「Role Administration」ダイアログ・ボックスの「Resource Roles」で、「Snapshot」および「Internal Repositories」に対して「Repository Manager」ロールを選択します。
- 「送信」をクリックして変更を保存します。
ノート:
Repository Managerロールでは、アーティファクトをアップロードできるだけでなく、リポジトリ構成を変更することもできます。
ロールをカスタマイズまたは変更するには、「User Roles」セクションで、より制限された新しいロールを追加し、それを該当するユーザーに割り当てます。
通常、リポジトリへのアクセス権を持つ各個人用に新しいユーザーを作成します。Hudsonの場合、リポジトリへのビルド出力を公開するには、リポジトリにアクセスする各ユーザーは独自のユーザーIDを持つ必要があり、デプロイ権限を持つ追加ユーザーの作成も必要となります。
Archiva(この章で説明)およびMaven(「ビルド自動化と依存性管理のためのMavenのインストールおよび構成」で説明)のインストールおよび構成を完了した後で、Mavenリポジトリ・マネージャへの移入の説明に従ってOracle提供のアーティファクトをArchivaリポジトリに移入します。
親トピック: Archivaの構成
Archivaの詳細
Archivaユーザー・ガイドには、Archivaの詳細な情報が掲載されています。
Archiva 1.3.6のユーザー・ガイドは、次の場所にあります。
http://archiva.apache.org/docs/1.3.6/userguide/
その他のリリースについては、次に示すArchivaホーム・ページで参照できます。
Mavenリポジトリ・マネージャ管理について
Mavenリポジトリ・マネージャを管理するには、スナップショット・オプションを理解して使用し、保存オプションを設定して、Archivaをバックアップする必要があります。
この項では、次の項目について説明します。
スナップショット・クリーンアップの理解
Archivaは、正常にデプロイされたジョブごとに特定のスナップショット・バージョン・アーティファクトのインスタンスを保持します。スナップショット・アーティファクトを要求すると、最新のスナップショットが取得されます。Mavenでは、リポジトリ内の関連するメタデータを調べて、ダウンロードする適切なコピーを識別します。Mavenリポジトリ・マネージャは、各コピーを一意のタイムスタンプとビルド番号を使用して保持します。
たとえば、アーティファクトのリポジトリ・ディレクトリの内容は、次のようになります。
maven-metadata.xml test-artifact-2.1-20110928.112713-14.jar test-artifact-2.1-20110928.112713-14.pom test-artifact-2.1-20110924.121415-13.pom test-artifact-2.1-20110924.121415-13.jar
対応するリポジトリ・メタデータは、次のようになります。
<?xml version="1.0" encoding="UTF-8"?> <metadata> <groupId>com.my.company</groupId> <artifactId>test-artifact</artifactId> <version>2.1-SNAPSHOT</version> <versioning> <snapshot> <timestamp>20110928.112713</timestamp> <buildNumber>14</buildNumber> </snapshot> <lastUpdated>20110928112718</lastUpdated> <snapshotVersions> <snapshotVersion> <extension>jar</extension> <value>2.1-20110928.112713-14</value> <updated>20110928112713</updated> </snapshotVersion> <snapshotVersion> <extension>pom</extension> <value>2.1-20110928.112713-14</value> <updated>20110928112713</updated> </snapshotVersion> <snapshotVersion> <extension>jar</extension> <value>2.1-20110924.121415-13</value> <updated>20110924121415</updated> </snapshotVersion> <snapshotVersion> <extension>pom</extension> <value>2.1-20110924.121415-13</value> <updated>20110924121415</updated> </snapshotVersion> ... </snapshotVersions> </versioning> </metadata>
/metadata/versioning/snapshot
要素には、test-artifact-2.1-SNAPSHOT
でスナップショット・アーティファクトを要求したときにフェッチされた最新のスナップショットに関する情報が含まれています。バージョンのタイムスタンプとビルド番号(2.1.-20110928.112713-14
など)を参照して、必要な特定のスナップショットを直接要求することもできます。
通常、継続的インテグレーション・ビルドの適切な運用に必要となるのは最新のスナップショットのみです。スナップショットの古いインスタンスを保持しておくと、スナップショット依存性の変更により統合プロセスに障害が発生したことを、継続的インテグレーション・サーバーによって通知されてときのトラブルシューティングに役立ちます。最後の作業ビルド後に、少し古いビルドをプルすると、問題の特定に役立つ場合があります。
クリーンアップ操作を繰り返し行わないと、スナップショット・インスタンスがプロジェクトの存続期間中に急速に累積する場合があります。リポジトリ・マネージャの記憶域要件を管理するには、古いスナップショットを削除します。使用可能な記憶域およびパフォーマンス要件に応じて、保存ポリシーに関するオプションを設定します。
保存オプションの設定
アーティファクトのチェックインによってビルドが頻繁にトリガーされる継続的インテグレーション環境では、大量のビルドが実行される可能性があります。これらの各ビルド(少なくとも正常に実行されたビルド)により、アーティファクトがリポジトリに公開されます。これらにより、領域が大量に消費されることになる可能性があるため、管理することが重要です。
Archivaでは、リポジトリ単位ベースで古いスナップショットを自動的にクリーンアップする次の2つの異なるオプションが提供されています。
-
Repository Purge by Number of Days Older
Archivaは、指定した日数よりも古いスナップショットを自動的に削除します。Archivaは、最新のスナップショットを、その古さに関係なく常に保持します。
-
Repository Purge by Retention Count
この方法を使用するには、
purge-by-days-older
値を0
に設定する必要があります。Archivaは、この値までの最新のスナップショット・インスタンスのみを保持します。このカウントを超えた古いインスタンスは削除されます。
これらのオプションは、「Administration」メニューの「Repositories」をクリックし、次に目的のリポジトリの「Edit」をクリックして表示および変更できます。
親トピック: スナップショット・クリーンアップの理解
削除されるリリース済スナップショットについて
対応するバージョンがリリースされると、そのバージョンのスナップショットは不要になります。領域を節約できるだけでなく、依存性参照を最新の状態にすることもできます。
このスナップショットを参照する既存の継続的インテグレーション・ビルドは、依存性がリポジトリ・マネージャから削除されると、依存性が欠落していることを示すメッセージが表示されて失敗します。このエラーにより、依存性参照が失効していることを認識することができ、問題を修正するよう促されます。
親トピック: スナップショット・クリーンアップの理解
高度なユーザー管理について
Archivaでは、ユーザー管理インフラストラクチャにApache Redbackを使用します。Archivaの認証およびロール管理システムを組織の既存のユーザー管理システムとともに使用するには、Redbackを使用して追加構成を行う必要があります。RedbackによるLDAPおよびその他の認証システムのサポートは限定されています。
次の場所で詳細を参照できます。
親トピック: Mavenリポジトリ・マネージャ管理について
Archivaのバックアップ
Archivaファイル・ストアおよび構成をバックアップするメカニズムを提供して、ファイル・システムの障害または破損の発生時にリストアできるようにする必要があります。
バックアップ・ソリューションの選択肢は、フェイルオーバー方法の影響を受ける場合があります。
親トピック: Mavenリポジトリ・マネージャ管理について
Archivaおよびフェイルオーバーについて
Archivaでは、フェイルオーバー・ソリューションを提供しませんが、最新状態を維持するフェイルオーバー・システムを保守することが重要です。必要に応じて、プライマリ・システムと同期される個別のファイル・システムを使用して同一構成のバックアップ・システムを設定したり、同じ共有ファイル・システムを使用するように両方のシステムを構成することができます。
Archivaページを参照してください。
https://cwiki.apache.org/confluence/display/ARCHIVA/High+Availability+Archiva
親トピック: Mavenリポジトリ・マネージャ管理について