配置和管理 Migration Toolkit for Applications 用户界面


Migration Toolkit for Applications 8.0

使用 Migration Toolkit for Applications 用户界面评估和分析应用程序

Red Hat Customer Content Services

摘要

通过使用 Migration Toolkit for Applications (MTA)用户界面,您可以对应用程序进行清单、评估、分析和管理应用程序,以便在产品组合和应用程序级别通过用户界面更快地迁移到 OpenShift。

您可以使用 Migration Toolkit for Applications (MTA)用户界面(UI)来评估和分析应用程序,以了解风险并适合迁移到 Red Hat OpenShift 上的混合云环境。您可以在库存、评估、分析和管理应用程序以更快地迁移到 OpenShift 时了解采用过程中的潜在问题。

您可以通过设置以下参数来配置应用程序(MTA)实例环境:

  • 一般的
  • 凭证
  • 软件仓库
  • Proxy
  • 自定义迁移目标
  • 问题管理
  • 评估问卷

2.1. 先决条件

2.2. 配置凭证

您可以设置以下凭证类型来配置应用程序(MTA)实例环境:

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

2.2.1. 配置源控制凭证

要在分析应用程序或创建一个从私有存储库拉取规则的自定义迁移目标时访问私有存储库,您可以配置源控制凭证。这些凭据包括用户名和密码或 Supply Chain Management (SCM)私钥和密码短语。

流程

  1. Administration 视图中,点 Credentials
  2. Create new
  3. 输入以下信息:

    • Name
    • 描述(可选)
  4. Type 列表中,选择 Source Control
  5. User credentials 列表中,选择 Credential Type 并输入请求的信息:

    • 用户名/密码

      • 用户名
      • 密码(隐藏)
    • SCM 私钥/密码

      • SCM 私钥
      • 私钥密码(隐藏)

        注意

        特定于类型的凭据信息(如密钥和密码短语)是隐藏的,或显示为 [Encrypted]。

  6. 可选:如果要将源控制凭证设置为默认,如果应用程序没有 分配任何来控制凭证,请启用 Use 作为源控制凭证
  7. Create

    注意

    MTA 验证输入并创建新凭证。必须解析和检查 SCM 密钥以获取有效性。如果验证失败,则会显示以下错误消息:“not a valid key/XML file”

2.2.2. 配置 Maven 凭证

要访问私有 Maven 存储库,您可以使用 settings.xml 设置文件配置新的 Maven 凭证。

流程

  1. Administration 视图中,点 Credentials
  2. Create new
  3. 输入以下信息:

    • Name
    • 描述(可选)
  4. Type 列表中,选择 Maven Settings File。
  5. 上传 settings.xml 设置文件或粘贴其内容。
  6. 可选:如果要将 Maven 凭证设置为默认,如果应用程序没有分配?切换,启用 Use 作为源控制凭证。默认情况下,所有没有分配凭证的应用都会使用这些凭证。

    重要

    如果没有将 Maven 凭证设置为默认,则必须在运行分析前手动将这些凭证分配给应用程序。否则,应用程序不会获取凭证,这可能会导致分析更长。

  7. Create

    注意

    MTA 验证输入并创建新凭证。必须解析 Maven settings.xml 文件,并检查其有效。如果验证失败,则会显示以下错误消息:“not a valid key/XML file”

2.2.3. 配置代理凭证

您可以与代理一起配置用户名和密码凭证。

流程

  1. Administration 视图中,点 Credentials
  2. Create new
  3. 输入以下信息:

    • Name
    • 描述(可选)
  4. Type 列表中,选择 Proxy
  5. 输入以下信息。

    • 用户名
    • 密码

      注意

      特定于类型的凭据信息(如密钥和密码短语)是隐藏的,或显示为 [Encrypted]。

  6. Create

    MTA 验证输入并创建新凭证。

2.3. 配置软件仓库

您可以为 Migration Toolkit for Applications (MTA)实例环境配置以下软件仓库类型:

  • Git
  • Subversion
  • Maven

2.3.1. 配置 Git 存储库

您可以在 Migration Toolkit for Applications (MTA) 用户界面的 Repositories 视图中配置 Git 存储库。

流程

  1. Administration 视图中,点 Repositories,然后点 Git
  2. 启用 Consume insecure Git 存储库 交换机。

2.3.2. 配置子版本软件仓库

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

流程

  1. Administration 视图中,点 Repositories,然后点 Subversion
  2. 启用 Consume insecure Subversion 软件仓库 交换机。

2.3.3. 配置 Maven 存储库

您可以配置 Maven 存储库,并在 Migration Toolkit for Applications (MTA)用户界面的 Repositories 视图中减少其大小。

重要

如果 Tackle CR 的 rwx_supported 配置选项被设置为 false,则 Local artifact repository 字段和 Clear repository 按钮都被禁用。因此,您无法执行以下步骤。

