Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

用户界面指南

Migration Toolkit for Applications 7.2

使用 Migration Toolkit for Applications 用户界面将您的应用程序分组到项目中进行分析。

Red Hat Customer Content Services

摘要

本指南介绍了如何在 Red Hat OpenShift 的混合云环境中使用 Migration Toolkit for Applications 用户界面来加快大规模应用程序现代化工作。

使开源包含更多
复制链接

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情，请参阅我们的首席技术官 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 及更高版本中，当您将应用程序添加到应用程序清单中时，MTA 会自动创建并执行语言和技术发现任务。语言发现标识了应用中使用的编程语言。技术发现可识别技术，如企业 Java Bean (EJB)、Spring 等。然后，每个任务会为应用程序分配适当的标签，从而减少了手动标记应用程序的时间和工作量。

MTA 使用大量默认问题作为评估应用程序的基础，或者您可以创建自己的自定义问题，使您能够估算准备容器化应用程序所需的难度、时间和其他资源。您可以使用评估结果作为与利益相关者进行的讨论基础，以确定哪些应用程序可以被容器化，哪些需要大量的准备工作，哪些不适用于容器化。

MTA 会根据一个或多个规则集来对应用程序进行分析，并找出应用程序的哪些部分需要进行修改才可以对其进行现代化。

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) 用户界面有两个视图：

  • 管理视图
  • 迁移视图

在 管理视图中，管理员可以配置实例环境，使用凭证和存储库，定义 HTTP 和 HTTPS 代理，创建自定义迁移目标、管理问题并添加自定义评估问题。

在 Migration 视图中，所有授权用户都可以审核报告，添加应用程序进行评估和分析。执行应用程序评估和分析，创建迁移 waves，查看可能影响迁移的问题，查看可以通过任务管理器进行分析和发现任务的状态。在此视图中，不同用户角色的 roles swig- swigadministrators、架构师和 migrators5-4-wagonvary 的权限。

您可以在所有 Red Hat OpenShift 云服务和 Red Hat OpenShift 自我管理的版本上安装 Migration Toolkit for Applications (MTA)用户界面。

重要

要能够创建 MTA 实例，您必须首先安装 MTA Operator。

MTA Operator 是一个结构性层，用于管理 OpenShift 中部署的资源（如数据库、前端和后端）来自动创建 MTA 实例。

3.1. 持久性卷要求
复制链接

要成功部署，MTA Operator 需要由不同组件使用的 2 个 RWO 持久性卷(PV)。如果 rwx_supported 配置选项设为 true，则 MTA Operator 需要额外的 2 RWX PV，供 Maven 和 hub 文件存储使用。下表中描述了 PV：

Expand
表 3.1. 所需的持久性卷
Name默认大小访问模式Description

hub 数据库

10Gi

RWO

hub 数据库

hub bucket

100Gi

RWX

Hub 文件存储；如果 rwx_supported 配置选项被设置为 true，则需要此项

keycloak postgresql

1Gi

RWO

Keycloak 后端数据库

缓存

100Gi

RWX

Maven m2 缓存；如果 rwx_supported 配置选项设为 true，则需要此项

您可以在 Red Hat OpenShift 版本 4.18, 4.17 上安装 Migration Toolkit for Applications (MTA)和用户界面。

先决条件

  • 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. Tackle CR 设置
    Namedefault描述

    cache_data_volume_size

    100Gi

    为缓存卷请求的大小；当 rwx_supported=false 时会被忽略

    cache_storage_class

    默认存储类

    用于缓存卷的存储类 ; 当 rwx_supported=false 时会被忽略

    feature_auth_required

    true

    用于指明是否需要 keycloak 授权（单用户/"noauth"）的标记

    feature_isolate_namespace

    true

    指定是否启用使用网络策略进行命名空间隔离的标志

    hub_database_volume_size

    10Gi

    为 Hub 数据库卷请求的大小

    hub_bucket_volume_size

    100Gi

    为 Hub 存储桶卷请求的大小

    hub_bucket_storage_class

    默认存储类

    用于存储桶卷的存储类

    keycloak_database_data_volume_size

    1Gi

    为 Keycloak 数据库卷请求的大小

    keycloak_sso_req_passwd_update

    true

    如果标志设为 true，则需要用户在第一次登录后更新其密码。

    pathfinder_database_data_volume_size

    1Gi

    为 Pathfinder 数据库卷请求的大小

    maven_data_volume_size

    100Gi

    为 Maven m2 缓存卷请求的大小；在 MTA 6.0.1 中弃用

    rwx_storage_class

    不适用

    为 Tackle RWX 卷请求的存储类；在 MTA 6.0.1 中弃用

    rwx_supported

    true

    指明集群存储是否支持 RWX 模式的标记

    rwo_storage_class

    不适用

    为 Tackle RW0 卷请求的存储类

    rhsso_external_access

    False

    指明是否创建了专用路由来访问 MTA 受管 RHSSO 实例的标志

    analyzer_container_limits_cpu

    1

    允许 pod 使用的最大 CPU 数量

    analyzer_container_limits_memory

    1Gi

    pod 允许使用的最大内存量。如果 pod 显示 OOMKilled 错误，您可以提高这个限制。

    analyzer_container_requests_cpu

    1

    pod 需要运行的最小 CPU 数量

    analyzer_container_requests_memory

    512Mi

    pod 运行所需的最小内存量

    ui_container_limits_cpu

    500m

    UI pod 资源允许使用的最大 CPU 数量

    ui_container_limits_memory

    800Mi

    UI pod 资源允许使用的最大内存量。如果 pod 显示 OOMKilled 错误，您可以提高这个限制。

    ui_container_requests_cpu

    100m

    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. 在管理视图中，点 Workloads → Pods 来验证 MTA Pod 是否正在运行。
  12. 使用 OpenShift 中的 mta-ui 应用公开的路由，从浏览器访问用户界面。

  13. 使用以下凭证登录：

    • 用户名 ：admin
    • 密码 ： Passw0rd!
  14. 出现提示时，创建新密码。

3.2.1. 驱除阈值
复制链接

每个节点分配有一定数量的内存。一些内存是为系统服务保留的。其余内存用于运行 pod。如果 pod 使用超过其分配的内存量，则会触发内存不足事件，并且节点会终止并带有 OOMKilled 错误。

要防止内存不足事件和保护节点，请使用 -eviction-hard 设置。此设置指定节点驱除 pod 的内存可用性阈值。设置的值可以是 absolute 或一个百分比。

节点内存分配设置示例

  • 节点容量： 32Gi
  • --system-reserved 设置： 3Gi
  • --eviction-hard 设置 ：100Mi

此节点上运行 pod 的内存量为 28.9 GB。这个数量是通过从节点整体容量中减去 system-reserved 和 eviction-hard 值来计算的。如果内存用量超过这个数量，节点将开始驱除 pod。

