Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

ユーザーインターフェイスガイド

Migration Toolkit for Applications 7.2

Migration Toolkit for Applications ユーザーインターフェイスを使用して、アプリケーションを分析用のプロジェクトにグループ化する

Red Hat Customer Content Services

概要

このガイドでは、Migration Toolkit for Applications ユーザーインターフェイスを使用して、Red Hat OpenShift 上のハイブリッドクラウド環境全体で大規模なアプリケーションモダナイゼーションの取り組みを促進する方法を説明します。

多様性を受け入れるオープンソースの強化
リンクのコピー

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 への移行をより短期間で行うことができます。

1.2. Migration Toolkit for Applications の概要
リンクのコピー

Migration Toolkit for Applications とは

Migration Toolkit for Applications (MTA) は、Red Hat OpenShift 上のハイブリッドクラウド環境全体で大規模なアプリケーションモダナイゼーションに対する取り組みを促進します。このソリューションは、導入プロセス全体を通じて、ポートフォリオレベルとアプリケーションレベルの詳細情報を提供します。ユーザーインターフェイスを使用して、アプリケーションのインベントリー作成、評価、分析、および管理を行い、OpenShift への移行をより短期間で行うことができます。

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 について、次の表で説明します。

Expand
表3.1 必要な永続ボリューム
名前デフォルトのサイズアクセスモード説明

hub database

10Gi

RWO

ハブのデータベース

hub bucket

100Gi

RWX

ハブのファイルストレージ。rwx_supported 設定オプションが true に設定されている場合は、必須です。

keycloak postgresql

1Gi

RWO

Keycloak バックエンドデータベース

cache

100Gi

RWX

Maven m2 キャッシュ。rwx_supported 設定オプションが true に設定されている場合は、必須です。

3.2. Migration Toolkit for Applications Operator とユーザーインターフェイスのインストール
リンクのコピー

Migration Toolkit for Applications (MTA) とユーザーインターフェイスは、Red Hat OpenShift バージョン 4.18、4.17 にインストールできます。

前提条件

  • 4 つ vCPU、8 GB RAM、および 40 GB の永続ストレージ。
  • クラウドサービス版またはセルフホスト版のバージョン 4.18、4.17 の Red Hat OpenShift。
  • cluster-admin 権限を持つユーザーとしてログインしている。

詳細は、OpenShift Operator のライフサイクル を参照してください。

手順

  1. Red Hat OpenShift Web コンソールで、Operators → OperatorHub をクリックします。
  2. Filter by keyword フィールドを使用して、MTA を検索します。
  3. Migration Toolkit for Applications Operator をクリックし、Install をクリックします。
  4. Install Operator ページで、Install をクリックします。
  5. Operators → Installed Operators をクリックして、MTA Operator が openshift-mta プロジェクトに Succeeded ステータスで表示されることを確認します。
  6. MTA Operator をクリックします。

  7. Provided APIs で Tackle を見つけ、Create Instance をクリックします。

    Create Tackle ウィンドウが Form ビューで開きます。

  8. カスタムリソース (CR) 設定を確認します。デフォルトの選択で問題ありませんが、ストレージ、メモリー、およびコアのシステム要件を確認してください。

  9. YAML ファイルを直接操作する場合は、YAML ビューをクリックして、YAML ファイルの spec セクションに列挙されている CR 設定を確認します。

    最も一般的に使用される CR 設定を次の表に示します。

    Expand
    表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

    NA

    Tackle RWX ボリュームに要求されるストレージクラス。MTA 6.0.1 で非推奨。

    rwx_supported

    true

    クラスターストレージが RWX モードをサポートしているかどうかを示すフラグ。

    rwo_storage_class

    NA

    Tackle RW0 ボリュームに要求されたストレージクラス

    rhsso_external_access

    False

    MTA 管理の RHSSO インスタンスにアクセスするための専用ルートが作成されているかどうかを示すフラグ

    analyzer_container_limits_cpu

    1

    Pod が使用できる CPU の最大数

    analyzer_container_limits_memory

    1Gi

    Pod が使用できるメモリーの最大量。Pod に OOMKilled エラーが表示される場合は、この制限を増やすことができます。

    analyzer_container_requests_cpu

    1

    Pod の実行に必要な CPU の最小数

    analyzer_container_requests_memory

    512 Mi

    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.5Gi

    Java プロバイダーリソースが使用できるメモリーの最大量。Pod に OOMKilled エラーが表示される場合は、この制限を増やすことができます。

    provider_java_container_requests_cpu

    1

    Java プロバイダーリソースの実行に必要な CPU の最小数

    provider_java_container_requests_memory

    2.5Gi

    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"
    Copy to Clipboard Toggle word wrap

  10. 必要に応じて CR 設定を編集し、Create をクリックします。
  11. Administration ビューで、Workloads → Pods をクリックして、MTA Pod が実行されていることを確認します。
  12. OpenShift 内の mta-ui アプリケーションによって公開されたルートを使用して、ブラウザーからユーザーインターフェイスにアクセスします。

  13. 次の認証情報を使用してログインします。

    • ユーザー名: admin
    • パスワード:Passw0rd!
  14. プロンプトが表示されたら、新しいパスワードを作成します。

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 を入力します。

以下に例を示します。

RHSSO の管理者認証情報は、MTA がインストールされている名前空間内の credential-mta-rhsso という名前の秘密ファイルに保存されます。

管理者の認証情報を取得するには、次のコマンドを実行します。 

oc get secret credential-mta-rhsso -o yaml
Copy to Clipboard Toggle word wrap

RHSSO インスタンス専用のルートを作成するには、MTA の Tackle カスタムリソース (CR) で rhsso_external_access パラメーターを true に設定します。

警告

リソースに対するマルチユーザーアクセス制限はありません。たとえば、あるユーザーが作成したアナライザータスクを別のユーザーがキャンセルできます。

関連情報

3.3.1. ロール、ペルソナ、ユーザー、権限
リンクのコピー

MTA は 3 つのロールを使用します。それぞれ 1 つのペルソナに対応しています。

Expand
表3.3 ロールとペルソナ
ロールペルソナ

tackle-admin

管理者

tackle-architect

アーキテクト

tackle-migrator

移行担当者

ロールは 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 ビューに対する管理者、アーキテクト、移行担当者のアクセス権限を、次の表にまとめます。

Expand
表3.4 ロールと MTA のビューへのアクセス権
メニューアーキテクト移行担当者管理者

管理

いいえ

いいえ

はい

移行

はい

はい

はい

3.3.1.2. ロールと権限
リンクのコピー

次の表には、MTA が管理対象の RHSSO インスタンスにシードするロールと権限 (スコープ) を示します。

Expand

tackle-admin

リソース名

動詞

 

addons

delete
get
post
put

 

adoptionplans

post
get
post
put

 

applications

delete
get
post
put

 

applications.facts

delete
get
post
put

 

applications.tags

delete
get
post
put

 

applications.bucket

delete
get
post
put

 

assessments

delete
get
patch
post
put

 

businessservices

delete
get
post
put

 

dependencies

delete
get
post
put

 

identities

delete
get
post
put

 

imports

delete
get
post
put

 

jobfunctions

delete
get
post
put

 

proxies

delete
get
post
put

 

reviews

delete
get
post
put

 

settings

delete
get
post
put

 

stakeholdergroups

delete
get
post
put

 

stakeholders

delete
get
post
put

 

tags

delete
get
post
put

 

tagtypes

delete
get
post
put

 

tasks

delete
get
post
put

 

tasks.bucket

delete
get
post
put

 

tickets

delete
get
post
put

 

trackers

delete
get
post
put

 

cache

delete
get

 

files

delete
get
post
put

 

rulebundles

delete
get
post
put

Expand

tackle-architect

リソース名

動詞

 

addons

delete
get
post
put

 

applications.bucket

delete
get
post
put

 

adoptionplans

post

 

applications

delete
get
post
put

 

applications.facts

delete
get
post
put

 

applications.tags

delete
get
post
put

 

assessments

delete
get
patch
post
put

 

businessservices

delete
get
post
put

 

dependencies

delete
get
post
put

 

identities

get

 

imports

delete
get
post
put

 

jobfunctions

delete
get
post
put

 

proxies

get

 

reviews

delete
get
post
put

 

settings

get

 

stakeholdergroups

delete
get
post
put

 

stakeholders

delete
get
post
put

 

tags

delete
get
post
put

 

tagtypes

delete
get
post
put

 

tasks

delete
get
post
put

 

tasks.bucket

delete
get
post
put

 

trackers

get

 

tickets

delete
get
post
put

 

cache

get

 

files

delete
get
post
put

 

rulebundles

delete
get
post
put

Expand

tackle-migrator

リソース名

動詞

 

addons

get

 

adoptionplans

post

 

applications

get

 

applications.facts

get

 

applications.tags

get

 

applications.bucket

get

 

assessments

get
post

 

businessservices

get

 

dependencies

delete
get
post
put

 

identities

get

 

imports

get

 

jobfunctions

get

 

proxies

get

 

reviews

get
post
put

 

settings

get

 

stakeholdergroups

get

 

stakeholders

get

 

tags

get

 

tagtypes

get

 

tasks

delete
get
post
put

 

tasks.bucket

delete
get
post
put

 

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
    Copy to Clipboard Toggle word wrap

  • Debian/Ubuntu では、以下を実行します。 

    sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system network-manager
    Copy to Clipboard Toggle word wrap

3.4.2. Red Hat OpenShift Local 環境への Migration Toolkit for Applications Operator のインストール
リンクのコピー

Red Hat OpenShift Local をインストールするには、次の手順を実行します。

  1. ご使用のプラットフォーム用の Red Hat OpenShift Local の最新リリースをダウンロードします。

    1. OpenShift Local をダウンロードします。
    2. プルシークレット をダウンロードします。

  2. アーカイブを ~/Downloads ディレクトリーに保存した場合は、次の手順に従います。 

    cd ~/Downloads
    Copy to Clipboard Toggle word wrap 
    tar xvf crc-linux-amd64.tar.xz
    Copy to Clipboard Toggle word wrap

  3. crc 実行ファイルをそこにコピーします。 

    cp ~/Downloads/crc-linux-<version-number>-amd64/crc ~/bin/crc
    Copy to Clipboard Toggle word wrap

  4. $PATH 変数に ~/bin/crc ディレクトリーを追加します。 

    export PATH=$PATH:$HOME/bin/crc
    Copy to Clipboard Toggle word wrap 
    echo 'export PATH=$PATH:$HOME/bin/crc' >> ~/.bashrc
    Copy to Clipboard Toggle word wrap

  5. テレメトリーを無効にするために、次のコマンドを実行します。 

    crc config set consent-telemetry no
    Copy to Clipboard Toggle word wrap
注記

macOS の場合は、適切な crc-macos-installer.pkg をダウンロードしてください。

  1. Finder を使用して Downloads に移動します。
  2. crc-macos-installer.pkg をダブルクリックします。

3.4.3. Red Hat OpenShift Local の設定
リンクのコピー

crc setup コマンドで、Red Hat OpenShift Local インスタンスのホストマシンの環境を設定する操作を実行します。

crc setup コマンドは ~/.crc ディレクトリーを作成します。

  1. Red Hat OpenShift Local 用にホストマシンを設定します。 

    crc setup
    Copy to Clipboard Toggle word wrap

3.4.4. Red Hat OpenShift Local インスタンスの起動
リンクのコピー

Red Hat OpenShift Local プリセットは、マネージドコンテナーランタイムと、インスタンスがそのランタイムの実行に必要なシステムリソースの下限を表します。

注記
  • Linux または macOS の場合は、ユーザーアカウントに sudo コマンドを使用できるようになっている。
  • Microsoft Windows の場合は、ユーザーアカウントが管理者権限に昇格できるようになっている。

crc start コマンドで、Red Hat OpenShift Local インスタンスと設定済みのコンテナーランタイムを起動します。以下のフラグを使用できます。

Expand
Flags型説明デフォルト値

-b、--bundle

string

バンドルのパス/URI - 絶対パスまたはローカルパス、HTTP、HTTPS、または docker URI (例: 'https://foo.com/crc_libvirt_4.15.14_amd64.crcbundle', 'docker://quay.io/myorg/crc_libvirt_4.15.14_amd64.crcbundle:2.37.1')

デフォルト '/home/<user>/.crc/cache/ crc_libvirt_4.15.14_amd64.crcbundle'

-c、–cpus

int

インスタンスに割り当てる CPU コアの数

4

–disable-update-check

 

更新をチェックしない

 

-d、–disk-size

uint

インスタンスが使用するディスクの合計サイズ (GB)

31

-h、–help

 

start のヘルプ

 

-m、–memory

int

インスタンスに割り当てるメモリーの Mi

10752

-n、–nameserver

string

インスタンスに使用するネームサーバーの IPv4 アドレス

 

-o、–output

string

JSON 形式の出力

 

-p、–pull-secret-file

string