流程

  1. Administration 视图中,点 Repositories,然后点 Maven
  2. 启用 Consume insecure artifact repositories 开关。
  3. 可选: 要减少 Maven 存储库的大小,请点 Clear repository 链接。

    注意

    根据 Maven 存储库的大小,大小更改可能无法识别。

2.4. 配置代理设置

您可以为 Migration Toolkit for Applications (MTA)实例环境配置 HTTP 和 HTTPS 代理设置。

流程

  1. Administration 视图中,点 Proxy
  2. 启用 HTTP 代理或 HTTPS 代理 开关以启用代理连接。
  3. 输入以下信息:

    • 代理主机
    • 代理端口
  4. 可选:启用 HTTP 代理凭证或 HTTPS 代理凭证 开关来启用身份验证。
  5. Insert

2.5. 创建自定义迁移目标

具有 admin 权限的架构师或用户可以创建和维护与自定义迁移目标相关的自定义规则集。架构师可以上传自定义规则文件,并将它们分配到各种自定义迁移目标。然后,可以在分析配置向导中选择自定义迁移目标。

通过使用可用的自定义迁移目标,您可以避免为每个分析运行配置自定义规则。这简化了非管理员用户或第三方开发人员分析配置和执行。

先决条件

  • 您以具有 admin 权限的用户身份登录。

流程

  1. Administration 视图中,点 Custom migration targets
  2. Create new
  3. 输入目标的名称和描述。
  4. Provider 下拉菜单并选择语言提供程序。

    重要

    对 Python 和 Node.js 语言供应商的支持仅作为技术预览提供。

  5. Image 部分中,上传目标图标的图形文件。该文件可以是 PNG 或 JPEG 格式,最多为 1 MB。如果您没有上传任何文件,则使用默认图标。
  6. Custom rules 部分中,从存储库选择 Upload manuallyRetrieve

    • 如果您选择了 Upload manually,请上传或拖放本地驱动器中所需的规则文件。
    • 如果您选择了 Retrieve from a repository,请完成以下步骤:

      1. 选择 GitSubversion
      2. 输入 Source repository,Branch, 和 Root path 字段。
      3. 如果存储库需要凭证,请在 Associated credentials 字段中输入这些凭证。
  7. Create

    新迁移目标会出现在 Custom migration targets 页面中。现在,非管理员用户可在 Migration 视图中使用。

2.6. 后续步骤

第 3 章 为应用程序实例配置 Migration Toolkit

如果您是项目架构师,您可以在迁移前配置实例的关键参数。您可以根据需要添加并编辑这些参数。以下参数定义了某个机构内的应用程序、个人、团队、垂直或区域,或参与迁移:

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

3.1. 创建利益相关者

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

  1. 创建 Stakeholder 组。请注意,默认情况下,没有定义利益相关组。
  2. 创建作业功能。job function 属性对利益相关者进行分类,并提供可扩展的默认值列表。
  3. 创建利益相关者.

流程

  1. 创建 stakeholder 组:

    1. Migration 视图中,点 Controls
    2. Stakeholder groups
    3. Create new
    4. 输入以下信息:

      • Name
      • 描述
      • 成员
    5. Create
  2. 创建新作业功能:

    1. Migration 视图中,点 Controls
    2. Job functions
    3. Create new
    4. Name 文本框中,输入作业功能标题。
    5. Create
  3. 创建新的拥有者:

    1. Migration 视图中,点 Controls
    2. Stakeholders
    3. Create new
    4. 输入以下信息:

      • Email
      • Name
      • 作业功能。请注意,您可以创建自定义功能。
      • stakeholder 组
    5. Create

3.2. 创建业务服务

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

流程

  1. Migration 视图中,点 Controls
  2. Business services
  3. Create new
  4. 输入以下信息:

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

3.3. 创建标签

Migration Toolkit for Applications (MTA) 使用多个类别中的标签,并提供默认值列表。但是,您可以创建自己的标签类别,以及一个不在默认列表中的新标签。

您可以以任何顺序创建和配置实例。但是,以下是创建标签的最有效顺序:

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

流程

  1. 创建标签类别:

    1. Migration 视图中,点 Controls
    2. Tags
    3. Create tag category
    4. 输入以下信息:

      • Name
      • rank :标签出现在应用程序中的顺序。
      • Color
    5. Create
  2. 创建标签:

    1. Migration 视图中,点 Controls
    2. Tags
    3. Create tag
    4. 输入以下信息:

      • Name
      • 标签类别
    5. Create

第 4 章 创建并配置 JIRA 连接

您可以通过在 Migration Toolkit for Applications (MTA)用户界面(UI)中为每个迁移创建一个 Jira 问题来跟踪应用程序迁移。

4.1. 配置 JIRA 凭证

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

  • 对于 Jira Cloud 和 private Jira 服务器或数据中心,请使用 Basic auth 凭证类型。
  • 对于 Jira Cloud 和 private Jira 服务器或数据中心,请使用 Basic auth 凭证类型。对于私有 Jira 服务器或数据中心,请使用 Bearer Token 凭据类型。