3.3. 红帽单点登录
复制链接

MTA 使用 Red Hat Single Sign-On (RHSSO) 实例进行用户身份验证和授权。

MTA 操作器管理 RHSSO 实例，并使用必要的角色和权限配置专用 域。

MTA 管理的 RHSSO 实例允许您执行高级 RHSSO 配置，如 为用户联邦添加 供应商或 集成身份提供程序。要访问 RHSSO 管理控制台，请将 < route> 替换为 MTA web 控制台地址，在浏览器中打开 URL https://<_route_>/auth/admin。

Example:

RHSSO 的 admin 凭证存储在安装 MTA 的命名空间中的名为 credential-mta-rhsso 的 secret 文件中。

要检索您的 admin 凭证，请运行以下命令： 

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. roles, Personas, Users, and Permissions
复制链接

MTA 使用三个角色，各自对应于用户角色：

Expand
表 3.3. 角色和用户角色
角色persona

tackle-admin

Administrator

tackle-architect

架构

tackle-migrator

migrator

角色已在 RHSSO 实例中定义。您不需要创建它们。

如果您是 MTA 管理员，您可以在 RHSSO 中创建用户，并为每个用户分配一个或多个角色，每个用户角色一个角色。

虽然用户可以有多个角色，但每个角色都对应于特定的用户角色：

  • 管理员：管理员具有架构师和 migrators 的全部权限，以及能够创建其他用户可消耗的应用程序范围配置参数，但不能更改或查看。示例：Git 凭证、Maven settings.xml 文件。
  • 架构师：迁移项目的技术领导，能够运行评估，并可创建和修改相关应用程序和信息。架构师无法修改或删除敏感信息，但可以使用这些信息。示例：将现有凭证与特定应用程序的存储库关联。
  • migrator ：用户可以分析应用程序，但不能创建、修改或删除应用程序。

如 用户界面视图 中所述，MTA 有两个视图，即 管理和迁移。

只有管理员才能访问 管理 视图。架构师和 migrator 无法访问 管理 视图，他们甚至无法看到它。

管理员可以执行 Migration 视图 支持的所有操作。架构师和 migrator 可以看到 Migration 视图的所有元素，但它们在 Migration 视图中执行操作的能力取决于对其角色授予的权限。

下表中总结了管理员、架构师和 migrator 访问 MTA 用户界面的管理和迁移视图的能力：

Expand
表 3.4. 角色与对 MTA 视图的访问
菜单架构migratorAdmin

管理

否

否

是

Migration

是

是

是

3.3.1.2. 角色和权限
复制链接

下表包含 MTA 查找受管 RHSSO 实例的角色和权限（范围）：

Expand

tackle-admin

资源名称

Verbs

 

附加组件

delete
get
post
put

 

adoptionplans

post
get
post
put

 

应用程序

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

 

设置

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

 

缓存

delete
get

 

files

delete
get
post
put

 

rulebundles

delete
get
post
put

Expand

tackle-architect

资源名称

Verbs

 

附加组件

delete
get
post
put

 

applications.bucket

delete
get
post
put

 

adoptionplans

post

 

应用程序

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

 

设置

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

 

缓存

get

 

files

delete
get
post
put

 

rulebundles

delete
get
post
put

Expand

tackle-migrator

资源名称

Verbs

 

附加组件

get

 

adoptionplans

post

 

应用程序

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

 

设置

get

 

stakeholdergroups

get

 

stakeholders

get

 

tags

get

 

tagtypes

get

 

tasks

delete
get
post
put

 

tasks.bucket

delete
get
post
put

 

tackers

get

 

tickets

get

 

缓存

get

 

files

get

 

rulebundles

get

Red Hat OpenShift Local 提供了一种快速轻松地在桌面或笔记本电脑上设置本地 OpenShift 集群的方法。此本地集群允许您在将应用程序和配置参数发送到生产环境前测试它们。

3.4.1. 操作系统要求
复制链接

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 主页版本。

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. Red Hat OpenShift Local 对 Linux 的要求
复制链接

在 Linux 中，只有最新的两个 Red Hat Enterprise Linux 8 和 9 个次发行版本以及最新的两个稳定 Fedora 版本才支持 Red Hat OpenShift Local。

使用 Red Hat Enterprise Linux 时，运行 Red Hat OpenShift Local 的机器必须使用红帽客户门户网站注册。

Ubuntu 18.04 LTS 或更高版本不支持 Debian 10 或更高版本，可能需要手动设置主机。

3.4.1.3.1. Linux 所需的软件包
复制链接

Red Hat OpenShift Local 需要 libvirt 和 NetworkManager 软件包在 Linux 上运行：

  • 在 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

要安装 Red Hat OpenShift Local：

  1. 为您的平台下载最新版本的 Red Hat OpenShift Local。

    1. 下载 OpenShift 本地。
    2. 下载 pull secret。

  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 presets 代表受管容器运行时，以及实例运行它所需的系统资源的低限。

注意
  • 在 Linux 或 macOS 中，请确保您的用户帐户有权使用 sudo 命令。
  • 在 Microsoft Windows 上，请确保您的用户帐户可以提升到管理员特权。

crc start 命令启动 Red Hat OpenShift Local 实例并配置的容器运行时。它提供以下标记：

Expand
标记类型描述默认值

-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'

default '/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

 

开始帮助

 

-m, -memory

int

分配给实例的内存失败

10752

-n, -nameserver

string

用于实例的名称服务器的 IPv4 地址

 

-o, -output

string

JSON 中的输出格式

 

-p, -pull-secret-file

string

镜像 pull secret 的文件路径（从 https://console.redhat.com/openshift/create/local下载）

 

它还提供以下全局标记：

Expand
标记类型描述默认值

-log-level

string

例如，日志级别：

* debug

* info

* 警告

* 错误

info

默认配置创建一个具有 4 个虚拟 CPU、磁盘大小为 31 GB 和 10 GB RAM 的虚拟机(VM)。但是，此默认配置不足以运行 MTA。

要将虚拟 CPU 的数量增加到 6，disk-size 到 200 GB，内存增加到 20 GB，请运行 crc 配置，如下所示： 

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 实例时，才会应用对 inputted 配置属性的更改。

如果您已经有一个正在运行的 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

下表显示了推荐的 Red Hat OpenShift Local 测试的最低配置：

