私の Web プロジェクト (または ear プロジェクト) をリモートサーバーとグラスフィッシュにデプロイする最良の方法は何ですか?
この目的のために netbeans が作成する ant-deploy.xml と build-impl.xml を使用する方法は?
autodeploy フォルダーを使用し、個別に sun-resources.xml を GF に追加するか、ant を使用して ....
順を追って説明していただけますか?
よろしく
私の Web プロジェクト (または ear プロジェクト) をリモートサーバーとグラスフィッシュにデプロイする最良の方法は何ですか?
この目的のために netbeans が作成する ant-deploy.xml と build-impl.xml を使用する方法は?
autodeploy フォルダーを使用し、個別に sun-resources.xml を GF に追加するか、ant を使用して ....
順を追って説明していただけますか?
よろしく
管理コンソールからアプリを手動でデプロイできます。
または、コマンドを使用できますasadmin
。最も単純なリモート展開は次のようになります。
asadmin deploy --user=<adminuser> --host=<hostname> <path to jar/war/ear>
これは、シェル スクリプトで記述されているか、Ant や Maven でラップされている可能性があります。
または、より専門的なツール ( Ant Task、maven glassfish プラグイン、maven asadmin プラグイン、Cargo )を使用することもできます。
それはすべてコンテキストに依存します。単一の答えはなく、多くの可能性があります。何を探しているのかわからない場合は、NetBeans によって作成された Ant ビルド スクリプトを使用してください。
次の組み合わせを使用します。
この質問に答えるには、より広い視点を取り、開発/展開のライフサイクル全体を検討することが役立ちます。Glassfishでの.warまたは.earアーカイブの実際のデプロイは、サイクルの1つのステップにすぎません。
本当に効果的になりたい場合は、ソフトウェアアプリケーションの構築と展開を自動化するためのツールとプラクティスの組み合わせを検討する必要があります。これは、開発者マシン、継続的インテグレーションマシン、QAマシン、および本番マシンを備えた「現実の」環境で作業する場合に特に当てはまります。
これらの項目については、次の段落で少し詳しく説明します。特に、今日、mavenによって駆動されるカスタムシェルスクリプトが、コミュニティで利用可能なglassfishmavenプラグインよりも優れていると思う理由を説明します。
Java開発を行う多くの人々にとって、Mavenはよく知られたツールです。他の人のために、ここに非常に簡単な紹介があります。Mavenの目標は、ソフトウェア成果物の構築を自動化することです。これはフレームワーク(オブジェクト指向フレームワークと同じ意味で)であり、次のことを意味します。
基本的に、Mavenを使用するときは、構築しているソフトウェア成果物の種類を記述します(.jar、.war、Androidアプリなど)。デフォルトでは、mavenは特定の場所でソースファイル、テストファイル、およびリソースを検索することを想定しています。デフォルトでは、Mavenは、ソフトウェアのビルドには、コンパイル、単体テスト、パッケージ化、展開、統合テスト、ドキュメントの生成など、さまざまなフェーズを経る必要があることを認識しています。
Mavenがあなたのために行うもう1つのこと(そしてこれがツールを使用する最初の理由であることが多い)は、依存関係の管理です。Mavenは、リポジトリー(パブリック、グローバル・リポジトリー、プライベート・リポジトリーの両方があります)を通じて利用可能になるライブラリー(名前とバージョン)を識別する方法を指定します。Mavenでは、「magiglibバージョン1.2.2に依存しています」などを指定します。Mavenにビルドを依頼すると、libが自動的にフェッチされ、ローカルリポジトリに保存され、構築とパッケージ化に使用されます。.jarファイルの手動転送を処理する必要はありません。同じライブラリの異なるバージョンが異なる開発者によって、または異なる段階で使用されるため、バグが発生するリスクはありません。
最後になりましたが、mavenは、ターゲットのデプロイメントマシンに応じて、ソフトウェアの構築をカスタマイズする機能を提供します。次のユースケースについて考えてください。
開発中は、開発者ごとにインストールが異なる可能性があると考えてください(mysqlが同じTCPポートでリッスンしない、glassfishが同じディレクトリにインストールされない、パスワードが異なるなど)。
開発マシンは、QAや本番環境とは明らかに異なる継続的インテグレーション環境とは明らかに異なります(ここでも、ネットワーク、ファイルシステム、クレデンシャルについて考えてみてください)。
Mavenは、変数、プロファイル、およびリソースフィルタリングの組み合わせでこれらのユースケースをサポートします。
Mavenは非常に強力なツールであるため、学習曲線があります。Netbeansを使用する場合は、数回クリックするだけでMaven駆動型プロジェクトを実際に作成でき、基本機能(依存関係管理など)を利用できます。高度なトピックについては、非常に優れたドキュメントが利用可能です。ここではこれ以上詳しくは説明しません。
Mavenの価値を理解し、それを使用することを決定したら、次の質問は、Mavenを使用して.warまたは.earアーカイブをGlassfishに(ローカルまたはリモートで)実際にデプロイする方法です。これは、多くのオプションがあり、長年にわたってかなり多くのことを学んだ場所です(ここ数年、GlassfishでMavenを使用しています)。
最初にできることは、GlassfishMavenプラグインの1つを使用することです。利用可能なさまざまなプラグインがあります。それらはまったく異なる機能と異なるレベルのサポートを持っています。最も強力なプラグインは実際にはサポートされておらず、Glassfish3ではそのままでは機能しません。プラグインは、アーカイブをGlassfishにデプロイするだけでなく、リソース(jdbcプール、jmsキューなど)を作成することも可能にしたため、興味深いものでした。また、その場でGlassfishドメインを作成することも可能になりました(統合テストを実行し、そのために新しいドメインが使用されていることを確認するのに非常に便利です)。とにかく、新しいプラグイン(製品ドキュメントに記載されています)はそれほど強力ではなく、純粋にデプロイメントタスクに焦点を合わせています。
私たちが作成し、長年にわたって進化させてきたビルドシステムでは、glassfish mavenプラグインをプロファイルおよびリソースフィルタリングと組み合わせることで、多くの制御と柔軟性を実現することができました。ソリューションは機能し、堅実ですが、非常に複雑です(pom.xmlとsettings.xmlは大幅に成長し、重くなっています)。
したがって、新しいビルドシステムを最初からセットアップする場合は、おそらく少し異なる方法で実行します。Glassfish Mavenプラグインのコードを見ると、 Glassfishが提供するasadminコマンドラインツールのラッパーであることがわかります(これは、asadminのパラメーターと動作がGlassfishのバージョンごとに変更されているためです。 Mavenプラグインが壊れていること)。
私がすることは:
Glassfishドメインを作成し、リソース(jdbc、jmsなど)を作成し、 .warと.earをデプロイするための一連のシェルスクリプトを記述します。スクリプトはasadminを使用してglassfishと対話します(ローカルとリモートの両方でasadminを使用できます)。
これらのスクリプトにMaven変数を埋め込み、リソースフィルタリングを使用して、スクリプトの環境固有のバージョンを動的に作成します。
Maven execプラグインを使用して、Mavenビルドサイクルのさまざまな段階(統合テスト、実行、カスタム目標など)でスクリプトを実行します。
ant タスクを使用して war ファイルを glassfish-V3 にデプロイできます。
Build.xml コンテンツ;
<target name="deploy"
description="deploys application to glassfish">
<exec failonerror="true" executable="cmd">
<arg value="/c" />
<arg value="asadmin --user ${gfUser} --passwordfile ${gfPassFile} --host ${host} deploy build/${war}" />
</exec>
</target>
アプリを展開するためのより多くの OS に依存しない方法:
<presetdef name="asadmin">
<java jar="${glassfish.home}/modules/admin-cli.jar" fork="true" jvm="${java.home}/bin/java" >
<arg line="--port ${glassfish.admin.port}" />
</java>
</presetdef>
<target name="deploy">
<asadmin failonerror="true">
<arg value="deploy" />
<arg value="--force=true" />
<arg value="${ear.file}" />
</asadmin>
</target>
asadminタスクでasadminプリセットを使用できます...
シナリオに応じて、いくつかの方法がうまく機能することがわかりました。
Glassfish では、実行中の Glassfish のファイルの「内部」の適切な場所に配置されたリソースの自動ホット デプロイが可能です。Glassfish 3.1.2.2 のデフォルトの場所は ですglassfish-3.1.2.2/glassfish/domains/domain1/autodeply
。以前に、Windows ではファイルが更新されたことを検出しない場合があることを発見しました。そのため、最初に削除し、アンデプロイを待ってから再度デプロイする必要がある場合があります。
管理者ページ (デフォルト ポート 4848) には、ユーザーがアプリケーションのアップロードと展開、無効化と有効化、および展開解除を行うことができる展開セクションが含まれています。これは、手動メンテナンスで最も堅牢であることがわかったものです。
また、基盤となるサーバーへのフル アクセスも必要ありません。
cargo プロジェクトは、適切に構成された Glasfish インスタンスへの自動デプロイを可能にします。
war デプロイメントを記述する pom.xml で実行される次のコマンドは、(2012 年 10 月 17 日現在) 現在のプロジェクトがデプロイされたグラスフィッシュをダウンロードして実行します。
mvn clean verify -Dcargo.maven.containerId=glassfish3x -Dcargo.maven.containerUrl=http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip org.codehaus.cargo:cargo-maven2-plugin:run
(グラスフィッシュの場所に関する追加の詳細を貨物に伝えるpom.xmlの小さなスニペットとともに)
Glassfish 3 では、Maven のサポートが充実しています。主な利点は、Glassfish を手動でダウンロードして展開し、起動する必要がないことです。maven ではすべて自動的に実行できます。
手順については、 http://embedded-glassfish.java.net/を参照してください。
私はこれを簡単にしか使用していませんが、IDE 中心のソリューションの優れた代替手段のようです。