使用 Migrate to Containers 将 Tomcat 应用迁移到容器

Last reviewed 2022-06-17 UTC

本文档适用于应用所有者和云架构师。本文档介绍如何将 Tomcat 上运行的 Java 应用迁移到 Google Kubernetes Engine (GKE)GKE AutopilotCloud RunGKE Enterprise 中运行的容器。您可以按照此过程从本地环境、私有托管环境或其他云服务商迁移 Tomcat 应用。还重点介绍了使用 Migrate to Containers 自动执行迁移的优势。

本文档假定您熟悉以下产品:

  • 部署在 Tomcat 应用服务器并在 Linux 虚拟机 (VM) 上运行的 Java 应用。
  • Kubernetes 概念和 Kubernetes 命令行工具的基本用法。

本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如需简要了解本系列,请参阅“迁移到 Google Cloud:选择迁移路径”

阅读本文档,使用 Migrate to Containers 将兼容的 Tomcat 应用从支持的来源环境迁移到 GKE、GKE Enterprise 或 Cloud Run 环境。这些来源环境可能包括以下环境:

Migrate to Containers 使用拟合评估工具发现、检查和迁移 Linux 虚拟机中的所有 Tomcat 应用。该工具会将 Tomcat 应用拆分为多个 Tomcat 应用容器。迁移后,您可以将部分或全部应用划分到一个共享的容器映像中。下图显示了 Migrate to Containers 如何拆分和迁移应用:

Migrate to Containers 拆分和迁移 Tomcat 应用。

Migrate to Containers 具有以下优势:

  • 工作负载现代化改造:提供以下功能:
  • 容器化环境:将基于虚拟机的现有应用容器化。请参阅迁移到容器的好处
  • 官方 Tomcat 映像:默认使用 Tomcat 官方映像,您也可以更新迁移或 Dockerfile 以使用您自己的映像。Docker 官方映像将 Docker 最佳实践引入您的基础映像。
  • 自动应用拆分:自动建议将每个发现的应用拆分到各个容器中,同时保留 Tomcat 的原始配置。
  • Secret 管理:发现 Tomcat 服务器使用的密钥库、信任库和证书,并自动生成 Kubernetes 基元以外部化它们并将其装载为 Kubernetes Secret
  • 建议的日志记录更改:自动发现常见的 Java 日志记录框架配置文件(例如 log4j2、log4j 和 logback),并提出更改建议以与 Kubernetes 上的日志记录保持一致。

使用 Migrate to Containers 功能将 Tomcat 应用迁移到容器是工作负载现代化改造之旅的一个可能步骤。迁移可帮助您转换 Tomcat 应用,使其在云端环境中运行。它还有助于避免代价高昂的重写工作。

理想的迁移候选对象是在受支持的 Tomcat 和 Java 版本上运行并且具有以下特点的应用:通过完全重写进行现代化改造的费用太高或者难度太大。

设计迁移到 Google Cloud 的过程

如需将 Tomcat 应用从来源环境迁移到 Google Cloud 上运行的容器,请遵循迁移到 Google Cloud 系列中介绍的框架。

下图说明了迁移过程的路径:

迁移路径包含四个阶段。

上图演示的框架有四个阶段:

  1. 评估:评估来源环境、要迁移到 Google Cloud 的应用,以及哪些 Tomcat 应用适合迁移。
  2. 规划:为 Migrate to Containers 创建基本基础架构,例如预配资源层次结构和设置网络访问。
  3. 部署:使用 Migrate to Containers 将 Tomcat 应用从来源环境迁移到 GKE、GKE Autopilot、Cloud Run 或 GKE Enterprise。
  4. 优化:开始利用云技术和功能。

评估来源环境和应用

在评估阶段,您将收集有关来源环境和要迁移的应用的信息。这样做可帮助您合理调整所需的资源 - 无论是针对迁移还是目标环境。

在评估阶段,您将完成以下任务:

  1. 构建一个完整的应用清单。
  2. 根据应用的属性和依赖项对应用进行分类。
  3. 为您的团队开展 Google Cloud 培训和指导
  4. 针对 Google Cloud 构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 选择您首先要迁移的应用。

以下部分基于“迁移到 Google Cloud:评估和发现工作负载”。但是,它们提供了在评估您要使用 Migrate to Containers 迁移到容器的 Tomcat 应用时所需的特定信息。

构建您的清单