イメージプルシークレットのファイルパス (https://console.redhat.com/openshift/create/local からダウンロード)

 

また、次のグローバルフラグも使用できます。

Expand
Flags型説明デフォルト値

–log-level

string

ログレベルの例:

* debug

* info

* warn

* error

info

デフォルト設定では、4 つの仮想 CPU、31 GB のディスクサイズ、10 GB の RAM を持つ仮想マシン (VM) が作成されます。ただし、このデフォルト設定では、MTA を安定して実行するには不十分です。

仮想 CPU の数を 6 に、ディスクサイズを 200 GB に、メモリーを 20 GB に増やすには、次のように crc config を実行します。 

crc config set cpus 6
Copy to Clipboard Toggle word wrap 
crc config set disk-size 200
Copy to Clipboard Toggle word wrap 
$ crc config set memory 20480
Copy to Clipboard Toggle word wrap

設定を確認するには、次のコマンドを実行します。 

crc config view
Copy to Clipboard Toggle word wrap

出力例

- consent-telemetry    : yes
- cpus                 : 6
- disk-size            : 200
- memory               : 16384
Copy to Clipboard Toggle word wrap

注記

入力した設定プロパティーへの変更は、CRC インスタンスの起動時にのみ適用されます。

すでに実行中の CRC インスタンスがある場合、この設定の変更を有効にするには、crc stop で CRC インスタンスを停止し、crc start で再起動します。

3.4.5. Red Hat OpenShift Local インスタンスのステータスの確認
リンクのコピー

Red Hat OpenShift Local インスタンスのステータスを確認するには、次のコマンドを実行します。 

crc status
Copy to Clipboard Toggle word wrap

出力例

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
Copy to Clipboard Toggle word wrap

3.4.6. Red Hat OpenShift Local 環境での Migration Toolkit for Applications Operator の設定
リンクのコピー

次の表は、テスト済みの Red Hat OpenShift Local の推奨最小設定を示しています。

Expand
メモリー (Gi)CPUディスクサイズ (Gi)

20Gi

5

110Gi

20Gi

5

35Gi (MTA Operator 設定の cache_data_volume_size と hub_bucket_volume_size が 5Gi に設定されている場合)

3.5. Java アナライザーと検出の最小要件の追加
リンクのコピー

Java アナライザーおよび検出タスクの最小要件は、デフォルトで 2.5 GB に設定されています。

この最小要件は 1.5 GB まで下げることができますが、これは推奨されません。

この最小要件を 2.5 GB 以上に増やすこともできます。 

kind: Tackle
apiVersion: tackle.konveyor.io/v1alpha1
metadata:
  name: tackle
  namespace: openshift-mta
spec:
  feature_auth_required: 'true'
  provider_java_container_limits_memory: 2.5Gi
  provider_java_container_requests_memory: 2.5Gi
Copy to Clipboard Toggle word wrap
注記

スケジュール設定用に適切な領域を確保するために、provider_java_container_limits_memory と provider_java_container_requests_memory に同じ量の領域を割り当ててください。

第4章 インスタンス環境の設定
リンクのコピー

Administration ビューでは次の設定を行うことができます。

  • 全般
  • 認証情報
  • リポジトリー
  • プロキシー (HTTP および HTTPS プロキシー設定)
  • カスタム移行ターゲット
  • 課題管理
  • アセスメント質問集

4.1. 全般
リンクのコピー

次のオプションを有効または無効にできます。

  • 分析実行後のレポートのダウンロードを許可する

4.2. 認証情報の設定
リンクのコピー

Administration ビューでは、次の種類の認証情報を設定できます。

  • ソース制御
  • Maven 設定ファイル
  • プロキシー
  • Basic 認証 (Jira)
  • ベアラートークン (Jira)

4.2.1. ソース管理認証情報の設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、ソース管理認証情報を設定できます。

手順

  1. Administration ビューで、Credentials をクリックします。
  2. Create new をクリックします。

  3. 以下の情報を入力します。

    • 名前
    • 説明 (任意)
  4. Type リストで、Source Control を選択します。

  5. User credentials リストで、Credential Type を選択し、要求された情報を入力します。

    • ユーザー名/パスワード

      • ユーザー名
      • パスワード (非表示)

    • SCM 秘密鍵のパスフレーズ

      • SCM 秘密鍵

      • 秘密鍵のパスフレーズ (非表示)

        注記

        鍵やパスフレーズなどのタイプ固有の認証情報は、非表示にされるか、[Encrypted] (暗号化済み) として表示されます。

  6. Create をクリックします。

    MTA は入力を検証し、新しい認証情報を作成します。SCM キーは、解析して有効性をチェックする必要があります。検証に失敗すると、“not a valid key/XML file” エラーメッセージが表示されます。

4.2.2. Maven 認証情報の設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、新しい Maven 認証情報を設定できます。

手順

  1. Administration ビューで、Credentials をクリックします。
  2. Create new をクリックします。

  3. 以下の情報を入力します。

    • 名前
    • 説明 (任意)
  4. Type リストで、Maven Settings File を選択します。
  5. 設定ファイルをアップロードするか、その内容を貼り付けます。

  6. Create をクリックします。

    MTA は入力を検証し、新しい認証情報を作成します。Maven の settings.xml ファイルを解析し、有効性をチェックする必要があります。検証に失敗すると、“not a valid key/XML file” エラーメッセージが表示されます。

4.2.3. プロキシー認証情報の設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Credentials ビューで、プロキシー認証情報を設定できます。

手順

  1. Administration ビューで、Credentials をクリックします。
  2. Create new をクリックします。

  3. 以下の情報を入力します。

    • 名前
    • 説明 (任意)
  4. Type リストで、Proxy を選択します。

  5. 以下の情報を入力します。

    • ユーザー名

    • パスワード

      注記

      鍵やパスフレーズなどのタイプ固有の認証情報は、非表示にされるか、[Encrypted] (暗号化済み) として表示されます。

  6. Create をクリックします。

    MTA は入力を検証し、新しい認証情報を作成します。

4.3. リポジトリーの設定
リンクのコピー

Administration ビューでは、次のタイプのリポジトリーを設定できます。

  • Git
  • Subversion
  • Maven

4.3.1. Git リポジトリーの設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで Git リポジトリーを設定できます。

手順

  1. Administration ビューで、Repositories をクリックし、Git をクリックします。
  2. Consume insecure Git repositories のスイッチを右に切り替えます。

4.3.2. subversion リポジトリーの設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで Subversion リポジトリーを設定できます。

手順

  1. Administration ビューで、Repositories をクリックし、Subversion をクリックします。
  2. Consume insecure Subversion repositories のスイッチを右に切り替えます。

4.3.3. Maven リポジトリーの設定とそのサイズの縮小
リンクのコピー

MTA ユーザーインターフェイスを使用して、Maven リポジトリーの設定とそのサイズの縮小の両方を行うことができます。

4.3.3.1. Maven リポジトリーの設定
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスの Repositories ビューで、Maven リポジトリーを設定できます。

手順

  1. Administration ビューで、Repositories をクリックし、Maven をクリックします。
  2. 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 ボタンの両方が無効になり、この手順は実行できません。

手順

  1. Administration ビューで、Repositories をクリックし、Maven をクリックします。

  2. Clear repository リンクをクリックします。

    注記

    リポジトリーのサイズによっては、機能が正常に動作していてもサイズの変化がわかりにくい場合があります。

4.4. HTTP および HTTPS プロキシーの設定
リンクのコピー

この管理モジュールを使用して、HTTP および HTTPS プロキシーを設定できます。

手順

  1. Administration ビューで、Proxy をクリックします。
  2. HTTP proxy または HTTPS proxy を切り替えて、プロキシー接続を有効にします。

  3. 以下の情報を入力します。

    • プロキシーホスト
    • プロキシーポート
  4. オプション: HTTP proxy credentials または HTTPS proxy credentials を切り替えて、認証を有効にします。
  5. Insert をクリックします。

4.5. カスタム移行ターゲットの作成
リンクのコピー

admin 権限を持つアーキテクトまたはユーザーは、カスタム移行ターゲットに関連付けられたカスタムルールセットを作成および維持できます。アーキテクトは、カスタムルールファイルをアップロードし、さまざまなカスタム移行ターゲットへの割り当てできます。その後、分析設定ウィザードでカスタム移行ターゲットを選択できます。

既製のカスタム移行ターゲットを使用すると、分析を実行するたびにカスタムルールを設定する必要がなくなります。これにより、管理者以外のユーザーやサードパーティーの開発者にとって分析の設定と実行が簡素化されます。

前提条件

  • admin 権限を持つユーザーとしてログインしている。

手順

  1. Administration ビューで Custom migration targets をクリックします。
  2. Create new をクリックします。
  3. ターゲットの名前と説明を入力します。
  4. Image セクションで、ターゲットのアイコンのイメージファイルをアップロードします。ファイルは PNG または JPEG 形式で、最大 1 MB にすることができます。ファイルをアップロードしない場合は、デフォルトのアイコンが使用されます。

  5. Custom rules セクションで、Upload manually または Retrieve from a repository を選択します。

    • Upload manually を選択した場合は、ローカルドライブから必要なルールファイルをアップロードまたはドラッグアンドドロップします。

    • Retrieve from a repository を選択した場合は、次の手順を実行します。

      1. Git または Subversion を選択します。
      2. Source repository、Branch、および Root path フィールドに入力します。
      3. リポジトリーに認証情報が必要な場合は、これらの認証情報を Associated credentials フィールドに入力します。

  6. Create をクリックします。

    新しい移行ターゲットが Custom migration targets ページに表示されます。Migration ビューで、管理者以外のユーザーが使用できるようになりました。

4.6. インスタンスのシード値設定
リンクのコピー

プロジェクトアーキテクトは、移行前にコントロールウィンドウでインスタンスの主要なパラメーターを設定できます。パラメーターは、必要に応じて追加および編集できます。次のパラメーターは、移行の影響を受ける、または移行に参加している組織内のアプリケーション、個人、チーム、垂直または領域を定義します。

  • Stakeholders
  • Stakeholder groups
  • Job functions
  • Business services
  • Tag categories
  • Tags

インスタンスは任意の順序で作成および設定できます。ただし、Stakeholders と Tags を作成するには、以下の推奨順序が最も効率的です。

Stakeholders:

  1. Stakeholder groups を作成する
  2. Job functions を作成する
  3. Stakeholders を作成する

Tags:

  1. Tag categories を作成する
  2. Tags を作成する

Stakeholders であり、以下によって定義されます。

  • Email
  • Name
  • Job function
  • Stakeholder groups

4.6.1. 新しい Stakeholder groups の作成
リンクのコピー

デフォルトの Stakeholder groups は定義されていません。以下の手順に従って、新しい Stakeholder groups を作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Stakeholder groups をクリックします。
  3. Create new をクリックします。

  4. 以下の情報を入力します。

    • Name
    • Description
    • Member(s)
  5. Create をクリックします。

4.6.2. 新しい Job function の作成
リンクのコピー

Migration Toolkit for Applications (MTA) は、Job function 属性を使用して Stakeholders を分類し、デプロイメント可能なデフォルト値のリストを提供します。

以下の手順に従って、デフォルトのリストにない新しい Job function を作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Job functions をクリックします。
  3. Create new をクリックします。
  4. Name テキストボックスに役職名を入力します。
  5. Create をクリックします。

4.6.3. 新しい Stakeholder の作成
リンクのコピー

以下の手順に従って、新しい移行プロジェクトの Stakeholder を作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Stakeholders をクリックします。
  3. Create new をクリックします。

  4. 以下の情報を入力します。

    • Email
    • Name
    • Job function- カスタム機能を作成可能
    • Stakeholder group
  5. Create をクリックします。

4.6.4. 新しい Business service の作成
リンクのコピー

Migration Toolkit for Applications (MTA) は、Business service 属性を使用して、アプリケーションを使用し、移行の影響を受ける組織内の部門を指定します。

以下の手順で新規業務サービスを作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Business services をクリックします。
  3. Create new をクリックします。

  4. 以下の情報を入力します。

    • Name
    • Description
    • Owner
  5. Create をクリックします。

4.6.5. 新しい Tag categories の作成
リンクのコピー

Migration Toolkit for Applications (MTA) は、複数のカテゴリーのタグを使用し、デフォルト値のリストを提供します。以下の手順で Tag categories を新規作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Tags をクリックします。
  3. Create tag category をクリックします。

  4. 以下の情報を入力します。

    • Name
    • Rank - タグがアプリケーションに表示される順序
    • Color
  5. Create をクリックします。
4.6.5.1. 新しい Tags の作成
リンクのコピー

デフォルトのリストにない新しい Tags を作成するには、次の手順に従います。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Tags をクリックします。
  3. Create tag をクリックします。

  4. 以下の情報を入力します。

    • Name
    • Tag category
  5. Create をクリックします。

第5章 Jira 接続の作成と設定
リンクのコピー

MTA ユーザーインターフェイス内から移行ごとに Jira 課題を作成することで、アプリケーションの移行を追跡できます。Jira 課題を作成できるようにするには、まず次のことを行う必要があります。

  1. 次のステップで作成する Jira インスタンスの API に対して認証するための MTA 認証情報を作成します。
  2. MTA で Jira インスタンスを作成し、そのインスタンスへの接続を確立します。

5.1. Jira 認証情報の設定
リンクのコピー

MTA で Jira インスタンスを定義し、そのインスタンスへの接続を確立するには、まず Jira インスタンスの API に対して認証するための MTA 認証情報を作成する必要があります。

次の 2 種類の認証情報を使用できます。

  • Basic auth - Jira Cloud およびプライベート Jira サーバーまたはデータセンター用
  • Bearer Token - プライベート Jira サーバーまたはデータセンター用

MTA 認証情報を作成するには、以下の手順に従います。

手順

  1. Administration ビューで、Credentials をクリックします。

    Credentials ページが開きます。

  2. Create new をクリックします。

  3. 以下の情報を入力します。

    • 名前
    • Description (任意)

  4. Type 一覧で、Basic Auth (Jira) または Bearer Token (Jira) を選択します。

    • Basic Auth (Jira) を選択した場合は、以下の手順を実行します。

      1. Email フィールドにメールを入力します。

      2. Token フィールドに、特定の Jira 設定に応じて、Jira サイトで生成されたトークンまたは Jira ログインパスワードのいずれかを入力します。

        注記

        Jira トークンを取得するには、Jira サイトにログインする必要があります。

      3. Save をクリックします。

        新しい認証情報が Credentials ページに表示されます。

    • Bearer Token (Jira) を選択した場合は、以下の手順を実行します。

      1. Token フィールドに、Jira サイトで生成されたトークンを入力します。

      2. Save をクリックします。

        新しい認証情報が Credentials ページに表示されます。

Edit をクリックして認証情報を編集できます。

認証情報を削除するには、Delete をクリックします。

注記

Jira コネクションインスタンスにすでに割り当てられている認証情報を削除できません。

5.2. Jira 接続の作成と設定
リンクのコピー

MTA で Jira インスタンスを作成し、そのインスタンスへの接続を確立するには、以下の手順に従います。

手順

  1. Administration ビューの Issue Management で Jira をクリックします。

    Jira configuration ページが開きます。

  2. Create new をクリックします。

    New instance ウィンドウが開きます。

  3. 以下の情報を入力します。

    • インスタンスの名前
    • Jira アカウントの Web インターフェイスの URL
    • インスタンスタイプ - リストから Jira Cloud または Jira Server/Data center のいずれかを選択します。

    • 認証情報 - 一覧から選択します。

      注記

      選択したインスタンスタイプが Jira Cloud の場合、Basic Auth 認証情報のみがリストに表示されます。

      選択したインスタンスタイプが Jira Server/Data center の場合は、Basic Auth と Token Bearer の認証情報の両方が表示されます。Jira サーバーまたはデータセンターの特定の設定に適したタイプを選択します。

  4. デフォルトでは、証明書が無効なサーバーとの接続は確立できません。この制限を無効にするには、Enable insecure communication のスイッチを切り替えます。

  5. 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 サーバーにログイン済みである。

手順

  1. Migration ビューで、Application Inventory をクリックします。
  2. Create new をクリックします。

  3. Basic information で、次のフィールドに入力します。

    • Name: 新しいアプリケーションの一意の名前
    • Description: アプリケーションの簡単な説明 (任意)
    • Business service: アプリケーションの目的 (任意)
    • Manual tags: アプリケーションを特徴別に分類するソフトウェアタグ (任意、1 つ以上)
    • Owner: ドロップダウンリストから登録されたソフトウェア所有者 (任意)
    • Contributors: ドロップダウンリストに含まれるコントリビューター (任意、1 人以上)
    • Comments: アプリケーションに関する関連するコメント (任意)

  4. 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 にブランチが含まれている場合、空白にする必要があります。

    • Root path: 対象アプリケーションのリポジトリー内のルートパス (任意)。

      • Subversion の場合: ソースリポジトリー URL にルートパスが含まれている場合、空白にする必要があります。

    注記: Branch または Root path フィールドに値を入力すると、Source repository フィールドが必須になります。

  5. オプション: Binary をクリックして、次のフィールドに入力します。

    • Group: アプリケーションアーティファクトの Maven グループ。
    • Artifact: アプリケーションの Maven アーティファクト。
    • Version: アプリケーションのソフトウェアバージョン。
    • Packaging: アプリケーションアーティファクトのパッケージ (JAR、WAR、EAR など)。

    注記: Binary セクションのフィールドのいずれかに値を入力すると、すべてのフィールドが自動的に必須になります。

  6. Create をクリックします。新しいアプリケーションが定義済みアプリケーションのリストに表示されます。

自動タスク

Application Inventory に新しいアプリケーションを追加した後、カーソルをアプリケーション名の上に置くと、アプリケーションした際に生成された自動タスクが表示されます。言語検出タスクは、アプリケーション内のプログラミング言語を識別します。テクノロジー検出タスクは、アプリケーション内の特定のテクノロジーを識別します。タスクによってアプリケーションに適切なタグが自動的に追加されるため、アプリケーションに手動でタグを割り当てる手間が軽減されます。これらのタスクが完了すると、アプリケーションに追加されたタグの数が Tags 列の下に表示されます。タグを表示するには、次の手順を実行します。

  1. アプリケーションの行のエントリーをクリックします。サイドペインが開きます。
  2. Tags タブをクリックします。アプリケーションに付加されたタグが表示されます。

必要に応じて手動でタグを追加できます。MTA はアプリケーションを分析するときに、アプリケーションに追加のタグを自動的に追加できます。

6.2. アプリケーションの編集
リンクのコピー

Application Inventory 内の既存のアプリケーションを編集し、このアプリケーションの評価または分析を再実行できます。

前提条件

  • MTA サーバーにログイン済みである。

手順

  1. Migration ビューで、Application Inventory をクリックします。
  2. Migration 作業モードを選択します。
  3. 左側のメニューバーで Application Inventory をクリックします。使用可能なアプリケーションのリストがメインペインに表示されます。
  4. Edit ( icon edit ) をクリックしてアプリケーション設定を開きます。
  5. アプリケーションの設定を見直してください。アプリケーション設定のリストは、アプリケーションの追加 を参照してください。
  6. アプリケーション設定を変更した場合は、Save をクリックします。
注記

アプリケーションを編集すると、MTA が言語検出タスクとテクノロジー検出タスクを再生成します。

6.3. アプリケーションへの認証情報の割り当て
リンクのコピー

認証情報を 1 つ以上のアプリケーションに割り当てることができます。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. Analyze の右側にある Options メニュー ( kebab ) をクリックして Manage credentials を選択します。
  3. Source credentials リストと Maven settings リストから 1 つの認証情報を選択します。
  4. Save をクリックします。

6.4. アプリケーションのリストのインポート
リンクのコピー

アプリケーションとその属性のリストを含む .csv ファイルを、Migration Toolkit for Applications (MTA) ユーザーインターフェイスにインポートできます。

注記

アプリケーションのリストをインポートしても、既存のアプリケーションは上書きされません。

手順

  1. インポートファイルを見直して、必要なすべての情報が必要な形式で含まれていることを確認します。
  2. Migration ビューで、Application Inventory をクリックします。
  3. Options メニュー ( kebab ) をクリックします。
  4. Import をクリックします。
  5. 目的のファイルを選択し、Open をクリックします。
  6. オプション: Enable automatic creation of missing entities を選択します。このオプションはデフォルトで選択されます。
  7. インポートが完了したことを確認し、承認または拒否された行数を確認します。

  8. チェックボックスの左側にある矢印をクリックして、インポートされたアプリケーションを確認します。

    重要

    一部の行は依存関係にあるため、承認された行は、Application inventory リスト内のアプリケーションの数と一致しない場合があります。確認するには、CSV ファイルの Record Type 列で、アプリケーションが 1、依存関係が 2 として定義されていることを確認します。

6.5. CSV テンプレートのダウンロード
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、アプリケーションリストをインポートするための CSV テンプレートをダウンロードできます。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. Review の右側にある ( kebab ) をクリックします。
  3. Manage imports をクリックして、Application imports ページを開きます。
  4. Import の右側にある ( kebab ) をクリックします。
  5. Download CSV template をクリックします。

6.6. Migration Wave の作成
リンクのコピー

Migration Wave は、特定のスケジュールで移行できるアプリケーションのグループです。ウェーブのアプリケーションのリストを Jira 課題管理システムにエクスポートすることで、各移行を追跡できます。これにより、Migration Wave のアプリケーションごとに個別の Jira 課題が自動的に作成されます。

手順

  1. Migration ビューで、Migration waves をクリックします。
  2. Create new をクリックします。New migration wave ウィンドウが開きます。

  3. 以下の情報を入力します。

    • Name (任意)。名前を指定しない場合は、開始日と終了日を使用して Migration Wave を識別できます。
    • Potential start date。この日付は現在の日付より後の日付である必要があります。
    • Potential end date。この日付は開始日より後の日付である必要があります。
    • Stakeholders (任意)
    • Stakeholder groups (任意)
  4. Create をクリックします。新しい Migration Wave が既存の Migration Wave のリストに表示されます。

  5. アプリケーションを Migration Wave に割り当てるには、Migration Wave の右側にあるオプションメニュー ( kebab ) をクリックし、Manage applications を選択します。

    Manage applications ウィンドウが開き、他の Migration Wave に割り当てられていないアプリケーションのリストが表示されます。

  6. Migration Wave に割り当てるアプリケーションのチェックボックスを選択します。

  7. Save をクリックします。

    注記

    Migration Wave に関連付けられた各アプリケーションの所有者とコントリビューターは、Migration Wave の関係者のリストに自動的に追加されます。

  8. オプション: Migration Wave を更新するには、Migration Wave の Options メニュー ( kebab ) から 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 アイコンをクリックします。

前提条件

手順

  1. Migration ビューで、Migration waves をクリックします。
  2. Jira 課題を作成する Migration Wave の右側にあるオプションメニュー ( kebab ) をクリックし、Export to Issue Manager を選択します。Export to Issue Manager ウィンドウが開きます。
  3. Jira Cloud または Jira Server/Datacenter インスタンスタイプを選択します。
  4. 一覧から、インスタンス、プロジェクト、および課題タイプを選択します。
  5. Export をクリックします。Migration waves ページの移行ステータスが Issues Created に変わります。
  6. オプション: Migration Wave の各アプリケーションのステータスを表示するには、Status 列をクリックします。
  7. オプション: 特定のアプリケーションが 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
Copy to Clipboard Toggle word wrap

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
...
    Copy to Clipboard Toggle word wrap

  • アプリケーションまたはアーキタイプに 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
...
    Copy to Clipboard Toggle word wrap
評価対象のアプリケーションまたはアーキタイプに存在するタグに基づく自動回答

自動回答は、アプリケーションまたはアーキタイプに存在するタグに基づいて選択されます。たとえば、アプリケーションまたはアーキタイプに 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
...
Copy to Clipboard Toggle word wrap
回答に基づいたアプリケーションの自動タグ付け

アセスメント中に、回答が選択されると、その回答に基づいてアプリケーションまたはアーキタイプにタグが自動的に適用されます。タグは推移的であることに注意してください。したがって、アセスメントが破棄されるとタグは削除されます。各タグは次の要素によって定義されます。

  • 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
...
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
7.2.2.2. カスタム質問集のフィールド
リンクのコピー

required とマークしたカスタム質問集のフィールドはすべて必須であり、入力する必要があります。記入しないと、アップロード時に YAML 構文が検証されません。フィールドの各サブセクションは、YAML で新しい構造体またはオブジェクトを定義します。次に例を示します。 

...
name: Testing
thresholds:
    red: 30
    yellow: 45
    unknown: 5
...
Copy to Clipboard Toggle word wrap
Expand
表7.1 カスタム質問集のフィールド
質問集のフィールド説明

name (必須、文字列)

質問集の名前。このフィールドは、MTA インスタンス全体で一意である必要があります。

description (任意、文字列)

質問集の簡単な説明。

thresholds (必須)

リスクレベルの影響を受けると考えられるアプリケーションまたはアーキタイプの、リスクカテゴリーごとのしきい値の定義。しきい値は次のとおりです。

  • red (必須、符号なし整数): リスクレベルを red とみなすために red の回答の割合がどの程度必要か (例: 30% の場合は 30)。
  • yellow (必須、符号なし整数): リスクレベルを yellow とみなすために yellow の回答の割合がどの程度必要か (例: 30% の場合は 30)。
  • unknown (必須、符号なし整数): リスクレベルを unknown とみなすために unknown の回答の割合がどの程度必要か (例: 30% の場合は 30)。

より高いリスクレベルが常に優先されます。たとえば、yellow のしきい値が 30%、red が 5% に設定され、アプリケーションまたはアーキタイプの回答が 35% yellow、6% red に設定されている場合、アプリケーションまたはアーキタイプのリスクレベルは red になります。

riskMessages (必須)

各リスクカテゴリーのレポートに表示されるメッセージ。risk_messages マップは次のフィールドで定義されます。

  • red (必須、文字列): red のリスクレベルのレポートに表示されるメッセージ。
  • yellow (必須、文字列): yellow のリスクレベルのレポートに表示されるメッセージ。
  • green (必須、文字列): green のリスクレベルのレポートに表示されるメッセージ。
  • unknown (必須、文字列): unknown のリスクレベルのレポートに表示されるメッセージ。

sections (必須)

質問集に含める必要があるセクションのリスト。

  • name (必須、文字列): セクションに表示される名前。
  • order (必須、整数): セクション内の質問の順序。
  • comment (任意、文字列): セクションの説明。

  • questions (必須): セクションに属する質問のリスト。

    • order (必須、整数): セクション内の質問の順序。
    • text (必須、文字列): 質問。
    • explanation (任意、文字列): 質問に対する追加の説明。

    • includeFor (任意): リストであって、このリストに含まれるタグのいずれかが対象のアプリケーションまたはアーキタイプに存在する場合に、質問を表示するかどうかを定義するリスト。

      • category (必須、文字列): 対象タグのカテゴリー。
      • tag (必須、文字列): 対象タグ。

    • excludeFor (任意): リストであって、このリストに含まれるタグのいずれかが対象のアプリケーションまたはアーキタイプに存在する場合に、質問をスキップするかどうかを定義するリスト。

      • category (必須、文字列): 対象タグのカテゴリー。
      • tag (必須、文字列): 対象タグ。

    • answers (必須): 指定された質問に対する回答のリスト。

      • order (必須、整数): セクション内の質問の順序。
      • text (必須、文字列): 質問に対する回答。
      • risk (必須): 現在の回答の暗黙的なリスクレベル (red、yellow、green、または unknown)。
      • rationale (任意、文字列): リスクとみなされる回答の理由。
      • mitigation (任意、文字列): 回答が暗示するリスクに対する潜在的な軽減策の説明。

      • applyTags (任意): この回答が選択された場合に、評価対象のアプリケーションまたはアーキタイプに自動的に適用されるタグのリスト。

        • category (必須、文字列): 対象タグのカテゴリー。
        • tag (必須、文字列): 対象タグ。

      • autoAnswerFor (任意、リスト): アプリケーションまたはアーキタイプが評価されるときに、この回答が自動的に選択されるようにするタグのリスト。

        • category (必須、文字列): 対象タグのカテゴリー。
        • tag (必須、文字列): 対象タグ。

7.3. アセスメント質問集の管理
リンクのコピー

MTA ユーザーインターフェイスを使用すると、アセスメント質問集に対して次のアクションを実行できます。

  • 質問集を表示します。回答の選択肢とそれに関連するリスクの重みを表示することもできます。
  • 質問集をシステム上の目的の場所にエクスポートします。

  • システムから質問集をインポートします。

    警告

    インポートされた質問集の名前は一意である必要があります。YAML 構文で定義されている名前 (name:<name of questionnaire>) が重複している場合、インポートは失敗し、UNIQUE constraint failed: Questionnaire.Name というエラーメッセージが返されます。

  • アセスメント質問集を削除します。

    警告

    質問集を削除すると、すべてのアーキタイプでその質問集を使用しているすべてのアプリケーションの回答も削除されます。

    重要

    デフォルトの質問集である Legacy Pathfinder は削除できません。

手順

  • 状況に応じて、次のいずれかの操作を実行します。

    • アセスメント質問集の質問を表示します。

      1. Administration ビューで、Assessment questionnaires を選択します。
      2. Options メニュー ( kebab ) をクリックします。
      3. 表示する質問集の View を選択します。
      4. オプション: 質問の左側にある矢印をクリックすると、回答の選択肢とそのリスク重みが表示されます。

    • アセスメント質問集をエクスポートします。

      1. Administration ビューで、Assessment questionnaires を選択します。
      2. 目的の質問集を選択します。
      3. Options メニュー ( kebab ) をクリックします。
      4. Export を選択します。
      5. ダウンロード先を選択します。
      6. Save をクリックします。

    • アセスメント質問集をインポートします。

      1. Administration ビューで、Assessment questionnaires を選択します。
      2. Import questionnaire をクリックします。
      3. Upload をクリックします。
      4. 質問集の場所に移動します。
      5. Open をクリックします。
      6. Import をクリックして、目的の質問集をインポートします。

    • アセスメント質問集を削除します。

      1. Administration ビューで、Assessment questionnaires を選択します。
      2. 削除する質問集を選択します。
      3. Options メニュー ( kebab ) をクリックします。
      4. Delete を選択します。
      5. 質問集の Name を入力して削除を確認します。

7.4. アプリケーションの評価
リンクのコピー

アプリケーションのアセスメントを実行することで、コンテナー化に向けたアプリケーションの準備に伴うリスクとコストを見積もることができます。Assessment モジュールを使用して、アプリケーションを評価し、現在保存されているアセスメントを表示できます。

Migration Toolkit for Applications (MTA) は、依存関係など、アプリケーションに関連する一連の質問に基づいてアプリケーションを評価します。

アプリケーションを評価するには、デフォルトの Legacy Pathfinder MTA 質問集を使用するか、カスタム 質問集をインポートできます。

重要

一度に評価できるアプリケーションは 1 つだけです。

前提条件

  • MTA サーバーにログイン済みである。

手順

  1. MTA ユーザーインターフェイスで、Migration ビューを選択します。
  2. 左側のメニューバーで Application inventory をクリックします。使用可能なアプリケーションのリストがメインペインに表示されます。
  3. 評価するアプリケーションを選択します。
  4. 行末の Options メニュー ( kebab ) をクリックし、ドロップダウンメニューから Assess を選択します。
  5. 利用可能な質問集のリストから、目的の質問集の Take をクリックします。

  6. リストから Stakeholders と Stakeholder groups を選択して、後で参照できるように誰がアセスメントに貢献したかをトラッキングします。

    注記

    Migration ビューの Controls ペインで Stakeholder Groups または Stakeholders を追加することもできます。詳細は、インスタンスのシード値設定 を参照してください。

  7. Next をクリックします。
  8. Application assessment の各質問に答えて、Next をクリックします。
  9. Save をクリックしてアセスメントを確認し、アプリケーションのレビュー の手順に進みます。
注記

アプリケーションで完全に解決できない誤検出が発生しても、それはまったく予想外のことではありません。

その理由は、呼び出されるクラスを MTA が検出できないためです。したがって、MTA は該当する一致が妥当なものかどうかを判定できません。

このような場合、MTA はデフォルトでより多くの情報を公開します。

このような状況では、次の解決策をお勧めします。

  1. Maven 設定がすべての依存関係を取得できることを確認します。
  2. アプリケーションが完全にコンパイルできることを確認します。

7.5. アプリケーションのレビュー
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、各アプリケーションの移行戦略と作業の優先順位を決定できます。

重要

一度にレビューできるアプリケーションは 1 つだけです。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. レビューしたいアプリケーションを選択します。

  3. 次のいずれかのアクションを実行して、アプリケーションをレビューします。

    • アプリケーションの評価中に Save and Review をクリックします。詳細は、アプリケーションの評価 参照してください。

    • 行末のオプションメニュー ( kebab ) をクリックして、ドロップダウンメニューから Review を選択します。アプリケーションの Review パラメーターがメインペインに表示されます。

      アプリケーションのレビュー
  4. Proposed action をクリックし、アクションを選択します。
  5. Effort estimate をクリックし、選択した質問集によるアセスメントを実行するのに必要な作業量を設定します。
  6. Business criticality フィールドに、アプリケーションがビジネスにとってどの程度重要かを入力します。
  7. Work priority フィールドにアプリケーションの優先度を入力します。
  8. オプション: Comments フィールドに、アセスメント質問集のコメントを入力します。

  9. Submit review をクリックします。

    Review のフィールドが Application details ページに入力されるようになりました。

7.6. アセスメントレポートのレビュー
リンクのコピー

MTA のアセスメントレポートには、複数のアプリケーションの質問集から取得されたデータを集約したアセスメントが表示されます。

手順

  1. Migration ビューで、Reports をクリックします。すべてのアプリケーションの集約されたアセスメントレポートが表示されます。

    アセスメントレポート

  2. 状況に応じて、次のいずれかの操作を実行します。

    • 特定の質問集のデータに関するレポートを表示します。

      1. レポートの Current landscape ペインにあるすべての質問集のドロップダウンリストから、必要な質問集を選択します。デフォルトでは、すべての質問集が選択されます。
      2. レポートの Identified risks ペインで、表示されたリストを、アプリケーション名、リスクレベル、質問集、質問集のセクション、質問、および回答で並べ替えます。

    • 特定のアプリケーションのレポートを表示します。

      1. レポートの Identified risks ペインの Applications 列のリンクをクリックします。Application inventory ページが開きます。リンクに含まれるアプリケーションは、リストに表示されます。

      2. 必要なアプリケーションをクリックします。Assessment サイドペインが開きます。

        • アプリケーションの評価されたリスクレベルを表示するには、Details タブを開きます。
        • アセスメントの詳細を表示するには、Reviews タブを開きます。

7.7. アプリケーションのタグ付け
リンクのコピー

分析対象のアプリケーションにさまざまなタグを割り当てることができます。タグを使用してアプリケーションを分類し、アプリケーションの種類、データセンターの場所、アプリケーション内で使用されるテクノロジーなどのアプリケーション情報を即座に特定できます。タグ付けを使用して、アーキタイプをアプリケーションに関連付け、自動アセスメントを行うこともできます。アーキタイプの詳細は、アーキタイプの操作 を参照してください。

タグ付けは、分析中に 自動 で行うことができるほか、いつでも 手動 で行うことができます。

注記

すべてのタグが自動的に割り当てられるわけではありません。たとえば、分析中にアプリケーションに付けることができるタグは、アプリケーションのテクノロジーに基づくタグだけです。アプリケーションに、それがデプロイされているデータセンターの場所もタグ付けする場合は、アプリケーションを手動でタグ付けする必要があります。

7.7.1. アプリケーションタグの作成
リンクのコピー

MTA が評価または分析するアプリケーションのカスタムタグを作成できます。

手順

  1. Migration ビューで、Controls をクリックします。
  2. Tags タブをクリックします。
  3. Create tag をクリックします。
  4. 開いたダイアログの Name フィールドに、タグの一意の名前を入力します。
  5. Tag category フィールドをクリックし、タグに関連付けるカテゴリータグを選択します。
  6. Create をクリックします。

  7. オプション: 作成したタグまたはタグカテゴリーを編集します。

    • タグを編集します。

      1. Tags タブのタグカテゴリーのリストで、目的のカテゴリーのタグのリストを開きます。
      2. ドロップダウンメニューから Edit を選択し、Name フィールドでタグ名を編集します。
      3. Tag category フィールドをクリックし、タグに関連付けるカテゴリータグを選択します。
      4. Save をクリックします。

    • タグカテゴリーを編集します。

      1. Tags タブで、定義済みのタグカテゴリーを選択し、Edit をクリックします。
      2. Name フィールドでタグカテゴリーの名前を編集します。
      3. カテゴリーの Rank 値を編集します。
      4. Color フィールドをクリックして、タグカテゴリーの色を選択します。
      5. Save をクリックします。

7.7.2. アプリケーションへの手動タグ付け
リンクのコピー

アプリケーション分析の実行前でも後でも、アプリケーションに手動でタグを付けることができます。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. 必要なアプリケーションの行で、Edit ( icon edit ) をクリックします。Update application ウィンドウが開きます。
  3. Select a tag(s) ドロップダウンリストから必要なタグを選択します。
  4. Save をクリックします。

7.7.3. 自動タグ付け
リンクのコピー

アプリケーションを Application Inventory に追加すると、MTA が言語検出タスクとテクノロジー検出タスクを自動的に生成します。言語検出タスクの実行中、テクノロジー検出タスクと分析タスクは、言語検出タスクが完了するまで待機します。これらのタスクによって、アプリケーションにタグが自動的に追加されます。MTA は、アプリケーション分析に基づいて、アプリケーションに自動的にタグを追加できます。自動タグ付けは、大規模なアプリケーションのポートフォリオを扱う場合に特に役立ちます。

アプリケーション分析に基づくアプリケーションの自動タグ付けは、デフォルトで有効になっています。Analysis configuration ウィザードの Advanced セクションで Enable automated tagging ボックスをオフにすると、アプリケーション分析中に自動タグ付けを無効にできます。

注記

アプリケーションを自動的にタグ付けするには、アプリケーション分析を実行する 前 に Enable automated tagging チェックボックスが選択されていることを確認します。

7.7.4. アプリケーションタグの表示
リンクのコピー

特定のアプリケーションに付加されたタグを表示できます。

注記

自動的に付加されたタグは、アプリケーション分析を実行した 後に のみ表示できます。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. 必要なアプリケーションの名前をクリックします。サイドペインが開きます。
  3. Tags タブをクリックします。アプリケーションに付加されたタグが表示されます。

7.8. アーキタイプの操作
リンクのコピー

アーキタイプ は、共通の特性を持つアプリケーションのグループです。アーキタイプを使用して、複数のアプリケーションを一度に評価できます。

アプリケーションのアーキタイプは、基準タグとアプリケーションの分類によって定義されます。各アーキタイプは、そのアーキタイプで定義された特性に基づいて Assessment モジュール でアプリケーションを評価する方法を定義します。アプリケーションのタグがアーキタイプの基準タグと一致する場合、アプリケーションはアーキタイプに関連付けられます。

アーキタイプの作成は、一連の tags、stakeholders、および stakeholder groups によって定義されます。タグには次のタイプが含まれます。

  • 基準タグ は、アプリケーションをメンバーとして含めるためにアーキタイプで必要なタグです。

    注記

    アーキタイプ基準タグがアプリケーションに部分的にしか一致しない場合、このアプリケーションはアーキタイプのメンバーになることはできません。たとえば、アプリケーション a にタグ a しかなく、アーキタイプ a の基準タグにタグ a とタグ b が含まれている場合、アプリケーション a はアーキタイプ a のメンバーにはなりません。

  • アーキタイプタグ は、アーキタイプエンティティーに適用されるタグです。
注記

アーキタイプに関連付けられたすべてのアプリケーションが、そのアプリケーションが属するアーキタイプグループから アセスメント と レビュー を継承します。これはデフォルト設定です。個別のアセスメントとレビューを完了することで、アプリケーションの継承をオーバーライドできます。

7.8.1. アーキタイプの作成
リンクのコピー

アーキタイプを作成すると、インベントリー内のアプリケーションにアーキタイプのタグと一致する基準タグがある場合、そのアプリケーションは自動的にそのアーキタイプに関連付けられます。

手順

  1. MTA Web コンソールを開きます。
  2. 左側のメニューで、Archetypes をクリックします。
  3. Create new archetype をクリックします。

  4. 開いたフォームに、新しいアーキタイプに関する次の情報を入力します。

    • Name: 新しいアーキタイプの名前 (必須)。
    • Description: 新しいアーキタイプの説明 (任意)。
    • Criteria Tags: 評価されたアプリケーションをアーキタイプに関連付けるタグ (必須)。基準タグが更新されると、アーキタイプが関連付けられているアプリケーションを計算するプロセスが再度トリガーされます。
    • Archetype Tags: アプリケーション内でアーキタイプが評価するタグ (必須)。
    • Stakeholder(s): アプリケーションの開発と移行に関与する特定のステークホルダー (任意)。
    • Stakeholders Group(s): アプリケーションの開発と移行に関与するステークホルダーのグループ (任意)。
  5. Create をクリックします。

7.8.2. アーキタイプの評価
リンクのコピー

アーキタイプは、必須の質問集がすべて回答されたときに、評価されたとみなされます。

注記

アプリケーションが複数のアーキタイプに関連付けられている場合、関連付けられている全アーキタイプが評価されたときに、そのアプリケーションは評価されたとみなされます。

前提条件

  • MTA サーバーにログイン済みである。

手順

  1. MTA Web コンソールを開きます。
  2. Migration ビューを選択し、Archetype をクリックします。
  3. Options メニュー ( kebab ) をクリックし、ドロップダウンメニューから Assess を選択します。
  4. 利用可能な質問集のリストから、Take をクリックして、目的の質問集を選択します。
  5. Assessment メニューで、必要な質問に回答します。
  6. Save をクリックします。

7.8.3. アーキタイプのレビュー
リンクのコピー

アーキタイプは、複数の質問集が必須とマークされている場合でも、一度レビューされたときに、レビューされたとみなされます。

注記

アプリケーションが複数のアーキタイプに関連付けられている場合、関連付けられているすべてのアーキタイプがレビューされたときに、そのアプリケーションはレビュー済みとみなされます。

前提条件

  • MTA サーバーにログイン済みである。

手順

  1. MTA Web コンソールを開きます。
  2. Migration ビューを選択し、Archetype をクリックします。
  3. Options メニュー ( kebab ) をクリックし、ドロップダウンメニューから Review を選択します。
  4. 利用可能な質問集のリストから、Take をクリックして、目的のアセスメント質問集を選択します。
  5. Assessment メニューで、必要な質問に回答します。
  6. Save and Review を選択します。自動的に Review タブにリダイレクトされます。

  7. 以下の情報を入力します。

    • Proposed Action: アーキタイプの移行またはモダナイズを完了するために必要な、提案されるアクション。
    • Effort estimate: 選択したアーキタイプのモダナイズまたは移行を実行するために必要な作業のレベル。
    • Business criticality: ビジネスに対するアプリケーションの重要度。
    • Work Priority: アーキタイプの優先度。
  8. Submit review をクリックします。

7.8.4. アーキタイプの削除
リンクのコピー

アーキタイプを削除すると、関連付けられている評価とレビューも削除されます。関連付けられているすべてのアプリケーションは、Unassessed および Unreviewed 状態に移行します。

7.9. アプリケーションの分析
リンクのコピー

Migration Toolkit for Applications (MTA) ユーザーインターフェイスを使用して、アプリケーション分析を設定および実行できます。分析により、アプリケーションを移行またはモダナイズする前に、アプリケーション内のどの行を変更する必要があるかを確認できます。

7.9.1. アプリケーション分析の設定と実行
リンクのコピー

同じ分析で、複数の変換ターゲットに対して一度に複数のアプリケーションを分析できます。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. 分析するアプリケーションを選択します。
  3. アプリケーションに割り当てられた認証情報を確認します。
  4. Analyze をクリックします。

  5. リストから Analysis mode を選択します。

    • Binary
    • Source code
    • Source code and dependencies
    • Upload a local binary。このオプションは、単一のアプリケーションを分析している場合にのみ表示されます。このオプションを選択した場合は、ローカルバイナリーをアップロード するように求められます。指定の領域にファイルをドラッグするか、Upload をクリックしてアップロードするファイルを選択します。
  6. Next をクリックします。

  7. 分析のターゲットオプションを 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
  8. Next をクリックします。

  9. 次の Scope オプションのいずれかを選択して、分析を絞り込みます。

    • アプリケーションと内部の依存関係のみ。
    • アプリケーションと、既知のオープンソースライブラリーを含むすべての依存関係。
    • 手動で分析するパッケージのリスト選択。このオプションを選択した場合は、ファイル名を入力して Add をクリックします。
    • パッケージの除外。このオプションを選択した場合は、パッケージ名を入力して Add をクリックします。
  10. Next をクリックします。

  11. Advanced では、Manual モードまたは Repository モードを選択して、分析に追加のカスタムルールを割り当てることができます。

    • Manual モードでは、Add Rules をクリックします。関連するファイルをドラッグするか、ディレクトリーからファイルを選択して、Add をクリックします。

    • Repository モードでは、Git または Subversion リポジトリーからルールファイルを追加できます。

      重要

      すでに移行ターゲットを分析にアタッチしている場合、カスタムルールのアタッチはオプションです。移行ターゲットをアタッチしていない場合は、ルールをアタッチする必要があります。

  12. オプション: 次のオプションのいずれかを設定します。

    • Target
    • Source(s)
    • Excluded rules tags。これらのタグを持つルールは処理されません。必要に応じて追加または削除します。

    • Enable automated tagging。このチェックボックスを選択すると、アプリケーションにタグが自動的に付加されます。このチェックボックスはデフォルトで選択されています。

      注記

      自動的に付加されたタグは、分析の実行 後に のみ表示されます。

      自動タグ付けを有効にする代わりに、または自動タグ付けに加えて、アプリケーションにタグを手動で付加できます。

      注記

      分析エンジンは、幅広い移行ターゲットに対応した標準ルールを使用します。ただし、ターゲットが含まれていない場合、ターゲットがカスタマイズされたフレームワークである場合、またはサポートされていない言語 (Node.js、Python など) でアプリケーションが記述されている場合は、Set Target タブでターゲットの選択をスキップし、Custom Rules タブでカスタムルールファイルをアップロードすることで、カスタムルールを追加できます。手動でアップロードされたカスタムルールファイルだけが検証されます。

  13. Next をクリックします。
  14. Review で、解析パラメーターを確認します。

  15. Run をクリックします。

    分析ステータスは、MTA がコンテナーを実行するイメージをダウンロードするため、Scheduled です。イメージがダウンロードされると、ステータスが In-progress に変わります。

注記

アプリケーションのサイズとクラスターの容量とリソースに応じて、分析の実行には数分から数時間かかります。

ヒント

MTA は、Kubernetes のスケジューリング機能に依存して、クラスターの容量に基づいて作成されるアナライザーインスタンスの数を決定します。分析用に複数のアプリケーションが選択されている場合、デフォルトでは、一度にプロビジョニングできるアナライザーは 1 つだけです。クラスター容量が増えると、より多くの分析プロセスを並行して実行できます。

  1. オプション: アクティブな分析タスクのステータスを追跡するには、通知ボタンをクリックして Task Manager ドロワーを開きます。

    または、アプリケーション名の上にマウスを置くと、ポップオーバーウィンドウが表示されます。

  2. 分析完了後、その結果を確認するには、アプリケーション名をクリックしてアプリケーションドロワーを開きます。
注記

Application Inventory ページでアプリケーションインスタンスを作成すると、言語検出タスクが開始し、ターゲットフィルターオプションが自動的に事前選択されます。ただし、必要に応じて別の言語を選択することもできます。

7.9.2. 分析の詳細の確認
リンクのコピー

分析のアクティビティーログを表示できます。アクティビティーログには、分析手順などの分析の詳細が含まれています。

手順

  1. Migration ビューで、Application inventory をクリックします。
  2. アプリケーション行をクリックし、アプリケーションドロワーを開きます。
  3. Reports タブをクリックします。
  4. View analysis details クリックし、分析のアクティビティーログを表示します。

  5. オプション: 分析中に検出された問題と依存関係は、アプリケーションドロワーの Details タブをクリックし、Issues または Dependencies をクリックします。

    または、Migration ビューで Issues または Dependencies ページを開きます。

7.9.3. 一致しないルールへのアクセス
リンクのコピー

一致しないルールにアクセスするには、拡張ロギングを有効にして分析を実行する必要があります。

  1. Application analysis の下にある Advanced に移動します。
  2. Options を選択します。
  3. Enhanced advanced analysis details を確認します。

分析を実行するときに、次の手順を実行します。

  1. サイドドロワーの Reports に移動します。
  2. View analysis details をクリックし、YAML/JSON 形式のログビューを開きます。
  3. issues.yaml ファイルを選択します。

  4. 各ルールセットに unmatched セクションがあります。ここに、一致するルールが見つからないルール ID がリストされます。

    issues.yaml 内の一致しないルール ID

7.9.4. 分析レポートのダウンロード
リンクのコピー

MTA 分析レポートには、アプリケーションで使用されているテクノロジーのリスト、アプリケーションの依存関係、アプリケーションを正常に移行または最新化するために変更する必要があるコード行など、複数のセクションが含まれています。

MTA 分析レポートの内容の詳細は、レポートの確認 を参照してください。

便利なように、分析レポートをダウンロードできます。デフォルトではこのオプションは無効になっていることに注意してください。

手順

  1. Administration ビューで、General をクリックします。
  2. Allow reports to be downloaded after running an analysis. のスイッチを切り替えます。
  3. Migration ビューに移動し、Application inventory をクリックします。
  4. アプリケーション行をクリックし、アプリケーションドロワーを開きます。
  5. Reports タブをクリックします。

  6. HTML または YAML リンクをクリックします。

    • HTML リンクをクリックすると、圧縮された analysis-report-app-<application_name>.tar ファイルがダウンロードされます。このファイルを展開すると、アプリケーションと同じ名前のフォルダーが作成されます。
    • YAML リンクをクリックすると、圧縮されていない analysis-report-app-<application_name>.yaml ファイルがダウンロードされます。

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 ページを使用します。

手順

  1. Migration ビューで、Task Manager をクリックします。
  2. Options メニュー ( kebab ) をクリックします。

  3. Task details をクリックします。

    または、Status 列のタスクステータスをクリックします。

7.10.2. タスク実行順序の制御
リンクのコピー

Task Manager を使用すると、実行をスケジュールした Migration Toolkit for Applications (MTA) タスクのプリエンプション (横取り) を行うことができます。

注記

プリエンプション は、スケジュール済みのタスク (Running、Succeeded、または Failed ステータスではないもの) に対して有効にできます。ただし、横取りの対象となるのは、優先度の低いタスクだけです。優先度の高いタスクが優先度の低いタスクによってブロックされ、プリエンプション が有効な場合、ブロックされた優先度の高いタスクが実行されるように、優先度の低いタスクが再スケジュールされることがあります。したがって、アプリケーション分析など、優先度の高いタスクに対してのみ プリエンプション を有効にすると便利です。

手順

  1. Migration ビューで、Task Manager をクリックします。
  2. Options メニュー ( kebab ) をクリックします。

  3. 状況に応じて、次のいずれかの手順を実行します。

    • タスクの プリエンプション を有効にするには、Enable preemption を選択します。
    • プリエンプション が有効になっているタスクの プリエンプション を無効にするには、Disable preemption を選択します。


改訂日時: 2025-06-24

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る