既存アプリをKubernetesへきゃりー - Konveyor Tackleを使った評価と分析

OpenShift Advent Calendar 2022 18日目 の投稿です。
こんにちわ。Red HatでOpenShiftのSolution Architectを担当している北山 ( @spchilden ) です。
さて今日は、既存アプリをKubernetesへのきゃりーぱみゅぱみゅさんについて語りたいと思います。
大事なことなので先にお伝えしておくと、12/21 - 12/23とコーチェラ再現Liveがあるので是非参加しましょう。
「Special Live 2022 -Back To Coachella-」

イマ再び求められる「Twelve-Factor App」

さて、この1年OpenShiftビジネスに携わっていると、モダンなクラウドネイティブアーキテクチャというより、既存アプリケーションのコンテナ化から始めているユーザーさんと会話させてもらう機会が大きく増えました。
たしかにコミュニティ界隈ではマイクロサービス化を推進するため、Kafkaを使ったデータストリーミングやChange Data Captureを活用したデータ移行などが主流ですが、現場では、まず今あるアプリケーションをまずはコンテナに変えていくことから始めているユーザーさんが大半な気がしています。これを「Replatform」と呼んでたりします。
2022/11に開催されたCNDT 2022(Cloud NataiveDays Tokyo)でも少しこの件について触れさせていただきました。
なお、ログインすると動画も見れますので是非。

speakerdeck.com

Kubernetesの利用が浸透してきている一方で、とりあえず既存の仮想マシン上で動いていたアプリケーションをコンテナ化すればよいという発想は回避しないといけません。
つまり、Kubernetesでアプリケーションを動かすためには、そのプロセスはやはり「Twelve-Factor App」に従ってReplatformされるべきです。そうしないと、Kubernetes上で運用していても運用の複雑さが増すばかりで、結果としてコンテナ導入メリットを感じられなくなります。

architecturenotes.co

ただ、これ。。。
言うは易く行うは難し。

全部アプリケーション改修する予算やノウハウがあれば良いのですが、そう言ってられないのがエンタープライズの世界。
こうした開発者さんの悩みに応えるのが「Konveyor Tackle」です。

Konveyor Tackleの概要

「Konveyor Tackle」とは、KubernetesへのアプリケーションのReplatform、Refactoringを評価、優先順位付けしてくれるプロジェクトです。
はじめてこの名前を聞く方もいらっしゃるかもしれませんが、実はCNCFにもJOINしているオープンソースプロジェクトです。

www.konveyor.io

いまのところJavaアプリケーションを対象としたコンテナ化の評価をおこなっていますが、アプリケーション以外にもいくつかの移行ツールが用意されています。

プロジェクト	概要
Tackle Application Inventory	アプリケーションの評価(Tackle Pathfinder) および分析(windup)へのゲートウェイ
Tackle Pathfinder	Kubernetes上にアプリをデプロイするための適合性を評価するアンケートベースのツール
Tackle Controls	Application InventoryとPathfinderの評価にエンティティを付けて管理するツール
Tackle Container Advisor	自然言語処理を使用して、アプリケーションの記述を分析し、アプリケーションをコンテナ化するのに最適なコンテナーイメージを提案
Tackle Data Intensive Validity Advisor (DiVA)	アプリケーションのデータ レイヤーを分析し、さまざまなデータ ストアや分散トランザクションへの依存関係を検出
Tackle-DiVA Database Operator Adaption (DiVA-DOA)	Kubernetesのマニフェスト(YAML)を生成して、レガシーDBMSシステムを使用するアプリケーションを、HA DB クラスターで動作できるように移行を支援
Tackle Test Generator	モダナイズされた後のアプリケーションが同じように動作していることを確認
Tackle Data Gravity Insights	モノリシックアプリケーションのコードを洞察し、ドメイン駆動型マイクロサービスにリファクタリングを支援

いっぱいありますね。
今回はこの中からアプリケーションの分析(windup)をご紹介します。

Konveyor Tackleのインストール

今回は「Tackle Operator」を活用して、Tackle v2()をOpenShift v4.11上にインストールします。

