寺田　佳央 – Yoshio Terada

Azure AD で OpenID Connect を使用したセキュアな Open Liberty アプリケーションの構築

原文はコチラ
https://cloudblogs.microsoft.com/opensource/2020/08/10/securing-open-liberty-applications-azure-active-directory-openid-connect/

* Application Development
* Cloud
* Tutorials and Demos
* Community/partners

Web アプリケーションで、ユーザーアカウントを独自に作成したり、認証・認可を個別に実装・管理する時代は終わりました。

その代わりに、現在のアプリケーションは、外部プロバイダーを利用して、上記の機能（Identity and Access Management略してIAM）を実装します。 完全な Javaアプリケーションの実行基盤として存在する、Open Liberty は、外部プロバイダーの IAM を利用するための機能を備えています。Open Liberty はソーシャルメディア・ログイン、SAML Web シングルサインオン、OpenID Connect クライアントなど IAM の主要な機能をサポートしています。

Bruce Tiffany のブログ・エントリ 「Securing Open Liberty apps and microservices with MicroProfile JWT and Social Media login」では、Open Liberty ソーシャルメディア・ログインの機能を使用して、既存のソーシャルメディアの認証情報を使用してユーザー認証する方法を紹介しています。

このブログ・エントリでは上記とは別の方法をご紹介します。ここで Microsoft の Azure Active Directory で Java アプリケーションを保護するために、Liberty ソーシャルログイン機能を OpenID Connectクライアントとして実装する方法を見てみましょう。

このブログで紹介するサンプルコードは、全て コチラの GitHub リポジトリで公開しています。ブログをご覧頂く前後で、コードをチェックし、ユーザーガイドに従い Java EE サンプル・アプリケーションを実行してください。

Azure Active Directory のセットアップ

Azure Active Directory（Azure AD）は、認証プロトコルとして OAuth 2.0 上に OpenID Connect（OIDC）を実装しているため、Azure AD を利用したアプリケーションのセキュアなユーザー認証ができるようになっています。

サンプルコードをご覧いただく前に、Azure AD テナントをセットアップし、リダイレクト URL の設定とクライアントシークレットでアプリケーションを登録してください。

Azure AD のテナント・セットアップ時に取得する、テナントID、アプリケーション（クライアント）ID、およびクライアントシークレットは、Open Liberty が Azure AD と接続し OAuth 2.0 承認フローを行うために使用しますので情報を控えておいてください。

Azure AD の設定方法は、下記の記事をご参照ください。

* クイック スタート:テナントを設定する
* クイック スタート:Microsoft ID プラットフォームにアプリケーションを登録する
* 新しいアプリケーション シークレットを作成する

OpenID Connect クライアントとしてソーシャルログインを構成

下記のサンプルコードは、Open Liberty サーバーで実行されているアプリケーションが、どのようにして、Azure AD を使用した OpenID Connectプロバイダーに対して、socialLogin-1.0 の機能を持つ OpenID Connect クライアントからユーザー認証を行うのか、その方法を示しています。

関連するサーバー構成：server.xml

GitHub の server.xml へのリンクはコチラ

oidcLogin 要素は、Open Liberty が持つ多数の設定可能要素の一つです。

サンプル・コードで示すように、Azure AD は検出用のエンドポイントをサポートしているため、Azure AD を利用する場合、多くの設定は不要で、サンプル・コードで示すように、いくつかのオプションのみを使用します。

検出用のエンドポイントを利用すると、ほとんどの OpenID Connect の設定情報をクライアントが自動的に取得できるため、設定が大幅に簡素化できます。

さらに、特定の Azure AD インスタンスは、検出用エンドポイント URL に対して既知のパターンを適用するため、テナントID を使用して、URL をパラメーター化することもできます。
また、クライアントIDとシークレットが必要で、署名アルゴリズムとして RS256 を使用します。

userNameAttribute 属性は、Azure AD のトークンと Liberty の一意のサブジェクト ID にマップするために使用します。
使用可能な Azure AD トークンは、この一覧に示すようにいくつかあります。
v1.0 と v2.0 で必要なトークンは異なるため、注意が必要です（v2.0は一部のv1.0トークンをサポートしていません）。
preferred_username もしくは oid は共に安全に使用できますが、通常 preferred_username の使用をお勧めします。

Azure ADを使用すると、アプリケーションは、Microsoft の認証局 (Root CA) によって署名された証明書を使用できます。

この証明書を、JVM のデフォルトの cacerts に追加します。 JVM のデフォルトの cacerts を信頼することで、OIDC クライアントと Azure AD 間で SSL ハンドシェイクが成功することが保証されます（つまり、defaultSSLConfig trustDefaultCerts値を true に設定する）。
この場合、Azure AD を介して認証されたすべてのユーザーにユーザーロールを割り当てます。必要に応じて、Liberty でより複雑なロールマッピングも可能です。

OpenID Connect を使用したユーザー認証

web.xmlの関連構成：

GitHub の web.xml へのリンクはコチラ

ワークフロー

図１：Azure AD で OpenID Connect を利用したトークン取得フロー

これは Java EE の標準セキュリティです。
認証されていないユーザーが JSF のアプリケーションに対してアクセスしようとすると、Azure AD の資格情報を取得するために Microsoft　のサイトにリダイレクトされます。

成功すると、ブラウザは認証コードを含んでクライアントにリダイレクトします。

次に、クライアントは、再度 Microsoft のサイトに接続し、認証コード、クライアントID、シークレットを使用して IDトークンとアクセストークンを取得します。最後に、クライアントで認証済みユーザーを作成し、JSF アプリに対してアクセスします。

認証されたユーザー情報を取得するには、@ Injectアノテーションを使用してjavax.security.enterprise.SecurityContextへの参照を取得し、getCallerPrincipal() メソッドを呼び出します。

GitHub の Cafe.java へのリンクはコチラ

JWT RBACを使用したセキュアな内部 RESTful 呼び出し

JAX-RS で実装した RESTful Web サービスである Cafe Bean は CafeResource に依存し、コーヒーの作成、読み取り、更新、削除を行います。

CafeResourceは、MicroProfile JWT を使用して RBAC（ロールベースのアクセス・コントロール）を実装し、トークンのグループ要求を検証します。

GitHub の CafeResource.java へのリンクはコチラ

admin.group.id は、ConfigProperty アノテーションで定義する事で、MicroProfile Config を使用し、アプリケーションの起動時に値を注入します。
MicroProfile JWT では JWT（JSON Web トークン）を @Inject で注入きます。

CafeResource REST エンドポイントは、OpenID Connect の承認ワークフローに従い、Azure AD によって発行された ID トークンから、preferred_username および groups クレームを含む JWT を受け取ります。

ID トークンは、com.ibm.websphere.security.social.UserProfileManager およびcom.ibm.websphere.security.social.UserProfile API を使用して取得できます。

関連する設定：server.xml

GitHub の server.xml へのリンクはコチラ

