ユーザーインターフェイスガイド
Migration Toolkit for Applications ユーザーインターフェイスを使用して、アプリケーションを分析用のプロジェクトにグループ化する
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 はじめに
1.1. ユーザーインターフェイスガイドについて
このガイドは、Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、Red Hat OpenShift のハイブリッドクラウド環境全体で大規模なアプリケーションモダナイゼーションの取り組みを促進することを検討しているアーキテクト、エンジニア、コンサルタントなどを対象としています。このソリューションは、導入プロセス全体を通じて、ポートフォリオレベルとアプリケーションレベルの詳細情報を提供します。ユーザーインターフェイスを使用して、アプリケーションのインベントリー作成、評価、分析、および管理を行い、OpenShift Container Platform への移行をより短期間で行うことができます。
1.2. Migration Toolkit for Applications の概要
Migration Toolkit for Applications とは
Migration Toolkit for Applications (MTA) は、Red Hat OpenShift 上のハイブリッドクラウド環境全体で大規模なアプリケーションモダナイゼーションに対する取り組みを促進します。このソリューションは、導入プロセス全体を通じて、ポートフォリオレベルとアプリケーションレベルの詳細情報を提供します。ユーザーインターフェイスを使用して、アプリケーションのインベントリー作成、評価、分析、および管理を行い、OpenShift Container Platform への移行をより短期間で行うことができます。
MTA 7.1 以降では、アプリケーションを Application Inventory に追加すると、MTA が言語検出タスクとテクノロジー検出タスクを自動的に作成して実行します。言語の検出では、アプリケーションで使用されているプログラミング言語が識別されます。テクノロジーの検出では、Enterprise Java Beans (EJB)、Spring などのテクノロジーが識別されます。その後、各タスクによってアプリケーションに適切なタグが割り当てられるため、アプリケーションに手動でタグを付ける時間と労力が削減されます。
MTA は、アプリケーションを評価するための基礎として広範にわたるデフォルトの質問リストを使用します。または、独自のカスタム質問リストを作成して、アプリケーションのコンテナー化の準備に必要な難易度、時間、およびその他のリソースを見積もることもできます。ステークホルダー間の議論の基礎として評価の結果を使用して、どのアプリケーションがコンテナー化に適しているか、どのアプリケーションが最初に多大な作業を必要とするか、どのアプリケーションがコンテナー化に適していないかを判断できます。
MTA は、対象のアプリケーションごとに 1 つ以上のルールセットを適用してアプリケーションを分析し、モダナイゼーションする前に、そのアプリケーションに含まれるどの行を変更するかを判断します。
MTA は、プロジェクトソースディレクトリーやアプリケーションアーカイブを含むアプリケーションアーティファクトを検査し、変更を必要とするエリアを強調表示する HTML レポートを作成します。
Migration Toolkit for Applications による移行を単純化する方法
Migration Toolkit for Applications は一般的なリソースを探し、アプリケーションを移行する際の既知の問題点を明らかにします。アプリケーションで使用されるテクノロジーの概要を示します。
MTA は、移行またはモダナイゼーションパスの評価に関する詳細なレポートを生成します。このレポートは、大規模なプロジェクトに必要な作業を見積もり、関係する作業を減らすのに役立ちます。
1.3. ユーザーインターフェイスについて
Migration Toolkit for Applications のユーザーインターフェイスを使用すると、ユーザーチームは、Red Hat OpenShift 上のハイブリッドクラウド環境への移行のリスクと適合性について、アプリケーションを評価および分析できます。
ユーザーインターフェイスを使用してアプリケーションを評価および分析し、OpenShift により迅速に移行ができるように、アプリケーションのインベントリー、評価、分析、および管理を行う際に、ポートフォリオレベルとアプリケーションレベルの両方で採用プロセスにおける問題点を理解できます。
第2章 ユーザーインターフェイスビュー
Migration Toolkit for Applications (MTA) ユーザーインターフェイスには、次の 2 つのビューがあります。
- Administration (管理) ビュー
- Migration (移行) ビュー
Administration ビューでは、管理者が、インスタンス環境の設定、認証情報とリポジトリーの操作、HTTP および HTTPS プロキシーの定義、カスタム移行ターゲットの作成、問題の管理、カスタムアセスメント質問集の追加を行うことができます。
Migration ビューでは、承認されたすべてのユーザーが、レポートの確認、評価および分析対象のアプリケーションの追加、アプリケーションの評価と分析、Migration Wave の作成、移行に影響を与える可能性のある問題の表示、Task Manager による分析タスクと検出タスクのステータスの表示を行うことができます。このビューでは、ユーザーロール (管理者、アーキテクト、移行担当者) によって権限が異なります。
第3章 Migration Toolkit for Applications ユーザーインターフェイスのインストール
Migration Toolkit for Applications (MTA) ユーザーインターフェイスは、すべての Red Hat OpenShift クラウドサービスと Red Hat OpenShift セルフマネージドエディションにインストールできます。
MTA のインスタンスを作成するには、まず MTA Operator をインストールする必要があります。
MTA Operator は、データベース、フロントエンド、バックエンドなど、OpenShift にデプロイされたリソースを管理し、MTA のインスタンスを自動的に作成する構造層です。
3.1. 永続ボリュームの要件
MTA Operator を正常にデプロイするには、RWO の永続ボリューム (PV) が 2 つ必要です。これらは、さまざまなコンポーネントによって使用されます。rwx_supported
設定オプションが true
に設定されている場合、MTA Operator に RWX の PV がさらに 2 つ必要です。これらは、Maven およびハブのファイルストレージによって使用されます。これらの PV について、次の表で説明します。
名前 | デフォルトのサイズ | アクセスモード | 説明 |
---|---|---|---|
|
| RWO | ハブのデータベース |
|
| RWX |
ハブのファイルストレージ。 |
|
| RWO | Keycloak バックエンドデータベース |
|
| RWX |
Maven m2 キャッシュ。 |
3.2. Migration Toolkit for Applications Operator とユーザーインターフェイスのインストール
Migration Toolkit for Applications (MTA) とユーザーインターフェイスは、Red Hat OpenShift バージョン 4.15 - 4.17 にインストールできます。
前提条件
- 4 つ vCPU、8 GB RAM、および 40 GB の永続ストレージ。
- バージョン 4.15 - 4.17 の Red Hat OpenShift のクラウドサービスまたはセルフホストエディション。
-
cluster-admin
パーミッションを持つユーザーとしてログインしている。
詳細は、OpenShift Operator のライフサイクル を参照してください。
手順
- Red Hat OpenShift Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、MTA を検索します。
- Migration Toolkit for Applications Operator をクリックし、Install をクリックします。
- Install Operator ページで、Install をクリックします。
-
Operators → Installed Operators をクリックして、MTA Operator が
openshift-mta
プロジェクトにSucceeded
ステータスで表示されることを確認します。 - MTA Operator をクリックします。
Provided APIs で Tackle を見つけ、Create Instance をクリックします。
Create Tackle ウィンドウが Form ビューで開きます。
- カスタムリソース (CR) 設定を確認します。デフォルトの選択で問題ありませんが、ストレージ、メモリー、およびコアのシステム要件を確認してください。
YAML ファイルを直接操作する場合は、YAML ビューをクリックして、YAML ファイルの
spec
セクションに列挙されている CR 設定を確認します。最も一般的に使用される CR 設定を次の表に示します。
表3.2 タックル CR 設定 名前 デフォルト 説明 cache_data_volume_size
100Gi
キャッシュボリュームに要求されるサイズ。
rwx_supported=false
の場合は、無視されます。cache_storage_class
デフォルトのストレージクラス
キャッシュボリュームに使用されるストレージクラス。
rwx_supported=false
の場合は、無視されます。feature_auth_required
true
キークローク認証が必要かどうかを示すフラグ (単一ユーザー/“認証なし”)。
feature_isolate_namespace
true
ネットワークポリシーを使用した名前空間の分離が有効かどうかを示すフラグ
hub_database_volume_size
10Gi
hub database ボリュームに要求されるサイズ
hub_bucket_volume_size
100Gi
hub bucket ボリュームに要求されるサイズ
hub_bucket_storage_class
デフォルトのストレージクラス
バケットボリュームに使用されるストレージクラス。
keycloak_database_data_volume_size
1Gi
Keycloak データベースボリュームに要求されたサイズ
keycloak_sso_req_passwd_update
true
フラグが
true
に設定されている場合、ユーザーは初回ログイン後にパスワードを更新する必要があります。pathfinder_database_data_volume_size
1Gi
Pathfinder データベースボリュームに要求されたサイズ
maven_data_volume_size
100Gi
Maven m2 キャッシュボリュームに要求されるサイズ。MTA 6.0.1 で非推奨。
rwx_storage_class
該当なし
Tackle RWX ボリュームに要求されるストレージクラス。MTA 6.0.1 で非推奨。
rwx_supported
true
クラスターストレージが RWX モードをサポートしているかどうかを示すフラグ。
rwo_storage_class
該当なし
Tackle RW0 ボリュームに要求されたストレージクラス
rhsso_external_access
False
MTA 管理の RHSSO インスタンスにアクセスするための専用ルートが作成されているかどうかを示すフラグ
analyzer_container_limits_cpu
1
Pod が使用できる CPU の最大数
analyzer_container_limits_memory
4Gi
Pod が使用できるメモリーの最大量。Pod に
OOMKilled
エラーが表示される場合は、この制限を増やすことができます。analyzer_container_requests_cpu
1
Pod の実行に必要な CPU の最小数
analyzer_container_requests_memory
4Gi
Pod の実行に必要なメモリーの最小量
ui_container_limits_cpu
500 m
UI Pod リソースが使用できる CPU の最大数
ui_container_limits_memory
800 Mi
UI Pod リソースが使用できるメモリーの最大量。Pod に
OOMKilled
エラーが表示される場合は、この制限を増やすことができます。ui_container_requests_cpu
100 m
UI Pod リソースの実行に必要な CPU の最小数
ui_container_requests_memory
350Mi
UI Pod リソースの実行に必要なメモリーの最小量
provider_java_container_limits_cpu
1
Java プロバイダーリソースが使用できる CPU の最大数
provider_java_container_limits_memory
2 Gi
Java プロバイダーリソースが使用できるメモリーの最大量。Pod に
OOMKilled
エラーが表示される場合は、この制限を増やすことができます。provider_java_container_requests_cpu
1
Java プロバイダーリソースの実行に必要な CPU の最小数
provider_java_container_requests_memory
2 Gi
Java プロバイダーリソースの実行に必要なメモリーの最小量
サンプル YAML ファイル
kind: Tackle apiVersion: tackle.konveyor.io/v1alpha1 metadata: name: mta namespace: openshift-mta spec: hub_bucket_volume_size: "25Gi" maven_data_volume_size: "25Gi" rwx_supported: "false"
- 必要に応じて CR 設定を編集し、Create をクリックします。
- Administration ビューで、Workloads → Pods をクリックして、MTA Pod が実行されていることを確認します。
-
OpenShift 内の
mta-ui
アプリケーションによって公開されたルートを使用して、ブラウザーからユーザーインターフェイスにアクセスします。 次の認証情報を使用してログインします。
- ユーザー名: admin
- パスワード:Passw0rd!
- プロンプトが表示されたら、新しいパスワードを作成します。
3.2.1. エビクションしきい値
各ノードには一定量のメモリーが割り当てられています。そのメモリーの一部はシステムサービス用に予約されています。残りのメモリーは Pod の実行に使用されます。Pod が割り当てられた量を超えるメモリーを使用すると、メモリー不足イベントがトリガーされ、ノードは OOMKilled
エラーで終了します。
メモリー不足イベントを回避し、ノードを保護するには、--eviction-hard
設定を使用します。この設定は、ノードが Pod をエビクトするメモリーの可用性のしきい値を指定します。設定値は絶対値またはパーセント値に指定できます。
ノードのメモリー割り当て設定の例
-
ノード容量:
32Gi
-
--system-reserved
設定:3Gi
-
--eviction-hard
設定:100Mi
このノードで Pod を実行するために使用できるメモリーの量は 28.9 GB です。この量は、ノードの全体的な容量から system-reserved
と eviction-hard
値を差し引くことによって計算されます。メモリー使用量がこの量を超えると、ノードは Pod のエビクトを開始します。
3.3. Red Hat Single Sign-On
MTA は、ユーザーの認証と認可に Red Hat Single Sign-On (RHSSO) インスタンスを使用します。
MTA Operator は RHSSO インスタンスを管理し、必要なロールと権限を持つ専用の レルム を設定します。
MTA 管理の RHSSO インスタンスを使用すると ユーザーフェデレーションのプロバイダーの追加 や アイデンティティープロバイダーの統合 など、高度な RHSSO 設定を実行できます。RHSSO 管理コンソール にアクセスするには、<route> を MTA Web コンソールのアドレスに置き換えて、ブラウザーに URL https://<_route_>/auth/admin を入力します。
以下に例を示します。
- MTA Web コンソール: https://mta-openshiftmta.example.com/
- RHSSO 管理コンソール: https://mta-openshiftmta.example.com/auth/admin
RHSSO の管理者認証情報は、MTA がインストールされている名前空間内の credential-mta-rhsso
という名前の秘密ファイルに保存されます。
管理者の認証情報を取得するには、次のコマンドを実行します。
oc get secret credential-mta-rhsso -o yaml
RHSSO インスタンス専用のルートを作成するには、MTA の Tackle カスタムリソース (CR) で rhsso_external_access
パラメーターを true
に設定します。
リソースに対するマルチユーザーアクセス制限はありません。たとえば、あるユーザーが作成したアナライザータスクを別のユーザーがキャンセルできます。
3.3.1. ロール、ペルソナ、ユーザー、権限
MTA は 3 つのロールを使用します。それぞれ 1 つのペルソナに対応しています。
ロール | ペルソナ |
---|---|
| 管理者 |
| アーキテクト |
| 移行担当者 |
ロールは RHSSO インスタンスですでに定義されています。作成する必要はありません。
MTA 管理者の場合は、RHSSO にユーザーを作成し、各ユーザーに 1 つ以上のロール (ペルソナごとに 1 つのロール) を割り当てることができます。
3.3.1.1. ロール、ペルソナ、ユーザーインターフェイスビューへのアクセス
ユーザーは複数のロールを持つことができますが、各ロールは特定のペルソナに対応しています。
-
管理者: 管理者は、アーキテクトや移行担当者が持つすべての権限を持っています。さらに、他のユーザーが使用できるが変更や表示はできないアプリケーション全体の設定パラメーターを作成する権限も持っています。例: Git 認証情報、Maven の
settings.xml
ファイル。 - アーキテクト: 移行プロジェクトの技術責任者です。評価を実行し、アプリケーションとそれに関連する情報を作成および変更できます。アーキテクトは機密情報を変更または削除することはできませんが、使用することはできます。例: 既存の認証情報を特定のアプリケーションのリポジトリーに関連付ける。
- 移行担当者: アプリケーションを分析することはできますが、作成、変更、削除はできないユーザーです。
ユーザーインターフェイスビュー の説明のとおり、MTA には Administration と Migration の 2 つのビューがあります。
Administration ビューにアクセスできるのは管理者だけです。アーキテクトと移行担当者は、Administration ビューにアクセスできず、表示することもできません。
管理者は、Migration ビューでサポートされているすべての操作を実行できます。アーキテクトおよび移行担当者は、Migration ビューのすべての要素を表示できます。ただし、Migration ビューで操作を実行できるかどうかは、各ロールに付与されている権限によって異なります。
MTA ユーザーインターフェイスの Administration ビューと Migration ビューに対する管理者、アーキテクト、移行担当者のアクセス権限を、次の表にまとめます。
メニュー | アーキテクト | 移行担当者 | 管理者 |
---|---|---|---|
管理 | いいえ | いいえ | はい |
移行 | はい | はい | はい |
3.3.1.2. ロールと権限
次の表には、MTA が管理対象の RHSSO インスタンスにシードするロールと権限 (スコープ) を示します。
tackle-admin | リソース名 | 動詞 |
addons |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
applications.bucket |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
delete | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
delete | |
reviews |
delete | |
settings |
delete | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
tickets |
delete | |
trackers |
delete | |
cache |
delete | |
files |
delete | |
rulebundles |
delete |
tackle-architect | リソース名 | 動詞 |
addons |
delete | |
applications.bucket |
delete | |
adoptionplans |
post | |
applications |
delete | |
applications.facts |
delete | |
applications.tags |
delete | |
assessments |
delete | |
businessservices |
delete | |
dependencies |
delete | |
identities |
get | |
imports |
delete | |
jobfunctions |
delete | |
proxies |
get | |
reviews |
delete | |
settings |
get | |
stakeholdergroups |
delete | |
stakeholders |
delete | |
tags |
delete | |
tagtypes |
delete | |
tasks |
delete | |
tasks.bucket |
delete | |
trackers |
get | |
tickets |
delete | |
cache |
get | |
files |
delete | |
rulebundles |
delete |
tackle-migrator | リソース名 | 動詞 |
addons |
get | |
adoptionplans |
post | |
applications |
get | |
applications.facts |
get | |
applications.tags |
get | |
applications.bucket |
get | |
assessments |
get | |
businessservices |
get | |
dependencies |
delete | |
identities |
get | |
imports |
get | |
jobfunctions |
get | |
proxies |
get | |
reviews |
get | |
settings |
get | |
stakeholdergroups |
get | |
stakeholders |
get | |
tags |
get | |
tagtypes |
get | |
tasks |
delete | |
tasks.bucket |
delete | |
tackers |
get | |
tickets |
get | |
cache |
get | |
files |
get | |
rulebundles |
get |
3.4. Red Hat OpenShift Local 環境での Migration Toolkit for Applications Operator のインストールと設定
Red Hat OpenShift Local を使用すると、デスクトップまたはラップトップ上にローカル OpenShift クラスターをすばやく簡単にセットアップできます。このローカルクラスターを使用すると、アプリケーションと設定パラメーターを実稼働環境に送信する前にテストできます。
3.4.1. オペレーティングシステム要件
Red Hat OpenShift Local には、サポートされるオペレーティングシステムの最小バージョンが必要です。
3.4.1.1. Microsoft Windows の Red Hat OpenShift Local の要件
Microsoft Windows を使用する場合、Red Hat OpenShift Local に、Windows 10 Fall Creators Update (バージョン 1709) 以降が必要です。Red Hat OpenShift Local は、それ以前のバージョンの Microsoft Windows では動作しません。Microsoft Windows 10 Home Edition はサポートされません。
3.4.1.2. macOS の Red Hat OpenShift Local の要件
macOS を使用する場合、Red Hat OpenShift Local に macOS 11 Big Sur 以降が必要です。Red Hat OpenShift Local は、それ以前のバージョンの macOS では動作しません。
3.4.1.3. Linux の Red Hat OpenShift Local の要件
Linux を使用する場合、Red Hat OpenShift Local は、最新の 2 つの Red Hat Enterprise Linux 8 および 9 マイナーリリースと、最新の 2 つの安定版 Fedora リリースでのみサポートされます。
Red Hat Enterprise Linux を使用する場合は、Red Hat OpenShift Local を実行するマシンが Red Hat カスタマーポータルに登録されている必要があります。
Ubuntu 18.04 LTS 以降および Debian 10 以降はサポートされておらず、ホストマシンの手動設定が必要になる場合があります。
3.4.1.3.1. Linux に必要なソフトウェアパッケージ
Red Hat OpenShift Local を Linux で実行するには、libvirt
および NetworkManager
パッケージが必要です。
Fedora および Red Hat Enterprise Linux では、以下を実行します。
sudo dnf install NetworkManager
Debian/Ubuntu では、以下を実行します。
sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system network-manager
3.4.2. Red Hat OpenShift Local 環境への Migration Toolkit for Applications Operator のインストール
Red Hat OpenShift Local をインストールするには、次の手順を実行します。
ご使用のプラットフォーム用の Red Hat OpenShift Local の最新リリースをダウンロードします。
- OpenShift Local をダウンロードします。
- プルシークレット をダウンロードします。
アーカイブを
~/Downloads
ディレクトリーに保存した場合は、次の手順に従います。cd ~/Downloads
tar xvf crc-linux-amd64.tar.xz
crc
実行ファイルをそこにコピーします。cp ~/Downloads/crc-linux-<version-number>-amd64/crc ~/bin/crc
$PATH
変数に~/bin/crc
ディレクトリーを追加します。export PATH=$PATH:$HOME/bin/crc
echo 'export PATH=$PATH:$HOME/bin/crc' >> ~/.bashrc
テレメトリーを無効にするために、次のコマンドを実行します。
crc config set consent-telemetry no
macOS の場合は、適切な crc-macos-installer.pkg をダウンロードしてください。
- Finder を使用して Downloads に移動します。
-
crc-macos-installer.pkg
をダブルクリックします。
3.4.3. Red Hat OpenShift Local の設定
crc setup
コマンドで、Red Hat OpenShift Local インスタンスのホストマシンの環境を設定する操作を実行します。
crc setup
コマンドは ~/.crc
ディレクトリーを作成します。
Red Hat OpenShift Local 用にホストマシンを設定します。
crc setup
3.4.4. Red Hat OpenShift Local インスタンスの起動
Red Hat OpenShift Local プリセットは、マネージドコンテナーランタイムと、インスタンスがそのランタイムの実行に必要なシステムリソースの下限を表します。
-
Linux または macOS の場合は、ユーザーアカウントに
sudo
コマンドを使用できるようになっている。 - Microsoft Windows の場合は、ユーザーアカウントが管理者権限に昇格できるようになっている。
crc start
コマンドで、Red Hat OpenShift Local インスタンスと設定済みのコンテナーランタイムを起動します。以下のフラグを使用できます。
フラグ | 型 | 説明 | デフォルト値 |
---|---|---|---|
-b、--bundle | string |
バンドルのパス/URI - 絶対パスまたはローカルパス、HTTP、HTTPS、または docker URI (例: |
デフォルト |
-c、–cpus | int | インスタンスに割り当てる CPU コアの数 | 4 |
–disable-update-check | 更新をチェックしない | ||
-d、–disk-size | uint | インスタンスが使用するディスクの合計サイズ (GB) | 31 |
-h、–help | start のヘルプ | ||
-m、–memory | int |
インスタンスに割り当てるメモリーの | 10752 |
-n、–nameserver | string | インスタンスに使用するネームサーバーの IPv4 アドレス | |
-o、–output | string | JSON 形式の出力 | |
-p、–pull-secret-file | string | イメージプルシークレットのファイルパス (https://console.redhat.com/openshift/create/local からダウンロード) |
また、次のグローバルフラグも使用できます。
フラグ | 型 | 説明 | デフォルト値 |
---|---|---|---|
–log-level | string | ログレベルの例:
*
*
*
* |
|
デフォルト設定では、4 つの仮想 CPU、31 GB のディスクサイズ、10 GB の RAM を持つ仮想マシン (VM) が作成されます。ただし、このデフォルト設定では、MTA を安定して実行するには不十分です。
仮想 CPU の数を 6 に、ディスクサイズを 200 GB に、メモリーを 20 GB に増やすには、次のように crc config
を実行します。
+
crc config set cpus 6
+
crc config set disk-size 200
+
$ crc config set memory 20480
設定を確認するには、次のコマンドを実行します。
+
crc config view
出力例
+
- consent-telemetry : yes - cpus : 6 - disk-size : 200 - memory : 16384
入力した設定プロパティーへの変更は、CRC インスタンスの起動時にのみ適用されます。
すでに実行中の CRC インスタンスがある場合、この設定の変更を有効にするには、crc stop
で CRC インスタンスを停止し、crc start
で再起動します。
3.4.5. Red Hat OpenShift Local インスタンスのステータスの確認
Red Hat OpenShift Local インスタンスのステータスを確認するには、次のコマンドを実行します。
+
crc status
出力例
+
CRC VM: Running OpenShift: Starting (v4.15.14) RAM Usage: 9.25GB of 20.97GB Disk Usage: 31.88GB of 212.8GB (Inside the CRC VM) Cache Usage: 26.83GB Cache Directory: /home/<user>/.crc/cache
3.4.6. Red Hat OpenShift Local 環境での Migration Toolkit for Applications Operator の設定
次の表は、テスト済みの Red Hat OpenShift Local の推奨最小設定を示しています。
メモリー (Gi) | CPU | ディスクサイズ (Gi) |
---|---|---|
| 5 |
|
| 5 |
|
3.5. Java アナライザーと検出の最小要件の追加
Java アナライザーと検出タスクには最小要件があります。最小要件はデフォルトで 2 GB に設定されます。
この最小要件は 1.5 GB まで下げることができますが、これは推奨されません。
この最小要件を 2 GB 以上に増やすこともできます。
kind: Tackle apiVersion: tackle.konveyor.io/v1alpha1 metadata: name: tackle namespace: openshift-mta spec: feature_auth_required: 'true' provider_java_container_limits_memory: 2Gi provider_java_container_requests_memory: 2Gi
スケジュール設定用に適切な領域を確保するために、provider_java_container_limits_memory
と provider_java_container_requests_memory
に同じ量の領域を割り当ててください。
第4章 インスタンス環境の設定
Administration ビューでは次の設定を行うことができます。
- 全般
- 認証情報
- リポジトリー
- プロキシー (HTTP および HTTPS プロキシー設定)
- カスタム移行ターゲット
- 課題管理
- アセスメント質問集
4.1. 全般
次のオプションを有効または無効にできます。
- 分析実行後のレポートのダウンロードを許可する
4.2. 認証情報の設定
Administration ビューでは、次の種類の認証情報を設定できます。
- ソース制御
- Maven 設定ファイル
- Proxy
- Basic 認証 (Jira)
- ベアラートークン (Jira)
4.2.1. ソース管理認証情報の設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、ソース管理認証情報を設定できます。
手順
- Administration ビューで、Credentials をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- 名前
- 説明 (任意)
- Type リストで、Source Control を選択します。
User credentials リストで、Credential Type を選択し、要求された情報を入力します。
ユーザー名/パスワード
- ユーザー名
- パスワード (非表示)
SCM 秘密鍵のパスフレーズ
- SCM 秘密鍵
秘密鍵のパスフレーズ (非表示)
注記鍵やパスフレーズなどのタイプ固有の認証情報は、非表示にされるか、[Encrypted] (暗号化済み) として表示されます。
Create をクリックします。
MTA は入力を検証し、新しい認証情報を作成します。SCM キーは、解析して有効性をチェックする必要があります。検証に失敗すると、
“not a valid key/XML file”
エラーメッセージが表示されます。
4.2.2. Maven 認証情報の設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、新しい Maven 認証情報を設定できます。
手順
- Administration ビューで、Credentials をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- 名前
- 説明 (任意)
- Type リストで、Maven Settings File を選択します。
- 設定ファイルをアップロードするか、その内容を貼り付けます。
Create をクリックします。
MTA は入力を検証し、新しい認証情報を作成します。Maven の
settings.xml
ファイルを解析し、有効性をチェックする必要があります。検証に失敗すると、“not a valid key/XML file”
エラーメッセージが表示されます。
4.2.3. プロキシー認証情報の設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、プロキシー認証情報を設定できます。
手順
- Administration ビューで、Credentials をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- 名前
- 説明 (任意)
- Type リストで、Proxy を選択します。
以下の情報を入力します。
- ユーザー名
パスワード
注記鍵やパスフレーズなどのタイプ固有の認証情報は、非表示にされるか、[Encrypted] (暗号化済み) として表示されます。
Create をクリックします。
MTA は入力を検証し、新しい認証情報を作成します。
4.3. リポジトリーの設定
Administration ビューでは、次のタイプのリポジトリーを設定できます。
- Git
- Subversion
- Maven
4.3.1. Git リポジトリーの設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで Git リポジトリーを設定できます。
手順
- Administration ビューで、Repositories をクリックし、Git をクリックします。
- Consume insecure Git repositories のスイッチを右に切り替えます。
4.3.2. subversion リポジトリーの設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで Subversion リポジトリーを設定できます。
手順
- Administration ビューで、Repositories をクリックし、Subversion をクリックします。
- Consume insecure Subversion repositories のスイッチを右に切り替えます。
4.3.3. Maven リポジトリーの設定とそのサイズの縮小
MTA ユーザーインターフェイスを使用して、Maven リポジトリーの設定とそのサイズの縮小の両方を行うことができます。
4.3.3.1. Maven リポジトリーの設定
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで、Maven リポジトリーを設定できます。
Tackle CR の rwx_supported
設定オプションが false
に設定されている場合、Consume insecure artifact repositories スイッチが無効になり、この手順は実行できません。
手順
- Administration ビューで、Repositories をクリックし、Maven をクリックします。
- Consume insecure artifact repositories のスイッチを右に切り替えます。
4.3.3.2. Maven リポジトリーのサイズ縮小
Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで、Maven リポジトリーのサイズを縮小できます。
Tackle CR の rwx_supported
設定オプションが false
に設定されている場合、Local artifact repository フィールドと Clear repository ボタンの両方が無効になり、この手順は実行できません。
手順
- Administration ビューで、Repositories をクリックし、Maven をクリックします。
Clear repository リンクをクリックします。
注記リポジトリーのサイズによっては、機能が正常に動作していてもサイズの変化がわかりにくい場合があります。
4.4. HTTP および HTTPS プロキシー設定の構成
この管理モジュールを使用して、HTTP および HTTPS プロキシー設定を設定できます。
手順
- Administration ビューで、Proxy をクリックします。
- HTTP proxy または HTTPS proxy を切り替えて、プロキシー接続を有効にします。
以下の情報を入力します。
- プロキシーホスト
- プロキシーポート
- オプション: HTTP proxy credentials または HTTPS proxy credentials を切り替えて、認証を有効にします。
- Insert をクリックします。
4.5. カスタム移行ターゲットの作成
admin
権限を持つアーキテクトまたはユーザーは、カスタム移行ターゲットに関連付けられたカスタムルールセットを作成および維持できます。アーキテクトは、カスタムルールファイルをアップロードし、さまざまなカスタム移行ターゲットへの割り当てできます。その後、分析設定ウィザードでカスタム移行ターゲットを選択できます。
既製のカスタム移行ターゲットを使用すると、分析を実行するたびにカスタムルールを設定する必要がなくなります。これにより、管理者以外のユーザーやサードパーティーの開発者にとって分析の設定と実行が簡素化されます。
前提条件
-
admin
権限を持つユーザーとしてログインしている。
手順
- Administration ビューで Custom migration targets をクリックします。
- Create new をクリックします。
- ターゲットの名前と説明を入力します。
- Image セクションで、ターゲットのアイコンのイメージファイルをアップロードします。ファイルは PNG または JPEG 形式で、最大 1 MB にすることができます。ファイルをアップロードしない場合は、デフォルトのアイコンが使用されます。
Custom rules セクションで、Upload manually または Retrieve from a repository を選択します。
- Upload manually を選択した場合は、ローカルドライブから必要なルールファイルをアップロードまたはドラッグアンドドロップします。
Retrieve from a repository を選択した場合は、次の手順を実行します。
- Git または Subversion を選択します。
- Source repository、Branch、および Root path フィールドに入力します。
- リポジトリーに認証情報が必要な場合は、これらの認証情報を Associated credentials フィールドに入力します。
Create をクリックします。
新しい移行ターゲットが Custom migration targets ページに表示されます。Migration ビューで、管理者以外のユーザーが使用できるようになりました。
4.6. インスタンスのシード値設定
プロジェクトアーキテクトは、移行前にコントロールウィンドウでインスタンスの主要なパラメーターを設定できます。パラメーターは、必要に応じて追加および編集できます。次のパラメーターは、移行の影響を受ける、または移行に参加している組織内のアプリケーション、個人、チーム、垂直または領域を定義します。
- Stakeholders
- Stakeholder groups
- Job functions
- Business services
- Tag categories
- Tags
インスタンスは任意の順序で作成および設定できます。ただし、Stakeholders と Tags を作成するには、以下の推奨順序が最も効率的です。
Stakeholders:
- Stakeholder groups を作成する
- Job functions を作成する
- Stakeholders を作成する
Tags:
- Tag categories を作成する
- Tags を作成する
Stakeholders であり、以下によって定義されます。
- Name
- Job function
- Stakeholder groups
4.6.1. 新しい Stakeholder groups の作成
デフォルトの Stakeholder groups は定義されていません。以下の手順に従って、新しい Stakeholder groups を作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Stakeholder groups をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- Name
- Description
- Member(s)
- Create をクリックします。
4.6.2. 新しい Job function の作成
Migration Toolkit for Applications (MTA) は、Job function 属性を使用して Stakeholders を分類し、デプロイメント可能なデフォルト値のリストを提供します。
以下の手順に従って、デフォルトのリストにない新しい Job function を作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Job functions をクリックします。
- Create new をクリックします。
- Name テキストボックスに役職名を入力します。
- Create をクリックします。
4.6.3. 新しい Stakeholder の作成
以下の手順に従って、新しい移行プロジェクトの Stakeholder を作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Stakeholders をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- Name
- Job function- カスタム機能を作成可能
- Stakeholder group
- Create をクリックします。
4.6.4. 新しい Business service の作成
Migration Toolkit for Applications (MTA) は、Business service 属性を使用して、アプリケーションを使用し、移行の影響を受ける組織内の部門を指定します。
以下の手順で新規業務サービスを作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Business services をクリックします。
- Create new をクリックします。
以下の情報を入力します。
- Name
- Description
- Owner
- Create をクリックします。
4.6.5. 新しい Tag categories の作成
Migration Toolkit for Applications (MTA) は、複数のカテゴリーのタグを使用し、デフォルト値のリストを提供します。以下の手順で Tag categories を新規作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Tags をクリックします。
- Create tag category をクリックします。
以下の情報を入力します。
- Name
- Rank - タグがアプリケーションに表示される順序
- Color
- Create をクリックします。
4.6.5.1. 新しい Tags の作成
デフォルトのリストにない新しい Tags を作成するには、次の手順に従います。
手順
- Migration ビューで、Controls をクリックします。
- Tags をクリックします。
- Create tag をクリックします。
以下の情報を入力します。
- Name
- Tag category
- Create をクリックします。
第5章 Jira 接続の作成と設定
MTA ユーザーインターフェイス内から移行ごとに Jira 課題を作成することで、アプリケーションの移行を追跡できます。Jira 課題を作成できるようにするには、まず次のことを行う必要があります。
- 次のステップで作成する Jira インスタンスの API に対して認証するための MTA 認証情報を作成します。
- MTA で Jira インスタンスを作成し、そのインスタンスへの接続を確立します。
5.1. Jira 認証情報の設定
MTA で Jira インスタンスを定義し、そのインスタンスへの接続を確立するには、まず Jira インスタンスの API に対して認証するための MTA 認証情報を作成する必要があります。
次の 2 種類の認証情報を使用できます。
- Basic Auth - Jira Cloud およびプライベート Jira サーバーまたはデータセンター用
- Bearer Token - プライベート Jira サーバーまたはデータセンター用
MTA 認証情報を作成するには、以下の手順に従います。
手順
Administration ビューで、Credentials をクリックします。
Credentials ページが開きます。
- Create new をクリックします。
以下の情報を入力します。
- 名前
- Description (任意)
Type 一覧で、Basic Auth (Jira) または Bearer Token (Jira) を選択します。
Basic Auth (Jira) を選択した場合は、以下の手順を実行します。
- Email フィールドにメールを入力します。
Token フィールドに、特定の Jira 設定に応じて、Jira サイトで生成されたトークンまたは Jira ログインパスワードのいずれかを入力します。
注記Jira トークンを取得するには、Jira サイトにログインする必要があります。
Save をクリックします。
新しい認証情報が Credentials ページに表示されます。
Bearer Token (Jira) を選択した場合は、以下の手順を実行します。
- Token フィールドに、Jira サイトで生成されたトークンを入力します。
Save をクリックします。
新しい認証情報が Credentials ページに表示されます。
Edit をクリックして認証情報を編集できます。
認証情報を削除するには、Delete をクリックします。
Jira コネクションインスタンスにすでに割り当てられている認証情報を削除できません。
5.2. Jira 接続の作成と設定
MTA で Jira インスタンスを作成し、そのインスタンスへの接続を確立するには、以下の手順に従います。
手順
Administration ビューの Issue Management で Jira をクリックします。
Jira configuration ページが開きます。
Create new をクリックします。
New instance ウィンドウが開きます。
以下の情報を入力します。
- インスタンスの名前
- Jira アカウントの Web インターフェイスの URL
- インスタンスタイプ - リストから Jira Cloud または Jira Server/Data center のいずれかを選択します。
認証情報 - 一覧から選択します。
注記選択したインスタンスタイプが Jira Cloud の場合、Basic Auth 認証情報のみがリストに表示されます。
選択したインスタンスタイプが Jira Server/Data center の場合は、Basic Auth と Token Bearer の認証情報の両方が表示されます。Jira サーバーまたはデータセンターの特定の設定に適したタイプを選択します。
- デフォルトでは、証明書が無効なサーバーとの接続は確立できません。この制限を無効にするには、Enable insecure communication のスイッチを切り替えます。
Create をクリックします。
Jira configuration ページに新しいコネクションインスタンスが表示されます。
接続が確立されて承認されると、Connection 列のステータスが Connected になります。
Connection のステータスが
Not connected
になった場合は、ステータスをクリックしてエラーの理由を確認します。
Jira configuration テーブルは、Name および URL でフィルタリングされ、Instance name および URL でソートされています。
Migration Wave の課題作成 に使用された Jira 接続は、Migration Wave が削除された後でも、課題が Jira に存在する限り削除できません。
第6章 MTA を使用したアプリケーションの管理
Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、次のタスクを実行できます。
- アプリケーションを追加する
- アプリケーション認証情報を割り当てる
- アプリケーションのリストをインポートする
- アプリケーションリストをインポートするための CSV テンプレートをダウンロードする
- アプリケーションの Migration Wave を作成する
- Migration Wave に関する Jira 課題を作成する
MTA ユーザーインターフェイスアプリケーションには、次の属性があります。
- Name (自由記述)
- Description (任意、自由記述)
- Business service (任意、リストから選択)
- Tags (任意、リストから選択)
- Owner (任意、リストから選択)
- Contributors (任意、リストから選択)
- Source code (ユーザーが入力したパス)
- Binary (ユーザーが入力したパス)
6.1. 新しいアプリケーションの追加
後で評価と分析を行うために、Application Inventory に新しいアプリケーションを追加できます。
アプリケーションを作成する前に、Business services を設定し、Tags と Tag categories を確認し、必要に応じて追加を作成します。
前提条件
- MTA サーバーにログイン済みである。
手順
- Migration ビューで、Application Inventory をクリックします。
- Create new をクリックします。
Basic information で、次のフィールドに入力します。
- Name: 新しいアプリケーションの一意の名前
- Description: アプリケーションの簡単な説明 (任意)
- Business service: アプリケーションの目的 (任意)
- Manual tags: アプリケーションを特徴別に分類するソフトウェアタグ (任意、1 つ以上)
- Owner: ドロップダウンリストから登録されたソフトウェア所有者 (任意)
- Contributors: ドロップダウンリストに含まれるコントリビューター (任意、1 人以上)
- Comments: アプリケーションに関する関連するコメント (任意)
Source Code をクリックし、次のフィールドに入力します。
- Repository type: Git または Subversion
Source Repository: ソフトウェアコードが保存されているリポジトリーの URL
- Subversion の場合: リポジトリーのルートへの URL、または (オプション) ブランチとネストされたディレクトリーを含む完全修飾 URL のいずれかである必要があります。完全修飾の場合、Branch と Root path は空白にする必要があります。
Branch: リポジトリー内のアプリケーションコードブランチ (任意)。
-
Git の場合: 任意の参照 (
commit-hash
、branch
、またはtag
) になります。 -
Subversion の場合: ブランチまたはタグへの完全修飾パスになります (例:
branches/stable
またはtags/stable
)。ソースリポジトリー URL にブランチが含まれている場合、空白にする必要があります。
-
Git の場合: 任意の参照 (
Root path: 対象アプリケーションのリポジトリー内のルートパス (任意)。
- Subversion の場合: ソースリポジトリー URL にルートパスが含まれている場合、空白にする必要があります。
注記: Branch または Root path フィールドに値を入力すると、Source repository フィールドが必須になります。
オプション: Binary をクリックして、次のフィールドに入力します。
- Group: アプリケーションアーティファクトの Maven グループ。
- Artifact: アプリケーションの Maven アーティファクト。
- Version: アプリケーションのソフトウェアバージョン。
-
Packaging: アプリケーションアーティファクトのパッケージ (
JAR
、WAR
、EAR
など)。
注記: Binary セクションのフィールドのいずれかに値を入力すると、すべてのフィールドが自動的に必須になります。
- Create をクリックします。新しいアプリケーションが定義済みアプリケーションのリストに表示されます。
自動タスク
Application Inventory に新しいアプリケーションを追加した後、カーソルをアプリケーション名の上に置くと、アプリケーションした際に生成された自動タスクが表示されます。言語検出タスクは、アプリケーション内のプログラミング言語を識別します。テクノロジー検出タスクは、アプリケーション内の特定のテクノロジーを識別します。タスクによってアプリケーションに適切なタグが自動的に追加されるため、アプリケーションに手動でタグを割り当てる手間が軽減されます。これらのタスクが完了すると、アプリケーションに追加されたタグの数が Tags 列の下に表示されます。タグを表示するには、次の手順を実行します。
- アプリケーションの行のエントリーをクリックします。サイドペインが開きます。
- Tags タブをクリックします。アプリケーションに付加されたタグが表示されます。
必要に応じて手動でタグを追加できます。MTA はアプリケーションを分析するときに、アプリケーションに追加のタグを自動的に追加できます。
6.2. アプリケーションの編集
Application Inventory 内の既存のアプリケーションを編集し、このアプリケーションの評価または分析を再実行できます。
前提条件
- MTA サーバーにログイン済みである。
手順
- Migration ビューで、Application Inventory をクリックします。
- Migration 作業モードを選択します。
- 左側のメニューバーで Application Inventory をクリックします。使用可能なアプリケーションのリストがメインペインに表示されます。
-
Edit (
) をクリックしてアプリケーション設定を開きます。
- アプリケーションの設定を見直してください。アプリケーション設定のリストは、アプリケーションの追加 を参照してください。
- アプリケーション設定を変更した場合は、Save をクリックします。
アプリケーションを編集すると、MTA が言語検出タスクとテクノロジー検出タスクを再生成します。
6.3. アプリケーションへの認証情報の割り当て
認証情報を 1 つ以上のアプリケーションに割り当てることができます。
手順
- Migration ビューで、Application inventory をクリックします。
-
Analyze の右側にある Options メニュー (
) をクリックして Manage credentials を選択します。
- Source credentials リストと Maven settings リストから 1 つの認証情報を選択します。
- Save をクリックします。
6.4. アプリケーションのリストのインポート
アプリケーションとその属性のリストを含む .csv
ファイルを、Migration Toolkit for Applications (MTA) ユーザーインターフェイスにインポートできます。
アプリケーションのリストをインポートしても、既存のアプリケーションは上書きされません。
手順
- インポートファイルを見直して、必要なすべての情報が必要な形式で含まれていることを確認します。
- Migration ビューで、Application Inventory をクリックします。
-
Options メニュー (
) をクリックします。
- Import をクリックします。
- 目的のファイルを選択し、Open をクリックします。
- オプション: Enable automatic creation of missing entities を選択します。このオプションはデフォルトで選択されます。
- インポートが完了したことを確認し、承認または拒否された行数を確認します。
チェックボックスの左側にある矢印をクリックして、インポートされたアプリケーションを確認します。
重要一部の行は依存関係にあるため、承認された行は、Application inventory リスト内のアプリケーションの数と一致しない場合があります。確認するには、CSV ファイルの Record Type 列で、アプリケーションが
1
、依存関係が2
として定義されていることを確認します。
6.5. CSV テンプレートのダウンロード
Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、アプリケーションリストをインポートするための CSV テンプレートをダウンロードできます。
手順
- Migration ビューで、Application inventory をクリックします。
-
Review の右側にある (
) をクリックします。
- Manage imports をクリックして、Application imports ページを開きます。
-
Import の右側にある (
) をクリックします。
- Download CSV template をクリックします。
6.6. Migration Wave の作成
Migration Wave は、特定のスケジュールで移行できるアプリケーションのグループです。ウェーブのアプリケーションのリストを Jira 課題管理システムにエクスポートすることで、各移行を追跡できます。これにより、Migration Wave のアプリケーションごとに個別の Jira 課題が自動的に作成されます。
手順
- Migration ビューで、Migration waves をクリックします。
- Create new をクリックします。New migration wave ウィンドウが開きます。
以下の情報を入力します。
- Name (任意)。名前を指定しない場合は、開始日と終了日を使用して Migration Wave を識別できます。
- Potential start date。この日付は現在の日付より後の日付である必要があります。
- Potential end date。この日付は開始日より後の日付である必要があります。
- Stakeholders (任意)
- Stakeholder groups (任意)
- Create をクリックします。新しい Migration Wave が既存の Migration Wave のリストに表示されます。
アプリケーションを Migration Wave に割り当てるには、Migration Wave の右側にあるオプションメニュー (
) をクリックし、Manage applications を選択します。
Manage applications ウィンドウが開き、他の Migration Wave に割り当てられていないアプリケーションのリストが表示されます。
- Migration Wave に割り当てるアプリケーションのチェックボックスを選択します。
Save をクリックします。
注記Migration Wave に関連付けられた各アプリケーションの所有者とコントリビューターは、Migration Wave の関係者のリストに自動的に追加されます。
-
オプション: Migration Wave を更新するには、Migration Wave の Options メニュー (
) から Update を選択します。Update migration wave ウィンドウが開きます。
6.7. 移行に関する Jira 課題の作成
Migration Wave を使用すると、Migration Wave に割り当てられたアプリケーションごとに Jira 課題を自動的に作成できます。Migration Wave に関連付けられたアプリケーションごとに、個別の Jira 課題が作成されます。各課題の以下のフィールドは自動的に入力されます。
-
Title:
Migrate <application name>
- Reporter: トークン所有者のユーザー名
-
Description:
Created by Konveyor
アプリケーションが Jira チケットにリンクされている場合、または Migration Wave に関連付けられている場合は、アプリケーションを削除できません。Jira チケットからアプリケーションのリンクを解除するには、アプリケーションの詳細ビューまたは Migration Wave の詳細ビューで Unlink from Jira
アイコンをクリックします。
前提条件
- Jira 接続を設定した。詳細は、Jira 接続の作成と設定 を参照してください。
手順
- Migration ビューで、Migration waves をクリックします。
-
Jira 課題を作成する Migration Wave の右側にあるオプションメニュー (
) をクリックし、Export to Issue Manager を選択します。Export to Issue Manager ウィンドウが開きます。
- Jira Cloud または Jira Server/Datacenter インスタンスタイプを選択します。
- 一覧から、インスタンス、プロジェクト、および課題タイプを選択します。
-
Export をクリックします。Migration waves ページの移行ステータスが
Issues Created
に変わります。 - オプション: Migration Wave の各アプリケーションのステータスを表示するには、Status 列をクリックします。
- オプション: 特定のアプリケーションが Migration Wave に関連付けられているかどうかを確認するには、Application inventory ページでアプリケーションの Details タブを開きます。
第7章 MTA によるアプリケーションの評価および分析
Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、アプリケーションの評価と分析を行うことができます。
- Application Inventory を追加または編集すると、MTA がプログラミング言語検出タスクとテクノロジー検出タスクを自動的に生成します。タスクによってアプリケーションに適切なタグが適用されるため、アプリケーションを手動でタグ付けするのにかかる時間が削減されます。
- アプリケーションを評価する際、MTA は、時間、人員、およびその他の要因を含め、アプリケーションのコンテナー化準備に伴うリスクとコストを見積もります。評価の結果を使用して関係者間で議論し、アプリケーションがコンテナー化に適しているかどうかを判断できます。
- アプリケーションを分析する際、MTA はルールを使用して、アプリケーションを移行またはモダナイズする前に、アプリケーションで変更する必要がある特定の行はどれかを判断します。
7.1. Assessment モジュールの機能
Migration Toolkit for Applications (MTA) Assessment モジュールは、次のようなアプリケーションの評価および分析機能を提供します。
- Assessment ハブ
- Assessment ハブは Application inventory と統合されます。
- アセスメント質問集機能の強化
MTA 7.0 では、アセスメント質問集をインポートおよびエクスポートできます。次の機能を含む YAML 構文を使用して、ダウンロード可能なテンプレートによりカスタムの質問集を設計することもできます。
- 条件付き質問: アプリケーションまたはアーキタイプに特定のタグが存在する場合、アプリケーションまたはアーキタイプに基づいて質問を含めたり除外したりできます。
- 回答に基づくアプリケーションの自動タグ付け: 特定の回答が提供された場合に、アプリケーションまたはアーキタイプに適用するタグを定義できます。
- アプリケーションまたはアーキタイプのタグからの自動応答。
詳細は、カスタムのアセスメント質問集 を参照してください。
デフォルトの質問集をカスタマイズして保存できます。詳細は、デフォルトのアセスメント質問集 を参照してください。
- 複数のアセスメント質問集
- Assessment モジュールは、1 つ以上のアプリケーションに関連する複数の質問集をサポートします。
- アーキタイプ
特性がにているアプリケーションをアーキタイプにグループ化できます。これにより、複数のアプリケーションを一度に評価できます。各アーキタイプには、タグ、ステークホルダー、およびステークホルダーグループの共有分類があります。すべてのアプリケーションは、割り当てられたアーキタイプからアセスメントとレビューを継承します。
詳細は、アーキタイプの操作 を参照してください。
7.2. MTA のアセスメント質問集
Migration Toolkit for Applications (MTA) は、デフォルト または カスタム のアセスメント質問集を使用して、アプリケーションのコンテナー化に伴うリスクを評価します。
アセスメントレポートは、移行に関連するアプリケーションとリスクに関する情報を提供します。このレポートは、評価用に提出されたアプリケーションの優先度、ビジネスの重要性、依存関係に基づいた導入計画も生成します。
7.2.1. デフォルトのアセスメント質問集
Migration Toolkit for Applications (MTA) のデフォルトの質問集は、Legacy Pathfinder です。Pathfinder は質問集ベースのツールです。エンタープライズ Kubernetes プラットフォーム上のコンテナーにおけるアプリケーションのモダナイゼーションの適合性を評価するために使用できます。
デフォルトの質問集やレビュープロセスとのやり取りの結果、アプリケーションの情報が、アセスメントレポートの収集を通じて明らかになり、システムに追加されます。
デフォルトの質問集は YAML ファイルにエクスポートできます。
例7.1 Legacy Pathfinder YAML ファイル
name: Legacy Pathfinder description: '' sections: - order: 1 name: Application details questions: - order: 1 text: >- Does the application development team understand and actively develop the application? explanation: >- How much knowledge does the team have about the application's development or usage? answers: - order: 2 text: >- Maintenance mode, no SME knowledge or adequate documentation available risk: red rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Little knowledge, no development (example: third-party or commercial off-the-shelf application) risk: red rationale: '' mitigation: '' - order: 3 text: Maintenance mode, SME knowledge is available risk: yellow rationale: '' mitigation: '' - order: 4 text: Actively developed, SME knowledge is available risk: green rationale: '' mitigation: '' - order: 5 text: greenfield application risk: green rationale: '' mitigation: '' - order: 2 text: How is the application supported in production? explanation: >- Does the team have sufficient knowledge to support the application in production? answers: - order: 3 text: >- Multiple teams provide support using an established escalation model risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- External support provider with a ticket-driven escalation process; no inhouse support resources risk: red rationale: '' mitigation: '' - order: 2 text: >- Separate internal support team, separate from the development team, with little interaction between the teams risk: red rationale: '' mitigation: '' - order: 4 text: >- SRE (Site Reliability Engineering) approach with a knowledgeable and experienced operations team risk: green rationale: '' mitigation: '' - order: 5 text: >- DevOps approach with the same team building the application and supporting it in production risk: green rationale: '' mitigation: '' - order: 3 text: >- How much time passes from when code is committed until the application is deployed to production? explanation: What is the development latency? answers: - order: 3 text: 2-6 months risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Not tracked risk: red rationale: '' mitigation: '' - order: 2 text: More than 6 months risk: red rationale: '' mitigation: '' - order: 4 text: 8-30 days risk: green rationale: '' mitigation: '' - order: 5 text: 1-7 days risk: green rationale: '' mitigation: '' - order: 6 text: Less than 1 day risk: green rationale: '' mitigation: '' - order: 4 text: How often is the application deployed to production? explanation: Deployment frequency answers: - order: 3 text: Between once a month and once every 6 months risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Not tracked risk: red rationale: '' mitigation: '' - order: 2 text: Less than once every 6 months risk: red rationale: '' mitigation: '' - order: 4 text: Weekly risk: green rationale: '' mitigation: '' - order: 5 text: Daily risk: green rationale: '' mitigation: '' - order: 6 text: Several times a day risk: green rationale: '' mitigation: '' - order: 5 text: >- What is the application's mean time to recover (MTTR) from failure in a production environment? explanation: Average time for the application to recover from failure answers: - order: 5 text: Less than 1 hour risk: green rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Not tracked risk: red rationale: '' mitigation: '' - order: 3 text: 1-7 days risk: yellow rationale: '' mitigation: '' - order: 2 text: 1 month or more risk: red rationale: '' mitigation: '' - order: 4 text: 1-24 hours risk: green rationale: '' mitigation: '' - order: 6 text: Does the application have legal and/or licensing requirements? explanation: >- Legal and licensing requirements must be assessed to determine their possible impact (cost, fault reporting) on the container platform hosting the application. Examples of legal requirements: isolated clusters, certifications, compliance with the Payment Card Industry Data Security Standard or the Health Insurance Portability and Accountability Act. Examples of licensing requirements: per server, per CPU. answers: - order: 1 text: Multiple legal and licensing requirements risk: red rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 2 text: 'Licensing requirements (examples: per server, per CPU)' risk: red rationale: '' mitigation: '' - order: 3 text: >- Legal requirements (examples: cluster isolation, hardware, PCI or HIPAA compliance) risk: yellow rationale: '' mitigation: '' - order: 4 text: None risk: green rationale: '' mitigation: '' - order: 7 text: Which model best describes the application architecture? explanation: Describe the application architecture in simple terms. answers: - order: 3 text: >- Complex monolith, strict runtime dependency startup order, non-resilient architecture risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 5 text: Independently deployable components risk: green rationale: '' mitigation: '' - order: 1 text: >- Massive monolith (high memory and CPU usage), singleton deployment, vertical scale only risk: yellow rationale: '' mitigation: '' - order: 2 text: >- Massive monolith (high memory and CPU usage), non-singleton deployment, complex to scale horizontally risk: yellow rationale: '' mitigation: '' - order: 4 text: 'Resilient monolith (examples: retries, circuit breakers)' risk: green rationale: '' mitigation: '' - order: 2 name: Application dependencies questions: - order: 1 text: Does the application require specific hardware? explanation: >- OpenShift Container Platform runs only on x86, IBM Power, or IBM Z systems answers: - order: 3 text: 'Requires specific computer hardware (examples: GPUs, RAM, HDDs)' risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Requires CPU that is not supported by red Hat risk: red rationale: '' mitigation: '' - order: 2 text: 'Requires custom or legacy hardware (example: USB device)' risk: red rationale: '' mitigation: '' - order: 4 text: Requires CPU that is supported by red Hat risk: green rationale: '' mitigation: '' - order: 2 text: What operating system does the application require? explanation: >- Only Linux and certain Microsoft Windows versions are supported in containers. Check the latest versions and requirements. answers: - order: 4 text: Microsoft Windows risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Operating system that is not compatible with OpenShift Container Platform (examples: OS X, AIX, Unix, Solaris) risk: red rationale: '' mitigation: '' - order: 2 text: Linux with custom kernel drivers or a specific kernel version risk: red rationale: '' mitigation: '' - order: 3 text: 'Linux with custom capabilities (examples: seccomp, root access)' risk: yellow rationale: '' mitigation: '' - order: 5 text: Standard Linux distribution risk: green rationale: '' mitigation: '' - order: 3 text: >- Does the vendor provide support for a third-party component running in a container? explanation: Will the vendor support a component if you run it in a container? answers: - order: 2 text: No vendor support for containers risk: red rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Not recommended to run the component in a container risk: red rationale: '' mitigation: '' - order: 3 text: >- Vendor supports containers but with limitations (examples: functionality is restricted, component has not been tested) risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Vendor supports their application running in containers but you must build your own images risk: yellow rationale: '' mitigation: '' - order: 5 text: Vendor fully supports containers, provides certified images risk: green rationale: '' mitigation: '' - order: 6 text: No third-party components required risk: green rationale: '' mitigation: '' - order: 4 text: Incoming/northbound dependencies explanation: Systems or applications that call the application answers: - order: 3 text: >- Many dependencies exist, can be changed because the systems are internally managed risk: green rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 4 text: Internal dependencies only risk: green rationale: '' mitigation: '' - order: 1 text: >- Dependencies are difficult or expensive to change because they are legacy or third-party risk: red rationale: '' mitigation: '' - order: 2 text: >- Many dependencies exist, can be changed but the process is expensive and time-consuming risk: yellow rationale: '' mitigation: '' - order: 5 text: No incoming/northbound dependencies risk: green rationale: '' mitigation: '' - order: 5 text: Outgoing/southbound dependencies explanation: Systems or applications that the application calls answers: - order: 3 text: Application not ready until dependencies are verified available risk: yellow rationale: '' mitigation: '' - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Dependency availability only verified when application is processing traffic risk: red rationale: '' mitigation: '' - order: 2 text: Dependencies require a complex and strict startup order risk: yellow rationale: '' mitigation: '' - order: 4 text: Limited processing available if dependencies are unavailable risk: green rationale: '' mitigation: '' - order: 5 text: No outgoing/southbound dependencies risk: green rationale: '' mitigation: '' - order: 3 name: Application architecture questions: - order: 1 text: >- How resilient is the application? How well does it recover from outages and restarts? explanation: >- If the application or one of its dependencies fails, how does the application recover from failure? Is manual intervention required? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Application cannot be restarted cleanly after failure, requires manual intervention risk: red rationale: '' mitigation: '' - order: 2 text: >- Application fails when a soutbound dependency is unavailable and does not recover automatically risk: red rationale: '' mitigation: '' - order: 3 text: >- Application functionality is limited when a dependency is unavailable but recovers when the dependency is available risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Application employs resilient architecture patterns (examples: circuit breakers, retry mechanisms) risk: green rationale: '' mitigation: '' - order: 5 text: >- Application containers are randomly terminated to test resiliency; chaos engineering principles are followed risk: green rationale: '' mitigation: '' - order: 2 text: How does the external world communicate with the application? explanation: >- What protocols do external clients use to communicate with the application? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: 'Non-TCP/IP protocols (examples: serial, IPX, AppleTalk)' risk: red rationale: '' mitigation: '' - order: 2 text: TCP/IP, with host name or IP address encapsulated in the payload risk: red rationale: '' mitigation: '' - order: 3 text: 'TCP/UDP without host addressing (example: SSH)' risk: yellow rationale: '' mitigation: '' - order: 4 text: TCP/UDP encapsulated, using TLS with SNI header risk: green rationale: '' mitigation: '' - order: 5 text: HTTP/HTTPS risk: green rationale: '' mitigation: '' - order: 3 text: How does the application manage its internal state? explanation: >- If the application must manage or retain an internal state, how is this done? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 3 text: State maintained in non-shared, non-ephemeral storage risk: yellow rationale: '' mitigation: '' - order: 1 text: Application components use shared memory within a pod risk: yellow rationale: '' mitigation: '' - order: 2 text: >- State is managed externally by another product (examples: Zookeeper or red Hat Data Grid) risk: yellow rationale: '' mitigation: '' - order: 4 text: Disk shared between application instances risk: green rationale: '' mitigation: '' - order: 5 text: Stateless or ephemeral container storage risk: green rationale: '' mitigation: '' - order: 4 text: How does the application handle service discovery? explanation: How does the application discover services? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Uses technologies that are not compatible with Kubernetes (examples: hardcoded IP addresses, custom cluster manager) risk: red rationale: '' mitigation: '' - order: 2 text: >- Requires an application or cluster restart to discover new service instances risk: red rationale: '' mitigation: '' - order: 3 text: >- Uses technologies that are compatible with Kubernetes but require specific libraries or services (examples: HashiCorp Consul, Netflix Eureka) risk: yellow rationale: '' mitigation: '' - order: 4 text: Uses Kubernetes DNS name resolution risk: green rationale: '' mitigation: '' - order: 5 text: Does not require service discovery risk: green rationale: '' mitigation: '' - order: 5 text: How is the application clustering managed? explanation: >- Does the application require clusters? If so, how is clustering managed? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: 'Manually configured clustering (example: static clusters)' risk: red rationale: '' mitigation: '' - order: 2 text: Managed by an external off-PaaS cluster manager risk: red rationale: '' mitigation: '' - order: 3 text: >- Managed by an application runtime that is compatible with Kubernetes risk: green rationale: '' mitigation: '' - order: 4 text: No cluster management required risk: green rationale: '' mitigation: '' - order: 4 name: Application observability questions: - order: 1 text: How does the application use logging and how are the logs accessed? explanation: How the application logs are accessed answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Logs are unavailable or are internal with no way to export them risk: red rationale: '' mitigation: '' - order: 2 text: >- Logs are in a custom binary format, exposed with non-standard protocols risk: red rationale: '' mitigation: '' - order: 3 text: Logs are exposed using syslog risk: yellow rationale: '' mitigation: '' - order: 4 text: Logs are written to a file system, sometimes as multiple files risk: yellow rationale: '' mitigation: '' - order: 5 text: 'Logs are forwarded to an external logging system (example: Splunk)' risk: green rationale: '' mitigation: '' - order: 6 text: 'Logs are configurable (example: can be sent to stdout)' risk: green rationale: '' mitigation: '' - order: 2 text: Does the application provide metrics? explanation: >- Are application metrics available, if necessary (example: OpenShift Container Platform collects CPU and memory metrics)? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: No metrics available risk: yellow rationale: '' mitigation: '' - order: 2 text: Metrics collected but not exposed externally risk: yellow rationale: '' mitigation: '' - order: 3 text: 'Metrics exposed using binary protocols (examples: SNMP, JMX)' risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Metrics exposed using a third-party solution (examples: Dynatrace, AppDynamics) risk: green rationale: '' mitigation: '' - order: 5 text: >- Metrics collected and exposed with built-in Prometheus endpoint support risk: green rationale: '' mitigation: '' - order: 3 text: >- How easy is it to determine the application's health and readiness to handle traffic? explanation: >- How do we determine an application's health (liveness) and readiness to handle traffic? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: No health or readiness query functionality available risk: red rationale: '' mitigation: '' - order: 3 text: Basic application health requires semi-complex scripting risk: yellow rationale: '' mitigation: '' - order: 4 text: Dedicated, independent liveness and readiness endpoints risk: green rationale: '' mitigation: '' - order: 2 text: Monitored and managed by a custom watchdog process risk: red rationale: '' mitigation: '' - order: 5 text: Health is verified by probes running synthetic transactions risk: green rationale: '' mitigation: '' - order: 4 text: What best describes the application's runtime characteristics? explanation: >- How would the profile of an application appear during runtime (examples: graphs showing CPU and memory usage, traffic patterns, latency)? What are the implications for a serverless application? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Deterministic and predictable real-time execution or control requirements risk: red rationale: '' mitigation: '' - order: 2 text: >- Sensitive to latency (examples: voice applications, high frequency trading applications) risk: yellow rationale: '' mitigation: '' - order: 3 text: Constant traffic with a broad range of CPU and memory usage risk: yellow rationale: '' mitigation: '' - order: 4 text: Intermittent traffic with predictable CPU and memory usage risk: green rationale: '' mitigation: '' - order: 5 text: Constant traffic with predictable CPU and memory usage risk: green rationale: '' mitigation: '' - order: 5 text: How long does it take the application to be ready to handle traffic? explanation: How long the application takes to boot answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: More than 5 minutes risk: red rationale: '' mitigation: '' - order: 2 text: 2-5 minutes risk: yellow rationale: '' mitigation: '' - order: 3 text: 1-2 minutes risk: yellow rationale: '' mitigation: '' - order: 4 text: 10-60 seconds risk: green rationale: '' mitigation: '' - order: 5 text: Less than 10 seconds risk: green rationale: '' mitigation: '' - order: 5 name: Application cross-cutting concerns questions: - order: 1 text: How is the application tested? explanation: >- Is the application is tested? Is it easy to test (example: automated testing)? Is it tested in production? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: No testing or minimal manual testing only risk: red rationale: '' mitigation: '' - order: 2 text: Minimal automated testing, focused on the user interface risk: yellow rationale: '' mitigation: '' - order: 3 text: >- Some automated unit and regression testing, basic CI/CD pipeline testing; modern test practices are not followed risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Highly repeatable automated testing (examples: unit, integration, smoke tests) before deploying to production; modern test practices are followed risk: green rationale: '' mitigation: '' - order: 5 text: >- Chaos engineering approach, constant testing in production (example: A/B testing + experimentation) risk: green rationale: '' mitigation: '' - order: 2 text: How is the application configured? explanation: >- How is the application configured? Is the configuration method appropriate for a container? External servers are runtime dependencies. answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: >- Configuration files compiled during installation and configured using a user interface risk: red rationale: '' mitigation: '' - order: 2 text: >- Configuration files are stored externally (example: in a database) and accessed using specific environment keys (examples: host name, IP address) risk: red rationale: '' mitigation: '' - order: 3 text: Multiple configuration files in multiple file system locations risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Configuration files built into the application and enabled using system properties at runtime risk: yellow rationale: '' mitigation: '' - order: 5 text: >- Configuration retrieved from an external server (examples: Spring Cloud Config Server, HashiCorp Consul) risk: yellow rationale: '' mitigation: '' - order: 6 text: >- Configuration loaded from files in a single configurable location; environment variables used risk: green rationale: '' mitigation: '' - order: 4 text: How is the application deployed? explanation: >- How the application is deployed and whether the deployment process is suitable for a container platform answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 3 text: Simple automated deployment scripts risk: yellow rationale: '' mitigation: '' - order: 1 text: Manual deployment using a user interface risk: red rationale: '' mitigation: '' - order: 2 text: Manual deployment with some automation risk: red rationale: '' mitigation: '' - order: 4 text: >- Automated deployment with manual intervention or complex promotion through pipeline stages risk: yellow rationale: '' mitigation: '' - order: 5 text: >- Automated deployment with a full CI/CD pipeline, minimal intervention for promotion through pipeline stages risk: green rationale: '' mitigation: '' - order: 6 text: Fully automated (GitOps), blue-green, or canary deployment risk: green rationale: '' mitigation: '' - order: 5 text: Where is the application deployed? explanation: Where does the application run? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Bare metal server risk: green rationale: '' mitigation: '' - order: 2 text: 'Virtual machine (examples: red Hat Virtualization, VMware)' risk: green rationale: '' mitigation: '' - order: 3 text: 'Private cloud (example: red Hat OpenStack Platform)' risk: green rationale: '' mitigation: '' - order: 4 text: >- Public cloud provider (examples: Amazon Web Services, Microsoft Azure, Google Cloud Platform) risk: green rationale: '' mitigation: '' - order: 5 text: >- Platform as a service (examples: Heroku, Force.com, Google App Engine) risk: yellow rationale: '' mitigation: '' - order: 7 text: Other. Specify in the comments field risk: yellow rationale: '' mitigation: '' - order: 6 text: Hybrid cloud (public and private cloud providers) risk: green rationale: '' mitigation: '' - order: 6 text: How mature is the containerization process, if any? explanation: If the team has used containers in the past, how was it done? answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Application runs in a container on a laptop or desktop risk: red rationale: '' mitigation: '' - order: 3 text: Some experience with containers but not yet fully defined risk: yellow rationale: '' mitigation: '' - order: 4 text: >- Proficient with containers and container platforms (examples: Swarm, Kubernetes) risk: green rationale: '' mitigation: '' - order: 5 text: Application containerization has not yet been attempted risk: green rationale: '' mitigation: '' - order: 3 text: How does the application acquire security keys or certificates? explanation: >- How does the application retrieve credentials, keys, or certificates? External systems are runtime dependencies. answers: - order: 0 text: unknown risk: unknown rationale: '' mitigation: '' - order: 1 text: Hardware security modules or encryption devices risk: red rationale: '' mitigation: '' - order: 2 text: >- Keys/certificates bound to IP addresses and generated at runtime for each application instance risk: red rationale: '' mitigation: '' - order: 3 text: Keys/certificates compiled into the application risk: yellow rationale: '' mitigation: '' - order: 4 text: Loaded from a shared disk risk: yellow rationale: '' mitigation: '' - order: 5 text: >- Retrieved from an external server (examples: HashiCorp Vault, CyberArk Conjur) risk: yellow rationale: '' mitigation: '' - order: 6 text: Loaded from files risk: green rationale: '' mitigation: '' - order: 7 text: Not required risk: green rationale: '' mitigation: '' thresholds: red: 5 yellow: 30 unknown: 5 riskMessages: red: '' yellow: '' green: '' unknown: '' builtin: true
7.2.2. カスタムのアセスメント質問集
Migration Toolkit for Applications (MTA) を使用すると、カスタムの YAML 構文を使用して質問集を定義し、カスタムのアセスメント質問集をインポートできます。YAML 構文は次の機能をサポートしています。
- 条件付きの質問
YAML 構文は、アプリケーションまたはアーキタイプに存在するタグに基づく質問の追加または除外をサポートします。次に例を示します。
アプリケーションまたはアーキタイプに
Language/Java
タグがある場合に、What is the main JAVA framework used in your application?
という質問を質問集に追加します。... questions: - order: 1 text: What is the main JAVA framework used in your application? explanation: Identify the primary JAVA framework used in your application. includeFor: - category: Language tag: Java ...
アプリケーションまたはアーキタイプに
Deployment/Serverless
およびArchitecture/Monolith
タグがある場合に、Are you currently using any form of container orchestration?
という質問を質問集から除外します。... questions: - order: 4 text: Are you currently using any form of container orchestration? explanation: Determine if the application utilizes container orchestration tools like Kubernetes, Docker Swarm, etc. excludeFor: - category: Deployment tag: Serverless - category: Architecture tag: Monolith ...
- 評価対象のアプリケーションまたはアーキタイプに存在するタグに基づく自動回答
自動回答は、アプリケーションまたはアーキタイプに存在するタグに基づいて選択されます。たとえば、アプリケーションまたはアーキタイプに
Runtime/Quarkus
タグがある場合は、Quarkus
の回答が自動的に選択され、アプリケーションまたはアーキタイプにRuntime/Spring Boot
タグがある場合は、Spring Boot
の回答が自動的に選択されます。... text: What is the main technology in your application? explanation: Identify the main framework or technology used in your application. answers: - order: 1 text: Quarkus risk: green autoAnswerFor: - category: Runtime tag: Quarkus - order: 2 text: Spring Boot risk: green autoAnswerFor: - category: Runtime tag: Spring Boot ...
- 回答に基づいたアプリケーションの自動タグ付け
アセスメント中に、回答が選択されると、その回答に基づいてアプリケーションまたはアーキタイプにタグが自動的に適用されます。タグは推移的であることに注意してください。したがって、アセスメントが破棄されるとタグは削除されます。各タグは次の要素によって定義されます。
-
category: 対象タグのカテゴリー (
文字列
)。 -
tag: ターゲットタグの定義 (
String
)。
たとえば、選択した回答が
Quarkus
の場合、評価対象のアプリケーションまたはアーキタイプにRuntime/Quarkus
タグが適用されます。選択した回答がSpring Boot
の場合、Runtime/Spring Boot
タグが評価対象のアプリケーションまたはアーキタイプに適用されます。... questions: - order: 1 text: What is the main technology in your application? explanation: Identify the main framework or technology used in your application. answers: - order: 1 text: Quarkus risk: green applyTags: - category: Runtime tag: Quarkus - order: 2 text: Spring Boot risk: green applyTags: - category: Runtime tag: Spring Boot ...
-
category: 対象タグのカテゴリー (
7.2.2.1. カスタム質問集の YAML テンプレート
次の YAML テンプレートを使用して、カスタムの質問集をビルドできます。このテンプレートは、Assessment questionnaires ページで Download YAML template をクリックするとダウンロードできます。
例7.2 カスタム質問集の YAML テンプレート
name: Uploadable Cloud Readiness Questionnaire Template description: This questionnaire is an example template for assessing cloud readiness. It serves as a guide for users to create and customize their own questionnaire templates. required: true sections: - order: 1 name: Application Technologies questions: - order: 1 text: What is the main technology in your application? explanation: Identify the main framework or technology used in your application. includeFor: - category: Language tag: Java answers: - order: 1 text: Quarkus risk: green rationale: Quarkus is a modern, container-friendly framework. mitigation: No mitigation needed. applyTags: - category: Runtime tag: Quarkus autoAnswerFor: - category: Runtime tag: Quarkus - order: 2 text: Spring Boot risk: green rationale: Spring Boot is versatile and widely used. mitigation: Ensure container compatibility. applyTags: - category: Runtime tag: Spring Boot autoAnswerFor: - category: Runtime tag: Spring Boot - order: 3 text: Legacy Monolithic Application risk: red rationale: Legacy monoliths are challenging for cloud adaptation. mitigation: Consider refactoring into microservices. - order: 2 text: Does your application use a microservices architecture? explanation: Assess if the application is built using a microservices architecture. answers: - order: 1 text: Yes risk: green rationale: Microservices are well-suited for cloud environments. mitigation: Continue monitoring service dependencies. - order: 2 text: No risk: yellow rationale: Non-microservices architectures may face scalability issues. mitigation: Assess the feasibility of transitioning to microservices. - order: 3 text: Unknown risk: unknown rationale: Lack of clarity on architecture can lead to unplanned issues. mitigation: Conduct an architectural review. - order: 3 text: Is your application's data storage cloud-optimized? explanation: Evaluate if the data storage solution is optimized for cloud usage. includeFor: - category: Language tag: Java answers: - order: 1 text: Cloud-Native Storage Solution risk: green rationale: Cloud-native solutions offer scalability and resilience. mitigation: Ensure regular backups and disaster recovery plans. - order: 2 text: Traditional On-Premises Storage risk: red rationale: Traditional storage might not scale well in the cloud. mitigation: Explore cloud-based storage solutions. - order: 3 text: Hybrid Storage Approach risk: yellow rationale: Hybrid solutions may have integration complexities. mitigation: Evaluate and optimize cloud integration points. thresholds: red: 1 yellow: 30 unknown: 15 riskMessages: red: Requires deep changes in architecture or lifecycle yellow: Cloud friendly but needs minor changes green: Cloud Native unknown: More information needed
関連情報
7.2.2.2. カスタム質問集のフィールド
required とマークしたカスタム質問集のフィールドはすべて必須であり、入力する必要があります。記入しないと、アップロード時に YAML 構文が検証されません。フィールドの各サブセクションは、YAML で新しい構造体またはオブジェクトを定義します。次に例を示します。
... name: Testing thresholds: red: 30 yellow: 45 unknown: 5 ...
質問集のフィールド | 説明 |
---|---|
| 質問集の名前。このフィールドは、MTA インスタンス全体で一意である必要があります。 |
| 質問集の簡単な説明。 |
| リスクレベルの影響を受けると考えられるアプリケーションまたはアーキタイプの、リスクカテゴリーごとのしきい値の定義。しきい値は次のとおりです。
より高いリスクレベルが常に優先されます。たとえば、 |
| 各リスクカテゴリーのレポートに表示されるメッセージ。risk_messages マップは次のフィールドで定義されます。
|
| 質問集に含める必要があるセクションのリスト。
|
関連情報
7.3. アセスメント質問集の管理
MTA ユーザーインターフェイスを使用すると、アセスメント質問集に対して次のアクションを実行できます。
- 質問集を表示します。回答の選択肢とそれに関連するリスクの重みを表示することもできます。
- 質問集をシステム上の目的の場所にエクスポートします。
システムから質問集をインポートします。
警告インポートされた質問集の名前は一意である必要があります。YAML 構文で定義されている名前 (
name:<name of questionnaire>
) が重複している場合、インポートは失敗し、UNIQUE constraint failed: Questionnaire.Name
というエラーメッセージが返されます。アセスメント質問集を削除します。
警告質問集を削除すると、すべてのアーキタイプでその質問集を使用しているすべてのアプリケーションの回答も削除されます。
重要デフォルトの質問集である Legacy Pathfinder は削除できません。
手順
状況に応じて、次のいずれかの操作を実行します。
アセスメント質問集の質問を表示します。
- Administration ビューで、Assessment questionnaires を選択します。
-
Options メニュー (
) をクリックします。
- 表示する質問集の View を選択します。
- オプション: 質問の左側にある矢印をクリックすると、回答の選択肢とそのリスク重みが表示されます。
アセスメント質問集をエクスポートします。
- Administration ビューで、Assessment questionnaires を選択します。
- 目的の質問集を選択します。
-
Options メニュー (
) をクリックします。
- Export を選択します。
- ダウンロード先を選択します。
- Save をクリックします。
アセスメント質問集をインポートします。
- Administration ビューで、Assessment questionnaires を選択します。
- Import questionnaire をクリックします。
- Upload をクリックします。
- 質問集の場所に移動します。
- Open をクリックします。
- Import をクリックして、目的の質問集をインポートします。
アセスメント質問集を削除します。
- Administration ビューで、Assessment questionnaires を選択します。
- 削除する質問集を選択します。
-
Options メニュー (
) をクリックします。
- Delete を選択します。
- 質問集の Name を入力して削除を確認します。
7.4. アプリケーションの評価
アプリケーションのアセスメントを実行することで、コンテナー化に向けたアプリケーションの準備に伴うリスクとコストを見積もることができます。Assessment モジュールを使用して、アプリケーションを評価し、現在保存されているアセスメントを表示できます。
Migration Toolkit for Applications (MTA) は、依存関係など、アプリケーションに関連する一連の質問に基づいてアプリケーションを評価します。
アプリケーションを評価するには、デフォルトの Legacy Pathfinder MTA 質問集を使用するか、カスタム 質問集をインポートできます。
一度に評価できるアプリケーションは 1 つだけです。
前提条件
- MTA サーバーにログイン済みである。
手順
- MTA ユーザーインターフェイスで、Migration ビューを選択します。
- 左側のメニューバーで Application inventory をクリックします。使用可能なアプリケーションのリストがメインペインに表示されます。
- 評価するアプリケーションを選択します。
-
行末の Options メニュー (
) をクリックし、ドロップダウンメニューから Assess を選択します。
- 利用可能な質問集のリストから、目的の質問集の Take をクリックします。
リストから Stakeholders と Stakeholder groups を選択して、後で参照できるように誰がアセスメントに貢献したかをトラッキングします。
注記Migration ビューの Controls ペインで Stakeholder Groups または Stakeholders を追加することもできます。詳細は、インスタンスのシード値設定 を参照してください。
- Next をクリックします。
- Application assessment の各質問に答えて、Next をクリックします。
- Save をクリックしてアセスメントを確認し、アプリケーションのレビュー の手順に進みます。
アプリケーションで完全に解決できない誤検出が発生しても、それはまったく予想外のことではありません。
その理由は、呼び出されるクラスを MTA が検出できないためです。したがって、MTA は該当する一致が妥当なものかどうかを判定できません。
このような場合、MTA はデフォルトでより多くの情報を公開します。
このような状況では、次の解決策をお勧めします。
- Maven 設定がすべての依存関係を取得できることを確認します。
- アプリケーションが完全にコンパイルできることを確認します。
7.5. アプリケーションのレビュー
Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、各アプリケーションの移行戦略と作業の優先順位を決定できます。
一度にレビューできるアプリケーションは 1 つだけです。
手順
- Migration ビューで、Application inventory をクリックします。
- レビューしたいアプリケーションを選択します。
次のいずれかのアクションを実行して、アプリケーションをレビューします。
- アプリケーションの評価中に Save and Review をクリックします。詳細は、アプリケーションの評価 参照してください。
行末のオプションメニュー (
) をクリックして、ドロップダウンメニューから Review を選択します。アプリケーションの Review パラメーターがメインペインに表示されます。
- Proposed action をクリックし、アクションを選択します。
- Effort estimate をクリックし、選択した質問集によるアセスメントを実行するのに必要な作業量を設定します。
- Business criticality フィールドに、アプリケーションがビジネスにとってどの程度重要かを入力します。
- Work priority フィールドにアプリケーションの優先度を入力します。
- オプション: Comments フィールドに、アセスメント質問集のコメントを入力します。
Submit review をクリックします。
Review のフィールドが Application details ページに入力されるようになりました。
7.6. アセスメントレポートのレビュー
MTA のアセスメントレポートには、複数のアプリケーションの質問集から取得されたデータを集約したアセスメントが表示されます。
手順
Migration ビューで、Reports をクリックします。すべてのアプリケーションの集約されたアセスメントレポートが表示されます。
状況に応じて、次のいずれかの操作を実行します。
特定の質問集のデータに関するレポートを表示します。
- レポートの Current landscape ペインにあるすべての質問集のドロップダウンリストから、必要な質問集を選択します。デフォルトでは、すべての質問集が選択されます。
- レポートの Identified risks ペインで、表示されたリストを、アプリケーション名、リスクレベル、質問集、質問集のセクション、質問、および回答で並べ替えます。
特定のアプリケーションのレポートを表示します。
- レポートの Identified risks ペインの Applications 列のリンクをクリックします。Application inventory ページが開きます。リンクに含まれるアプリケーションは、リストに表示されます。
必要なアプリケーションをクリックします。Assessment サイドペインが開きます。
- アプリケーションの評価されたリスクレベルを表示するには、Details タブを開きます。
- アセスメントの詳細を表示するには、Reviews タブを開きます。
7.7. アプリケーションのタグ付け
分析対象のアプリケーションにさまざまなタグを割り当てることができます。タグを使用してアプリケーションを分類し、アプリケーションの種類、データセンターの場所、アプリケーション内で使用されるテクノロジーなどのアプリケーション情報を即座に特定できます。タグ付けを使用して、アーキタイプをアプリケーションに関連付け、自動アセスメントを行うこともできます。アーキタイプの詳細は、アーキタイプの操作 を参照してください。
タグ付けは、分析中に 自動 で行うことができるほか、いつでも 手動 で行うことができます。
すべてのタグが自動的に割り当てられるわけではありません。たとえば、分析中にアプリケーションに付けることができるタグは、アプリケーションのテクノロジーに基づくタグだけです。アプリケーションに、それがデプロイされているデータセンターの場所もタグ付けする場合は、アプリケーションを手動でタグ付けする必要があります。
7.7.1. アプリケーションタグの作成
MTA が評価または分析するアプリケーションのカスタムタグを作成できます。
手順
- Migration ビューで、Controls をクリックします。
- Tags タブをクリックします。
- Create tag をクリックします。
- 開いたダイアログの Name フィールドに、タグの一意の名前を入力します。
- Tag category フィールドをクリックし、タグに関連付けるカテゴリータグを選択します。
- Create をクリックします。
オプション: 作成したタグまたはタグカテゴリーを編集します。
タグを編集します。
- Tags タブのタグカテゴリーのリストで、目的のカテゴリーのタグのリストを開きます。
- ドロップダウンメニューから Edit を選択し、Name フィールドでタグ名を編集します。
- Tag category フィールドをクリックし、タグに関連付けるカテゴリータグを選択します。
- Save をクリックします。
タグカテゴリーを編集します。
- Tags タブで、定義済みのタグカテゴリーを選択し、Edit をクリックします。
- Name フィールドでタグカテゴリーの名前を編集します。
- カテゴリーの Rank 値を編集します。
- Color フィールドをクリックして、タグカテゴリーの色を選択します。
- Save をクリックします。
7.7.2. アプリケーションへの手動タグ付け
アプリケーション分析の実行前でも後でも、アプリケーションに手動でタグを付けることができます。
手順
- Migration ビューで、Application inventory をクリックします。
-
必要なアプリケーションの行で、Edit (
) をクリックします。Update application ウィンドウが開きます。
- Select a tag(s) ドロップダウンリストから必要なタグを選択します。
- Save をクリックします。
7.7.3. 自動タグ付け
アプリケーションを Application Inventory に追加すると、MTA が言語検出タスクとテクノロジー検出タスクを自動的に生成します。言語検出タスクの実行中、テクノロジー検出タスクと分析タスクは、言語検出タスクが完了するまで待機します。これらのタスクによって、アプリケーションにタグが自動的に追加されます。MTA は、アプリケーション分析に基づいて、アプリケーションに自動的にタグを追加できます。自動タグ付けは、大規模なアプリケーションのポートフォリオを扱う場合に特に役立ちます。
アプリケーション分析に基づくアプリケーションの自動タグ付けは、デフォルトで有効になっています。Analysis configuration ウィザードの Advanced セクションで Enable automated tagging ボックスをオフにすると、アプリケーション分析中に自動タグ付けを無効にできます。
アプリケーションを自動的にタグ付けするには、アプリケーション分析を実行する 前 に Enable automated tagging チェックボックスが選択されていることを確認します。
7.7.4. アプリケーションタグの表示
特定のアプリケーションに付加されたタグを表示できます。
自動的に付加されたタグは、アプリケーション分析を実行した 後に のみ表示できます。
手順
- Migration ビューで、Application inventory をクリックします。
- 必要なアプリケーションの名前をクリックします。サイドペインが開きます。
- Tags タブをクリックします。アプリケーションに付加されたタグが表示されます。
7.8. アーキタイプの操作
アーキタイプ は、共通の特性を持つアプリケーションのグループです。アーキタイプを使用して、複数のアプリケーションを一度に評価できます。
アプリケーションのアーキタイプは、基準タグとアプリケーションの分類によって定義されます。各アーキタイプは、そのアーキタイプで定義された特性に基づいて Assessment モジュール でアプリケーションを評価する方法を定義します。アプリケーションのタグがアーキタイプの基準タグと一致する場合、アプリケーションはアーキタイプに関連付けられます。
アーキタイプの作成は、一連の tags、stakeholders、および stakeholder groups によって定義されます。タグには次のタイプが含まれます。
基準タグ は、アプリケーションをメンバーとして含めるためにアーキタイプで必要なタグです。
注記アーキタイプ基準タグがアプリケーションに部分的にしか一致しない場合、このアプリケーションはアーキタイプのメンバーになることはできません。たとえば、アプリケーション a にタグ a しかなく、アーキタイプ a の基準タグにタグ a とタグ b が含まれている場合、アプリケーション a はアーキタイプ a のメンバーにはなりません。
- アーキタイプタグ は、アーキタイプエンティティーに適用されるタグです。
アーキタイプに関連付けられたすべてのアプリケーションが、そのアプリケーションが属するアーキタイプグループから アセスメント と レビュー を継承します。これはデフォルト設定です。個別のアセスメントとレビューを完了することで、アプリケーションの継承をオーバーライドできます。
7.8.1. アーキタイプの作成
アーキタイプを作成すると、インベントリー内のアプリケーションにアーキタイプのタグと一致する基準タグがある場合、そのアプリケーションは自動的にそのアーキタイプに関連付けられます。
手順
- MTA Web コンソールを開きます。
- 左側のメニューで、Archetypes をクリックします。
- Create new archetype をクリックします。
開いたフォームに、新しいアーキタイプに関する次の情報を入力します。
- Name: 新しいアーキタイプの名前 (必須)。
- Description: 新しいアーキタイプの説明 (任意)。
- Criteria Tags: 評価されたアプリケーションをアーキタイプに関連付けるタグ (必須)。基準タグが更新されると、アーキタイプが関連付けられているアプリケーションを計算するプロセスが再度トリガーされます。
- Archetype Tags: アプリケーション内でアーキタイプが評価するタグ (必須)。
- Stakeholder(s): アプリケーションの開発と移行に関与する特定のステークホルダー (任意)。
- Stakeholders Group(s): アプリケーションの開発と移行に関与するステークホルダーのグループ (任意)。
- Create をクリックします。
7.8.2. アーキタイプの評価
アーキタイプは、必須の質問集がすべて回答されたときに、評価されたとみなされます。
アプリケーションが複数のアーキタイプに関連付けられている場合、関連付けられている全アーキタイプが評価されたときに、そのアプリケーションは評価されたとみなされます。
前提条件
- MTA サーバーにログイン済みである。
手順
- MTA Web コンソールを開きます。
- Migration ビューを選択し、Archetype をクリックします。
-
Options メニュー (
) をクリックし、ドロップダウンメニューから Assess を選択します。
- 利用可能な質問集のリストから、Take をクリックして、目的の質問集を選択します。
- Assessment メニューで、必要な質問に回答します。
- Save をクリックします。
7.8.3. アーキタイプのレビュー
アーキタイプは、複数の質問集が必須とマークされている場合でも、一度レビューされたときに、レビューされたとみなされます。
アプリケーションが複数のアーキタイプに関連付けられている場合、関連付けられているすべてのアーキタイプがレビューされたときに、そのアプリケーションはレビュー済みとみなされます。
前提条件
- MTA サーバーにログイン済みである。
手順
- MTA Web コンソールを開きます。
- Migration ビューを選択し、Archetype をクリックします。
-
Options メニュー (
) をクリックし、ドロップダウンメニューから Review を選択します。
- 利用可能な質問集のリストから、Take をクリックして、目的のアセスメント質問集を選択します。
- Assessment メニューで、必要な質問に回答します。
- Save and Review を選択します。自動的に Review タブにリダイレクトされます。
以下の情報を入力します。
- Proposed Action: アーキタイプの移行またはモダナイズを完了するために必要な、提案されるアクション。
- Effort estimate: 選択したアーキタイプのモダナイズまたは移行を実行するために必要な作業のレベル。
- Business criticality: ビジネスに対するアプリケーションの重要度。
- Work Priority: アーキタイプの優先度。
- Submit review をクリックします。
7.8.4. アーキタイプの削除
アーキタイプを削除すると、関連付けられている評価とレビューも削除されます。関連付けられているすべてのアプリケーションは、Unassessed および Unreviewed 状態に移行します。
7.9. アプリケーションの分析
Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、アプリケーション分析を設定および実行できます。分析により、アプリケーションを移行またはモダナイズする前に、アプリケーション内のどの行を変更する必要があるかを確認できます。
7.9.1. アプリケーション分析の設定と実行
同じ分析で、複数の変換ターゲットに対して一度に複数のアプリケーションを分析できます。
手順
- Migration ビューで、Application inventory をクリックします。
- 分析するアプリケーションを選択します。
- アプリケーションに割り当てられた認証情報を確認します。
- Analyze をクリックします。
リストから Analysis mode を選択します。
- Binary
- Source code
- Source code and dependencies
- Upload a local binary。このオプションは、単一のアプリケーションを分析している場合にのみ表示されます。このオプションを選択した場合は、ローカルバイナリーをアップロード するように求められます。指定の領域にファイルをドラッグするか、Upload をクリックしてアップロードするファイルを選択します。
- Next をクリックします。
分析のターゲットオプションを 1 つ以上選択します。
次のいずれかのプラットフォームへのアプリケーションサーバーの移行:
- JBoss EAP 7
- JBoss EAP 8
- Containerization
- Quarkus
- OracleJDK to OpenJDK
OpenJDK。次の JDK バージョンのいずれかにアップグレードするには、このオプションを使用します。
- OpenJDK 11
- OpenJDK 17
- OpenJDK 21
- Linux。アプリケーションに Microsoft Windows パスがハードコードされていないことを確認するには、このオプションを使用します。
- Jakarta EE 9。Java EE 8 から移行するには、このオプションを使用します。
- Spring Boot on Red Hat Runtimes
- Open Liberty
- Camel。Apache Camel 2 から Apache Camel 3 に、または Apache Camel 3 から Apache Camel 4 に移行するには、このオプションを使用します。
- Azure App Service
- Next をクリックします。
次の Scope オプションのいずれかを選択して、分析を絞り込みます。
- アプリケーションと内部の依存関係のみ。
- アプリケーションと、既知のオープンソースライブラリーを含むすべての依存関係。
- 手動で分析するパッケージのリスト選択。このオプションを選択した場合は、ファイル名を入力して Add をクリックします。
- パッケージの除外。このオプションを選択した場合は、パッケージ名を入力して Add をクリックします。
- Next をクリックします。
Advanced では、Manual モードまたは Repository モードを選択して、分析に追加のカスタムルールを割り当てることができます。
- Manual モードでは、Add Rules をクリックします。関連するファイルをドラッグするか、ディレクトリーからファイルを選択して、Add をクリックします。
Repository モードでは、Git または Subversion リポジトリーからルールファイルを追加できます。
重要すでに移行ターゲットを分析にアタッチしている場合、カスタムルールのアタッチはオプションです。移行ターゲットをアタッチしていない場合は、ルールをアタッチする必要があります。
オプション: 次のオプションのいずれかを設定します。
- Target
- Source(s)
- Excluded rules tags。これらのタグを持つルールは処理されません。必要に応じて追加または削除します。
Enable automated tagging。このチェックボックスを選択すると、アプリケーションにタグが自動的に付加されます。このチェックボックスはデフォルトで選択されています。
注記自動的に付加されたタグは、分析の実行 後に のみ表示されます。
自動タグ付けを有効にする代わりに、または自動タグ付けに加えて、アプリケーションにタグを手動で付加できます。
注記分析エンジンは、幅広い移行ターゲットに対応した標準ルールを使用します。ただし、ターゲットが含まれていない場合、ターゲットがカスタマイズされたフレームワークである場合、またはサポートされていない言語 (Node.js、Python など) でアプリケーションが記述されている場合は、Set Target タブでターゲットの選択をスキップし、Custom Rules タブでカスタムルールファイルをアップロードすることで、カスタムルールを追加できます。手動でアップロードされたカスタムルールファイルだけが検証されます。
- Next をクリックします。
- Review で、解析パラメーターを確認します。
Run をクリックします。
分析ステータスは、MTA がコンテナーを実行するイメージをダウンロードするため、
Scheduled
です。イメージがダウンロードされると、ステータスがIn-progress
に変わります。
アプリケーションのサイズとクラスターの容量とリソースに応じて、分析の実行には数分から数時間かかります。
MTA は、Kubernetes のスケジューリング機能に依存して、クラスターの容量に基づいて作成されるアナライザーインスタンスの数を決定します。分析用に複数のアプリケーションが選択されている場合、デフォルトでは、一度にプロビジョニングできるアナライザーは 1 つだけです。クラスター容量が増えると、より多くの分析プロセスを並行して実行できます。
オプション: アクティブな分析タスクのステータスを追跡するには、通知ボタンをクリックして Task Manager ドロワーを開きます。
または、アプリケーション名の上にマウスを置くと、ポップオーバーウィンドウが表示されます。
- 分析完了後、その結果を確認するには、アプリケーション名をクリックしてアプリケーションドロワーを開きます。
Application Inventory ページでアプリケーションインスタンスを作成すると、言語検出タスクが開始し、ターゲットフィルターオプションが自動的に事前選択されます。ただし、必要に応じて別の言語を選択することもできます。
7.9.2. 分析の詳細の確認
分析のアクティビティーログを表示できます。アクティビティーログには、分析手順などの分析の詳細が含まれています。
手順
- Migration ビューで、Application inventory をクリックします。
- アプリケーション行をクリックし、アプリケーションドロワーを開きます。
- Reports タブをクリックします。
- View analysis details クリックし、分析のアクティビティーログを表示します。
オプション: 分析中に検出された問題と依存関係は、アプリケーションドロワーの Details タブをクリックし、Issues または Dependencies をクリックします。
または、Migration ビューで Issues または Dependencies ページを開きます。
7.9.3. 一致しないルールへのアクセス
一致しないルールにアクセスするには、拡張ロギングを有効にして分析を実行する必要があります。
- Application analysis の下にある Advanced に移動します。
- Options を選択します。
- Enhanced advanced analysis details を確認します。
分析を実行するときに、次の手順を実行します。
- サイドドロワーの Reports に移動します。
- View analysis details をクリックし、YAML/JSON 形式のログビューを開きます。
-
issues.yaml
ファイルを選択します。 各ルールセットに unmatched セクションがあります。ここに、一致するルールが見つからないルール ID がリストされます。
7.9.4. 分析レポートのダウンロード
MTA 分析レポートには、アプリケーションで使用されているテクノロジーのリスト、アプリケーションの依存関係、アプリケーションを正常に移行または最新化するために変更する必要があるコード行など、複数のセクションが含まれています。
MTA 分析レポートの内容の詳細は、レポートの確認 を参照してください。
便利なように、分析レポートをダウンロードできます。デフォルトではこのオプションは無効になっていることに注意してください。
手順
- Administration ビューで、General をクリックします。
- Allow reports to be downloaded after running an analysis. のスイッチを切り替えます。
- Migration ビューに移動し、Application inventory をクリックします。
- アプリケーション行をクリックし、アプリケーションドロワーを開きます。
- Reports タブをクリックします。
HTML または YAML リンクをクリックします。
-
HTML リンクをクリックすると、圧縮された
analysis-report-app-<application_name>.tar
ファイルがダウンロードされます。このファイルを展開すると、アプリケーションと同じ名前のフォルダーが作成されます。 -
YAML リンクをクリックすると、圧縮されていない
analysis-report-app-<application_name>.yaml
ファイルがダウンロードされます。
-
HTML リンクをクリックすると、圧縮された
7.10. Task Manager を使用した MTA タスクの制御
Task Manager は、実行キューに追加された Migration Toolkit for Applications (MTA) タスクに関する正確な情報を提供します。Task Manager は次の種類のタスクを処理します。
- アプリケーション分析
- 言語検出
- テクノロジー検出
タスク関連の情報は、次のいずれかの方法で表示できます。
- アクティブなタスクを表示するには、通知ボタンをクリックして Task Manager ドロワーを開きます。
- すべてのタスクを表示するには、Migration ビューで Task Manager ページを開きます。
リソースに対するマルチユーザーアクセス制限はありません。たとえば、あるユーザーが作成したアナライザータスクを別のユーザーがキャンセルできます。
7.10.1. タスクログの確認
特定の Migration Toolkit for Applications (MTA) タスクの詳細とログを見つけるには、Task Manager ページを使用します。
手順
- Migration ビューで、Task Manager をクリックします。
-
Options メニュー (
) をクリックします。
Task details をクリックします。
または、Status 列のタスクステータスをクリックします。
7.10.2. タスク実行順序の制御
Task Manager を使用すると、実行をスケジュールした Migration Toolkit for Applications (MTA) タスクのプリエンプション (横取り) を行うことができます。
プリエンプション は、スケジュール済みのタスク (Running、Succeeded、または Failed ステータスではないもの) に対して有効にできます。ただし、横取りの対象となるのは、優先度の低いタスクだけです。優先度の高いタスクが優先度の低いタスクによってブロックされ、プリエンプション が有効な場合、ブロックされた優先度の高いタスクが実行されるように、優先度の低いタスクが再スケジュールされることがあります。したがって、アプリケーション分析など、優先度の高いタスクに対してのみ プリエンプション を有効にすると便利です。
手順
- Migration ビューで、Task Manager をクリックします。
-
Options メニュー (
) をクリックします。
状況に応じて、次のいずれかの手順を実行します。
- タスクの プリエンプション を有効にするには、Enable preemption を選択します。
- プリエンプション が有効になっているタスクの プリエンプション を無効にするには、Disable preemption を選択します。
改訂日時: 2025-01-27