新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

IBM Developer Blog

IBM Developer サイトで最新の出来事をフォローし、情報を入手しましょう。

Spring のモダナイゼーションとは、Spring Boot v2 を使用するように既存の Spring Framework および Spring Boot v1 アプリケーションをアップグレードするプロセス…


このコンテンツは「Spring Modernization」の翻訳です。

Spring のモダナイゼーションとは、Spring Boot v2 を使用するように既存の Spring Framework および Spring Boot v1 アプリケーションをアップグレードするプロセスのことです。Pivotal は、既存のアプリケーションの Spring Boot v2 へのモダナイゼーションが必要となる可能性のある、サポート対象の Spring バージョンのリストに変更を加えました。

IBM は Open Liberty プロジェクトで Spring Boot のサポートを提供し、ランタイムと Docker イメージを Spring Boot に合わせて最適化しました。

Open Liberty ランタイム上で Spring Boot アプリケーションを実行することには、次のメリットがあります。

  • パフォーマンス。ベンチマークでは、スループットと応答時間のどちらの点でも、Liberty のパフォーマンスが Tomcat よりも上回っていると示されています。
  • サイズ。Liberty のメモリー・フットプリントは Tomcat を下回ります。けれどもさらに重要なのは、Spring Boot ライブラリーはランタイム・ライブラリーから分離できるという点です。Docker がレイヤーを重ねてイメージをビルドする仕組みを考えると、最適化された形でイメージをビルドすれば、アプリケーションの部分がかなり小さくなります。つまり、ビルド時間が短くなるということです。さらに、アプリケーションのすべてのバージョンを保管する場合、バージョン間の差分も大幅に小さくなります。
  • サポート。IBM Cloud Paks を使用して OpenShift 上で実行する場合、このライセンシング・モデルには Liberty ランタイムの使用が含まれているので、追加料金なしで Liberty を使用できます。Liberty に関するサポートが必要になったとしても、ライセンスにサポートが含まれています。Tomcat で標準的な Spring Boot を使い続けるとしたら、サポート対象外のプラットフォーム上で実行するか、Tomcat ランタイムのサポートに追加料金を支払うかのいずれかを選択しなければなりません。
  • 一貫性のあるランタイム・モデル。Liberty の実行に関しては多くのベスト・プラクティスがあり、特に、Kubernetes/OpenShift に関連するものが多くあります。これらのベスト・プラクティスは、OpenShift に統合するよう意図された指標とモニタリング・ツールに反映されています。こうした指標とモニタリング・ツールが環境のメンテナンスに効果を発揮するとしたら、Liberty を使用するとベスト・プラクティスの多くを活用できます。

このリポジトリーに格納されているソリューションは、Spring アプリケーションを Open Liberty 上で実行する Spring Boot にアップグレードし、IBM Cloud Pak for Applications を利用して Red Hat OpenShift にデプロイされるようモダナイゼーションした結果です。

アプリケーションの概要

Pet Clinic は、Spring Framework の特徴と機能をデモンストレーションするために 2003 年に作成されたアプリケーションです。当初の Pet Clinic アプリケーションについての説明は、このリンク先の Readme「The Pet Clinic Application」セクションに記載されています。

アプリケーションのモダナイゼーション方法

Spring Framework アプリケーションを Spring Boot と Open Liberty を使用して OpenShift 上で動作するようにモダナイゼーションするために行った、デモ・アプリケーションのコード変更ビルドおよびデプロイのフェーズを以下に説明します。

コードの変更

Pet Clinic はオープンソース・コミュニティーにより、2013 年に Spring Framework 2.5 から Spring Framework 3.0 にアップグレードされ、さらに 2016 年に Spring Boot を使用するようにモダナイゼーションされました。コードの変更プロセスはこのドキュメントの対象外ですが、一般的なモダナイゼーション・プロセスを説明しているページへのリンクを以下に記載します。

ビルド

ビルド・フェーズでデモ・アプリケーションの Dockerfile ファイルが作成されました。

