Rainbond

Rainbond是建立在 Kubernetes 之上的开源应用管理平台，可从源码、镜像或已有组件创建应用，并用拓扑表达组件关系。迁移传统应用时，重点不是把一个目录成功跑成容器，而是让构建来源、运行依赖、状态数据和网关入口都成为可复制、可排障的应用模型。

先把传统应用拆成组件清单

以 Web 系统为例，分别记录前端、API、异步任务、数据库和缓存的代码库、启动命令、端口、健康检查、环境变量及存储。运行依赖与业务调用分开标注，密码和证书移入秘密管理。拆分后先在现有环境画出请求和数据流，避免迁入平台才发现隐藏的本地目录或固定 IP。

源码构建与镜像构建不要混用结论

Rainbond 官方支持从 Git 源码自动识别语言并构建，也可使用 Dockerfile 或现成镜像。新源码组件的构建体系会随版本演进，已有升级组件可能保留旧路径；因此每个组件都应保存代码提交、构建方式、依赖源、镜像地址和启动命令。特殊系统依赖无法由默认构建满足时，再使用可审阅的 Dockerfile。

拓扑中的线不等于依赖已经可靠

复制应用来检查环境是否可迁移

官方环境管理支持把组件复制到其他团队或应用，并调整源码分支或镜像 Tag；组件一起复制时可保留依赖关系，跨团队只复制依赖方时关系可能解除。利用这一行为建立测试环境，逐项比较配置、域名、外部服务和数据。复制成功但依赖缺失，说明应用模型仍不完整。

从典型故障反查底层

等待启动先看依赖组件，ImagePullBackOff 检查镜像和仓库权限，反复重启查看业务日志，内存退出则核对资源与泄漏；网关问题查看路由及网关日志。团队仍需掌握 Kubernetes 事件、网络和存储排查，不能只等界面提示。

准备不依赖界面的退出包

为每个组件导出镜像地址与摘要、启动命令、环境变量清单、资源规格、健康检查、网关规则和依赖关系，另存数据库备份与对象文件。选择一个小环境，用原生 Kubernetes 或另一集群重建关键链路。若离开 Rainbond 后无法判断启动顺序、服务地址或存储挂载，说明应用模型还没有形成真正可迁移的交付物。

回滚与恢复分别验收

组件构建会形成版本记录，可用历史版本回滚运行镜像，但应用属性和数据库并不会因此自动回退。上线前演练镜像回滚、配置恢复、数据库还原和文件恢复，并保存平台之外的镜像、配置模板与数据备份。灾备插件等能力可能有版本或商业边界，应以当前部署形态核对。