事前準備

Tackleをインストールするには、合計5つの永続ボリューム(PV) が必要です。PVC を介して3つの RWO ボリュームと2つのRWX ボリュームが要求されます。

Name	Default Size	Access Mode	Description
hub database	5Gi	RWO	Hub DB
hub bucket	100Gi	RWX	Hub file storage
keycloak postgresql	1Gi	RWO	Keycloak backend DB
pathfinder postgresql	1Gi	RWO	Pathfinder backend DB
maven	100Gi	RWX	maven m2 repository

ここで戸惑っちゃうのが、RWXボリューム。…普通無いですよね。
ということで、事前に万能ストレージ「OpenShift Data Fundation(ODF)」をインストールしておきます。

(1) Operator Hubから「ODF」を検索してインストール

ODF Operator Install

(2) OperatorのSubscriptionを定義してインストール実行

詳細はこちら
第2章 動的ストレージデバイスを使用した OpenShift Data Foundation のデプロイ Red Hat OpenShift Data Foundation 4.11 | Red Hat Customer Portal

失敗しないための秘訣は、Install後に待つこと。ODFは様々なコンポーネントから出来ているため、「Installed」の表記に頼らず忍耐強く待ちましょう。

ODF Operator subscription

(3) CustomResource(Storage System)の作成

Operatorのインストールが終わったら、今度はCR(Storage System)を作成してODFクラスタを作ります。

詳細はこちら
2.4. OpenShift Data Foundation クラスターの作成 Red Hat OpenShift Data Foundation 4.11 | Red Hat Customer Portal

今回は以下のCR内容で検証しました。CRを作成した後も忍耐強く待ちましょう。

**Backing storage**   
Deployment type: Full deployment    
Backing storage type: gp2   
**Capacity and nodes**   
Cluster capacity: 2 TiB   
Selected nodes: 3 node   
CPU and memory: 48 CPU and 181.7 GiB memory    
Zone: 1 zone   
Taint nodes: Disabled   
Security and network   
Encryption: Disabled   
Network: Default (SDN)   

(4) ODFクラスタの確認

OpenShiftポータルのAdministrator Perspectiveから[Storage]>[Data Fundation]を選択し、以下の表記に変わればクラスタ作成は完了です。
ODFクラスタが立ち上がってそのボリュームが利用できるまで10分くらい待ちます。

Data Fundation Confirmation

Tackle Operatorのインストール

ボリュームが用意できたら、次にTackle Operatorをインストールしていきます。

詳細はこちら
GitHub - konveyor/tackle2-operator: Tackle Operator fully manages the deployment and life cycle of Tackle on Kubernetes and OpenShift.

(1) Operator Hubから「Tackle Operator」を検索してインストール

Tackle Operator Install

(2) OperatorのSubscriptionを定義してインストール実行

Tackle Operator subscription

(3) CustomResource(Tackle)の作成

Tackle Operatorには、CR(Tackle)の作成必須です。Operatorのインストール作業が終わるとすぐに作るように求められます。
また、通常通り[Operaors]>[Installed Operators]から「Tackle Operator」を選択し、[Tackle]タブにある「Create Tackle」からも設定が可能です。
ここで注意することは、先ほど作成したODFの領域をRWXストレージ領域として割り当てることです。通常であればフォームから作成しますが、フォームにストレージを設定する項目がないため今回はYAML形式でCRを記載してください。
CRには、hub_bucket_storage_classにODFで作成されたRWXのストレージクラス(ocs-storagecluster-cephfs)を設定します。
なお、CRの詳細はこちらからご確認下さい。

apiVersion: tackle.konveyor.io/v1alpha1
kind: Tackle
metadata:
  name: tackle
  namespace: konveyor-tackle
spec:
  feature_auth_required: 'true'
  hub_bucket_volume_size: "50Gi"
  hub_bucket_storage_class: "ocs-storagecluster-cephfs"
  cache_data_volume_size: "50Gi"

(4) Tackle UIの確認