Spring Boot アプリケーションの JAR または WAR ファイルは自己完結型の成果物です。最終成果物には、Tomcat、Jetty、または Undertow などの組み込みサーバー実装を含むアプリケーションのコンテンツと併せて、アプリケーションのすべての依存関係がパッケージ化されます。そのため、JVM を備えたサーバーであればどのサーバー上でも簡単に実行できる、不足のない成果物になっています。その一方で、必要最小限の hello world Spring Boot Web アプリケーションの場合でさえも、成果物のサイズはかなりの大きさになります。

以下に、自己完結型 jar に対応する Pet Clinic の Dockerfile を記載します。

FROM openliberty/open-liberty:springBoot2-ubi-min
COPY --chown=1001:0 spring-petclinic/target/spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar /config/dropins/spring/

以下に示すのは、Docker イメージを最適化するために、IBM が開発した二層構造手法を使用して生成された Dockerfile です。

FROM openliberty/open-liberty:springBoot2-ubi-min as staging
USER root
COPY spring-petclinic/target/spring-petclinic-2.1.0.BUILD-SNAPSHOT.jar /staging/fatClinic.jar

RUN springBootUtility thin \
 --sourceAppPath=/staging/fatClinic.jar \
 --targetThinAppPath=/staging/thinClinic.jar \
 --targetLibCachePath=/staging/lib.index.cache

FROM openliberty/open-liberty:springBoot2-ubi-min
USER root
COPY --from=staging /staging/lib.index.cache /opt/ol/wlp/usr/shared/resources/lib.index.cache
COPY --from=staging /staging/thinClinic.jar /config/dropins/spring/thinClinic.jar

RUN chown -R 1001.0 /config && chmod -R g+rw /config
RUN chown -R 1001.0 /opt/ol/wlp/usr/shared/resources/lib.index.cache && chmod -R g+rw /opt/ol/wlp/usr/shared/resources/lib.index.cache

USER 1001

最終的なファイルは以下のリンク先で確認できます。

  • Dockerfile
  • コードと構成ファイルを git リポジトリーにコミットする前に、コンテナー化されたアプリケーションをローカルでテストしました。

デプロイ

デプロイ・フェーズでは、アプリケーションのビルドおよびデプロイメント・パイプラインを自動化するために必要な、Jenkins、Kubernetes、Red Hat OpenShift の成果物が作成されました。説明を目的に、開発、ステージング、本番の各環境をシミュレーションする 3 つの異なる Red Hat OpenShift プロジェクトにアプリケーションがデプロイされています。以下の図は、パイプラインでのフローを示しています。詳細な説明については、このリンク先のページをご覧ください。

パイプライン

パイプラインでのステップは以下のとおりです。

  1. 必要な SecurityContextConstraints 定義を作成して、WebSphere 用の Red Hat OpenShift クラスターを構成します。構成ファイルは以下のリンク先で確認できます。
  2. Red Hat OpenShift ビルド・テンプレートを作成します。このテンプレート・ファイルは、ビルド・プロセス関連の Red Hat OpenShift 成果物 (ImageStreamBuildConfig など) を定義するために使用されます。このテンプレート・ファイルは以下のリンク先で確認できます。
  3. Red Hat OpenShift デプロイメント・テンプレートを作成します。このテンプレート・ファイルは、Pet Clinic アプリケーション関連の Red Hat OpenShift 成果物 (DeploymentConfigServiceRoute など) を定義するために使用されます。このテンプレート・ファイルは以下のリンク先で確認できます。
  4. パイプラインの Jenkins Jenkinsfile を作成します。Jenkinsfile で定義されるのは、パイプラインで Pet Clinic アプリケーションをビルドするところから、不変の Docker イメージを作成し、そのイメージを dev 環境から stage 環境、prod 環境に移行するまでのステップです。このファイルは以下のリンク先で確認できます。
  5. build プロジェクトを作成し、ビルド・テンプレートをロードして Jenkins を構成します。
  6. devstageprod の各プロジェクトを作成して、デプロイメント・テンプレートをロードします。
  7. パイプラインを検証します。

これらのステップを複製する詳細な手順については、このリンク先のページをご覧ください。

アプリケーションをデプロイする

このセクションでは、モダナイゼーションされた、Open Liberty コンテナー内の Pet Clinic アプリケーションを Red Hat OpenShift クラスターにデプロイする手順を説明します。

前提条件

次のものが必要です。

  • Git CLI
  • Red Hat OpenShift 3.11 とクラスター管理者権限
  • oc CLI
  • DB2 データベース

