如 Maximo 管理器 演变为容器原生平台，其许多支持工具和开发工作流程仍与传统技术息息相关。BIRT（商业智能和报告工具）就是这样一种工具，它仍然是Maximo报告功能的核心部分，但它带来了一些沉重的负担。
‍

在这篇文章中，我将探讨在现代环境中使用BIRT所面临的挑战，以及容器化BIRT开发环境如何解决的不仅仅是一个挑战，而是许多挑战。

‍

问题：传统依赖关系和安全风险

Maximo Manage 8.x 和 9.x（以及之前的 7.6.x）依赖于不同版本的 Birt，其中一些版本已有七年以上的历史了。例如，Maximo Manage 8.x 到 9.0 要求的 BIRT 4.8 依赖于 Java 1.8，甲骨文于 2019 年 1 月停止支持 Java 1.8。

这会带来几个问题：

• 安全漏洞: Java 1.8 不再接收安全补丁，使其成为潜在的攻击载体

• 合规问题：运行不受支持的软件可能会违反公司安全策略

• 环境冲突: Java 1.8 可能会干扰同一台计算机上的现代 Java 应用程序

‍

解决方案：容器化

为了解决这些问题，我使用无根容器引擎 Podman 对 BIRT 开发环境进行了容器化。这种方法带来了许多好处：

安全与隔离

• Java 1.8 只能在容器内运行，从不接触主机系统
• Podman 的无根模式和命名空间隔离降低了权限升级或系统受损的风险

环境一致性

• 每个开发人员都使用相同的容器镜像，从而消除了 “在我的机器上运行” 的问题
• 所有必需的库、字体、JDBC 驱动程序和配置均已预先绑定

开发人员生产力

• 零设置时间：开发人员可以通过拉动并运行容器来立即开始工作
• 并行开发：并行运行多个版本的 Java 或 BIRT，不会发生冲突
• 更快的入门速度：新团队成员无需花费数小时配置环境

云和 CI/CD 集成

• 容器可以直接部署到 OpenShift 中，与 Maximo 基于容器的架构保持一致
• BIRT 报告的生成可以集成到 CI/CD 管道中，以实现自动测试和部署

便携性和定制

• 容器可以在任何支持 Podman 或 Docker 的操作系统上运行
• 您可以使用预加载的报告和库创建特定于客户的图像，从而缩短设置时间并确保一致性

‍

与 Maximo 的未来保持一致

由于 Maximo Manage 本身现在在容器中运行，因此将 BIRT 开发环境引入同一个生态系统是完全合理的。通过容器化 BIRT：

• 你可以降低风险
• 你改善了开发者体验
• 你符合现代 DevOps 实践

‍

也许最重要的是，你的开发工作流程可以适应未来的发展。

‍

协作和团队可扩展性

容器化 BIRT 开发环境的另一个主要优势是它可以增强团队之间的协作。通过使用共享的、受版本控制的容器镜像，团队可以确保所有人（从开发人员到测试人员再到 DevOps 工程师）都在稳定的环境中工作。这减少了沟通不畅，简化了故障排除，并使跨多个项目或客户扩展开发工作变得更加容易。无论您是要招募新团队成员还是跨时区协作，容器都提供了可靠且可重复的基础，使每个人保持一致。

‍

现实世界的例子

在最近的一个项目中，我们在使用容器化版本的 BIRT 为 IBM Maximo 应用程序套件 (MAS) Manage 9.0 开发报告时遇到了一个意想不到的问题。具体而言，报告预览功能无法正常工作——这是其他开发团队以前从未遇到过的问题。

‍

经过一番调查，我们发现根本原因与容器化 BIRT 环境捆绑在一起的库创建的报告上下文有关。尽管这些库在技术上是正确的，但它们引入了与 MAS Manage 9.0 细微的不兼容性。

‍

解决方案涉及修改报告，手动将缺失的 Maximo 属性添加到报表上下文中。有趣的是，这个问题以前从未浮出水面，因为MAS 9的大多数报告都是根据IBM的BIRT开发指南编写的。这些指南链接到用于 BIRT 8.x 的库文件，这些文件没有同样的问题。

‍

这种经历是一个宝贵的提醒：开发环境可能会有很大差异，这些差异可能会导致以后出现意想不到的问题。它强调了在部署环境的特定环境中验证工具和库的重要性，即使遵循官方文档也是如此。

‍

‍

像 BIRT 这样的传统工具不必阻碍你。通过容器化，您可以对开发环境进行现代化改造，而无需从头开始重写所有内容。这是一种实用、可扩展的解决方案，可为您的 Maximo 报告工作流程带来安全性、一致性和灵活性。