注意：
グループ claim はデフォルトでは伝搬されないため、Azure AD の追加設定が必要です。
ID トークンにグループ claim を 追加するためには、Azure ADでタイプが「セキュリティ」のグループを作成し、1 名以上のメンバーをそのグループに追加する必要があります。
Azure AD の設定で、アプリケーションの登録時に、下記の情報を取得する必要があります。
「Token configuration」 を選択> 「Add groups claim」 を選択 >「セキュリティグループ」を選択(ID トークンを含むグループ)　>「ID」を展開 >　「Customize token Properties」から「Group ID」を選択

詳細はコチラをご覧ください。

* Azure Active Directory を使用して基本グループを作成してメンバーを追加する
* グループの省略可能な要求を構成する

まとめ

この取り組みは、Jakarta EE (Java EE)、および MicroProfile を使用する開発者に有用な情報とツールを提供するため、Microsoft と IBM が協力してできた物の一つです。

* Java EE はベンダー中立のオープンソースガバナンスの下で Jakarta EE として Eclipse Foundation に移管されました
* MicroProfileは、Java EEテクノロジーに基づいて構築され、マイクロサービスドメインを対象とする一連のオープンソース仕様です

どのようなツールやガイダンスが必要かご意見をお聞かせください。
また、特に、クラウド・マイグレーションにご興味があり、（無償で）私たちと緊密に連携したいご要望がある場合、
可能でしたら、このブログ・エントリに関する 5 分間のアンケートにご協力・ご記入頂き、貴重なフィードバックをください。
どうぞ宜しくお願いします。

2020年9月3日 at 2:24 午後 1件のコメント

Java 開発者のための Docker Multi Stage Build の活用方法

Java 開発者のために Docker Multi Stage Build を活用した本番用イメージの作成方法と、監視やデバッグが可能な検証用イメージの同時作成方法についてビデオにまとめました。どうぞご覧ください。

下記のような Multi Stage Build に対応した Dockerfile を作成します。（動画中は少し Dockerfile の書き方が変わっていますが、基本的には下記と同じです。）

# syntax = docker/dockerfile:1.0-experimental
###############################################
# Create Runtime Bases Image
###############################################
FROM mcr.microsoft.com/java/jre:11u6-zulu-alpine as base