プロジェクトのリポジトリーを取得する

以下のコマンドを実行すると、メインの GitHub リポジトリー・ページからプロジェクトのリポジトリーを複製して、このバージョンのアプリケーションに対応するブランチをチェックアウトできます。

git clone https://github.com/ibm-cloud-architecture/cloudpak-for-applications.git
cd cloudpak-for-applications
git checkout spring

Security Context Constraints を作成する

Open Liberty Docker イメージを OpenShift クラスター内にデプロイして実行するには、その前に、クラスターのセキュリティーに関する特定の側面を構成する必要があります。このリンク先のページに記載されている Security Context Constraints が、Open Liberty Docker コンテナーを実行するサービス・アカウントに、コンテナーが正常に機能するために必要な権限を付与します。

クラスター管理者権限で以下のコマンドを実行することで、このリンク先のファイルを使用して Security Context Constraints (SCC) を作成できます。

cd Deployment/OpenShift
oc apply -f ssc.yaml

プロジェクトを作成する

このシナリオでは、以下の 4 つの Red Hat OpenShift プロジェクトが必要です。

  • ビルド: このプロジェクトに、Jenkins サーバーと、アプリケーション・イメージを作成するために使用する成果物を格納します。
  • 開発: このプロジェクトが、このアプリケーションの development 環境になります。
  • ステージング: このプロジェクトが、このアプリケーションの staging 環境になります。
  • 本番: このプロジェクトが、このアプリケーションの production 環境になります。

プロジェクトを簡単に作成できるよう、このリンク先のファイルに 4 つのプロジェクトをまとめて定義しています。

以下のコマンドを実行するだけで、4 つのプロジェクトのすべてが作成されます。

oc create -f liberty-projects.yaml

サービス・アカウントを作成する

Kubernetes のベスト・プラクティスは、アプリケーション用のサービス・アカウントを作成することです。サービス・アカウントが、ポッド内で実行されるプロセスのアイデンティティーとなります。このステップでは、devstageprod の各プロジェクト内で websphere という名前の新しいサービス・アカウントを作成し、前のステップで作成した Security Context Constraint をそれぞれのサービス・アカウントに追加します。

以下のコマンドを実行すると、websphere サービス・アカウントが作成されて、各プロジェクト内で作成されたサービス・アカウントに ibm-websphere-scc がバインドされます。

oc create serviceaccount websphere -n petclinic-liberty-dev
oc create serviceaccount websphere -n petclinic-liberty-stage
oc create serviceaccount websphere -n petclinic-liberty-prod
oc adm policy add-scc-to-user ibm-websphere-scc -z websphere -n petclinic-liberty-dev
oc adm policy add-scc-to-user ibm-websphere-scc -z websphere -n petclinic-liberty-stage
oc adm policy add-scc-to-user ibm-websphere-scc -z websphere -n petclinic-liberty-prod

Jenkins をデプロイする

一部の Red Hat OpenShift クラスターはビルド・プロジェクト内で Jenkins インスタンスを自動的にプロビジョニングするように構成されています。クラスターが Jenkins の自動プロビジョニングに対応するように構成されていない場合は、以下のコマンドで Jenkins をデプロイできます。

oc project petclinic-liberty-build
oc new-app jenkins-persistent

Jenkins サービス・アカウントを更新する

Jenkins マスターのプロビジョニング時に、jenkins という名前のサービス・アカウントが作成されます。このサービス・アカウントには、このアカウントで実行されるプロジェクト内でのみ新しい成果物を作成する権限が付与されます。このシナリオの場合、Jenkins は devstageprod の各プロジェクト内で成果物を作成する必要があります。

jenkins サービス・アカウントが devstageprod の各プロジェクト内で成果物を編集できるようにするには、以下のコマンドを実行します。

oc policy add-role-to-user edit system:serviceaccount:petclinic-liberty-build:jenkins -n petclinic-liberty-dev
oc policy add-role-to-user edit system:serviceaccount:petclinic-liberty-build:jenkins -n petclinic-liberty-stage
oc policy add-role-to-user edit system:serviceaccount:petclinic-liberty-build:jenkins -n petclinic-liberty-prod

デプロイメント・テンプレートをインポートする