重要

您无法删除已分配给 JIRA 连接实例的凭证。

流程

  1. Administration 视图中,点 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 页面中。

  5. 可选: 要编辑凭证,请点击 Edit

4.2. 创建 JIRA 连接

要跟踪应用程序迁移,您可以在 MTA 中定义 JIRA 实例并建立连接。

重要

如果 JIRA 中存在问题,您无法删除用于创建迁移问题的 JIRA 连接,即使迁移 wave 被删除。

先决条件

流程

  1. Administration 视图中,在 Issue Management 下点 Jira
  2. Create new
  3. New instance 窗口中输入以下信息:

    • 实例的名称
    • Jira 帐户 Web 界面的 URL
    • 从列表中选择 Jira CloudJira Server/Data center 实例类型
    • 从列表中选择凭证

      注意

      如果您选择了 Jira Cloud 作为实例类型,则列表中仅显示 Basic Auth 凭证。

      如果将 Jira Server/Data Center 选为实例类型,则将显示 Basic AuthToken Bearer 凭据。

      选择适合 Jira 服务器或数据中心的特定配置的类型。

  4. 默认情况下,无法通过具有无效证书的服务器建立连接。要覆盖这个限制,请启用 启用不安全的通信 开关。
  5. Create

    新的连接实例会出现在 JIRA 配置 页面中。

验证

  • Jira 配置 页面中,确保已建立连接并授权:

    • 如果 Connection 列的状态显示 Connected,则 JIRA 连接将被建立并授权。
    • 如果 Connection 列的状态显示 Not connected,请单击状态以检查错误的原因。

第 5 章 使用以下方法管理应用程序

您可以使用 Migration Toolkit for Applications (MTA)用户界面(UI)来执行以下任务,以准备应用程序进行评估和分析:

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

MTA UI 应用程序具有以下属性:

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

5.1. 在 MTA UI 中添加新应用程序

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

注意

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

先决条件

  • 您已登录到 MTA 服务器。

流程

  1. Migration 视图中,点 Application Inventory
  2. Create new
  3. Basic information 下,输入以下字段:

    • 名称 :新应用的唯一名称。
    • 描述 :应用程序的简短描述(可选)。
    • 业务服务 :应用的目的(可选)。
    • 手动标签 :用于表示应用程序的软件标签(可选,一个或多个)。
    • Owner: 下拉列表中注册的软件所有者(可选)。
    • 供稿人 :下拉列表的 Contributors (可选,一个或多个)。
    • 注释 :与应用程序相关的注释(可选)。
  4. Source Code 并输入以下字段:

    • 存储库类型GitSubversion
    • 源存储库 :保存软件代码的存储库的 URL。

      • 对于 Subversion:这必须是存储库根目录的 URL 或一个完全限定的 URL,(可选)包括分支和嵌套目录。当完全限定时,BranchRoot 路径 必须为空。
    • 分支 :存储库中的应用代码分支(可选)。

      • 对于 Git:这可能是任何引用; 提交哈希分支 或标签
      • 对于 Subversion:这可能是分支或标签的完全限定路径,如 branch /stabletags/stable。当 Source 存储库 URL 包含分支时,这必须为空。
    • 根路径 :目标应用程序存储库中的根路径(可选)。

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

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

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

    • :应用程序工件的 Maven 组。
    • 工件 :应用程序的 Maven 工件。
    • 版本 :应用程序的软件版本。
    • 打包 :应用程序工件的打包,如 JARWAREAR

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

  6. Create。新应用程序会出现在定义的应用程序列表中。
  7. 可选:点应用程序名称旁的 Edit 来更改应用程序设置:

    1. 进行必要的调整。
    2. 点击 Save
    注意

    编辑应用程序后,MTA 会重新创建语言发现和技术发现任务。如需更多信息,请参阅 显示自动化任务

5.2. 显示自动化任务

将新应用程序添加到 Application Inventory 后,您可以通过添加应用程序来显示自动创建的自动化任务:

  • 语言发现任务标识应用中的编程语言。
  • 技术发现任务标识了应用中的特定技术。

这些任务会自动为应用添加适当的标签,从而减少了手动为应用分配标签所涉及的工作量。这些任务完成后,添加到应用的标签数量将显示在 Tags 列下。

注意

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

流程

  1. Application Inventory 中,将鼠标悬停在应用程序名称上,以显示自动化任务。
  2. 显示应用程序标签:

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

5.3. 导入应用程序列表

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

注意

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

流程

  1. 下载用于导入应用程序列表的 CSV 模板:

    1. Migration 视图中,点 Application inventory
    2. Review 右侧的 Options 菜单( kebab )。
    3. Manage import 以打开 Application import 页面。
    4. 点击 Import 右侧的 Options 菜单( kebab )。
    5. Download CSV template
  2. 将应用程序列表添加到 .csv 导入文件中。确保 文件以所需格式包含所有需要的信息。
  3. Migration 视图中,点 Application Inventory
  4. 点 Options 菜单( kebab )。
  5. Import
  6. 选择所需的文件,然后单击 打开
  7. 可选: 选择 启用自动创建缺少的实体。默认选择这个选项。