CR(Tackle)によってインストールが終わると、Project[konveyor-tackle]のRouteにTackle UIへの接続URLが払い出されます。
OpenShiftポータルのAdministrator Perspectiveから[Networking]>[Routes]を選択し、[Tackle]のURLにブラウザから接続して以下が表示されたら完了です。

Konveyor Tacle Login Portal

ここでのデフォルトのユーザー名とパスワードは以下のとおりです。
Username: admin
Password: Passw0rd!

ログインすると、始めにパスワードの変更が求められます。

Tackle Controlsによるエンティティ登録

Tackleのポータルには「Application Inventory」「Reports」「Controls」が表示されます。まずは「Tackle Controls」から評価対象の構成要素を作成しておきます。
Tackle ControlsはApplication Inventoryで利用されるエンティティの管理です。これらはStakeholders(利害関係者)、Stakeholder groups(利害関係者グループ)、Job functions(職務)、Business Service(ビジネスサービス)、Tags(タグ タイプ)で構成されています。

Tackle Controls Portal

今回はサンプルのアプリケーション登録のため、必要がない場合は「エンティティ登録」は一旦スキップしていただいても構いません。

(1) Stekeholders(利害関係者)の登録

対象アプリケーションに携わる関係者とその属性を登録します。Tackle Controlsの[Stakeholders] タブから[Create new] を選択して情報を登録します。

Create stakeholders

(2) Stekeholder groups(利害関係者グループ)の登録

次に彼らのグループを登録します。Tackle Controlsの[Stakeholder groups] タブから[Create new] を選択して情報を登録します。

Create Stakeholder Groups

必要に応じて、先程登録したStakeholdersをメンバーに加えておきます。

(3) Business Service(ビジネスサービス)の登録

次にビジネスサービス名を登録します。Tackle Controlsの[Business Service] タブから[Create new] を選択して情報を登録します。

Create Business Service

必要に応じて、先程登録したStakeholdersをメンバーに加えておきます。
以上で最小の登録は完了です。

Confirm Stakeholder

Windupによる「Analyze(分析)」

次にWindupを使ってアプリケーションを分析してみましょう。
Application Inventryは、Tackle Pathfinderによる評価(Assessment)とWindupによる分析(Analysis)のインターフェイスです。双方行えますが、今回は分析の方を紹介します。

Application Inventory Portal

(1) Applicationの登録

まずは、Tackle Application Inventryの[Analysis]タブから[Create new]を選択して以下の情報を登録します。

Name: Customer
Description: Legacy Customers management service
Business Service: Retail
Tags: Tomcat, Java

Create new application

Applicationの登録が完了するとApplication Inventoryのページに一度戻ります。[Assessment]、[Analysis]の双方にApplicationが登録されていれば完了です。

(2) Analysis(分析)の開始

Tackle Application Inventryの[Analysis]タブから登録したApplicationを選択し、[Analysis]ボタンを押します。

Start Analysis

(3) Analysis Mode

立ち上がったポップアップからAnalysisの対象を登録します。
ここではローカルのサンプルをアップロードするため「Upload a local binary」を選択してください。

サンプルに使用するバイナリファイル(.war)は、事前にここからダウンロードしておきます。*1

ダウンロードしたcustomers-tomcat.warファイルをドラッグアンドドロップするか、ローカル ファイル システムからアップロードします。

Analysis Mode file upload

アップロードが完了するまで、おそらく数秒かかります。「Success: Uploaded binary file.」の表示が出るまで少し待ちましょう。登録が完了したら「Next」を押して次に行きます。

(4) Set Targets

次は変換先のターゲットオプションが表示されます。ここでは、移行するテクノロジーを選択します。
サンプルは Linuxコンテナをターゲットとして、独自JDKディストーションの依存を取り除くため、Containerization、Linux、 OracleJDK to OpenJDKをターゲットとして選択します。
登録が完了したら「Next」を押して次に行きます。

(5) Application Scope

診断するアプリケーションに関する依存関係のスコープが選べます。
今回はアプリケーション内部のライブラリだけで良いため、Application and internal dependencies onlyを選択してください。 　　

Scope Setting