Red Hat OpenShift テンプレートを使用すると、成果物の作成が容易になるとともに、同じ成果物を繰り返し作成できます。このリンク先のページに記載されているテンプレート定義では、CustomerOrderServices アプリケーションを対象とした Kubernetes の ServiceRouteDeploymentConfig を定義しています。

gse-spring-deploy テンプレートが定義する要素は次のとおりです。

  • ポート 908094439082 上で listen する service
  • ポート 9443 を外部に公開する route
  • Open Liberty コンテナーをホストする DeploymentConfig
    • コンテナーの image は Jenkins パイプラインによって ImageStream に取り込まれ、そこから取得されます。
    • 各環境に固有の情報を注入できるよう、アプリケーションで使用する DB2 データベースの環境変数が定義されています。
    • ポート 9443 がアクティブであることを確認する、livenessreadinessプローブが定義されています。
    • securityContext は、ファイルシステムに対する読み取り/書き込みアクセスを許可し、コンテナーを user 1001 として実行するように設定されています。
    • 新しいイメージが ImageStream にロードされた場合、または構成の変更が検出された場合は、デプロイメントが更新されます。

以下のコマンドを実行すると、gse-spring-deploy という名前のテンプレートが devstageprod の各プロジェクト内にロードされます。

oc create -f template-liberty-deploy.yaml -n petclinic-liberty-dev
oc create -f template-liberty-deploy.yaml -n petclinic-liberty-stage
oc create -f template-liberty-deploy.yaml -n petclinic-liberty-prod

デプロイメント定義を作成する

このステップでは gse-spring-deploy テンプレートを使用して、petclinic-liberty という名前の Red Hat OpenShift アプリケーションdevstageprod の各名前空間内に作成します。

このステップを完了すると、次の要素が定義されます。

  • ポート 908094439082 上で listen する service
  • ポート 9443 を外部に公開する route
  • Open Liberty コンテナーをホストする DeploymentConfig。このデプロイメント構成は、Jenkins パイプラインによって ImageStream に Docker イメージがロードされるまで待機します。

以下のコマンドを実行して、テンプレートからアプリケーションを作成します。

oc new-app gse-spring-deploy -p APPLICATION_NAME=petclinic-liberty -n petclinic-liberty-dev
oc new-app gse-spring-deploy -p APPLICATION_NAME=petclinic-liberty -n petclinic-liberty-stage
oc new-app gse-spring-deploy -p APPLICATION_NAME=petclinic-liberty -n petclinic-liberty-prod

ビルド・テンプレートをインポートする

このステップでは、build プロセスのテンプレートを build プロジェクト内にロードします。このリンク先に記載されているテンプレートが定義している要素は次のとおりです。

  • アプリケーション・イメージの ImageStream。ここに、Jenkins パイプラインによってイメージが取り込まれます。
  • Open Liberty の ImageStream。Open Liberty はここから最新バージョンの openliberty/open-liberty:springBoot2-ubi-min イメージをプルするために、DockerHub をモニタリングして更新の有無を確認します。
  • binary BuildConfig。Jenkins パイプラインでアプリケーションの Docker イメージをビルドするために使用されます。
  • jenkinsfile BuildConfig。GitHub 内の Jenkinsfile を使用して Pipeline を定義します。
  • テンプレートをインスタンス化するときに Open Liberty イメージと GitHub リポジトリーを指定するために使用されるパラメーター

以下のコマンドを実行すると、gse-springboot-build という名前のテンプレートが build プロジェクト内にロードされます。

oc create -f template-liberty-build.yaml -n petclinic-liberty-build

ビルド定義を作成する

このステップでは gse-springboot-build テンプレートを使用して、petclinic-liberty という名前の Red Hat OpenShift アプリケーションbuild 名前空間内に作成します。

このステップを完了すると、次の要素が定義されます。

  • アプリケーション・イメージの ImageStream。ここに、Jenkins パイプラインによってイメージが取り込まれます。
  • Open Liberty の ImageStream。Open Liberty はここから最新バージョンの openliberty/open-liberty:springBoot2-ubi-min イメージをプルするために、DockerHub をモニタリングして更新の有無を確認します。
  • binary BuildConfig。Jenkins パイプラインでアプリケーションの Docker イメージをビルドするために使用されます。
  • jenkinsfile BuildConfig。GitHub 内の Jenkinsfile を使用して Pipeline を定義します (URL は、アプリケーションの作成時にパラメーターとして指定します)。