验证

  1. 验证导入是否已完成,并检查接受或拒绝的行数。
  2. 点复选框左侧的箭头来查看导入的应用程序。

    重要

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

5.4. 为应用程序分配凭证

将应用程序添加到 Migration Toolkit for Applications (MTA)用户界面(UI)后,您可以为此应用程序分配凭证。

流程

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

5.5. 设置默认凭证

您可能需要将大量应用程序列表导入到 Migration Toolkit for Applications (MTA)用户界面(UI)。每个应用程序都需要凭证用于语言和技术发现任务。您可以设置默认要使用的凭证,而不是为每个应用程序手动定义凭证。

重要

您只能将 Maven 或源控制凭证设置为默认凭证。您只能为每个凭证类型定义一个默认凭证集合。

注意

默认凭证不适用于已经为其分配了凭证的应用程序。

先决条件

流程

  1. 可选:识别没有为其分配凭证的应用程序:

    1. 在 Migration 视图中,点 Application inventory 显示应用程序列表。
    2. 将鼠标悬停在没有为其分配凭证的应用程序名称上。对于此类应用,应用程序发现任务会失败。
  2. 在 Administration 视图中,点 Credentials。
  3. 设置默认凭证:

    1. 单击您要设置为默认凭证右侧的 Options 菜单()。
    2. 点 Set 为 default。

      或者,您可以在创建 Maven 或源代码凭证时直接设置默认凭据。如需更多信息,请参阅以下步骤:

验证

  1. Migration 视图中,点 Application inventory 显示应用程序列表。
  2. 将鼠标悬停在没有为其分配凭证的应用程序名称上。由于您设置了默认凭据,因此应用程序发现任务会重启。

5.6. 创建迁移 wave

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

流程

  1. Migration 视图中,点 Migration waves
  2. Create newNew migration wave 窗口将打开。
  3. 输入以下信息:

    • name (可选)。如果没有提供名称,则迁移 wave 可通过其开始和结束日期来标识。
    • 潜在的开始日期.此日期必须早于当前日期。
    • 潜在的结束日期.此日期必须早于开始日期。
    • 利益相关者 (可选)
    • 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 窗口。

5.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 选项卡。

第 6 章 使用 MTA 评估应用程序

您可以使用 Migration Toolkit for Applications (MTA)用户界面(UI)来评估应用程序。在评估应用程序时,MTA 会估算准备应用程序进行容器化的风险和成本,包括时间、人员和其他因素。您可以使用评估结果来讨论利益相关者之间的讨论,以确定应用程序是否适合容器化。

6.1. 评估模块功能

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

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

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

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

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

注意

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

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

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

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

6.2. MTA 评估问题

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

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

6.2.1. 默认评估问题

传统的 Pathfinder 是应用程序(MTA)问题的默认 Migration Toolkit。Pathfinder 是一个基于问题的工具,可用于评估企业 Kubernetes 平台上容器中的现代化应用程序是否适合性。 

通过与默认的问卷和审阅过程交互,系统可以通过一系列评估报告来公开应用程序知识。

您可以将默认问题导出到 YAML 文件:

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

6.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/ServerlessArchitecture/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
6.2.2.1. 自定义问卷的 YAML 模板

您可以使用以下 YAML 模板来构建自定义问题。您可以点击 评估问题 页面中的 Download YAML 模板 下载此模板。

例 6.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
6.2.2.2. 自定义问题字段

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

...
name: Testing
thresholds:
    red: 30
    yellow: 45
    unknown: 5
...
Copy to Clipboard Toggle word wrap
Expand
表 6.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 (必需,字符串):目标标签。

6.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. 在问题 的名称 中输入 来确认删除。

6.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. 从列表中选择 StakeholdersStakeholder groups 来跟踪为未来参考提供评估的人员。

    注意

    您还可以在 Migration 视图的 Controls 窗格中添加 Stakeholder GroupsStakeholders。如需更多信息,请参阅为应用程序实例配置 Migration Toolkit

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

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

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

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

在这种情况下,建议使用以下解决方案:

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

6.5. 查看应用程序

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

重要

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

流程

  1. Migration 视图中,点 Application inventory
  2. 选择您要查看的应用程序。
  3. 通过执行以下操作之一查看应用程序:

    • 在评估应用程序时点 Save and Review。如需更多信息,请参阅 评估应用程序
    • 点击行右末尾的 Options 菜单( kebab ),然后从下拉菜单中选择 Review
  4. Proposed action 并选择操作。
  5. Effort estimate 并设置执行评估所需的工作量级别。
  6. Business criticality 字段中,输入应用程序对业务的关键程度。
  7. Work priority 字段中,输入应用程序的优先级。
  8. 可选:在注释字段中输入评估问卷 注释
  9. Submit review

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

6.6. 查看评估报告

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

流程

  1. Migration 视图中,点 Reports。显示所有应用程序的聚合评估报告。
  2. 根据您的场景,执行以下操作之一:

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

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

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

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

第 7 章 标记应用程序

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

标记可以 自动完成也可以手动 完成。

注意

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

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.2. 手动标记应用程序

您可以在运行应用程序分析前或之后手动标记应用程序。

流程

  1. Migration 视图中,点 Application inventory
  2. 在所需应用程序所在的行中,点 Edit ( icon edit )。此时会打开 Update application 窗口。
  3. Select a tag(s) 下拉列表中选择所需的标签。
  4. 点击 Save

7.3. 自动标记

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

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

注意

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

7.4. 显示应用程序标签

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

注意

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

流程

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

第 8 章 使用 archetypes

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

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

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

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

    注意

    应用程序必须具有所有 archetype 的 criteria 标签才能成为成员。例如,如果应用仅具有标记,但 archetype a criteria 标签 包括标记 AND b则应用 将不会成为 archetype 的 一个成员

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

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

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

8.2. 评估归档类型

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

注意

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

先决条件

  • 您已登录到 MTA 服务器。

流程

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

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

第 9 章 使用 MTA 分析应用程序

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

9.1. 配置并运行应用程序分析

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

重要

如果您分析了需要 Maven 凭证来访问私有存储库的应用程序,您必须在 Administration 视图的 Credentials 部分中分配这些凭证。否则,可能会对分析质量、发现问题或 MTA 性能的影响。如需更多信息,请参阅配置凭证

重要

当您的系统在断开连接的环境中,但您可以访问 Maven 代理时,应用程序分析会在没有失败的情况下运行。但是,如果您无法访问 Maven 代理,Maven 无法构建应用程序,因为它无法访问所需的依赖项。

另请注意,在断开连接的环境中的分析输出通常会产生较少的事件,因为依赖项分析在没有访问 Maven 的情况下准确运行。

流程

  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 中,您可以通过选择 ManualRepository 模式,将额外的自定义规则附加到分析中:

    • Manual 模式中,单击 Add Rules。拖动相关文件或从其目录中选择文件,然后单击添加
    • Repository 模式中,您可以从 Git 或 Subversion 存储库添加规则文件。

      重要

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

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

    • 目标
    • 排除的规则标签。使用这些标签的规则不会被处理。根据需要添加或删除。
    • 启用自动标记。选中该复选框,以自动将标签附加到应用。默认选择此复选框。

      注意

      只有在运行分析 ,才会显示自动附加的标签。您可以手动将标签附加到应用程序,而不是启用自动标记或添加。

      注意

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

  13. Next
  14. Review 中,验证分析参数。
  15. Run

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

    注意

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

    注意

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

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

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

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

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

9.2. 查看分析详情

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

流程

  1. Migration 视图中,点 Application inventory
  2. 点击应用程序行打开 application drawer。
  3. Reports 选项卡。
  4. 点分析的活动日志的 View analysis details
  5. 可选: 对于分析过程中发现的问题和依赖项,点应用程序 drawer 中的 Details 选项卡,然后点 问题或 依赖项

    或者,在 Migration 视图中打开 IssuesDependencies 页面。

9.3. 访问不匹配的规则

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

流程

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

运行分析时:

  1. 进入 side drawer 中的 Reports
  2. View analysis details,打开 YAML/JSON 格式日志视图。
  3. 选择 issues.yaml 文件。
  4. 对于每个规则集,有一个不匹配的部分,其中列出了找不到与规则匹配的规则 ID。

9.4. 下载分析报告

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

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

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

流程

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

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

9.5. 访问分析分析

分析分析分析包含有关应用程序中使用的技术及其用法的信息。与问题不同,您不需要修复成功迁移的见解。它们由任何没有分配正工作值和类别的规则生成。它们可能含有消息和标签。从静态或动态报告运行应用程序分析后,您可以访问分析分析信息。

流程

  • 根据您的场景,完成以下步骤之一:

    • 从静态报告访问应用程序见解:

      1. .tar 格式下载分析报告。如需更多信息,请参阅 下载分析报告
      2. 提取 .tar 文件。
      3. 打开 index.html 文件以查看静态报告。
      4. 单击 Insights
    • 从动态报告访问应用程序见解:

      1. Migration 视图中,点 Insights
      2. Insights 页面上,根据应用程序名称过滤应用程序 insights,以显示特定应用程序的 insights。

第 10 章 使用任务管理器控制 MTA 任务

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

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

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

  • 要显示活跃的任务,点 notifications 按钮打开 Task Manager drawer。
  • 要显示所有任务,请在 Migration 视图中打开 Task Manager 页面。
警告

对资源没有多用户访问限制。例如,用户创建的分析器任务可由任何其他用户取消。

10.1. 查看任务日志

