| Oracle® Fusion Middleware継続的統合によるアプリケーションの開発 12c (12.2.1) E69943-01 |
|
 前 |
 次 |
この章では、Apache Archivaのインストールおよび基本構成について説明します。Archivaは、アーティファクト・リポジトリの複数ある選択肢の1つであり、Mavenベースの継続的インテグレーション・ビルド・システムの重要なコンポーネントです。
Mavenリポジトリ・マネージャまたはアーティファクト・リポジトリについて精通していない場合は、1.5項を参照してください。
この章の構成は、次のとおりです。
Archiva(この章で説明)およびMaven(第5章で説明)のインストールおよび構成を完了した後で、Oracle提供のアーティファクトをArchivaリポジトリに移入します。詳細は、5.3項を参照してください。
Archivaは、スタンドアロン・インストールとしてJettyにバンドルされて配布されます。WARファイル配布も提供されるため、Archivaを既存のアプリケーション・サーバーにインストールできます。
この章では、スタンドアロン・バージョンのインストール・プロセスについて説明します。WARファイルのインストールおよび構成に関する指示は、次の場所にある公式Archivaドキュメントで提供されています。
最新のスタンドアロンArchivaリリースを.zipファイルまたはtar.gzファイルとして次の場所からダウンロードできます。
配布をターゲット・インストール・ディレクトリに解凍します。この場所は、プリファレンスおよびターゲット・オペレーテイング・システムによって異なります。継続的インテグレーション関連のワークスペース用に共通の場所を作成することをお薦めします。たとえば、次の場所に配布を解凍します。
/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の構成方法について、一般的な説明だけでなく、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>
サーバーを構成した後は、そのサーバーをコマンドライン・インタフェースから起動できます。
サーバーを起動するには、次の手順を実行します。
次のコマンドを実行します。
/ciroot/archiva/bin/archiva start
64ビットLinuxシステムでは、次のようなエラー・メッセージを受信する場合があります。
./archiva: /ciroot/archiva/bin/./wrapper-linux-x86-32: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
このエラーが表示された場合は、glibc.i686パッケージを(yumなどを使用して)インストールし、再試行します。
次のコマンドを実行して、サーバー起動中のログ出力をチェックし、予期したとおりに起動していることを確認します。
tail -f /ciroot/archiva/logs/*
起動タスクが完了すると、Archivaサーバーは次の場所で使用可能になります。
http://localhost:8081/archiva
Archivaホーム・ページに最初にアクセスすると、管理者パスワードを設定するよう求められます。管理者ユーザーのフルネーム、電子メール・アドレスおよびパスワードを指定します。
Archivaは、ホストされている構成済の次の2つのリポジトリで起動します。
内部
内部リポジトリは、組織によってデプロイされた固定バージョンのリリース・アーティファクトを保持するリポジトリであり、完了バージョンのアーティファクト、開発されなくなったバージョン、およびリリース済のバージョンが含まれます。同じアーティファクトの開発中バージョンがスナップショット・リポジトリに今後存在する可能性があることに注意してください。
スナップショット
スナップショット・リポジトリでは、接尾辞SNAPSHOTが付いたバージョンとして示される作業中のアーティファクト、およびまだリリースされていないアーティファクトが保持されます。
内部リポジトリは、内部的にデプロイされたアーティファクトのホスティングに加えて、パブリックMaven中央リポジトリとして機能するようにデフォルトで構成されます。プロキシ・リポジトリは、サード・パーティのリポジトリを直接参照するかわりに使用できます。プロキシでは、前に要求されたアーティファクトがローカルにキャッシュされます。これにより、共有サーバーでの負荷が軽減されるため、空のリポジトリからビルドを実行する場合は特に推奨される方法です。共有サーバーに負荷をかけすぎると、ホストからの追加要求が抑制されたり禁止される場合があります。ビルド・パフォーマンスを大幅に向上させるには、負荷が少ない近接のプロキシ・サーバーから依存性をフェッチします。
他のパブリック・リポジトリからのサード・パーティ・アーティファクトが必要な場合は、それらを追加のプロキシ・コネクタとして自分のリポジトリに追加します。
通常はキャッシュされたサード・パーティのプロキシ・アーティファクトを複数のリポジトリ間で共有する必要があるため、キャッシュされたアーティファクトを個別のリポジトリに移動して、プロジェクト・アーティファクトから分離します。
ミラー・リポジトリを作成および構成するには、次の手順を実行します。
プロキシ接続を内部リポジトリから削除します。
「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」を選択します。
Mavenビルドで対象とするOracle Fusion Middleware環境ごとに個別のリポジトリを作成する必要があります。Oracleによる個別パッチ適用(5.3.7項を参照)のサポートとは、バージョンが同じであるが、適用されている個別パッチが異なるため一部のファイルが異なるという、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)ごとに繰り返します。
内部リポジトリへのデプロイメントをサポートするには、適切な権限を持つユーザーを少なくとも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(第5章で説明)のインストールおよび構成を完了した後で、Oracle提供のアーティファクトをArchivaリポジトリに移入します(5.3項で説明)。
Archiva 1.3.6のユーザー・ガイドは、次の場所にあります。
http://archiva.apache.org/docs/1.3.6/userguide/
その他のリリースについては、次に示す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およびその他の認証システムのサポートは限定されています。
次の場所で詳細を参照できます。
Archivaファイル・ストアおよび構成をバックアップするメカニズムを提供して、ファイル・システムの障害または破損の発生時にリストアできるようにする必要があります。
バックアップ・ソリューションの選択肢は、フェイルオーバー方法の影響を受ける場合があります。
Archivaでは、フェイルオーバー・ソリューションを提供しませんが、最新状態を維持するフェイルオーバー・システムを保守することが重要です。必要に応じて、プライマリ・システムと同期される個別のファイル・システムを使用して同一構成のバックアップ・システムを設定したり、同じ共有ファイル・システムを使用するように両方のシステムを構成することができます。
詳細は、次のArchivaページを参照してください。
https://cwiki.apache.org/ARCHIVA/high-availability-archiva.html