如需确定迁移范围,您必须了解您的 Tomcat 环境。如需了解您的环境,请收集有关应用及其依赖项的信息。

构建应用清单介绍如何构建您的 Tomcat 环境中的工作负载及其依赖项的清单。请按照该指导信息操作并构建清单。完成该工作后,请继续阅读本文档。

构建工作负载及其依赖项的清单后,就可以优化该清单了。评估您的组织在使用 Migrate to Containers 迁移 Tomcat 应用时感兴趣的方面和功能。

在评估您的 Tomcat 环境以进行迁移之前,请完成使用 Migrate to Containers 将虚拟机迁移到容器以及“迁移到 Google Cloud:评估和发现您的工作负载”中的评估工作。完成该工作后,请完成工作负载清单。

如需完成工作负载清单,请考虑以下事项:

  • 在 Tomcat 实例中运行的操作系统:收集有关在 Tomcat 实例中运行的操作系统及其许可的信息,并确保操作系统列在兼容的操作系统和 Kubernetes 版本中。
  • 运行应用的 Tomcat 版本:收集有关运行应用的 Tomcat 版本的信息,并确保这些版本与 Migrate to Containers 兼容
  • 在 Tomcat 实例中部署的应用:评估在每个 Tomcat 实例中部署的应用。然后,映射应用之间以及应用与外部服务之间的依赖项。接下来,收集有关应用的配置来源的信息,其中可能包括以下配置:
    • 环境变量
    • 非标准 Tomcat 安装路径
    • LDAP 用户注册表
    • Java 数据库连接 (JDBC)
    • Tomcat 代理
    • Java 代理
  • Migrate to Containers 拟合得分:评估您的 Tomcat 应用是否适合使用 Migrate to Containers 进行迁移。Migrate to Containers 提供了一个拟合评估工具,您必须在托管 Tomcat 实例的虚拟机上运行该工具,以计算拟合得分并推荐迁移过程。Migrate to Containers 使用一组评估规则来成功迁移 Tomcat 应用。
  • Tomcat 集群Tomcat 集群支持在集群中的所有 Tomcat 节点中进行会话复制。由于缺少网络级多播支持,某些集群实现(包括内置的 McastService 成员资格提供程序)无法在 Kubernetes 中正常运行。这意味着,配置 Tomcat 集群需要在迁移过程中进行一些手动配置。如需了解详情,请参阅 Apache Tomcat wiki 上的 ClusteringCloud
  • Tomcat 代理:在许多实际场景中,Tomcat 可能配置为在反向代理后面运行。反向代理的主要用途包括:
  • Java 代理:如果您使用代理服务器来控制来自 Tomcat 和 Java 应用的出站流量,则可以停用 Java 代理设置。从 Java 虚拟机 (JVM) 命令行选项中移除代理设置。然后,配置 Anthos Service Mesh (ASM) 出站流量网关,以控制来自 Tomcat 容器的出站流量网络。

完成评估

构建与您的环境和 Tomcat 工作负载相关的清单后,请完成“迁移到 Google Cloud:评估和发现您的工作负载”中介绍的剩余评估阶段活动。完成该工作后,请继续阅读本文档。

规划和构建基础

按照规划和构建基础中的指导操作后,完成您的 Tomcat 基础:

  1. 确认您的 Tomcat 工作负载和来源环境满足迁移 Tomcat 工作负载的前提条件。
  2. 如需完成数据收集阶段,请在运行 Tomcat 实例的虚拟机上运行 mfit。如需了解详情,请参阅使用适合度评估工具

如需预配和配置 Migrate to Containers 及其依赖项,请参阅设置 Migrate to Containers

完成该工作后,请继续阅读本文档。

将 Tomcat 应用迁移到容器

在部署阶段,使用以下里程碑来引导您。

生成并查看迁移计划

为您的 Tomcat 应用创建 Migrate to Containers 迁移计划

  1. 将来源环境配置为 Migrate to Containers 迁移来源:为了迁移 Tomcat 应用,Migrate to Containers 需要有关运行虚拟机的来源环境的信息。您可以通过执行本文档的构建您的清单部分中所述的任务来收集这些信息。如需详细了解如何配置来源环境,请参阅添加迁移来源
  2. 创建迁移计划:如需指定要从来源环境迁移到受支持的目标环境的 Tomcat 应用,请创建迁移计划。例如,您可以配置要用来存储永久性数据的位置。

    如需详细了解如何创建和监控迁移计划,请参阅创建迁移。 如需为 Tomcat 应用创建迁移计划,您可以使用执行迁移中所述的 migctl 命令行工具

  3. 查看并自定义迁移计划:为要迁移的每个虚拟机生成迁移计划后,请查看并自定义每个计划,以确保其符合您的要求。如需详细了解如何自定义迁移计划,请参阅自定义迁移计划