要查找特定 Migration Toolkit for Applications (MTA)任务的详情和日志,您可以使用 Task Manager 页面。

流程

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

    或者,单击 Status 列中的任务状态。

10.2. 控制任务执行顺序

您可以使用 Task Manager 来抢占您计划执行的 Migration Toolkit for Applications (MTA)任务。

注意

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

流程

  1. Migration 视图中,点 Task Manager
  2. 点所选任务的 Options 菜单( kebab )。
  3. 根据您的场景,完成以下步骤之一:

    • 要为任务启用 抢占,请选择 Enable preemption
    • 要在启用了 Preemption 的任务中禁用 Preemption,请选择 Disable preemption

第 11 章 MTA 用户界面中的平台感知

从 8.0.0 开始,MTA 支持平台感知,直接从源平台实例导入所有或选择的应用程序。

您可以通过两种方式将应用程序与源平台关联:

  • 通过为 MTA 清单中可用的应用程序手动配置源平台
  • 通过从源平台实例发现(导入)应用程序。在这种情况下,应用程序会在 MTA 清单中导入时与源平台连接。

在 MTA 8.0.0 中,红帽支持 Cloud Foundry (CF)作为源平台。

导入应用程序后,您可以检索平台和运行时配置(也称为发现)。发现是获取连接到其源平台实例的导入应用程序的配置的过程。检索或发现会生成包含应用程序配置的发现清单。

之后,您可以使用发现清单来生成在目标平台中部署应用程序所需的最终资产集合。

您可以在 MTA 用户界面中执行以下任务:

  1. 创建多个源平台(CF)实例。
  2. 将 MTA 用户界面中创建的应用程序链接到源平台。
  3. 获取发现清单。您可以为每个应用程序或批量生成发现清单。

11.1. 在 MTA 用户界面中创建源平台

创建源平台实例,以检索一个或多个应用的平台和运行时配置。

MTA 管理员可以在 MTA 用户界面中配置一个或多个源平台实例。

先决条件

  • MTA 管理员在管理模式中创建了源平台(如 Cloud Foundry (CF))的 Source Control 凭证。

流程

  1. 在 MTA 用户界面中,选择 管理 工作模式。
  2. 单击左侧菜单栏中的 Source platform,以进入 Source platforms 页面。
  3. Create new platform。此时会出现 Create new platform 对话框。
  4. 在表单中,输入以下信息:

    1. 名称 :源平台(CF)实例的唯一名称。
    2. 键入: 从下拉菜单中选择源平台。例如,Cloud Foundry.
    3. URL :源平台的 API URL。例如,CF 平台的 API URL。
    4. 凭证 :选择您为源平台配置的 Source Control 凭证的名称。
  5. Create

    源平台实例已创建。源平台实例可以与一个或多个应用程序相关联。

11.2. 通过源平台发现应用程序

配置源平台后,您可以发现一个或多个应用程序到 MTA 应用程序清单中。

先决条件

  • 在管理模式中至少配置一个源平台实例。
  • 源平台实例应该正在运行。

流程

  1. 在 MTA 用户界面中,选择 管理 工作模式。
  2. 点导航菜单中的 Source Platforms 进入 Source Platforms 页面。
  3. Source platforms 页面中选择一个源平台。
  4. 点击源平台的 Options 菜单( kebab )并点 Discover applications。此时会出现 Discover application 窗口。

    发现过程将源平台实例中部署的所有或选定应用程序导入到 MTA 上的 Applications Inventory 页面。

  5. 根据在发现过程中过滤应用程序的 MTA,输入平台协调详情。

    以下示例显示了 CF 实例的平台协调:

    {
        "names": ["app-a", "app-b"],
        "spaces": ["example-space"]
    }
    Copy to Clipboard Toggle word wrap
    注意

    对于 CF 实例,应用程序名称 字段可以包含 globs。例如: app*

  6. 检查配置并点 Discover applications。此操作会切换应用程序导入任务。
  7. 关闭 Discover 应用程序 窗口。
  8. (可选)通过源平台名称检查应用程序导入任务的状态,然后点应用程序导入任务以 YAML 格式查看任务详情。

11.3. 将应用程序与源平台关联

您可以通过在源平台中配置应用程序的协调,将 MTA 中创建的应用程序与其 Cloud Foundry (CF)实例关联。

具体协调因您选择的源平台而异。例如,CF 实例的协调是 namespace

先决条件

  • 在管理模式中至少配置一个源平台实例。

流程

  1. 在 MTA 用户界面中,选择 Migration 模式。
  2. Application Inventory 页面中,点应用程序中的编辑图标( icon edit )。此时会出现 Update application 对话框。
  3. 以以下格式输入以下信息:
  4. Source platform 并输入以下字段:

    1. 源平台 :选择一个源平台实例。
    2. 源平台协调 :配置源平台以以下任一方式协调:

      1. 在字段中输入源平台协调。例如,CF 实例的名称空间
      2. 启用源平台协调,在 JSON 中输入应用程序协调。例如,CF 实例协调可以是:

        {
            "name": ["example-app"],
            "space": ["example-space"]
        }
        Copy to Clipboard Toggle word wrap
    3. Name :输入应用程序的名称。
    4. 空间 :配置在源平台中部署应用程序的 CF 空间。
  5. Save 并关闭 Update application 对话框。

