在落地DevOps项目中遇到的困难挑战和解决思路
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了在落地DevOps项目中遇到的困难挑战和解决思路相关的知识,希望对你有一定的参考价值。
DevOps落地困境
本文章由www.mingpaixinxi.com网转载分享,DevOps落地为什么那么难?因为从设计人员、组织架构、流程、人员技能到工具,变化很大,要求很高,建设风险很高。从理念到落地,需要一定的周期才能够成熟,技术决策者一般都比较慎重。
DevOps落地困境包括:
设计部门多
流程改造复杂
责任边界需要重新划分
考核等配套机制没有跟上
技术成熟度低
自动化是核心问题
回过头来看,人们把过去打包、配置、部署,甚至运维,都做了很多自动化的尝试。最为典型的是CI和CD,为什么说典型呢?因为它解决了两类人员边界清晰的需求:打包应用,部署应用。
从整个软件的生命周期看,再往前就是开发阶段了,从目前的技术发展水平来看,还没有一种比较普世的自动化Coder Machine来根据你的需求直接生成代码,这里面涉及到大量的需求分析、归纳、架构设计、技术选型、编码、调试等复杂的工作;往后看,运维工作能不能自动化呢?现在看,至少对于常例性的工作,可以自动化的,不如批量的文件上传、软件安装等等,但是由于系统的运行涉及的因素太多,无论是基础设施、还是操作系统、还是环境配置、以及用户的输入/输出,其组合起来的模式空间还是非常庞大的,所以这一部分完全自动化也比较困难。
传统的CI/CD怎么实现的?
Jenkins:任务、代码仓库、构建脚本、配置变量。
本质上这种自动化也是Case-by-Case的,因为每一个项目选用的开发语言、构建工具、配置方式等都不完全相同,所以,Jenkins构建属于“一次配置,多次受益”,这一次的配置操作本质无法自动化,需要经验丰富的开发人员(项目leader)开发脚本来处理。
那么Docker这样的容器技术出现了以后,是不是简化了这个工作呢?
应该说把一部分任务通过docker封装,实现了开箱即可用,这一部分工作主要就是配置工作。具体到系统构建,还是需要依赖Jenkins类的工具。那么,为什么大家都欢迎Docker这个技术呢?我看,最主要贡献是清晰了发生问题的边界,减少了开发和运维之间的扯皮。开发给出的是一个可运行的环境,而不是一个需要二次人工部署配置的文件集合。
针对Docker环境的CI/CD自动化部分,也是很多PaaS平台软件的主要功能有:
Openshift、RancherOS、CloudFoundry、heroku、stackato、tsuru等。
从开发和运维的角色看问题是不是都解决了?
从开发的角度看,针对环境稍微复杂的应用,需要开发自己的框架插件;从运维的角度看,应用架构的灵活性也需要不同的插件来支撑,同时,运维还需要解决环境适配问题,比如用生成环境的IP等替换配置文件中的默认值等。
所以,引入了docker后看,问题还是不少。
开发/运维的核心需求
开发人员构建自动化,至少不增加现有开发的工作量;运维人员,交付的系统边界清晰,提供编排/配置自动化能力。
DevOps开发运维流程
DevOps关键动作
构建
构建动作用来生成应用程序包、配置文件、安装/部署脚本等,维护程序包的版本。
编排
根据应用系统的拓扑、应用依赖平台、软件包、配置文件(脚本)等,根据依赖关系进行架构编排、动作设置。
部署
根据编排控制文件,进行实例化部署,完成环境设置、平台配置、软件安装、配置更新等动作。
配置
定义不同阶段要进行的配置行为,解析配置模板,自动进行依赖解析,完成应用系统配置。
那么Docker及云环境下的CI/CD系统设计原则
确定工作流程;
树立关键动作;
明确动作交互边界;
根据角色设计工具;
内置大量可复用模板;
同时保持一定的灵活性。
角色/工作流/关键动作
本次演讲重点聚焦与开发(Dev)和运维(Ops)在CI/CD中的交互界面对象确定、CI/CD平台整合、关键技术分析和业务流转流程等四个方面。从实践的角度分享在落地DevOps项目中遇到的困难、挑战和解决思路。
以上是关于在落地DevOps项目中遇到的困难挑战和解决思路的主要内容,如果未能解决你的问题,请参考以下文章