可以从以下几个方面进行过渡:
1.降低容器化开发的学习成本。
一方面是要做一些普及性的推广和培训,
另外一方面是尽量降低容器操作复杂度,可以构建常用的dockerfile以及yaml模板,增加web界面来代替常用管理操作。
2.降低容器化开发和改造难度
理想的容器化应用,要求无状态,分布式,配置分离,简化依赖等等,具体实施的时候可以根据情况降低要求,对已有的系统尽量采用封装,而不是直接改造。
至于CICD,初期建议不要强制要求,基于容器的CICD容易实现,但是并不是必须要实现的。
3.从生产上线要求上进行约束
如果实际上线的业务系统是基于非容器的底座,则要求开发人员进行容器化应用开发是毫无意义的。
容器化上线要求涉及很多方面,包括端口,存储,网络设置,负载要求,服务名,发布方式等,需要循序渐进,以生产上线强制性规范作为指挥棒,督促整体应用系统的容器化开发,部署和运维。
1、可以考虑在DEVOPS平台,定制出相应的PIPELINE流水线,屏蔽掉开发人员写Dockerfile的负担,兼容开发人员的编译习惯,譬如JAVA开发人同,只需要保证和之前一样,正常编译出JAR/WAR,DEVOPS平台按标准化规范(注:包括BASEIMAGE,JDK、中间件等的标准化)就能够自动生成容器镜像。
2、做好推广工作,譬如举办培训和考试认证。
收起挺好的问题,我觉得几个方面:
1.需要做一些普及性的宣传和广告,告诉他们新的平台的好处,比如你不用再申请虚拟机,物理机了,然后你的应用写个Dockerfile就可以一键上云了什么的。
2.需要设立项目对接组,在推广的初期是需要帮项目组去做传统环境到容器环境的切换的,大概可以做一个示范以后,其他的组件他们自己完成。
3.让他们确实感受到CICD和容器云的便捷性,比如他们同样的30多个组件要部署在功能测试,stage以及客户验收环境,原来模式部署可能需要3天的时间,而容器化部署后只需要半天,这优势就体现出来了。这样才能更好的接收容器化改造。