验证

验证您配置的协调是否保存在 MTA 中:

  1. 点应用程序行中的任意位置打开应用程序详情视图。
  2. Platform 选项卡验证源平台协调您配置的配置。
  3. 为源平台启用 JSON 开关以 JSON 格式检查协调。

11.4. 生成发现清单

要生成发现清单,您必须从 Cloud Foundry (CF)源平台实例检索应用程序配置。MTA 生成带有应用程序配置的发现清单,稍后您可以用它来生成资产(部署清单)。

您可以一次检索一个或多个应用程序的配置。

先决条件

  • 要从中重试配置的 Cloud Foundry 实例。
  • 您已为需要检索配置的应用程序配置了源平台。

流程

  1. 在 MTA 用户界面中,选择 Migration 工作模式。
  2. Application Inventory 页面中,您可以检索一个或多个应用的配置。

    1. 检索应用程序的配置:

      1. 选择应用程序并点 Options 菜单( kebab )。
      2. 单击 Retrieve Configuration
    2. 检索多个应用程序的配置:

      1. 选择目标应用程序或者点 Select all 选项( select )。
      2. 单击顶部的 Options 菜单,然后单击 Retrieve Configuration
  3. 您可以在 Retrieve Configuration 对话框中查看只读配置 然后点 Retrieve。MTA 触发一个任务来检索每个应用程序的配置。

验证

  1. 点击应用程序行打开应用程序详情视图并点 Platform 标签页。
  2. 使用检索到的配置检查发现清单,并根据需要下载 JSON 配置。

从 8.0.0 开始,在 MTA 用户界面中生成资产允许您创建将应用程序从 Cloud Foundry (CF)实例部署到 Red Hat OpenShift Container Platform 或 Kubernetes 所需的不同资产(manifests)。

要生成资产,您必须熟悉以下实体:

  • archetypes - Archetypes 包含一个或多个条件标签来标识 EAP 6 等技术。archetype 可帮助您根据常见技术对应用程序进行分类。对于资产生成,您可以按照 archetypes 来规划迁移路径,因为您可以在 archetype 中配置其他资产生成实体(例如,包含生成器的目标配置集)。
  • generators - 生成器使用模板引擎,如 Helm,以及一组模板作为输入配置。生成器使用为目标平台定义的模板和生成部署资产的迁移路径。当您运行资产生成过程时,生成器会解析应用程序发现清单以创建部署资产。

    例如,EAP 6 应用的迁移路径是 EAP 8,目标平台是 Kubernetes。生成器可以生成所需的资产,以将 EAP 6 应用迁移到要在 Kubernetes 上部署的 EAP 8。通过解析 EAP 6 应用的发现清单来生成资产。

  • 目标配置集 - 目标配置集代表您要迁移的目标平台。它包含生成器的排序。通过目标配置集,您可以运行多个生成器,每个生成器都会为特定迁移路径创建资产。因此,目标配置集可让您为给定 Archetype 的同时为多个迁移路径目标平台组合生成资产。

    例如,如果要创建资产将 EAP 6 应用程序作为 OpenJDK 21 应用程序迁移,并在 OpenShift Container Platform (目标平台)中作为 EAP 8 应用迁移,您可以通过具有两个生成器的目标配置集来实现此目的,每个迁移路径一个。

  • Application - 应用程序包括发现清单、标签和资产存储库。

    配置检索过程会生成一个发现清单,其中包含源平台(CF)实例中部署的应用程序的平台和运行时配置。在资产生成过程中,发现清单由生成器模板解析,该模板为部署生成最终资产。

    应用程序还包含标签,您必须将这些标签配置为 Archetype 中的条件标签。

    资产仓库是在目标平台中找到生成的用于部署资产的位置。

您可以在不同的 archetypes 中重复使用生成器。

12.1. 配置生成器

生成器包含一个生成不同资产清单所需的模板存储库。

创建生成器:

先决条件

  • 已安装 MTA 8.0.0 operator 以访问 Web 控制台。
  • 您是可在 MTA 用户界面中 访问管理模式的管理员。
  • 作为管理员,您为模板存储库(如果适用)配置了源控制凭证。