生成迁移工件和部署描述符

如需为应用生成目标 Tomcat 工件,Migrate to Containers 需要提取您在迁移计划中配置的虚拟机中运行的应用。然后,它会创建多个工件并将其放入 Cloud Storage 存储桶中。Migrate to Containers 还会生成部署描述符,您可以进行自定义并使用它们在目标环境中部署容器映像的实例。

对于每个迁移的应用,Migrate to Containers 都会创建一个包含以下内容的文件夹:

  • Dockerfile
  • 应用二进制文件
  • Tomcat 配置文件
  • 构建脚本
  • Skaffold YAML,用于构建和部署
  • (可选)secrets.sh 脚本
  • (可选)日志记录归档

您可以监控您创建和迁移的容器工件的进度。如需详细了解如何监控迁移,请参阅监控迁移的工作负载

检查和验证生成的资源和描述符

使用 Migrate to Containers 生成容器工件和部署描述符后,请查看并更新这些工件和描述符,以确保它们符合您的要求。例如,请考虑以下几个方面:

  • 容器映像描述符:查看使用 Migrate to Containers 生成的容器映像描述符,并验证它们是否足以满足容器工作负载的需求。如果您需要更新基础容器映像,请在生成的 Dockerfile 中更新 FROM 值。您还可以更改 Dockerfile 中的 CATALINA_OPTS 环境变量来设置或更改 JVM 环境变量。
  • 应用级日志记录:Migrate to Containers 会自动生成修改后的日志记录归档,您可以使用该归档来修改日志记录设置,以将日志写入控制台而不是本地文件。

如需详细了解如何查看容器工件和部署描述符,请参阅查看工件

将容器化工作负载部署到 GKE、GKE Autopilot、Cloud Run 或 GKE Enterprise 并进行验证

工作负载的部署描述符准备就绪后,您可以执行以下任务:

  1. 构建应用容器映像:为迁移后的工作负载构建应用容器映像。如需了解说明,请参阅构建容器映像
  2. 在目标环境中部署您的迁移后应用
  3. 监控迁移后的工作负载:部署 Tomcat 应用容器后,您可以收集其在目标环境中的表现数据。如需了解详情,请参阅监控迁移的工作负载
  4. 集成迁移后的工作负载:将工作负载部署到目标环境中后,将工作负载的容器工件生成和部署流程与您的部署流程和流水线相集成。如果您没有自动部署流程,并且正在手动部署工作负载,我们建议您从手动部署迁移到自动部署

卸载 Migrate to Containers

使用 Migrate to Containers 完成工作负载迁移后,我们建议您执行以下操作:

  1. 确保您拥有 Migrate to Containers 在迁移过程中生成的工件的所有引用。
  2. 卸载 Migrate to Containers

迁移后优化您的环境

如需完成迁移,请参阅优化环境

您可以为迁移的 Tomcat 应用执行以下特定于 Tomcat 的优化:

  • 调整日志记录:与日志文件通常写入本地文件系统的虚拟机不同,Kubernetes 日志通常流式传输到 stdoutstderr。然后,您通过专用后端(例如 Cloud Logging)存储、分析和查询这些日志。您可以使用 logConfigs 归档工件中的 Migrate to Containers 建议更改,或手动更改日志记录配置,以将日志写入 stdoutstderr
  • 保护敏感数据:将密码和任何其他敏感数据放入 Kubernetes Secret 中。在容器启动时使用 Kubernetes Secret 替换配置占位符。
  • 调整资源配置文件:为了帮助 Kubernetes 高效地安排 Pod,请微调请求和限制的资源限制条件。微调资源以与 JVM 堆大小保持一致也至关重要,可避免内存不足 (OOM) 异常。
  • 控制 Pod 位置:如果迁移后的 Tomcat 应用经常相互通信,您可能需要安排它们在同一节点上运行。如果控制 pod 放置将对迁移后的应用有利,请参阅将 pod 分配给节点

后续步骤