ここも登録が完了したら「Next」を押して次に行きます。

(6) Application Scope

分析には、カスタムルールエンジンが使用されており、移行ターゲットに応じて多くのルールが付属されています。
またカスタムルールをXMLで独自に作成することで拡張も可能です。
ここではアプリで使用されている特定のライブラリの使用を検出し、削除を提案するカスタム ルールを提供してみます。

サンプルに使用するカスタムルールファイル(.xml)は、事前にここからダウンロードしておきます。 *2

ダウンロードしたカスタムルールファイルをドラッグ アンド ドロップするか、ローカル ファイル システムからアップロードします。

Custom Rules

カスタムルールの登録が確認できたら「Next」を押して次に行きます。

(7) Options

分析を微調整するためのオプションが表示されますが、今回はデフォルトのまま使用します。

Select Options

「Next」を押して次に行きます。

(8) Reviews

最後に全体の確認を行います。ここまで登録できると以下が表示されています。

Review analysis details
Review the information below, then run the analysis.

Applications: Customer
Mode: Upload a local binary
Targets:
   - openjdk
   - linux
   - cloud-readiness
Sources: 
   - java
Scope: Application and internal dependencies
Included packages: 
Excluded packages: 
Custom rules:
   - corporate-framework-config.windup.xml
Excluded rules tags: 
Transaction Report: Disabled

確認して問題がなければ[Run]を押して分析を実行します。
分析を実行する前に、Windup用のコンテナイメージをプルする必要があるため、分析には数分かかる場合があります。

Windupによる「Analyze(分析)」結果レポート

レポートが完成したら、リンクをクリックしてレポートにアクセスし、アプリケーション(customers-tomcat.war)をクリックします。

View Report

レポートのDashboardにはアプリケーションが使用するテクノロジや依存関係などあらゆる情報が提供されますが、修正が必要な点は「Issues」タブに記載されています。

Issue Mandatory

必須の修正箇所は以下の4件です。
- Legacy configuration - 2件
- Hard coded IP address - 1件
- File system - Java IO - 1件

それぞれのリンクを辿りながら、簡単に詳細を見ていきましょう。

(1) Legacy configuration

これは先程カスタムルールで定義した課題がソースコードから見つかったことを示しています。

Legacy Configuration

内容としては、従来のApplicationConfigurationクラスが使用されていることが指摘されています。Springの@PropertySourceアノテーションとEnvironmentクラスを使用したアプローチに置き換えるよう推奨されています。
Kubernetesを利用したアプリケーションでは、内部でパラメータ設定を行うのではなくConfigMapやSecretなどで環境変数として取り扱うことが推奨されています。
冒頭のCNDT 2022の資料とも合わせて確認してください。

(2) Hard coded IP address

次は、ソースコードにDBに接続するためのIPアドレスが定義されていることを指摘されています。

Hard coded IP address

プロパティファイル(WEB-INF/classes/persistence.properties)に、アドレスが記載されているため、Kubernetesではサービス名などに置き換える必要があります。

(3) File system - Java IO

最後はローカルにあるプロパティファイル(/opt/config/persistence.properties)を呼び出していることが指摘されています。

File system - Java IO

Kubernetes上ではローカルホストに置かれたファイルをマウントすることは推奨されていないため、ConfigMapなどを活用して設定情報を取り扱ってください。

まとめ

Konveryor Tackleいかがでしたでしょうか。今回は簡単なアプリケーションを診断にかけてみました。
クラウドネイティブにマイクロサービス化することも重要なことではありますが、まずはReplatformによってコンテナ化するところから始めてみましょう。
その選択肢の一つとして、Konveryor Tackleを使ってみてはいかがでしょうか。

最後に、大事なこともぅ一度お伝えしておくと、12/21 - 12/23とコーチェラ再現Liveがあるので是非楽しみましょう。 「Special Live 2022 -Back To Coachella-」

*1:これは、Red Hat Modern Application Development Workshopで利用される分析用のサンプルファイルです。

*2:これは、Red Hat Modern Application Development Workshopで利用される分析用のサンプルファイルです。