docker
WebSphere
openliberty

OpenLibertyのDockerイメージを使ってサーバーを実行する

More than 1 year has passed since last update.

まとめ(2017/10/26更新)

  • OpenLibertyのDockerイメージは、「openliberty/open-liberty」。
  • その上で、以下の3種類のタグが指定された個別のイメージが提供されている。
    • javaee7(=latest): JavaEE7 フルプロファイル。server.xml内のfeature-managerの指定が <feature>javaee7</feature>ということ
    • webProfile7: WebProfile7.0。server.xml内のfeature-managerの指定が <feature>webProfile-7.0</feature>ということ
    • microProfile1: MicroProfile1.x。server.xml内のfeature-managerの指定が<feature>microProfile-1.2</feature>ということ
  • (2017/10/26追記:PullRequestがマージされたため、右のステップは不要になりました) デフォルトで利用されるサーバー定義ファイル(server.xml)では、Dockerホストからの接続はできないため、明示的にserver.xmlをDockerイメージに追加するようにDockerfileを構成する必要がある。 *但し、これはIssueで指摘され、PR待ち(https://github.com/OpenLiberty/ci.docker/issues/11) PRを作成しました

コンテナの起動準備

(1) 任意の作業用ディレクトリを作成します。

(2) そこに以下のようなDockerfileを作成します。

# based on a Docker image of OpenLiberty
FROM openliberty/open-liberty:webProfile7

# add a server.xml file

# add your WAR file
# COPY ./MyWebApp.war /config/dropins/

# set OS environment variables for your web app
# ENV YOUR_ENV_NAME=YOUR_ENV_VALUE

# expose listen ports of OpenLiberty server.
EXPOSE 9080 9443

なお、コメントアウトしていますが、通常はOpenLibertyにデプロイして動作させたいWARファイル(あるいはEARファイル)を、これもあらかじめ規定されている /config/dropins/ディレクトリ下にコピー配置するようにします。同ディレクトリは、LibertyProfileと同様にアプリの簡易デプロイ用に監視されるディレクトリであり、そこにWARファイルを配置することで、起動時にデプロイ処理が行われます。

この手順では、まず起動の確認までなので、特にWARのデプロイ指定はせずに進めます。必要ならENVも指定してアプリケーションのための環境変数を指定することが多いでしょう。

また、websphere-libertyイメージを使用していた方は、ライセンス許諾のためのRUN installUtility install --acceptLicense defaultServerの指定は不要になっていることに気づくかもしれません。

コンテナのビルド

Dockerfile(とserver.xml)の用意が終わったら、通常通りにdocker run や docker-compose run (あるいはdocker-compose.ymlを用意してup)などのコマンドを使って、コンテナを起動します。

ここでは-tオプションを使ってイメージ名を指定つつ、作業ディレクトリ(カレントディレクトリ)のDockerfileを使ってイメージのビルドを行います。

ここでは openlibertytest というイメージ名を指定しました。

$ docker build . -t openlibertytest
 :中略
Successfully tagged openlibertytest:latest

正しくDockerfileを指定している場合は、ビルドが成功するはずです。エラーが発生した場合は、エラーメッセージを元に、Dockerfileの内容を確認しましょう。

コンテナの起動

Dockerイメージのビルドに成功したら、今回作成したその openlibertytest イメージを使ってコンテナを起動します。(ここでは-dオプションを指定してデーモン起動しつつ、--nameでコンテナ名「liberty」を指定しています)

$ docker run -d -p 80:9080 -p 443:9443 --name liberty openlibertytest

必要に応じて、docker logsコマンドを使って、コンテナのログを確認しましょう。

$ docker logs liberty
Launching defaultServer (Open Liberty 17.0.0.3/wlp-1.0.18.cl170320170927-1854) on IBM J9 VM, version 8.0.5.0 - pxa6480sr5-20170905_01(SR5) (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT   ] CWWKS4104A: LTPA keys created in 1.291 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
[AUDIT   ] CWWKF0012I: The server installed the following features: [jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1, servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1, jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, jpaContainer-2.1, cdi-1.2, distributedMap-1.0, webProfile-7.0, websocket-1.1, jpa-2.1].
[AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

末尾の「CWWKF0011I: The server defaultServer is ready to run a smarter planet.」が、サーバーとしての起動の完了を意味しています。(Webアプリケーションを/config/dropins/にコピー=デプロイしていたら、その後に起動が開始します)。

WebSphere Libertyでは 「/opt/IBM/wlp/...」のディレクトリでしたが、OpenLibertyでは「/opt/ol/wlp/...」に変わっていますね。(wlpというディレクトリ名はいろいろなところに影響があるので変えられなかったのでしょうか)

起動が終わったら、ブラウザで http://localhost/ にアクセスしましょう。コンテナが待ち受ける9080ポートを、ホスト側の80で公開しているので、このアドレスでコンテナのサーバーに接続します。
以下のようなOpenLibertyの初期ページが表示されれば、動作確認のステップは完了です。

Screenshot-2017-10-22 Open Liberty.png

自分のWebアプリケーション(例:MyWebApp.war)をデプロイしていたら、拡張子を除いたファイル名部分がコンテキストルートになるので http://localhost/MyWebApp/ のURLで、そのWARのトップページにアクセスすることが出来ます。

所感

製品版であるIBM WebSphere LibertyProfile にもDockerイメージ「websphere-liberty」が提供されていましたが、あくまで製品であり、例外規定(*)があるとはいえその条件で本番環境に実際にはなかなか使いづらいものでした。

(*) 法人組織内で、合計2GBまでのJavaヒープサイズの使用の範囲であれば本番環境用途であっても無償、というもの(リンク)ですが、厳密に「法人内」で統一的にヒープサイズを管理することは通常の規模の企業ではあまり現実味がなく、ライセンス違反のリスクを考えるとなかなか手が出しづらかったのではないかと思います。(※なお、開発テスト用途では、もともと無償での利用が可能)

OpenLibertyは、製品サポートが不要であれば、内容としてはIBM WebSphere LibertyProfile と同一といって良いものなので、もともとIBM製のJavaEEサーバーを使っていた人には気軽に使えますね。有償製品であるRedHat JBoss EAPに対応するOSSのWildFly、というのと同じ構図で、WebSphere LibertyProfile にもOSSのOpenLibertyが登場して選択肢が増えたのは良いことだと思います。

余談

OpenLibertyの初期時点のバージョンは、17.0.0.3 となっていて、LibertyProfileのバージョンに完全に一致させるポリシーのようです。OpenLibertyとしてはこれが最初のリリースであるにもかかわらず、上記のバージョン表記は2017年で3回目のFixリリースという意味なので、そういう判断なのであろうと思われます。

参考情報