容器云平台与虚拟机平台devops工具兼容问题？

我理解这里主要的差异在构建节点和工具层面，对于流水线过程来说，只是在部署环节的实现不同。也就是整条流水线的其中一个stage的实现不同，对流水线过程来说不一定存在差异。部署过程流水线提供的是发布到虚拟机和容器云平台的能力，比如我们在虚拟机的部署方面是通过ansible来进行的，容器云平台的部署则是通过Kubectl命令行工具管理Kubernetes集群。应用部署逻辑则是由项目团队提供playbook或yaml文件，设置环境信息：对于虚拟机来说是ip，对于容器来说是namespace。也就是平台提供两种部署方式的能力，项目团队只需要关注自己需要哪种部署方式，以及流水线在什么时间需要执行部署任务。在后续的建设中我们计划通过统一的发布平台来提供应用部署到虚拟机和容器云平台的支持，流水线基于统一的发布平台完成部署过程，进一步减小用户对两种部署方式差异的感知。

在整个工具链里面CI无论是部署在虚拟机还是部署容器里面都是一样，主要的区别还是在CD部分，现在国内主流的做法还都是基于容器来做，无法把CD这块的范围扩大的传统的环境中（物理机、虚拟机、云主机）。如果要运用到传统环境中，对CD平台资源管理的能力要求更高，需要能够对容器、虚拟机、软件进行统一的建模（TOSCA模型）、部署。通过这种建模方式，能够有效的基于容器和虚拟机整合devops流程。

从环境兼容视角分析，需要考虑devops中哪些流程需要构建在容器云平台上，哪些流程需要落在虚拟机平台上，两种平台各有自身擅长的地方，应发挥其特长实现devops流程兼容。
如：灰度发布、金丝雀发布、AB测试、沙箱环境、混沌工程等场景适合资源池快速扩缩要求，需要采用容器+devops方案，从代码管理、开发环境，仅限本地开发视角来分析，支持多平台操作系统、数据库虚拟机环境更加适合现阶段需求开发、代码管理工作，可选择虚拟机+devops方案。
两者的结合与兼容，需要判断devops各个环节所需要工作是否适用哪种环境，还需要考虑受限环境下如何采用最低成本投入方式来建设devops平台。

我们建议将容器平台作为基础设施，然后再容器和IaaS平台之上建设一个统一的应用发布平台。最后CICD流水线的最后一步与这个应用发布平台对接。这样在开发测试阶段，可以实现兼容容器和虚拟机的应用发布，在生产环境也可以实现容器/虚拟机应用的统一发布管理