以下のコマンドを実行して、テンプレートからアプリケーションを作成します。

oc new-app gse-springboot-build -p APPLICATION_NAME=petclinic-liberty -p SOURCE_URL="https://github.com/ibm-cloud-architecture/cloudpak-for-applications" -n petclinic-liberty-build

パイプラインを実行する

新しく作成されたパイプラインは、Red Hat OpenShift コンソールから起動できます。このコンソールで Jenkins ログにアクセスできますが、OCP コンソールでもパイプラインの進行状況を追跡できます。

  1. 「Application Console (アプリケーション・コンソール)」 –> 「Pet Clinic on Liberty – Build」 –> 「Builds (ビルド)」 –> 「Pipelines (パイプライン)」の順に選択し、「Start Pipeline (パイプラインを起動)」ボタンをクリックします。
    パイプラインを起動する画面のスクリーンショット
  2. パイプラインが起動したら、「View Log (ログを表示)」リンクをクリックして Jenkins 管理コンソールを開きます。パイプラインでの最初のビルド時には、「View Log (ログを表示)」リンクが表示されるまでに 1、2 分かかる場合があります。
    「View Log (ログを表示)」リンクを示す画面のスクリーンショット
  3. ログインするよう求められたら、OpenShift アカウントを使用してログインし、必要なアクセス権限を付与します。Jenkins コンソールに以下のようなログが表示されます。
    Jenkins ログを示す画面のスクリーンショット
  4. OpenShift コンソールに戻り、パイプラインの進行状況を追跡します。
    実行中のパイプランを示す画面のスクリーンショット
  5. パイプラインは最終的に「Promotion Gate (プロモーション・ゲート)」で停止し、本番環境にデプロイする承認を求めます。以下に示されている「Input Required (要入力)」リンクをクリックします。
    プロモーション・ゲートを示す画面のスクリーンショット
  6. 「Promote application to Production (アプリケーションを本番環境にプロモートしますか)」という質問が表示されたら、「Proceed (続行)」をクリックします。
    「Proceed (続行)」ボタンを示す画面のスクリーンショット
  7. OpenShift コンソールに戻り、パイプラインが完了していることを確認します。
    完了したパイプラインを示す画面のスクリーンショット

アプリケーションを検証する

パイプラインが完了したら、Pet Clinic アプリケーションが devstageprod の各プロジェクト内にデプロイされて実行中になっていることを確認します。

  1. OpenShift コンソールで「Application Console (アプリケーション・コンソール)」 –> 「Pet Clinic on Liberty – Dev」 –> 「Applications (アプリケーション)」 –> 「Deployments (デプロイメント)」の順に選択し、「Latest Version (最新バージョン)」列に示されているリンクをクリックします。
    「Deployments (デプロイメント)」ページのスクリーンショット
  2. 使用されたイメージを含め、デプロイメントに関する情報が表示されます (イメージに付けられているタグは、stage および prod デプロイメントで同じです)。数分後に、コンテナーが動作可能としてマークされます。
    ポッドを示す画面のスクリーンショット
  3. 「Applications (アプリケーション)」 –> 「Routes (ルート)」の順にクリックし、アプリケーションのルートをクリックします。この URL は <アプリケーション名>-<プロジェクト名>. の形式になっています。この例の場合、プロジェクト名は petclinic-liberty-dev です。
    ルートを示す画面のスクリーンショット
  4. アプリケーションのホーム・ページが表示されます。「Find Owners (飼い主を探す)」をクリックした後、「Find Owner (飼い主を探す)」をクリックしてデータベース内に保管されている飼い主のリストを表示します。
    Dev プロジェクト内で実行中のアプリケーションを示す画面のスクリーンショット
  5. stage プロジェクトと prod プロジェクトについて、検証を繰り返します。

まとめ

このアプリケーションは当初の Spring Framework バージョンから Open Liberty 上で稼働する Spring Boot v2 バージョンに変更されて、IBM Cloud Pak for Applications によってデプロイされています。

IBM Developer Staff