hatenob

プログラムって分からないことだらけ

一人Web開発～第5夜 Wildfly導入

JavaEE7実行環境であるWildflyをインストールします。
ApacheとMySQLとの連携に必要な設定も施します。

テンプレートも含めるとコード量がそこそこあるので、実物はGithubのほうで参照ください。
https://github.com/nobrooklyn/oneman/tree/master/platform
やったことだけ書きます。

Wildflyインストール

Wildflyを動かすためのJavaと、Wildfly本体をインストールします。
JavaにはOpenJDKを使います。Wildflyは現時点で最新のCR1をインストールします。今後バージョンが変わった場合でも、attributesでバージョン指定を変えるだけで済むように心がけています。
以下、レシピの内容。

  • OpenJDKのインストール
  • Wildfly実行ユーザ、グループの作成。wildflyユーザで動かす想定です。
  • Wildflyのダウンロード。mod_clusterもそうだけれど、クックブック的にはダウンロードがいいのか、ダウンロード済みのものをfilesに置くのがいいのかは分からない。ただ、Githubにリポジトリがあるので2次配布のこととか気にしないといけないと嫌なのでダウンロードにしてます。ただし、一度だけ。すでにある場合はしない。
  • インストール先ディレクトリの作成。インストールと言っても展開するだけなので、展開先のディレクトリってこと。
  • tarボールの展開。
  • 今後複数バージョン出てきたように、メインのモジュールへは/opt/wildfly/availableでアクセスできるようにシンボリックリンクを貼る。ネーミングセンスは問わないで頂きたい。

MariaDB用JDBCドライバインストール

MariaDBにJDBCで接続するためのドライバをインストール。

  • JDBCドライバのダウンロード。
  • インストール先のディレクトリ作成。Wildflyでは、modules配下にディレクトリを作成してそこにjarと一緒にmodules.xmlというファイルを作ることで、Wildflyにロードさせることができるようになる。クラスパスに追加していくモジュール型クラスローダと異なり、依存関係のあるモジュールを動的に追加していくモジュール型クラスローダを採用しているため。
  • jarのコピー。コピーにはcontentを使ってIO.readというRubyのAPIでコピーをしてます。Chefにはファイルコピーの構文がないので。で、Chefはレシピをパースしたあとに逐次実行するのだけれど、RubyのAPIを書くと、パースの時点で実行されてしまい、ファイルがないためエラーとなる。なので、「lazy{}」を付けて遅延実行するようにしています。
  • module.xmlの配置。

Wildflyの設定

今回はstandaloneモードで動作させることにするため、standlaone.xmlを作成して配置します。

  • 先にログディレクトリの作成。今回は、標準出力、serverログ、auditログ、アクセスログの4つを取ることにします。
  • 最初から存在するstandalone-*.xmlを削除します。
  • standalone.xmlの配置。中身はちょこちょこいじってあります。
  • mgmt-users.propertiesの配置。管理ユーザを定義したファイル。世に向けてサービスを展開するような場合は公開すべきではないです。
  • standalone.confの配置。Javaの起動オプションを書いてます。今回は主にGCのログ出力を追加。
  • init.dスクリプトから読まれるwildfly.confの配置。Wildflyの実行ユーザやコンソールログ出力先の設定等。
  • initi.dスクリプト。もとはWildflyに同梱されているものを少し改変。コンソールログのオーナーをWildfly実行ユーザに合わせました。

standalone構成にする理由

standaloneにする理由にはdomainモードとの比較が必要です。
一般的に、今回のようなクラスタ構成とする場合、domainモードにすることで集中管理ができるという利点があげられます。Wildflyの場合、集中管理機能の主は設定とデプロイの伝播です。ところが、今回のようにChefとデプロイツールを使う場合、Wildflyの外でそれをできるため、特に利点でなくなります。それどころか、1台だけクラスタから切り離してバージョンを上げたいというようなことをやろうと思ったときにはdomain単位の管理が邪魔になることも考えられます。ま、まだ何も運用していないので何とも言えませんが。いずれにしろ、standaloneのほうのがシンプルなのでこっちにします。

ログの棲み分け

デフォルトだと、コンソールログとserverログには同じ内容が出力されます。同じ内容ならどちらか片方でいいですよね。厳密には少し違って、起動時のコンフィグレーション情報はserverログにしか出ません。一方でコンソールログにはJDKが標準出力に向けて出力する情報が出力されます。GCログを標準出力に出すことにすると、コンソールログにGCの状況が出力されます。コンソールログにアプリケーションの細かな情報を出力するようにしておくことで、アプリの状況とGCの状況を時系列でみることができるようになり、デバッグに役立ちそうな気がするので、基本、情報はコンソールログに出すことにし、serverログは監視に使用するためにWARN以上を出力するように設定することにしました。

Wildflyの起動、停止

先ほど追加したinit.dスクリプトを使用して起動、停止を行います。

# service wildfly [start|stop|status|restart]

restartは中でstartとstopを呼んでいるだけです。あと、Usageにはreloadというのがありますが、これはCR1の時点では実装されてませんでした。多分、CLIでつないでreloadコマンドを呼ぶのだと思います。

Wildflyのテスト

テストはちょっといい加減です。特に、standalone.xmlの検証が入ってません。xmlなのでどう検証すべきか迷い、ひとまず保留。serverspecのfileでは行単位でgrepしての検証しかできないので、xmlリソースみたいのを作るのがいいのかなぁ。
テスト内容は下記。

  • JDKのインストール。
  • サービスの起動。
  • ポートのリスン。
  • wildfly.confの内容。
  • 各種ログの存在とオーナー、グループ。なお、アクセスログはアクセスがないと作成されないため、事前にNet::HTTP.getのAPIを使ってリクエストを発行している。
  • プロセス実行ユーザとその所属グループ。

実はJDBC接続設定がすでに入っているので、起動するためにはMariaDBをインストールしてコンフィグレーション済みじゃないとダメなんだす。本当は順番的に、MariaDB→Wildflyの順にすべきでしたね。なお、mod_clusterの設定を入れていると、Wildfly起動時にHTTPDが起動していないとWARNを吐く模様。なので、キレイに立ち上げようと思ったらWildflyは最後に起動させないとダメっぽい。