流程

  1. Administration 视图中,点 Generators

    Generators 页面中,您可以创建、编辑和删除生成器。

  2. 单击 Create new generator
  3. 配置以下字段:

    1. 在打开的对话框中的 Name 字段中输入生成器的唯一名称。
    2. 选择 Helm 作为生成器。
    3. 单击 Template repository 以展开该部分。

      1. GitSubversion 中选择 Repository 类型
      2. (可选)输入包含 Helm 模板的仓库的 URL。
      3. (可选)输入存储库的 Branch
      4. (可选) 输入存储库的根路径
      5. 如果存储库为私有,请选择用于访问您的存储库的凭证。
    4. (可选)点 Values,并以键值对形式在发现清单中输入新值。

      在资产生成过程中,生成器会使用您输入的值覆盖发现清单中的匹配属性的值。

    5. (可选)点 Parameters 来输入参数及其默认值作为键值对。

      参数字段在模板生成资产前需要用户输入。

      注意

      在模板实例化过程中,参数优先于发现清单中存在的配置。

  4. 点击 Save。您可以单击 generator 行上的任何位置,以打开显示生成器配置详情、参数和值的详细信息视图。

12.2. 配置目标配置集

目标配置集包含一个或多个生成器,每个生成器会为不同的迁移路径生成资产。migrator 可以在 Archetypes 页面中为特定 archetype 创建并跟踪目标配置集。您可以根据您要将特定 archetype 应用程序迁移到的目标平台,为 archetype 配置多个目标配置文件。

生成器以优先级顺序运行,低优先级生成器生成的清单不会覆盖由其他生成器生成的清单。

流程

  1. Migration 视图中,点 Archetypes
  2. 点击 archetype 的 Options 菜单( kebab ),然后选择 Manage target profiles

    此时会出现 <archetype-name> 的 Target 配置集

  3. Create new target profile
  4. 在打开的对话框中的 Name 字段中输入目标配置集的唯一名称。
  5. 单击 Tag category 字段,再选择要与标签关联的类别标签。
  6. 选择特定的生成器,然后单击右箭头,将生成器从 Available generators 列表移到 Chosen generators 列表中。
  7. Create

您可以点 archetype 行打开 archetype 详细视图,其中列出了 archetype 的目标配置集。

12.3. 配置资产仓库

Migration Toolkit for Applications (MTA)生成资产并将其发布到您配置的资产存储库。如果没有配置资产存储库,应用程序存储库将作为发布所生成的资产的默认值。

当您为应用程序配置资产存储库时,您还可以在生成资产前关联资产库的 Source Control 凭证。如果您没有为资产存储库配置 Source Control 凭证,则 MTA 会将源代码存储库凭证视为资产存储库的默认 Source Control 凭证。

流程

  1. Migration 视图中,点 Applications
  2. 点编辑图标( icon edit )更新导入的应用程序。
  3. Update application 对话框中,点 Asset repository 并配置以下详情:

    1. GitSubversion 选择 Asset 存储库类型
    2. Asset 仓库字段中,输入 asset 仓库 URL。
    3. 输入存储库的 Branch
    4. 输入存储库的 Root 路径
  4. Save 并关闭 Update application 对话框。
  5. 从应用的 Options 菜单( kebab )点 Manage Credentials
  6. Manage Credentials 对话框中选择 asset 仓库凭证并关闭对话框。

12.4. 生成部署资产

当您为应用程序生成资产时,生成器会呈现与应用程序架构关联的所有迁移路径的清单。

先决条件

  1. 您生成了发现清单。
  2. 您在 archetype 中配置了应用程序标签。
  3. 您已在 archetype 中配置了生成器和目标配置集。

流程

  1. Migration 视图中,点 Applications
  2. 点击应用程序的 Options 菜单( kebab )。
  3. 点 Generate asset 来打开 Generate assets 对话框。
  4. 选择一个目标配置文件并点 Next
  5. 点切换按钮打开 JSON 视图,您可以在其中输入参数值。
  6. Next 查看配置以生成资产。
  7. Generate asset

您可以在您配置的资产中查看生成的资产。

附录 A. 对 MTA 项目做出贡献

可以帮助 Migration Toolkit for Applications 包括大多数应用程序结构和服务器配置,包括您的。

您可以为您提供以下任意项目的帮助:

  • 发送电子邮件到 jboss-migration-feedback@redhat.com,并告知我们哪些 MTA 迁移规则必须涵盖的内容。
  • 提供示例应用程序来测试迁移规则。
  • 识别迁移可能很难迁移的应用程序组件和问题区域:

    • 编写问题迁移区域的简短描述。
    • 编写简短概述,了解如何解决问题迁移区域。
  • 在应用程序上尝试 Migration Toolkit for Applications。确保报告您符合的任何问题。
  • 在应用程序上尝试 Migration Toolkit for Applications。确保报告您符合的任何问题。MTA 使用 JIRA 作为其问题跟踪系统。如果您遇到执行 MTA 的问题,请提交 JIRA 问题
  • 对应用程序规则存储库的 Migration Toolkit 贡献:

    • 编写 Migration Toolkit for Applications 规则以识别或自动迁移过程。
    • 为新规则创建一个测试。

      如需更多信息,请参阅规则开发指南

  • 贡献项目源代码:

    • 创建核心规则。
    • 提高 MTA 性能或效率。

法律通告

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

© 2025 Red Hat