Expand
内存(Gi)CPU磁盘 sze (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）设置为 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 视图中配置以下内容：

  • General
  • 凭证
  • 软件仓库
  • 代理(HTTP 和 HTTPS 代理设置)
  • 自定义迁移目标
  • 问题管理
  • 评估问卷

4.1. General
复制链接

您可以启用或禁用以下选项：

  • 在运行分析后允许下载报告

4.2. 配置凭证
复制链接

您可以在 Administration 视图中配置以下类型的凭证：

  • 源控制
  • Maven 设置文件
  • Proxy
  • 基本身份验证(JIRA)
  • bearer 令牌(JIRA)

4.2.1. 配置源控制凭证
复制链接

您可以在 Migration Toolkit for Applications (MTA) 用户界面的 Credentials 视图中配置源控制凭证。

流程

  1. 在 Administration 视图中，点 Credentials。
  2. 点 Create new。

  3. 输入以下信息：

    • Name
    • 描述（可选）
  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. 输入以下信息：

    • Name
    • 描述（可选）
  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. 输入以下信息：

    • Name
    • 描述（可选）
  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 存储库 开关切换到右侧。

4.3.2. 配置子版本软件仓库
复制链接

您可以在 Migration Toolkit for Applications (MTA) 用户界面的 Repositories 视图中配置 subversion 软件仓库。

流程

  1. 在 Administration 视图中，点 Repositories，然后点 Subversion。
  2. 将 Consume insecure Subversion 软件仓库 切换到右边。

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 存储库 切换到右边。
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 代理或 HTTPS 代理以启用代理连接。

  3. 输入以下信息：

    • 代理主机
    • 代理端口
  4. 可选：切换 HTTP 代理凭证 或 HTTPS 代理凭证来启用身份验证。
  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 ：

    • 如果您选择了 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. seeding 一个实例
复制链接

如果您是项目架构师，可以在迁移前在 Controls 窗口中配置实例的关键参数。可以根据需要添加和删除参数。以下参数定义了在一个机构中会受迁移影响或参阅迁移的应用程序、个人、团队、以及在机构中的不同部门：

  • 利益相关者
  • stakeholder 组
  • 任务功能
  • 业务服务
  • 标签类别
  • Tags

您可以以任何顺序创建和配置实例。但是，以下建议的顺序是创建利益相关者和标签最有效的。

利益相关者：

  1. 创建 Stakeholder 组
  2. 创建作业功能
  3. 创建 Stakeholders

标签：

  1. 创建标签类别
  2. 创建标签

利益相关者，并通过以下方法定义：

  • 电子邮件
  • Name
  • 作业功能
  • stakeholder 组

4.6.1. 创建新的拥有者组
复制链接

没有定义默认的拥有者组。您可以按照以下步骤创建新的拥有者组。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Stakeholder groups。
  3. 点 Create new。

  4. 输入以下信息：

    • Name
    • 描述
    • 成员
  5. 点 Create。

4.6.2. 创建新作业功能
复制链接

Migration Toolkit for Applications (MTA) 使用 job function 属性来分类利益相关者，并提供可扩展的默认值列表。

您可以按照以下步骤创建新作业功能，使其不在默认列表中。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Job functions。
  3. 点 Create new。
  4. 在 Name 文本框中输入作业功能标题。
  5. 点 Create。

4.6.3. 创建新的拥有者
复制链接

您可以按照以下步骤创建新的迁移项目拥有者。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Stakeholders。
  3. 点 Create new。

  4. 输入以下信息：

    • 电子邮件
    • Name
    • 作业功能 - 可以创建自定义功能
    • stakeholder 组
  5. 点 Create。

4.6.4. 创建新业务服务
复制链接

Migration Toolkit for Applications (MTA )使用业务服务属性来指定使用应用程序以及迁移影响的部门。

您可以按照以下过程创建新业务服务。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Business services。
  3. 点 Create new。

  4. 输入以下信息：

    • Name
    • 描述
    • 所有者
  5. 点 Create。

4.6.5. 创建新标签类别
复制链接

Migration Toolkit for Applications (MTA) 使用多个类别中的标签，并提供默认值列表。您可以按照以下步骤创建新标签类别。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Tags。
  3. 点 Create tag category。

  4. 输入以下信息：

    • Name
    • Rank - 标签出现在应用程序中的顺序
    • Color
  5. 点 Create。
4.6.5.1. 创建新标签
复制链接

您可以按照以下步骤创建新标签，该标签不在默认列表中。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 点 Tags。
  3. 点 Create tag。

  4. 输入以下信息：

    • Name
    • 标签类别
  5. 点 Create。

第 5 章 创建并配置 JIRA 连接
复制链接

您可以通过从 MTA 用户界面中为每个迁移创建一个 Jira 问题来跟踪应用程序迁移。要能够创建 JIRA 问题，首先需要执行以下操作：

  1. 创建 MTA 凭证，以对您在下一步中创建的 Jira 实例的 API 进行身份验证。
  2. 在 MTA 中创建 JIRA 实例并建立连接。

5.1. 配置 JIRA 凭证
复制链接

要在 MTA 中定义 Jira 实例并建立与该实例的连接，您必须首先创建一个 MTA 凭证来向 Jira 实例的 API 进行身份验证。

可用的凭证类型有两种：

  • JIRA Cloud 和私有 JIRA 服务器或数据中心的 基本身份验证 -
  • 私有 Jira 服务器或数据中心的 bearer Token -

要创建 MTA 凭证，请按照以下步骤操作。

流程

  1. 在 Administration 视图中，点 Credentials。

    Credentials 页面将打开。

  2. 点 Create new。

  3. 输入以下信息：

    • Name
    • 描述 （可选）

  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 配置页面 将打开。

  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 配置 页面中。

    建立连接并授权后，连接 列中的状态将变为 Connected。

    如果 Connection 状态变为 Not connected，点状态查看错误的原因。

Jira 配置 表根据 名称和 URL 过滤，并按 实例名称 和 URL 进行排序。

注意

在 JIRA 中存在问题时 ，用来为迁移创建问题的 Jira 连接不能被删除，即使在迁移 wave 被删除后也是如此。

第 6 章 使用 MTA 管理应用程序
复制链接

您可以使用 Migration Toolkit for Applications (MTA)用户界面执行以下任务：

  • 添加应用程序
  • 分配应用程序凭证
  • 导入应用程序列表
  • 下载用于导入应用程序的 CSV 模板
  • 创建应用程序迁移 waves
  • 为迁移 waves 创建 JIRA 问题

MTA 用户界面应用程序有以下属性：

  • 名称（无文本）
  • 描述（可选，自由文本）
  • 业务服务（可选，从列表中选择）
  • 标签（可选，从列表中选择）
  • Owner （可选，从列表中选择）
  • 供稿者（可选，从列表中选择）
  • 源代码（用户输入的路径）
  • 二进制（用户输入的路径）

6.1. 添加新应用程序
复制链接

您可以将新应用添加到应用程序清单中，以便进行后续评估和分析。

提示

在创建应用程序之前，设置业务服务，检查标签和标签类别，并根据需要创建添加。

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. 在 Migration 视图中，点 Application Inventory。
  2. 点 Create new。

  3. 在 Basic information 下，输入以下字段：

    • 名称 ：新应用的唯一名称。
    • 描述 ：应用程序的简短描述（可选）。
    • 业务服务 ：应用的目的（可选）。
    • 手动标签 ：用于表示应用程序的软件标签（可选，一个或多个）。
    • Owner: 下拉列表中注册的软件所有者（可选）。
    • 供稿人 ：下拉列表的 Contributors （可选，一个或多个）。
    • 注释 ：与应用程序相关的注释（可选）。

  4. 点 Source Code 并输入以下字段：

    • 存储库类型 ：Git 或 Subversion。

    • 源存储库 ：保存软件代码的存储库的 URL。

      • 对于 Subversion：这必须是存储库根目录的 URL 或一个完全限定的 URL，（可选）包括分支和嵌套目录。当完全限定时，Branch 和 Root 路径 必须为空。

    • 分支 ：存储库中的应用代码分支（可选）。

      • 对于 Git：这可能是任何引用； 提交哈希、分支 或标签。
      • 对于 Subversion：这可能是分支或标签的完全限定路径，如 branch /stable 或 tags/stable。当 Source 存储库 URL 包含分支时，这必须为空。

    • 根路径 ：目标应用程序存储库中的根路径（可选）。

      • 对于 Subversion：当 Source Repository URL 包含根路径时，这必须为空。

    注意：如果您在 Branch 或 Root 路径字段中输入任何值，则 Source repository 字段将变为必需。

  5. 可选：点击 Binary 并输入以下字段：

    • 组 ：应用程序工件的 Maven 组。
    • 工件 ：应用程序的 Maven 工件。
    • 版本 ：应用程序的软件版本。
    • 打包 ：应用程序工件的打包，如 JAR、WAR 或 EAR。

    注意： 如果您在任何 Binary 部分字段中输入任何值，则所有字段都会自动成为强制的。

  6. 点 Create。新应用程序会出现在定义的应用程序列表中。

自动化任务

将新应用程序添加到应用程序 清单后，您可以将光标设置为将鼠标悬停在应用程序名称上，以查看通过添加应用程序生成的自动化任务。语言发现任务标识应用中的编程语言。技术发现任务标识了应用中的特定技术。这些任务自动为应用添加适当的标签，从而减少了手动为应用分配标签所涉及的工作量。这些任务完成后，添加到应用的标签数将显示在 Tags 列下。查看标签：

  1. 点应用程序的行条目。此时会打开侧窗格。
  2. 单击 标签选项卡。此时会显示附加到应用程序的标签。

您可以根据需要手动添加其他标签。当 MTA 分析应用程序时，它可以自动向应用程序添加其他标签。

6.2. 编辑应用程序
复制链接

您可以编辑应用程序清单中的现有应用程序，并重新运行此应用程序的评估或分析。

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. 在 Migration 视图中，点 Application Inventory。
  2. 选择 Migration working 模式。
  3. 单击左侧菜单栏中的 Application Inventory。可用应用程序列表会出现在主窗格中。
  4. 点击 Edit ( icon edit )打开应用程序设置。
  5. 检查应用设置。有关应用程序设置列表，请参阅 添加应用程序。
  6. 如果您更改了任何应用程序设置，请点击 Save。
注意

编辑应用程序后，MTA 会重新显示语言发现和技术发现任务。

6.3. 为应用程序分配凭证
复制链接

您可以为一个或多个应用程序分配凭证。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 点 Analyze 右侧的 Options 菜单( kebab )并选择 Manage credentials。
  3. 从 Source credentials 列表中选择一个凭证，并从 Maven settings 列表中选择一个凭证。
  4. 点击 Save。

6.4. 导入应用程序列表
复制链接

您可以将包含应用程序及其属性列表的 .csv 文件导入到 Migration Toolkit for Applications (MTA)用户界面。

注意

导入应用程序列表不会覆盖任何现有的应用程序。

流程

  1. 检查导入文件，以确保它包含所有必需的信息（以所需格式表示）。
  2. 在 Migration 视图中，点 Application Inventory。
  3. 点 Options 菜单( kebab )。
  4. 点 Import。
  5. 选择所需的文件，然后单击 打开。
  6. 可选： 选择 启用自动创建缺少的实体。默认选择这个选项。
  7. 验证导入是否已完成，并检查接受或拒绝的行数。

  8. 点复选框左侧的箭头来查看导入的应用程序。

    重要

    可接受的行可能与 Application inventory 列表中的应用程序数量不匹配，因为某些行是依赖项。要验证，请检查 CSV 文件的 Record Type 列，以了解定义为 1 的应用程序和依赖项定义为 2。

6.5. 下载 CSV 模板
复制链接

您可以使用 Migration Toolkit for Applications (MTA)用户界面下载用于导入应用程序列表的 CSV 模板。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 点 Review 右侧的 Options 菜单( kebab )。
  3. 点 Manage import 以打开 Application import 页面。
  4. 点击 Import 右侧的 Options 菜单( kebab )。
  5. 点 Download CSV template。

6.6. 创建迁移 wave
复制链接

迁移 wave 是一个按给定计划迁移的组应用程序。您可以通过将 wave 的应用程序列表导出到 JIRA 问题管理系统来跟踪每个迁移。这会自动为每个迁移 wave 的应用程序创建一个单独的 JIRA 问题。

流程

  1. 在 Migration 视图中，点 Migration waves。
  2. 点 Create new。New migration wave 窗口将打开。

  3. 输入以下信息：

    • name （可选）。如果没有指定名称，您可以使用开始和结束日期来标识迁移。
    • 潜在的开始日期.此日期必须早于当前日期。
    • 潜在的结束日期.此日期必须早于开始日期。
    • 利益相关者 （可选）
    • stakeholder 组 （可选）
  4. 点 Create。新迁移 wave 会出现在现有迁移 waves 列表中。

  5. 要将应用程序分配到迁移 wave，请点击迁移 wave 右侧的 Options 菜单( kebab )并选择 Manage application。

    此时会打开 Manage applications 窗口，其中显示没有分配给任何其他迁移 wave 的应用列表。

  6. 选择您要分配给迁移的应用程序的复选框。

  7. 点击 Save。

    注意

    与迁移有关的每个应用程序的拥有者和贡献者会自动添加到迁移 wave 的利益相关者列表中。

  8. 可选： 要更新迁移 wave，请从迁移 wave 的 Options 菜单中选择 Update ( kebab )。此时会打开 Update migration wave 窗口。

6.7. 为迁移创建 JIRA 问题
复制链接

您可以使用迁移 wave 为分配给迁移 wave 的每个应用程序自动创建 JIRA 问题。为与迁移 wave 关联的每个应用程序创建一个单独的 Jira 问题。每个问题的以下字段会自动填写：

  • title: Migrate <application name>
  • reporter ：令牌所有者的用户名。
  • 描述 ： Konveyor创建
注意

如果应用程序链接到 JIRA ticket 或与迁移 wave 关联，则无法删除应用程序。要从 JIRA ticket 中取消链接应用程序，请点击应用程序的详情视图中的 Jira 图标中的 Unlink。

先决条件

流程

  1. 在 Migration 视图中，点 Migration waves。
  2. 点击您要为其创建 Jira 问题迁移右侧的 Options 菜单 kebab ，然后选择 Export to Issue Manager。此时会打开 Export to Issue Manager 窗口。
  3. 选择 Jira Cloud 或 Jira Server/Datacenter 实例类型。
  4. 从列表中选择 instance、project 和 issue 类型。
  5. 单击 Export。迁移 waves 页中的 迁移状态会更改为 Created 的问题。
  6. 可选： 要查看迁移 wave 的每个应用程序的状态，请点 Status 列。
  7. 可选： 要查看任何特定应用程序是否与迁移关联，请在 Application inventory 页面中打开应用程序的 Details 选项卡。

第 7 章 使用 MTA 评估和分析应用程序
复制链接

您可以使用 Migration Toolkit for Applications (MTA)用户界面来评估和分析应用程序：

  • 添加或编辑应用程序清单 时 ，MTA 会自动生成编程语言和技术发现任务。这些任务对应用程序应用适当的标签，从而减少了手动标记应用程序的时间。
  • 在评估应用程序时，MTA 会估算准备应用程序进行容器化的风险和成本，包括时间、人员和其他因素。您可以使用评估结果来讨论利益相关者之间的讨论，以确定应用程序是否适合容器化。
  • 在分析应用程序时，MTA 使用规则来决定应用程序中的哪些特定行必须进行修改，然后才能迁移或现代化应用程序。

7.1. 评估模块功能
复制链接

Migration Toolkit for Applications (MTA) 评估 模块提供以下功能来评估和分析应用程序：

评估 hub
评估 中心与应用程序 清单集成。
增强的评估问卷功能

在 MTA 7.0 中，您可以导入和导出评估问题。您还可以使用 YAML 语法通过可下载模板设计自定义问题，其中包括以下功能：

  • 条件问题：如果此应用程序或 archetype 上存在特定标签，您可以根据应用程序或架构类型包含或排除问题。
  • 基于答案的应用程序自动标记：如果提供了某个答案，您可以定义要应用到应用程序或架构类型的标签。
  • 应用程序或架构类型中的标签自动回答。

如需更多信息，请参阅自定义 评估问卷。

注意

您可以自定义并保存默认问题。如需更多信息，请参阅 默认评估问卷。

多个评估问题
评估 模块支持多个问题，与一个或多个应用程序相关。
archetypes

您可以将具有类似特征的应用程序分组到 archetypes 中。这可让您一次评估多个应用程序。每个 archetype 都有共享的税务标签、利益相关者和利益相关者组。所有应用程序都会继承其分配的 archetypes 中的评估和审核。

如需更多信息，请参阅使用 archetypes。

7.2. MTA 评估问题
复制链接

Migration Toolkit for Applications (MTA)使用评估问题( default 或 custom )来评估应用程序容器化的风险。

评估报告提供有关与迁移相关的应用程序和风险的信息。该报告还通过提交评估的应用程序的优先级别、业务关键性和依赖项生成采用计划。

7.2.1. 默认评估问题
复制链接

传统的 Pathfinder 是应用程序(MTA)问题的默认 Migration Toolkit。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 语法支持根据应用程序上的现有标签或 archetype 包括或排除问题，例如：

  • 如果应用程序或 archetype 具有 Language/Java 标签，则 应用程序中使用的主 JAVA 框架是什么？ 问题包括在问题中： 

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

  • 如果应用程序或 archetype 具有 Deployment/Serverless 和 Architecture/Monolith 标签 ，您当前使用任何形式的容器编配？ 问题不包括在问题中： 

    ...
  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
基于评估的应用程序或架构类型上的标签进行自动化答案

根据应用程序或 archetype 的现有标签选择自动回答。例如，如果应用程序或 archetype 具有 Runtime/Quarkus 标签，则会自动选择 Quarkus 回答，如果应用程序或 archetype 具有 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
根据回答自动标记应用程序

在评估过程中，如果选择了此答案，标签会根据答案自动应用到应用程序或架构类型。请注意，标签是传输的。因此，如果评估被丢弃，则会移除标签。每个标签由以下元素定义：

  • 类别 ：目标标签(字符串)的类别。
  • 标签 ：目标标签定义为 (字符串)。

例如，如果所选的答案是 Quarkus，则 Runtime/Quarkus 标签将应用到评估的应用程序或 archetype。如果所选答案是 Spring Boot，则 Runtime/Spring Boot 标签将应用到评估的应用程序或 archetype： 

...
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 模板来构建自定义问题。您可以点击 评估问题 页面中的 Download YAML 模板 下载此模板。

例 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. 自定义问题字段
复制链接

每个标记为 必要的 自定义问题字段都是强制的，必须完成。否则，YAML 语法不会在上传时进行验证。字段的每个小节在 YAML 中定义一个新的结构或对象，例如： 

...
name: Testing
thresholds:
    red: 30
    yellow: 45
    unknown: 5
...
Copy to Clipboard Toggle word wrap
Expand
表 7.1. 自定义问题字段
questionnaire 字段描述

Name （必需，字符串）

问题的名称。此字段对于整个 MTA 实例必须是唯一的。

description （可选，字符串）

问题的简短描述。

阈值 （必需）

每个应用程序或架构类别的阈值的定义，它们被视为受该风险级别影响。阈值可以是以下：

  • Red Hat （必需，未签名整数）：数字百分比（例如，30 代表 30% ），在风险级别被认为是 红色的 红色的红色回答。
  • 黄色 （必需，未签名整数）：数字百分比（例如，30 代表 30% ）的黄色回答，直到风险级别被视为黄色。
  • Unknown （必需，未签名整数）：数字百分比（例如，30 代表 30% ），问题问题可以有未知的答案，直到风险级别被视为未知为止。

更高的风险级别始终具有优先权。例如，如果 黄色 阈值设置为 30%，red 设为 5%，并且应用程序或 archetype 的答案被设置为 35% 黄色，6% 红色，应用程序或 archetype 的风险级别为红色。

riskMessages （必需）

要显示在报告中每个风险类别的消息。risk_messages 映射由以下字段定义：

  • Red Hat （必需，字符串）：报告中带有红色风险级别的消息。
  • yellow （必需，字符串）：报告中要显示为黄色风险级别的消息。
  • Gen （必需，字符串）：报告中要显示为绿色风险级别的消息。
  • unknown （必需，字符串）：报告中要显示的消息，显示未知风险级别。

部分 （必需）

问题naire 必须包括的部分列表。

  • name （必需，字符串）：显示该部分的名称。
  • order （必需，整数）：部分中问题的顺序。
  • 注释 （可选，字符串）：该部分的描述。

  • 问题 （必需）：属于该部分的问题列表。

    • order （必需，整数）：部分中问题的顺序。
    • text （必需，字符串）：要询问的问题。
    • 解释 （可选，字符串）：问题的额外说明。

    • includeFor （可选）：如果目标应用程序或 archetype 中包含任何标签，则必须显示问题的列表。

      • category （必需，字符串）：目标标签的类别。
      • tag （必需，字符串）：目标标签。

    • excludeFor （可选）：如果目标应用程序或 archetype 中包含任何标签，则必须跳过定义是否需要跳过问题的列表。

      • category （必需，字符串）：目标标签的类别。
      • tag （必需，字符串）：目标标签。

    • answer （必需）：给定问题的答案列表。

      • order （必需，整数）：部分中问题的顺序。
      • text （必需，字符串）：问题答案。
      • 风险 （必需）：当前答案的简化风险级别（红色、黄色、绿色或未知）。
      • rationale （可选，字符串）：对被视为风险的回答的合理性。
      • 缓解方案 （可选，字符串）：回答所暗示的风险的潜在的缓解策略的解释。

      • applyTags （可选）：如果选择了此答案，则会自动应用到评估的应用程序或架构类型的标签列表。

        • category （必需，字符串）：目标标签的类别。
        • tag （必需，字符串）：目标标签。

      • autoAnswerFor （可选）：当评估应用程序或存档类型时，会自动选择此答案的标签列表。

        • category （必需，字符串）：目标标签的类别。
        • tag （必需，字符串）：目标标签。

7.3. 管理评估问题
复制链接

通过使用 MTA 用户界面，您可以在评估问卷时执行以下操作：

  • 显示问卷。您还可以减少回答选择及其关联的风险权重。
  • 将问卷导出到您系统上所需的位置。

  • 从您的系统导入问题。

    警告

    导入的问卷的名称必须是唯一的。如果名称（以 YAML 语法定义）(name:<naire>)被重复，则导入将失败，并显示以下错误消息： UNIQUE constraint failed: questionsnaire.Name。

  • 删除评估问卷。

    警告

    当您删除问题时，所有 archetypes 中使用它的所有应用程序的回答也会被删除。

    重要

    您不能删除 Legacy Pathfinder 默认问题。

流程

  • 根据您的场景，执行以下操作之一：

    • 显示评估问卷：

      1. 在 管理视图中，选择 评估问题。
      2. 点 Options 菜单( kebab )。
      3. 为您要显示的问卷选择 View。
      4. 可选：点击问题左侧的箭头来显示回答选择及其风险权重。

    • 导出评估问题：

      1. 在 管理视图中，选择 评估问题。
      2. 选择所需的问题。
      3. 点 Options 菜单( kebab )。
      4. 选择 Export。
      5. 选择下载的位置。
      6. 点击 Save。

    • 导入评估问题：

      1. 在 管理视图中，选择 评估问题。
      2. 单击 Import questionnaire。
      3. 点 Upload。
      4. 导航到您的问题所在位置。
      5. 点 Open。
      6. 单击 Import 来导入所需的问题。

    • 删除评估问题：

      1. 在 管理视图中，选择 评估问题。
      2. 选择您要删除的问题。
      3. 点 Options 菜单( kebab )。
      4. 选择 Delete。
      5. 在问题 的名称 中输入 来确认删除。

7.4. 评估应用程序
复制链接

您可以通过执行应用程序评估来估算准备应用程序进行容器化的风险和成本。您可以使用评估模块评估应用程序并显示当前保存的评估。

Migration Toolkit for Applications (MTA)根据与应用程序相关的一组问题（如依赖项）评估应用程序。

要评估应用程序，您可以使用默认的 Legacy Pathfinder MTA issuenaire 或导入 您的自定义 问题。

重要

您可以一次只评估一个应用程序。

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. 在 MTA 用户界面中，选择 Migration 视图。
  2. 单击左侧菜单栏中的 Application inventory。可用应用程序的列表会出现在主窗格中。
  3. 选择您要评估的应用程序。
  4. 点击行右末尾的 Options 菜单( kebab )，并从下拉菜单中选择 Assess。
  5. 在可用问卷列表中点击 Take for the desired questionnaire。

  6. 从列表中选择 Stakeholders 和 Stakeholder groups 来跟踪为未来参考提供评估的人员。

    注意

    您还可以在 Migration 视图的 Controls 窗格中添加 Stakeholder Groups 或 Stakeholders。如需更多信息，请参阅查看实例。

  7. 点击 Next。
  8. 回答 每个应用程序评估 问题，然后单击下一步。
  9. 点 Save 查看评估，然后执行 检查应用程序 中的步骤。
注意

如果您在无法完全可解析的应用程序中看到假的正状态，则这不是完全意外的。

原因在于 MTA 无法发现该类是被调用的。因此，MTA 无法确定它是有效的匹配项。

当发生这种情况时，MTA 默认为公开比较小的信息。

在这种情况下，建议使用以下解决方案：

  1. 确保 maven 设置可以获取所有依赖项。
  2. 确保应用程序可以完全编译。

7.5. 查看应用程序
复制链接

您可以使用 Migration Toolkit for Applications (MTA )用户界面来确定每个应用程序的迁移策略和工作优先级。

重要

您可以一次只查看一个应用程序。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 选择您要查看的应用程序。

  3. 通过执行以下操作之一查看应用程序：

    • 在评估应用程序时点 Save and Review。如需更多信息，请参阅 评估应用程序。

    • 点击行右末尾的 Options 菜单( kebab )，然后从下拉菜单中选择 Review。应用程序 Review 参数会出现在主窗格中。

      应用程序审核
      View larger image
      应用程序审核
  4. 点 Proposed action 并选择操作。
  5. 点 Effort estimate 并设置执行评估所需的工作量级别。
  6. 在 Business criticality 字段中，输入应用程序对业务的关键程度。
  7. 在 Work priority 字段中，输入应用程序的优先级。
  8. 可选：在注释字段中输入评估问卷 注释。

  9. 点 Submit review。

    Review 中的字段现在在 Application details 页面中填充。

7.6. 查看评估报告
复制链接

MTA 评估报告显示从多个问卷获取的数据聚合评估，用于多个应用程序。

流程

  1. 在 Migration 视图中，点 Reports。显示所有应用程序的聚合评估报告。

    评估报告
    View larger image
    评估报告

  2. 根据您的场景，执行以下操作之一：

    • 显示特定问题中数据的报告：

      1. 从报告的 Current landscape 窗格中的所有问题下拉列表中，选择所需的问题问题。默认情况下，选择所有问题。
      2. 在报告 识别风险 窗格中，按应用程序名称、风险级别、调查问卷、问卷和回答对显示的列表进行排序。

    • 显示特定应用程序的报告：

      1. 在报告的 Identified risk 窗格中，点 Applications 列中的链接。此时会打开 Application inventory 页面。链接中包含的应用程序会显示为列表。

      2. 点所需的应用程序。此时会打开 assessment side 窗格。

        • 要查看应用程序评估的风险级别，请打开 Details 选项卡。
        • 要查看评估的详情，请打开 Reviews 选项卡。

7.7. 标记应用程序
复制链接

您可以将各种标签附加到您要分析的应用程序。您可以使用标签来对应用程序进行分类，并即时识别应用程序信息，如应用程序中使用的应用程序类型、数据中心位置和技术。您还可以使用标记将 archetypes 与应用程序关联，以进行自动评估。有关 archetypes 的更多信息，请参阅使用 archetypes。

标记可以随时在分析 过程中 自动完成。

注意

并非所有标签都可以自动分配。例如，分析只能根据其技术标记应用程序。如果还想为应用程序标记部署它的数据中心的位置，您需要手动标记应用程序。

7.7.1. 创建应用程序标签
复制链接

您可以为 MTA 评估或分析的应用程序创建自定义标签。

流程

  1. 在 Migration 视图中，点 Controls。
  2. 单击 标签选项卡。
  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. 自动标记
复制链接

将应用添加到应用清单时，MTA 会自动生成语言发现和技术发现任务。当语言发现任务运行时，技术发现和分析任务会等待语言发现任务完成。这些任务会自动向应用添加标签。MTA 可以根据应用程序分析自动将标签添加到应用程序。自动标记在处理大型应用程序组合时特别有用。

默认启用基于应用程序分析的应用程序自动标记。您可以通过在 Analysis 配置 向导的 Advanced 部分中取消选择 Enable automated tagging 复选框，在应用程序分析过程中禁用自动标记功能。

注意

要自动标记应用程序，请确保在运行应用程序分析 前 选择了 Enable automated tagging 复选框。

7.7.4. 显示应用程序标签
复制链接

您可以显示附加到特定应用程序的标签。

注意

您只能在运行应用程序分析后显示自动附加的标签。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 点所需应用程序的名称。此时会打开侧窗格。
  3. 单击 标签选项卡。此时会显示附加到应用程序的标签。

7.8. 使用 archetypes
复制链接

archetype 是一组具有常见特征的应用程序。您可以使用 archetypes 同时评估多个应用程序。

应用程序架构由标准标签和应用程序分类定义。每个 archetype 定义 评估模块 如何根据该 archetype 中定义的特征来评估应用程序。如果应用程序的标签与 archetype 的标准标签匹配，则应用程序会与 archetype 关联。

创建架构类型由一系列 标签、利益相关者和利益相关者 组定义。标签包括以下类型：

  • 条件 标签是 archetype 要求将应用程序作为成员的标签。

    注意

    如果 archetype 条件标签仅与某个应用程序部分匹配，则此应用程序不能是 archetype 的成员。例如，如果应用仅具有标记，但 archetype a criteria 标签 包括标记 AND b，则应用 将不会成为 archetype 的 一个成员。

  • archetype 标签是应用到 archetype 实体的标签。
注意

与 archetype 关联的所有应用程序都会继承这些应用程序所属的 archetype 组中的 评估 和审核。这是默认设置。您可以通过完成单个评估和检查来覆盖应用程序的继承。

7.8.1. 创建 archetype
复制链接

当您创建 archetype 时，如果此应用程序具有与 archetype 匹配的条件标签，则清单中的应用程序会自动与那个 archetype 关联。

流程

  1. 打开 MTA Web 控制台。
  2. 在左侧菜单中，单击 Archetypes。
  3. 单击 Create new archetype。

  4. 在打开的表单中，输入新 archetype 的以下信息：

    • 名称 ：新 archetype 的名称（必需）。
    • Description: 新 archetype （可选）的描述。
    • criteria Tags ：将评估的应用程序与 archetype 关联的标签（必需）。如果更新条件标签，则会再次触发与 archetype 关联的应用程序的进程。
    • arch etype Tags: 标签，在应用程序中评估 archetype 的标签（必需）。
    • 利益相关者 ：与应用程序开发和迁移相关的特定利益相关者（可选）。
    • 利益相关者组 ：与应用程序开发和迁移相关的利益相关者组（可选）。
  5. 点 Create。

7.8.2. 评估归档类型
复制链接

如果回答所有必需的问题，则被视为已评估 archetype。

注意

如果应用程序与几个 archetypes 关联，则评估此应用程序时，会考虑评估此应用程序。

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. 打开 MTA Web 控制台。
  2. 选择 Migration 视图并点 Archetype。
  3. 点击 Options 菜单 kebab ，并从下拉菜单中选择 Assess。
  4. 从可用问题列表中，单击 Take 以选择所需的问卷。
  5. 在" 评估 "菜单中，回答所需问题。
  6. 点击 Save。

7.8.3. 查看 archetype
复制链接

如果已审阅过一次 archetype，即使多个问题已标记为必填，也被视为已审阅。

注意

如果应用程序与几个 archetypes 关联，则当检查所有相关 archetypes 时，会考虑这个应用程序。

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. 打开 MTA Web 控制台。
  2. 选择 Migration 视图并点 Archetype。
  3. 点击 Options 菜单 kebab ，并从下拉菜单中选择 Review。
  4. 从可用问卷列表中，单击 Take 以选择所需的评估问卷。
  5. 在" 评估 "菜单中，回答所需问题。
  6. 选择 Save and Review。您将自动重定向到 Review 选项卡。

  7. 输入以下信息：

    • 建议的操作 ：完成架构类型迁移或现代化所需的相应操作。
    • 工作量估计 ：执行现代化或迁移所选 archetype 所需的工作量级别。
    • 业务连续性 ：应用程序对业务的关键程度。
    • work Priority: archetype 的优先级。
  8. 点 Submit review。

7.8.4. 删除 archetype
复制链接

删除 archetype 会删除任何关联的评估和审核。所有相关的应用程序都移到 Unassessed 和 Unreviewed 状态。

7.9. 分析应用程序
复制链接

您可以使用 Migration Toolkit for Applications (MTA)用户界面来配置和运行应用程序分析。分析决定了应用程序在迁移或现代化应用程序之前必须修改哪些特定行。

7.9.1. 配置并运行应用程序分析
复制链接

您可以一次分析多个应用程序，在同一分析中有多个转换目标。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 选择您要分析的应用程序。
  3. 检查分配给应用程序的凭据。
  4. 点 Analyze。

  5. 从列表中选择 Analysis 模式 ：

    • 二进制
    • 源代码
    • 源代码和依赖项
    • 上传本地二进制文件。只有在分析单个应用程序时会出现这个选项。如果选择了这个选项，系统会提示您 上传本地二进制文件。将文件拖动到提供的区域中，或者点击 Upload 并选择要上传的文件。
  6. 点击 Next。

  7. 为分析选择一个或多个目标选项：

    • 应用程序服务器迁移到以下平台之一：

      • JBoss EAP 7
      • JBoss EAP 8
    • 容器化
    • Quarkus
    • OracleJDK 到 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 应用程序服务
  8. 点击 Next。

  9. 选择以下范围选项之一以更好地关注分析：

    • 仅限应用和内部依赖项。
    • 应用程序及所有依赖项，包括已知的开源库。
    • 选择要手动分析的软件包列表。如果选择了这个选项，请键入文件名并点添加。
    • 排除软件包。如果选择了这个选项，请输入软件包名称并单击 添加。
  10. 点击 Next。

  11. 在 Advanced 中，您可以通过选择 Manual 或 Repository 模式，将额外的自定义规则附加到分析中：

    • 在 Manual 模式中，单击 Add Rules。拖动相关文件或从其目录中选择文件，然后单击添加。

    • 在 Repository 模式中，您可以从 Git 或 Subversion 存储库添加规则文件。

      重要

      如果您已将迁移目标附加到分析中，附加自定义规则是可选的。如果您还没有附加任何迁移目标，则必须附加规则。

  12. 可选：设置以下选项之一：

    • 目标
    • 源
    • 排除的规则标签。使用这些标签的规则不会被处理。根据需要添加或删除。

    • 启用自动标记。选中该复选框，以自动将标签附加到应用。默认选择此复选框。

      注意

      只有在运行分析 后，才会显示自动附加的标签。

      您可以手动将标签附加到应用程序，而不是启用自动标记或添加。

      注意

      分析引擎将标准规则用于一组全面的迁移目标。但是，如果没有包含目标，是一个自定义框架，或者应用程序使用不支持的语言（如 Node.js、Python）编写，您可以在 Set Target 选项卡中跳过目标选择，并在 Custom Rules 选项卡中上传自定义规则。只有手动上传的自定义规则文件才会被验证。

  13. 点击 Next。
  14. 在 Review 中，验证分析参数。

  15. 点 Run。

    当 MTA 下载要执行的容器的镜像时，会调度分析状态。下载镜像后，状态会更改为 In-progress。

注意

分析需要几分钟的时间根据应用程序的大小以及集群容量和资源来运行。

提示

MTA 依赖于 Kubernetes 调度功能来确定基于集群容量创建多少分析器实例。如果选择多个应用程序进行分析，则一次只能置备一个分析器。使用更多集群容量时，可以并行执行更多分析过程。

  1. 可选： 要跟踪活跃分析任务的状态，点 notifications 按钮打开 Task Manager drawer。

    或者，将鼠标悬停在应用程序名称上，以显示弹出窗口。

  2. 分析完成后，若要查看其结果，请点击应用程序名称来打开 application drawer。
注意

在 Application Inventory 页面上创建应用程序实例后，语言发现任务将启动，自动预先选择目标过滤器选项。但是，您可以选择您需要的不同语言。

7.9.2. 查看分析详情
复制链接

您可以显示分析的活动日志。活动日志包含此类分析详情，如分析步骤。

流程

  1. 在 Migration 视图中，点 Application inventory。
  2. 点击应用程序行打开 application drawer。
  3. 点 Reports 选项卡。
  4. 点分析的活动日志的 View analysis details。

  5. 可选： 对于分析过程中发现的问题和依赖项，点应用程序 drawer 中的 Details 选项卡，然后点 问题或 依赖项。

    或者，在 Migration 视图中打开 Issues 或 Dependencies 页面。

7.9.3. 访问不匹配的规则
复制链接

要访问不匹配的规则，您必须运行启用了增强日志的分析。

  1. 导航到 Application analysis 下的 Advanced。
  2. 选择 Options。
  3. 检查 增强的高级分析详情。

运行分析时：

  1. 进入 side drawer 中的 Reports。
  2. 点 View analysis details，打开 YAML/JSON 格式日志视图。
  3. 选择 issues.yaml 文件。

  4. 对于每个规则集，有一个不匹配的部分，其中列出了找不到与规则匹配的规则 ID。

    issues.yaml 中的不匹配规则 ID
    View larger image
    issues.yaml 中的不匹配规则 ID

7.9.4. 下载分析报告
复制链接

MTA 分析报告包含多个部分，包括应用程序使用的技术列表、应用程序依赖项以及必须更改的代码行，以便成功迁移或现代化应用程序。

有关 MTA 分析报告内容的更多信息，请参阅 检查报告。

为方便起见，您可以下载分析报告。请注意，默认情况下这个选项被禁用。

流程

  1. 在 Administration 视图中，点 General。
  2. 将 Allow 报告切换为在运行分析后下载。
  3. 进入 Migration 视图，点 Application inventory。
  4. 点击应用程序行打开 application drawer。
  5. 点 Reports 选项卡。

  6. 点 HTML 或 YAML 链接：

    • 点击 HTML 链接，您可以下载压缩的 analysis-report-app-<application_name>.tar 文件。提取此文件会创建一个文件夹，其名称与应用相同。
    • 点击 YAML 链接，您可以下载未压缩的 analysis-report-app-<application_name>.yaml 文件。

7.10. 使用任务管理器控制 MTA 任务
复制链接

任务管理器 提供有关注入应用程序(MTA)任务的 Migration Toolkit for Applications (MTA)任务的精确信息。任务管理器 处理以下类型的任务：

  • 应用程序分析
  • 语言发现
  • 技术发现

您可以通过以下方法之一显示与任务相关的信息：

  • 要显示活跃的任务，点 notifications 按钮打开 Task Manager drawer。
  • 要显示所有任务，请在 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)任务。

注意

您可以在任何调度的任务上启用 Preemption （未处于 Running、Succeeded 或 Failed的状态）。但是，只有较低优先级的任务才会被抢占。当较低优先级任务被低优先级任务阻止并启用了 Preemption 时，可能会重新调度低优先级任务，以便阻止更高优先级的任务可以运行。因此，仅在较高优先级任务（如应用程序分析）上启用 抢占 任务时才有用。

流程

  1. 在 Migration 视图中，点 Task Manager。
  2. 点所选任务的 Options 菜单( kebab )。

  3. 根据您的场景，完成以下步骤之一：

    • 要为任务启用 抢占，请选择 Enable preemption。
    • 要在启用了 Preemption 的任务中禁用 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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat