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项目中遇到的困难、挑战和解决思路。