RUN apk update \
 && apk add tzdata \
 && rm -rf /var/cache/apk/*

ENV LANG ja_JP.UTF-8
ENV LANGUAGE ja_JP
ENV LC_ALL ja_JP.UTF-8

ENV TZ='Asia/Tokyo'
ENV APP_HOME /home/java

RUN addgroup -g 2000 -S java && adduser -u 2000 -S java -G java
USER java

WORKDIR $APP_HOME

###############################################
# Build Source Code
###############################################
FROM maven:3.6.3-jdk-11-slim as BUILD
#FROM mcr.microsoft.com/java/maven: as BUILD

WORKDIR /build
COPY pom.xml .
COPY src/ /build/src/

## Maven のローカル・レポジトリをキャッシュ
RUN --mount=type=cache,target=/root/.m2 \
     mvn clean package

###############################################
# Create Final Image
###############################################
FROM base as final

COPY --from=BUILD /build/target/sample-java-app-0.0.1-SNAPSHOT.jar /home/java/app.jar

ENTRYPOINT ["java", "-jar", "/home/java/app.jar"]
EXPOSE 8080

###############################################
# Create Debuggable Monitorable Image
###############################################
FROM base as debug

COPY --from=BUILD /build/target/sample-java-app-0.0.1-SNAPSHOT.jar /home/java/app.jar

ENTRYPOINT ["java", "-Xdebug", 
"-Xrunjdwp:server=y,transport=dt_socket,address=*:5050,suspend=n",
"-Dcom.sun.management.jmxremote.local.only=false",
"-Djava.rmi.server.hostname=127.0.0.1",
"-Dcom.sun.management.jmxremote",
"-Dcom.sun.management.jmxremote.port=18686",
"-Dcom.sun.management.jmxremote.rmi.port=18686",
"-Dcom.sun.management.jmxremote.authenticate=false",
"-Dcom.sun.management.jmxremote.ssl=false", 
"-jar", "/home/java/app.jar"]
EXPOSE 8080 5050 18686

上記の Dockerfile を元にイメージを作成する際、それぞれ下記のようにターゲットを指定してビルドを行ってください。

本番用イメージの作成 (–target=final)

$ docker build -t tyoshio2002/spring-sample:1.0 . --target=final
$ docker run -p 8080:8080 -it tyoshio2002/spring-sample:1.0

検証環境イメージの作成と起動 (–target=debug)

$ docker build -t tyoshio2002/spring-sample-debug:1.0 . --target=debug
$ docker run -p 8080:8080 -p 5050:5050 -p 18686:18686 -it tyoshio2002/spring-sample-debug:1.0

その他の特記事項

RUN --mount=type=cache,target=/root/.m2 \
     mvn clean package

より詳しく説明すると、今まではマルチステージ・ビルド中では、Maven のローカル・レポジトリをキャッシュできなかったため、ビルドの度に毎回大量の依存ライブラリをパブリック・レポジトリからダウンロードしなければなりませんでしたが、この–mount=type=cacheで毎回のダウンロードは不要になります。

こうした Docker の新しい機能もどうぞご活用ください。

2020年5月11日 at 6:31 午後

Deploying Java EE apps to Azure: Part 1

この記事は Deploying Java EE apps to Azure: Part 1 の記事の日本語翻訳版です。

クラウド環境用に Java アプリケーションを開発し展開するためには下記のような様々な選択肢があります。

• IaaS（Infrastructure-as-a-Service）
• PaaS（Platform-as-a-Service）
• CaaS（Containers-as-a-Service）
• Kubernetes
• サーバーレス
• その他

上記は、いずれか一つだけを選択して使用するというよりも、それぞれに「長所と短所」があるため、利用者のニーズに応じて適材適所で組み合わせて利用することが必要です。最終的にはビジネス要件に従いどれを使用するかを決定してください。利用者にとって「選択肢」が複数あることはとても良いことです。

ここでは、Azure 上で Java EE アプリケーションを実行するための選択肢をいくつかご紹介します。
はじめに、従来のオンプレミス環境で実施していた方法と同じ手法をご紹介します。まず Microsoft Azure 上に仮想マシンを構築し、その上にアプリケーション・サーバをインストールします。そして Java EE アプリケーションをアプリケーション・サーバにデプロイします。アプリケーションはバックエンドのデータベースに接続をしますが、ここでは Azure Database for PostgreSQL をバックエンドのデータベース・サーバとして利用します。この構成は Java EE アプリケーションの構築・配備において最も典型的な構成で、本質的には IaaS（Azure VM）とPaaS（マネージドPostgreSQL on Azure）を組み合わせた構成です。

コンテナーやKubernetesなどの他の構成については、今後の投稿で取り上げます

本エントリで使用するアプリケーションのサンプルは、JAX-RS、EJB、CDI、JPA、JSF、Bean Validation など Java EE 8 の仕様に準拠した 基本的な３階層アプリケーションです。 今回 IaaS で Payara Server を構成し、バックエンドの PostgreSQL に対して接続をします。

チュートリアルは、下記の手順にしたがい行います。

1. Azure 上に仮想マシンと Postgres を構築
2. 仮想マシン上に Payara Server をインストール
3. Java EEアプリケーションを配備
4. アプリケーションの動作確認

このチュートリアルで使用するアプリケーションは一部を除いて、Reza Rahman が作成したこのプロジェクトを利用します。

前提条件

チュートリアルを実行するには、Microsoft Azure アカウントと Azure CLI が必要です。
Microsoft Azureアカウントをお持ちでない場合は、無料アカウントにサインアップしてください！ Azure CLIは、Azureリソースを管理するためのクロスプラットフォームのコマンドラインエクスペリエンスです。こちらの手順に従ってインストールしてください。

最初に

Azure CLIを使用して、チュートリアルで使用する Azure のサブスクリプション ID を設定します。
AzureサブスクリプションIDを設定するには下記のコマンドを実行してください。

export AZURE_SUBSCRIPTION_ID=[to be filled]
az account set --subscription $AZURE_SUBSCRIPTION_ID

次に、このチュートリアルで作成するサービス（リソース）を含むリソース・グループを作成します。

リソースグループは、Azure 上で構築する関連リソースをまとめて管理する論理的なコンテナー（ディレクトリ）のようなものです。
リソースグループを作成するために、下記のコマンドを実行してください。

export AZURE_RESOURCE_GROUP_NAME=[to be filled]
export AZURE_LOCATION=[to be filled]
az group create --name $AZURE_RESOURCE_GROUP_NAME ¥ 
--location $AZURE_LOCATION

Azure 上に PostgreSQL のインストール

Azure Database for PostgreSQL はオープンソースの Postgres データベースを利用した完全マネージドなリレーショナル・データベースサービスです。 単一サーバーもしくは、ハイパースケール（Citus）なクラスターのいずれかを選択し構築出来ます。

このチュートリアルでは、単一サーバーのオプションを選択して構築します。
Azure 上に Postgres Server のインスタンスを作成するには、az postgres server create コマンドを使用します。 まずサーバ名、管理ユーザーやパスワードなどを設定します。

export AZURE_POSTGRES_SERVER_NAME=[to be filled]
export AZURE_POSTGRES_ADMIN_USER=[to be filled]
export AZURE_POSTGRES_ADMIN_PASSWORD=[to be filled]
export SKU=B_Gen5_1
export STORAGE=5120

ストレージとSKU で指定可能なオプションについては、こちらのドキュメントをご参照ください

下記のコマンドを実行してデータベース・インスタンスを作成します。

az postgres server create ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME ¥
  --name $AZURE_POSTGRES_SERVER_NAME  ¥
  --location $AZURE_LOCATION ¥
  --admin-user $AZURE_POSTGRES_ADMIN_USER ¥
  --admin-password $AZURE_POSTGRES_ADMIN_PASSWORD ¥
   --storage-size $STORAGE ¥
   --sku-name $SKU

コマンド実行後、構築完了まで数分かかります。しばらくお待ちください。
作成した Postgres データベースの詳細を確認するには az postgres server show コマンドを実行します。

az postgres server show ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME ¥
  --name $AZURE_POSTGRES_SERVER_NAME

コマンドを実行すると、JSON が表示されます。のちほど、Postgres インスタンスに接続するので、fullyQualifiedDomainName の値を書き留めてください。

[AZURE_POSTGRES_DB_NAME].postgres.database.azure.com
のように表示されています。

Azure 上に仮想マシンをインストール

Azure 上に 仮想マシン(UbuntuベースのLinux VM)を構築し、JavaEE の仕様に準拠した Payara アプリケーションサーバーをインストールします。

Linux VM の構築に必要な情報を設定します。

export AZURE_VM_NAME=[to be filled]
export AZURE_VM_USER=[to be filled]
export AZURE_VM_PASSWORD=[to be filled]
export VM_IMAGE=UbuntuLTS

az vm create コマンドを実行して Linux VM のインスタンスを構築します

az vm create ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME ¥
  --name $AZURE_VM_NAME ¥
  --image $VM_IMAGE ¥
  --admin-username $AZURE_VM_USER ¥
  --admin-password $AZURE_VM_PASSWORD

VM のプロビジョニングには数分かかりますのでしばらくお待ちください。

パブリック IP アドレスを取得するために、az vm list-ip-addresses コマンドを実行してください。

az vm list-ip-addresses ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME  ¥
   --name $AZURE_VM_NAME

コマンドを実行すると JSON が表示されます。publicIpAddresses の箇所を確認し、ipAddress プロパティの値を確認します。
以降の手順で使用するため、環境変数に設定しておいてください。

export VM_IP=[to be filled]

Linux VM から Postgres データベースへのアクセス許可設定

Postgres データベースはデフォルトで外部からのアクセスが許可されていません。 Linux VM から Postgres インスタンスにアクセスするために、ファイアウォールでルールを追加し、アクセス許可設定を行います。az postgres server firewall-rule create コマンドを実行し、Linux VM 上にデプロイされた JavaEE アプリケーションから Postgres へ通信できるようにします。

export FIREWALL_RULE_NAME=AllowJavaEECafeAppOnVM
az postgres server firewall-rule create ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME ¥
  --server $AZURE_POSTGRES_SERVER_NAME ¥
  --name $FIREWALL_RULE_NAME ¥
  --start-ip-address $VM_IP ¥
  --end-ip-address $VM_IP

Linux VM へ　Payara サーバのインストール

Payara Serverは、GlassFish から派生したオープンソースのアプリケーションサーバーです。オンプレミス、クラウド、ハイブリッド環境などいずれの環境でも、高信頼でセキュアな Java EE（Jakarta EE）/ MicroProfile の実行環境を提供します。

詳細については、GitHubのプロジェクトもしくはドキュメントをご参照ください。

Linux VM の IP に対してユーザ名を指定し SSH 接続します。

ssh $AZURE_VM_USER@$VM_IP

プロンプトが表示されたらパスワードを入力してください。Linux VM にログインしたのち、下記の手順を実行してください。

必要なツールセットのインストール

Payara サーバーをインストールする前に、JDK/Maven のインストールを行います。

sudo apt-get update
sudo apt install openjdk-11-jdk
sudo apt install maven

Payara サーバーのセットアップ

このチュートリアル執筆時点の最新の Payara サーバーのバージョンは Payara Server 5.201 です。
Payara のセットアップは、zipファイルをダウンロードして解凍するだけです。

export PAYARA_VERSION=5.201
wget https://s3-eu-west-1.amazonaws.com/payara.fish/Payara+Downloads/$PAYARA_VERSION/payara-$PAYARA_VERSION.zip
sudo apt install unzip
unzip payara-$PAYARA_VERSION.zip

asadmin コマンドを実行しサーバの起動

ls ~/payara5/ コマンドを実行し、インストールされたファイルやディレクトリなどのを確認してください。
次に、bin ディレクトリ下にある asadmin コマンドを使用してサーバーを起動します

ls ~/payara5/
~/payara5/bin/asadmin start-domain

サーバーが起動するまで少し時間がかかります。 起動が完了すると下記のようなログが表示されます。

Waiting for domain1 to start .........
Successfully started the domain : domain1
domain  Location: /root/payara5/glassfish/domains/domain1
Log File: /root/payara5/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

アプリケーションのセットアップとデプロイ

以上で Linux VM を構築し Payara サーバをインストールし起動しました。そこでアプリケーションのデプロイを行います。
アプリケーションをデプロイするため Git リポジトリをクローンしてください。

git clone https://github.com/abhirockzz/javaee-on-azure-iaas
export APP_FOLDER_NAME=javaee-on-azure-iaas

Azure の Postgres データベースに接続するために、設定ファイル中の JDBC 接続URLを更新する必要があります。
設定ファイルは、web.xmlファイル（javaee-on-azure-iaas/src/main/webapp/WEB-INF のディレクトリ下）に存在し、ファイル中の セクションの 属性を更新してください。

jdbc:postgresql://POSTGRES_FQDN:5432/postgres?user=AZURE_POSTGRES_ADMIN_USER@=AZURE_POSTGRES_SERVER_NAME&password=AZURE_POSTGRES_ADMIN_PASSWORD&sslmode=require

以下は、JDBC URL の設定項目に関するリストです。

• POSTGRES_FQDN は Postgres インスタンスが稼働するサーバの完全修飾ドメイン名を指定
• AZURE_POSTGRES_ADMIN_USER は Postgres インストール時に設定した管理者ユーザー名
• AZURE_POSTGRES_SERVER_NAME は Postgres のインストール時に設定したサーバー名
• AZURE_POSTGRES_ADMIN_PASSWORD は Postgres のインストール時に設定した管理者のパスワード

環境変数に設定します。

export POSTGRES_FQDN=[to be filled]
export AZURE_POSTGRES_ADMIN_USER=[to be filled]
export AZURE_POSTGRES_SERVER_NAME=[to be filled]
export AZURE_POSTGRES_ADMIN_PASSWORD=[to be filled]

下記のコマンドを実行して、設定項目を修正します。

export FILE_NAME=javaee-on-azure-iaas/src/main/webapp/WEB-INF/web.xml
sed -i 's/POSTGRES_FQDN/'"$POSTGRES_FQDN"'/g' $FILE_NAME
sed -i 's/AZURE_POSTGRES_SERVER_NAME/'"$AZURE_POSTGRES_SERVER_NAME"'/g' $FILE_NAME
sed -i 's/AZURE_POSTGRES_ADMIN_USER/'"$AZURE_POSTGRES_ADMIN_USER"'/g' $FILE_NAME
sed -i 's/AZURE_POSTGRES_ADMIN_PASSWORD/'"$AZURE_POSTGRES_ADMIN_PASSWORD"'/g' $FILE_NAME

下記に セクションの例を示します。

<data-source>
    <name>java:global/JavaEECafeDB</name>
    <class-name>org.postgresql.ds.PGPoolingDataSource</class-name>
    <url>jdbc:postgresql://foobar-pg.postgres.database.azure.com:5432/postgres?user=foobar@foobar-pg&amp;amp;password=foobarbaz&amp;amp;sslmode=require</url>
</data-source>

アプリケーションの設定を変更しましたので、ソースコードをビルドしましょう！

mvn clean install -f $APP_FOLDER_NAME/pom.xml

上記コマンドを実行すると、war ファイルが生成されます。下記のコマンドで war ファイルが生成されているか確認してください。

ls -lrt $APP_FOLDER_NAME/target | grep javaee-cafe.war

アプリケーション設定の最後に、Postgres の JDBC ドライバーをダウンロードして Payara サーバーに追加しましょう。
ここではドライバーのバージョンは 42.2.12 を使用しています

export PG_DRIVER_JAR=postgresql-42.2.12.jar
wget https://jdbc.postgresql.org/download/$PG_DRIVER_JAR

asadmin add-library コマンドを実行し入手した jar ファイルを Payara に追加できます。

~/payara5/glassfish/bin/asadmin add-library $PG_DRIVER_JAR

もしくは、Maven の pom.xml ファイルに下記の依存関係を追加してください。

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.2.12</version>
</dependency>

最後に、WAR ファイルを Payara サーバにデプロイします。デプロイは Payara ドメインの autodeploy ディレクトリにコピーするだけでとても簡単です。

cp $APP_FOLDER_NAME/target/javaee-cafe.war ~/payara5/glassfish/domains/domain1/autodeploy

デプロイにはしばらく時間がかかりるため、それまでの間、次のコマンドでログを表示し、作業状況を確認します。

tail -f ~/payara5/glassfish/domains/domain1/logs/server.log

正常に、javaee-cafe アプリケーションのデプロイが完了すると、下記のようなメッセージが表示されます。

[2019-11-18T13:34:21.317+0000] [Payara 5.193] [INFO] [NCLS-DEPLOYMENT-02035] [javax.enterprise.system.tools.deployment.autodeploy] [tid: _ThreadID=104 _ThreadName=payara-executor-service-scheduled-task] [timeMillis: 1574084061317] [levelValue: 800] [[
[AutoDeploy] Successfully autodeployed : /home/abhishgu/payara5/glassfish/domains/domain1/autodeploy/javaee-cafe.war.]]

アプリケーションの動作確認

デプロイが完了したので、JavaEE アプリケーションの動作確認を行います。このアプリケーションは Web ブラウザーを利用してアクセスできます。しかし現時点で、Postgres のインスタンスと同様、Payara サーバーへパブリックのインターネットからは接続できません。アクセスするためには、az vm open-port を使用してファイアウォールルールを作成します。ここでは Payaraサーバーが使用するデフォルトのHTTPポート番号 8080 を公開します。

az vm open-port --port 8080 ¥
  --resource-group $AZURE_RESOURCE_GROUP_NAME  ¥
  --name $AZURE_VM_NAME

JSF のフロントエンドにアクセス

ブラウザで http://[ENTER_VM_IP]:8080/javaee-cafe にアクセスしてください。GUIで、コーヒーの作成、削除、表示できます。

REST API の使用

このアプリケーションは、コーヒーの作成、削除、表示のための REST API も公開しています。

export VM_IP=[to be filled]

コーヒーの作成

curl -X POST $VM_IP:8080/javaee-cafe/rest/coffees ¥
  -d '{"name":"cappuccino","price":"10"}' ¥ 
  -H "Content-Type: application/json"

curl -X POST $VM_IP:8080/javaee-cafe/rest/coffees ¥
  -d '{"name":"caffe-latte","price":"15"}' ¥
  -H "Content-Type: application/json"

コーヒー一覧の取得

curl -H "Accept: application/json" ¥
  $VM_IP:8080/javaee-cafe/rest/coffees

追加されているコーヒーのオプションのリスをを JSON で表示

ID 指定によるコーヒーの取得

curl -H "Accept: application/json"  ¥
   $VM_IP:8080/javaee-cafe/rest/coffees/1

ID 指定によるコーヒーの削除

curl -X DELETE $VM_IP:8080/javaee-cafe/rest/coffees/1
curl -H "Accept: application/json" ¥
  $VM_IP:8080/javaee-cafe/rest/coffees

カプチーノが削除され、一覧から削除されている事を確認

リソースのクリーンアップ

アプリケーションの動作確認が完了したら、リソースを削除します。今回、リソースグループで一元管理したので、単一のコマンドを実行して削除できます。
これにより、チュートリアルの一部で作成した全リソース（VM、Postgresなど）を削除できます、ご注意ください。

az group delete --name $AZURE_RESOURCE_GROUP_NAME

まとめ

ここでは、仮想マシンにデプロイしたアプリサーバーを使用して、Java EE アプリケーションを Azure にデプロイする方法と、長期的な永続化のためにマネージド・データベースを使用する方法を学びました。
前述したように、各オプションには独自の長所と短所があります。IaaS の場合、アプリケーション、デプロイメント用のインフラストラクチャ、スケーリング方法などを完全に制御できます。一方、インフラの管理、アプリケーションのサイジング、セキュリティ保護などは、 アプリケーション機能の一部として、ご自身で責任を持たなければなりません。

次のパートでは、Dockerコンテナープラットフォームを使用してJava EEアプリケーションをデプロイする方法について説明します。 どうぞお楽しみにみしてください！

2020年5月7日 at 3:32 午後 1件のコメント

大きなファイルを 各 Pod から参照する際、DaemonSet をキャッシュとして扱う

今回とあるお客様と出会い、ハックフェストを実施した際に出てきた課題と、私からお客様に提案した対処方法が、他でも同様のニーズがあった場合に有効になるのではないかと想定し、ここにその方法を共有します。

今回のやり方にあうユースケース：

1. 各 Pod から同一の巨大ファイル（GBクラスのファイル）を読み込む必要がある
2. ファイルは読み込みのみで、書き込みは発生しない
   （書き込みが必要な場合、別の手法で対応可能）
3. 巨大ファイルをできるだけ早く読み込みたい

※ ご注意：ユースケースに応じて手法は各自でご検討ください。

上記のようなユースケースの場合、DaemonSet をキャッシュとして利用する方法もご検討ください。各 Node に一つ Pod を起動する DaemonSet を利用し、DaemonSetの各 Pod にファイルのコピーを持たせます。そしてファイルを参照・取得したい Pod は、DaemonSet の Pod にあるコピー・ファイルを取得・参照する事で、ネットワークを跨いだ通信を削減できるだけでなく、ローカルでのファイル転送になるため短時間でファイルを取得できるようになります。
まぁ、普通に考えて当たり前の事を当たり前に説明しているだけなのですが。

一般的な Kubernetes での Volume のマウント方法

Kubernetes のドキュメントをご参照：
* Volumes
* Persistent Volumes

Azure で各 Pod からディスクを 1対1 でマウントする場合 (ReadWriteOnce)、Azure Disk を利用します。また複数の Pod から同一 Disk を共有したい場合 (ReadOnlyMany、ReadWriteMany)、Azure Files を利用します。 今回のユースケースでは、サイズの大きなファイルを複数の Pod から参照したいので、通常であれば Azure Files (ReadOnlyMany) を選択します。

具体的には、下記の手順で Azure Files を作成し、Kubernetes の Persistence Volume として Azure Files を 利用できます。

$ export AKS_PERS_STORAGE_ACCOUNT_NAME=myfilestorageaccount
$ export AKS_PERS_RESOURCE_GROUP=Yoshio-Storage
$ export AKS_PERS_LOCATION=japaneast
$ export AKS_PERS_SHARE_NAME=aksshare

$ az storage account create -n $AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -l $AKS_PERS_LOCATION --sku Standard_LRS

$ export AZURE_STORAGE_CONNECTION_STRING=`az storage account show-connection-string -n $AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -o tsv`

$ az storage share create -n $AKS_PERS_SHARE_NAME

$ STORAGE_KEY=$(az storage account keys list --resource-group $AKS_PERS_RESOURCE_GROUP --account-name $AKS_PERS_STORAGE_ACCOUNT_NAME --query "[0].value" -o tsv)

$ kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=$AKS_PERS_STORAGE_ACCOUNT_NAME --from-literal=azurestorageaccountkey=$STORAGE_KEY

続いて、これを Pod からマウントするために volumeMounts, volumes の設定を各 Pod で行います。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ubuntu
  template:
    metadata:
      labels:
        app: ubuntu
        version: v1
    spec:
      containers:
      - name: ubuntu
        image: ubuntu
        command:
          - sleep
          - infinity
        volumeMounts:
          - mountPath: "/mnt/azure"
            name: volume
        resources:
          limits:
            memory: 4000Mi
          requests:
            cpu: 1000m
            memory: 4000Mi
        env:
          - name: NODE_IP
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
      volumes:
        - name: volume
          azureFile:
            secretName: azure-secret
            shareName: aksshare
            readOnly: true

※ 今回ファイルサイズの大きなファイルをコピーするため４GBのメモリをアサインしています。

上記のファイルを deployment.yaml として保存し下記のコマンドを実行してください。

$ kubectl apply -f deployment.yaml

Pod が正常に起動したのち、Pod 上で mount コマンドを実行すると Azure Files が /mnt/azure にマウントされていることを確認できます。

$ kubectl exec -it ubuntu-884df4bfc-7zgkz mount |grep azure
//**********.file.core.windows.net/aksshare on /mnt/azure type cifs (rw,relatime,vers=3.0,cache=strict,username=********,domain=,uid=0,noforceuid,gid=0,noforcegid,addr=40.***.***.76,file_mode=0777,dir_mode=0777,soft,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

この時、このファイルの実態は Azure Storage の Files Share (***************.file.core.windows.net/aksshare) 上に存在しています。

Pod から /aksshare に存在するファイルを参照する際にファイルを SMB プロトコルを利用してダウンロードします。
実際に、/mnt/azure にあるサイズの大きなファイルを Pod 内にコピーします。

# date
Wed Jan 15 16:29:03 UTC 2020
# cp /mnt/azure/Kuberenetes-Operation-Demo.mov ~/mount.mov
# date
Wed Jan 15 16:29:54 UTC 2020 (51秒)

上記を確認すると Pod に約 3 Gb の動画ファイルをコピーするのに 51 秒ほど時間を要している事がわかります。仮に複数の Pod が起動し同一ファイルを参照した場合、ネットワークをまたいでファイルコピーが繰り返されます。これが通常の利用方法になります。

そして今回は、このファイル共有におけるネットワーク転送回数、スピードなどを DaemonSet を利用し改善します。

DaemonSet をキャッシュとして利用するための環境構築

FROM alpine:3.6

RUN apk update && \
    apk add --no-cache nginx

RUN apk add curl

ADD default.conf /etc/nginx/conf.d/default.conf

EXPOSE 80
RUN mkdir /app
RUN mkdir -p /run/nginx

WORKDIR /app
CMD nginx -g "daemon off;"

上記の内容を Dockerfile として保存してください。

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  root /app;

  location / {
  }
}

上記の内容を default.conf として保存してください。

このイメージをビルドし Azure Container Registry に Push します。

$ docker build -t tyoshio2002/nginxdatamng:1.1 .
$ docker tag tyoshio2002/nginxdatamng:1.1 yoshio.azurecr.io/tyoshio2002/nginxdatamng:1.1
$ docker login -u yoshio yoshio.azurecr.io 
Password: 
$ docker push yoshio.azurecr.io/tyoshio2002/nginxdatamng:1.1

次に Kubernetes から Azure Container Registry に接続するための Secret を作成します。

kubectl create secret docker-registry docker-reg-credential --docker-server=yoshio.azurecr.io --docker-username=yoshio  --docker-password="***********************" --docker-email=foo-bar@microsoft.com

Azure Container Registry にイメージを Push したので、Daemonset のマニュフェストを記述します。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: mydaemonset
  labels:
    app: mydaemonset
spec:
  selector:
    matchLabels:
      name: mydaemonset
  template:
    metadata:
      labels:
        name: mydaemonset
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      imagePullSecrets:
        - name: docker-reg-credential
      volumes:
        - name: host-pv-storage
          hostPath:
            path: /mnt
            type: Directory
      containers:
      - name: nginx
        image: yoshio.azurecr.io/tyoshio2002/nginxdatamng:1.1
        volumeMounts:
         - name: host-pv-storage
           mountPath: /mnt
        resources:
          limits:
            memory: 4000Mi
          requests:
            cpu: 1000m
            memory: 4000Mi
        lifecycle:
          postStart:
            exec:
              command:
                - sh
                - -c
                - "curl https://myfilestorageaccount.blob.core.windows.net/fileshare/Kuberenetes-Operation-Demo.mov -o /app/aaa.mov"
      terminationGracePeriodSeconds: 30

※ 今回は検証を簡単にするため、単一ファイル (Kuberenetes-Operation-Demo.mov) を postStart のフェーズで /app 配下にダウンロードしています。複数ファイルを扱う場合、コンテナのイメージ内で複数ファイルをダウンロードする仕組みを別途実装してください。また Nginx をカスタマイズ、もしくは他の Web サーバ、App サーバを利用する事でコンテンツキャッシュを効かせるなど効率化をはかることも可能かと想定します。

上記マニュフェストファイルを daemonset.yaml として保存し、下記のコマンドを実行してください。

$ kubectl apply -f daemonset.yaml

DaemonSet を作成したのち、DaemonSet を Service として登録します。Service を作成する事で各ノードの 30001 番ポート番号にアクセスし Nginx に Node の IP アドレスとポート番号でアクセスできるようにします。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: daemonset-service
  name: daemonset-service
spec:
  ports:
  - port: 80
    name: http
    targetPort: 80
    nodePort: 30001
  selector:
    name: mydaemonset
  sessionAffinity: None
  type: NodePort

上記を service.yaml として保存し、下記のコマンドを実行してください。

$ kubectl apply -f service.yaml

Nginx の DaemonSet と Ubuntu の Deployment をそれぞれ配備したのち、下記のコマンドを実行し、どのノードでどの Pod が動作しているかを確認します。

$ kubectl get no -o wide
NAME                                STATUS   ROLES   AGE    VERSION                         INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
aks-agentpool-41616757-vmss000000   Ready    agent   176m   v1.15.7                         10.240.0.4            Ubuntu 16.04.6 LTS   4.15.0-1064-azure   docker://3.0.8
aks-agentpool-41616757-vmss000001   Ready    agent   176m   v1.15.7                         10.240.0.35           Ubuntu 16.04.6 LTS   4.15.0-1064-azure   docker://3.0.8
aks-agentpool-41616757-vmss000002   Ready    agent   176m   v1.15.7                         10.240.0.66           Ubuntu 16.04.6 LTS   4.15.0-1064-azure   docker://3.0.8
virtual-node-aci-linux              Ready    agent   175m   v1.14.3-vk-azure-aci-v1.1.0.1   10.240.0.48                                  
$ kubectl get po -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE                                NOMINATED NODE   READINESS GATES
mydaemonset-gqlrw        1/1     Running   0          72m   10.240.0.24   aks-agentpool-41616757-vmss000000              
mydaemonset-nnn5l        1/1     Running   0          72m   10.240.0.50   aks-agentpool-41616757-vmss000001              
mydaemonset-pzvzx        1/1     Running   0          72m   10.240.0.82   aks-agentpool-41616757-vmss000002              
ubuntu-884df4bfc-7zgkz   1/1     Running   0          64m   10.240.0.69   aks-agentpool-41616757-vmss000002              
ubuntu-884df4bfc-gd26h   1/1     Running   0          63m   10.240.0.33   aks-agentpool-41616757-vmss000000              
ubuntu-884df4bfc-vh7rg   1/1     Running   0          63m   10.240.0.49   aks-agentpool-41616757-vmss000001              

上記では、ubuntu-884df4bfc-vh7rg は aks-agentpool-41616757-vmss000001 のノード上で動作しており、aks-agentpool-41616757-vmss000001 のノード上では　mydaemonset-nnn5l の DaemonSet の Pod がうごしています。
そして aks-agentpool-41616757-vmss000001 のノードの IP アドレスは 10.240.0.35 である事がわかります。Ubuntu の Pod 内では Pod が稼働している Node の IP アドレスを環境変数 $NODE_IP で取得できるように設定しています。

$ kubectl exec -it ubuntu-884df4bfc-vh7rg env|grep NODE_IP
NODE_IP=10.240.0.35

補足
最後に、ここでは環境構築方法の詳細説明を割愛しますが、Azure Blob Storage で Standard と Premium (高速) のそれぞれ作成し、それぞれのストレージに同一の動画ファイルを配置しておきます。
※ Azure Blob の Premium Storage は AKS の VNET と接続し VNET 経由でファイル取得しています。

その他の参考情報

* Azure Premium Storage: 高パフォーマンス用に設計する
* Troubleshoot Azure Files problems in Linux
* Troubleshoot Azure Files performance issues

検証内容

今回、下記の 4 点を検証しました。

1. Azure Files をマウントしたディレクトリに存在するファイルを Pod 内にコピーする際にかかる所用時間
2. Azure Blob (Standard) に存在するファイルを Pod で取得する際の所用時間
3. Azure Blob (Premium) に存在するファイルを Pod で取得する際の所用時間
4. DaemonSet 内にコピーしたファイルから取得する際の所用時間

1回目（実際の検証内容の動画）

下記のコマンド実行で確認しています

kubectl exec -it ubuntu-884df4bfc-vh7rg

## File Put on Azure Files (File shares : Samba)
$ date
$ cp /mnt/azure/Kuberenetes-Operation-Demo.mov ~/mount.mov
$ date

## File Put on Azure Blob (Containers)
$ curl https://myfilestorageaccount.blob.core.windows.net/fileshare/Kuberenetes-Operation-Demo.mov -o ~/direct.mov
$ curl https://mypremiumstorageaccount.blob.core.windows.net/fileshare/Kuberenetes-Operation-Demo.mov -o ~/premium2.mov
$ curl http://$NODE_IP:30001/aaa.mov -o ~/fromNodeIP.mov

※ ちなみに、DaemonSet の Nginx を利用した際も、初回アクセス時は時間がかかっています。これはおそらく Nginx のメモリに乗っていない為、取得に時間がかかっているように想定します。他の環境でも２回目アクセス以降は早くなっています。

検証結果のまとめ

上記、３回の実行結果より、一旦 DaemonSet にファイルを取得し、DaemonSet のキャッシュからファイルを入手するのが最も高速に入手できる事がわかりました。
Premium のストレージを利用する事で Standard のストレージよりも高速にファイル転送ができますが、Premium にすると Standard より高コストになります。また、Storage からの入手の場合、毎回ネットワークを経由してのダウンロードになる事から、それを考えても、一旦同一のノード(VM) にファイルを取ってきて、そこから入手する方が最も効率的で早い事は当たり前ですね。

DaemonSet を利用する利点
ネットワーク通信量の削減
ファイル取得スピードの高速化
DaemonSet 内のコンテナの実装を機能豊富にすれば、他にも用途が広がる（例：書き込み対応など）

懸念事項

* 現在は、特定の単一ファイルを取得していますが、複数ファイルを扱う場合、もしくはファイルの更新があった場合は、DaemonSet の内部で定期的に更新をチェックし、更新分をダウンロードする仕組みなどを実装する必要あり
* DaemonSet の Pod 内のファイルサイズが肥大化する可能性がありクリーン・アップをする必要がある
* ファイルの書き込みについては、今回の検証方法をそのまま利用した場合は対応は難しいが、DaemonSet 内のコンテナで独自に In Memory Grid 製品のような機能を実装すれば対応かと想定します。

最後に：
その他にも、内部的に検証をしたのですが、説明内容が増え視点がぼやける可能性があった為、特に効果的な点だけに絞ってまとめました。また、極力簡単にするために、DaemonSet で Nginx を使用していますが、Nginx の部分をさらにチューニングをしたり、Nginx の部分を他の実装に変更するなどで、さらなるパフォーマンス向上も見込まれるかと思います。

ぜひ、こちらの情報を元にさらなるチューニングなどを施していただければ誠に幸いです。

2020年1月17日 at 6:05 午後

日本全国 Java & AKS (k8s) サマー・ツアー 開始

7月下旬から、8月下旬の約１ヶ月をかけて、日本全国で Java & AKS (Kubernetes) のサマー・ツアーを開始します。

既に、昨日(7月27日)、一昨日(7月28日)と仙台で Kubernetes のハッカソン・イベントを開催してきました。

今後の日本全国サマー・ツアーの予定は下記の通りです。ぜひ各地方のエンジニアの皆様どうぞお越しください。

● 仙台(7/27-7-28)：https://jazug.connpass.com/event/135986/

● 札幌(7/29)：https://jazug.connpass.com/event/137069/

● 東京女子部(8/3)：https://jazug.connpass.com/event/137077/
● Java 女子部(8/3)：https://javajo.doorkeeper.jp/events/94041

● 名古屋(8/5)：https://75az.connpass.com/event/137002/

● 大阪 Day 1(8/7)：https://jazug.connpass.com/event/136591/
● 大阪 Day 2(8/8)：https://kanjava.connpass.com/event/139275/

● 岡山(8/10)：https://okajug.doorkeeper.jp/events/94008

● 広島(8/11)：https://hiroshima-jug.connpass.com/event/135650/

● 福岡(8/17-8/18)：https://jazug.connpass.com/event/138372/

● 熊本(8/19)：https://kumamotojava.doorkeeper.jp/events/94011

● 沖縄(8/24-8/25)：https://java-kuche.doorkeeper.jp/events/94636

● 東京(8/31) : Coming Soon

皆様とお会いできるのを心より楽しみにしています。

2019年7月29日 at 5:15 午後 1件のコメント

Quarkus: コンテナ上で Java アプリを高速起動する新しい手法のご紹介

Docker 環境上で Java のアプリを起動するのは遅いと思っていらっしゃる方は必見!!
どうぞ下記の内容をご参照いただき、どうぞお試しください！！

先日、Red Hat から Quarkus (https://quarkus.io) という新しい技術が発表されました。こちらを実際に試して見ましたが、想定通りというか、まさにこれを待っていた！！という技術でした。今後、私の中で注目の技術の一つになりそうです。もし、Docker/k8s 上で Java アプリを動かす方は、こちらの方法をご覧いただき、ぜひ試しください。

※ GraalVM については、きしださんや Java Champion である阪田さんがまとめてくださっていますので、ここではその詳細説明を割愛させていただきます。
* GraalVMについて (きしださん)
* 詳説GraalVM(1) イントロダクション(阪田さん)

事前準備

• GraalVM の入手 (https://github.com/oracle/graal)
• JDK 8 以上の入手
• Maven/Gradle の入手

GraalVM を入手したのち、.bash_profile などに環境変数 GRAALVM_HOME を指定しておきます。

GRAALVM_HOME=/Library/Java/JavaVirtualMachines/graalvm-ce-1.0.0-rc13/Contents/Home
export GRAALVM_HOME

それでは、実際に試して見ましょう。

1. Quarkus のクィック・スタートに従い Java のプロジェクトを作成します

$ mvn io.quarkus:quarkus-maven-plugin:0.11.0:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=getting-started \
    -DclassName="org.acme.quickstart.GreetingResource" \
    -Dpath="/hello"

プロジェクトを作成すると下記のようなファイルが作成されます。

├── pom.xml
└── src
    ├── main
    │   ├── docker
    │   │   └── Dockerfile
    │   ├── java
    │   │   └── org
    │   │       └── acme
    │   │           └── quickstart
    │   │               └── GreetingResource.java
    │   └── resources
    │       └── META-INF
    │           ├── microprofile-config.properties
    │           └── resources
    │               └── index.html
    └── test
        └── java
            └── org
                └── acme
                    └── quickstart
                        ├── GreetingResourceTest.java
                        └── NativeGreetingResourceIT.java

2. Java のソースコードをビルドし Linux の Native バイナリを作成します

$ mvn package -Pnative -Dnative-image.docker-build=true

-Dnative-image.docker-build=true は Docker on Linux 上で実行するバイナリを生成する事を明示するオプションです。これを指定しない場合、ビルドをした環境（例えば Mac OS/X なら Mac ）用のバイナリが生成されます。

2.1 作成された Linux 用のバイナリを確認します

$ ls -l target/getting-started-1.0-SNAPSHOT-runner
-rwxr-xr-x 1 yoterada staff 20112760 3 11 13:52 getting-started-1.0-SNAPSHOT-runner

2.2 file コマンドでファイル内容を確認すると Linux ELF バイナリが作成されています

$ file getting-started-1.0-SNAPSHOT-runner
getting-started-1.0-SNAPSHOT-runner: ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
for GNU/Linux 2.6.32, BuildID[sha1]=61ef9e78267993b688b9cf2de04e2aff9f1a4bfa, 
with debug_info, not stripped

3. Docker のビルド

Dockerfile のサンプルも下記の Dockerfile が自動的に作成されていますので、こちらをそのまま利用してビルドを行います。
17行目の COPY でビルド時に生成された Linux ELF バイナリを追加しています。

自動生成された Dockerfile

####
# Before building the docker image run:
#
# mvn package -Pnative -Dnative-image.docker-build=true
#
# Then, build the image with:
#
# docker build -f src/main/docker/Dockerfile -t quarkus/getting-started .
#
# Then run the container using:
#
# docker run -i --rm -p 8080:8080 quarkus/getting-started
#
###
FROM registry.fedoraproject.org/fedora-minimal
WORKDIR /work/
COPY target/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

Dockerfile からコンテナ・イメージをビルドしてください。

$ docker build -f src/main/docker/Dockerfile -t tyoshi2002/quarkus-quickstart:1.0 .

4. Docker の起動

$ docker run -i --rm -p 8080:8080 tyoshi2002/quarkus-quickstart:1.0
2019-03-11 05:10:42,697 INFO [io.quarkus] (main) Quarkus 0.11.0 started in 0.005s. Listening on: http://0.0.0.0:8080
2019-03-11 05:10:42,699 INFO [io.quarkus] (main) Installed features: [cdi, resteasy]

私の環境では 0.005 秒で CDI+REST アプリが起動できました。
Quarkus 0.11.0 started in 0.005s. Listening on: http://0.0.0.0:8080

5. 動作確認

$ curl http://localhost:8080/hello
hello

6. 備考

$ mvn compile quarkus:dev

こちらで起動したのち、ソースコードを修正しコンテンツを再読み込みします。
すると、再起動は不要で修正されたコードの内容を確認することができます。

7. 注意事項

8. Extension

Quarkus のアプリケーションに対して、追加のエクステンションを追加できます。追加可能なエクステンションのリストは下記から参照できます。

$ mvn quarkus:list-extensions
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
[INFO] Scanning for projects...
[INFO] 
[INFO] ----------------------< org.acme:getting-started >----------------------
[INFO] Building getting-started 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- quarkus-maven-plugin:0.11.0:list-extensions (default-cli) @ getting-started ---
[INFO] Available extensions:
[INFO] 	 * Agroal - Database connection pool (io.quarkus:quarkus-agroal)
[INFO] 	 * Arc (io.quarkus:quarkus-arc)
[INFO] 	 * AWS Lambda (io.quarkus:quarkus-amazon-lambda)
[INFO] 	 * Camel Core (io.quarkus:quarkus-camel-core)
[INFO] 	 * Camel Infinispan (io.quarkus:quarkus-camel-infinispan)
[INFO] 	 * Camel Netty4 HTTP (io.quarkus:quarkus-camel-netty4-http)
[INFO] 	 * Camel Salesforce (io.quarkus:quarkus-camel-salesforce)
[INFO] 	 * Eclipse Vert.x (io.quarkus:quarkus-vertx)
[INFO] 	 * Hibernate ORM (io.quarkus:quarkus-hibernate-orm)
[INFO] 	 * Hibernate ORM with Panache (io.quarkus:quarkus-hibernate-orm-panache)
[INFO] 	 * Hibernate Validator (io.quarkus:quarkus-hibernate-validator)
[INFO] 	 * Infinispan Client (io.quarkus:quarkus-infinispan-client)
[INFO] 	 * JDBC Driver - H2 (io.quarkus:quarkus-jdbc-h2)
[INFO] 	 * JDBC Driver - MariaDB (io.quarkus:quarkus-jdbc-mariadb)
[INFO] 	 * JDBC Driver - PostgreSQL (io.quarkus:quarkus-jdbc-postgresql)
[INFO] 	 * Kotlin (io.quarkus:quarkus-kotlin)
[INFO] 	 * Narayana JTA - Transaction manager (io.quarkus:quarkus-narayana-jta)
[INFO] 	 * RESTEasy (io.quarkus:quarkus-resteasy)
[INFO] 	 * RESTEasy - JSON-B (io.quarkus:quarkus-resteasy-jsonb)
[INFO] 	 * Scheduler (io.quarkus:quarkus-scheduler)
[INFO] 	 * Security (io.quarkus:quarkus-elytron-security)
[INFO] 	 * SmallRye Fault Tolerance (io.quarkus:quarkus-smallrye-fault-tolerance)
[INFO] 	 * SmallRye Health (io.quarkus:quarkus-smallrye-health)
[INFO] 	 * SmallRye JWT (io.quarkus:quarkus-smallrye-jwt)
[INFO] 	 * SmallRye Metrics (io.quarkus:quarkus-smallrye-metrics)
[INFO] 	 * SmallRye OpenAPI (io.quarkus:quarkus-smallrye-openapi)
[INFO] 	 * SmallRye OpenTracing (io.quarkus:quarkus-smallrye-opentracing)
[INFO] 	 * SmallRye Reactive Messaging (io.quarkus:quarkus-smallrye-reactive-messaging)
[INFO] 	 * SmallRye Reactive Messaging - Kafka Connector (io.quarkus:quarkus-smallrye-reactive-messaging-kafka)
[INFO] 	 * SmallRye Reactive Streams Operators (io.quarkus:quarkus-smallrye-reactive-streams-operators)
[INFO] 	 * SmallRye Reactive Type Converters (io.quarkus:quarkus-smallrye-reactive-type-converters)
[INFO] 	 * SmallRye REST Client (io.quarkus:quarkus-smallrye-rest-client)
[INFO] 	 * Spring DI compatibility layer (io.quarkus:quarkus-spring-di)
[INFO] 	 * Undertow (io.quarkus:quarkus-undertow)
[INFO] 	 * Undertow WebSockets (io.quarkus:quarkus-undertow-websockets)
[INFO] 
Add an extension to your project by adding the dependency to your project or use `mvn quarkus:add-extension -Dextensions="name"`
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.696 s
[INFO] Finished at: 2019-03-11T19:45:32+09:00
[INFO] ------------------------------------------------------------------------

上記のリストを元に、追加するエクステンションの groupId と artifactId を指定し追加ができます。

$ mvn quarkus:add-extension -Dextensions="groupId:artifactId"　

例：

$ mvn quarkus:add-extension -Dextensions="io.quarkus:quarkus-smallrye-health"　

9. さいごに

その他の Java on Azure に関する日本語情報へのリンク

2019年3月11日 at 3:27 午後 1件のコメント