标签：
DevOps（Deveplopment 和 Operations 的简称），中译为开发运维一体化，可定义为是一种过程、方法、文化、运动或实践，主要是为了通过一条高度自动化的流水线来加强开发和其他 IT 职能部门之间的沟通和协作，加速软件和服务的交付。
在一个较成熟的软件和服务交付的团队里，就技术层面来说主要分为三个组成部分：开发、测试和运维。DevOps的作用就是将这三个部分紧密的连接起来，提供一条从软件开发到质量保障到技术运营的自动化流水线，加强不同角色之间的沟通和协作，基于用户需求实现软件和服务的快速交付。
“开发的这群傻叉新给的发布包又把系统 CPU 搞到100%了，应用又夯住了，都是些什么水平的人啊……”
“运维的这帮傻鸟技术太差，维护的是些什么稀烂的系统，在我这跑得好好的，上他们那应用就挂……”
“这是开发的锅……”
“这是运维的盘……”
描述得略显浮夸……但这种踢皮球的事情在 IT 公司里面真的是随处可见。无谓对错，也无锅可背，都是由开发和运维的基因所决定，但是最终的受害者却是用户。偏偏比较有意思的就是，开发和运维人员所做的这些也都是为了用户，开发人员必须根据用户的需求对应用的功能进行不停的变更，运维人员也必须根据用户的需求提供稳定和持续的服务。各司其职的同时也在两者之间形成了一面无形的墙，阻碍了开发和运维之间的沟通和协作，而DevOps的出现就是为了击碎这堵无形之墙。
不是一个工具，但它需要被工具来实现，好在现今已经有了很多商业版和开源版的软件来形成一个有效的工具链来作为 DevOps 技术层面的支撑。但是光有工具还不够，再好的工具没人会用也没意义，所以需要有熟悉这个工具链的 IT 人员来提供技术支持，利用工具实现 DevOps 的高度自动化。
DevOps 是一条从开发到运维的流水线，想要流水线能够高效的自动运行，必须要设定一系列的流程和规范来进行管控。IT 的管理者需要有基于软件或服务交付的全局观，能够清晰的认识到交付周期中不同角色的痛点在哪里，进而定制出合适的协作流程。
DevOps 并不是简单的将开发部门和运维部门合并，而是加强开发部门和运维部门之间的协作和沟通。这需要管理者们对企业的 IT 部门有着足够的重视并且愿意去推动 DevOps 这种开发和运维间高效协作的模式，并且开发和运维的人员之间也需要有开放、接纳和协作的意识。
DevOps 是一个虚无缥缈的玩意儿，它并不能被工具或软件来简单的定义或量化。但工具或软件却是实现 DevOps 的一个重要组成部分，而 Docker 就是实现 DevOps 最合适的工具之一。
Docker 是一个分布式应用构建、迁移和运行的开放平台，它允许开发或运维人员将应用和运行应用所依赖的文件打包到一个标准化的单元（容器）中运行。
容器是一个非常早期的技术，Unix 的 Chroot 功能可以说是容器的雏形，而后到大家所熟知的基于 Namespace 和 Cgroups 技术的 LXC（Linux Container），最后到现在如日中天的 Docker。站在前人的肩膀之上，Docker 最妙的地方就是将容器的使用简单化和标准化，再配合一波开源、互联网、云计算、大数据的浪潮，可谓是时代的宠儿。
很多人都喜欢拿容器和虚拟机对比，其实容器和虚机都是属于虚拟化技术的一种实现。两种架构在底层上相同，需要物理硬件和操作系统的支持。不同的是虚拟机场景中，Hypervisor（如 KVM）作为操作系统到虚拟机的中间层，而容器场景中 Docker Engine（以 Docker 为例）作为操作系统到容器的中间层。虚机封装操作系统和应用，而容器则直接封装应用，这也是为什么容器要比虚机轻量的原因。
上图中将虚拟机和容器的特性进行了对比，可以看出容器相对于虚拟机比较有优势的地方就是轻量、灵活、资源利用率高。缺点主要就是隔离性不如虚拟机，也就是一直被无限放大的容器的安全性问题。但偏偏就是因为容器没有完全被隔离到一个密封的小黑屋里面，所以才能带来比虚拟机更好的资源利用率。
个人认为容器在短期之内还取代不了虚机，在未来很长一段时间内会是容器和虚机并存的情况。而到最终谁替代谁，取决的不是技术本身，而是用户体验时代的需求。
了解 Docker 的朋友都知道，Docker 将自身最主要的特点以下面这一句话来描述”Build,Ship and Run Any App Anywhere”。Build 出 Image，然后使用 Registry 来 Ship 镜像，最终使用 Engine 将 Container 和包含的 App 在任意平台（Anywhere）上运行起来。
这三个工具构成了 Docker 的原生环境，加上比较火的 Kubernetes、Mesos、Rancher、etcd 等外部生态，构建出了一个比较完整的 Docker 容器生态圈。对于原生工具和外部工具，个人觉得工具或技术并没有好坏之分，主要还是看适用场景和客户需求。而正是有这些生态的合作和竞争造就的乱世，才促进了容器技术的高速发展和逐步成熟。
Docker 官方给的 Use Case 是 CI/CD、DevOps、Big Data 和 Infrastructure Optimization（Cloud）。
这里比较有意思的就是，这几个使用场景似乎正好描绘着 Docker 当前的发展史。
起初 Docker 的出现主要面向的对象是开发者，为开发者提供应用快速开发和测试的环境，这就是 CI/CD 所在的场景。
随后的发展使得 Docker 不再仅仅只关注开发层面的东西，而在向运维层面迈进，就出现了 DevOps 的场景。
既然有了运维，那肯定避免不了接触到基础架构的东西，而现今的基础架构基本都是围绕着云计算来展开，所以 Docker 又涉及到了基础架构优化的层面，也就是 Container Cloud。
基础架构的容器云有了，那么势必需要对云中的应用提供服务，加上 Docker 自身的许多优势，自然而然的又涉及到了 Big Data 的使用场景。
而 Docker 自身的解决方案 Docker Cloud 和 Docker Data Center 的先后推出也侧面反应了从开发到运维场景的逐步支持。DDC 的出现更是将目标直接瞄准了企业内部容器云。
难以分清是新技术成就了 Docker，还是 Docker 承载了新技术。至少就目前来看，Docker 的发展方向是顺应这个时代的。这只是三岁多的 Docker，不敢想象它在将来会有多大的能量爆发出来，将这些留给时间去述说。
开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。
解决底层基础环境的异构问题。基础环境的多元化造成了从 Dev 到 Ops 过程中的阻力，而使用 Docker Engine 可无视基础环境的类型。不同的物理设备，不同的虚拟化类型，不同云计算平台，只要是运行了 Docker Engine 的环境，最终的应用都会以容器为基础来提供服务。
易于构建、迁移和部署。Dockerfile 实现镜像构建的标准化和可复用，镜像本身的分层机制也提高了镜像构建的效率。使用 Registry 可以将构建好的镜像迁移到任意环境，而且环境的部署仅需要将静态只读的镜像转换为动态可运行的容器即可。
轻量和高效。和需要封装操作系统的虚拟机相比，容器仅需要封装应用和应用需要的依赖文件，实现轻量的应用运行环境，且拥有比虚拟机更高的硬件资源利用率。
工具链的标准化和快速部署。将实现 DevOps 所需的多种工具或软件进行 Docker 化后，可在任意环境实现一条或多条工具链的快速部署。
标签：
原文地址：http://www.cnblogs.com/zhanghonghai/p/5795834.html
