Red Hat - Open Innovation Labs の技術ブログ

全900件

2022/12/18

既存アプリを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 で利用される分析用のサンプルファイルです。

GitHub, Java, Linux, ドメイン駆動, 自然言語処理, Kubernetes, OSS, アーキテクチャ, Microservices, OpenShift

Red Hat - Open Innovation Labs の技術ブログ

コンテンツ