比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
快速迭代敏捷集成：Docker上运行微服务之妙用
关键字：新闻
　　在过去的两年里，微服务架构已经成了非常热门的名词，它出现在很多论坛、视频、演讲中。作为一种更灵活、可靠、开放的架构，其应用实践也越来越多。因此，由七牛主办的开发者最佳实践日第13期，成功邀请到对持续项目交付深有研究的ThoughtWorks首席咨询师王磊、一站式Docker云平台DaoCloud联合创始人&研发副总裁郭峰、使用Docker应用于电商场景的京东资深架构师季锡强和对容器技术有着一定研究的七牛云韩拓，分别就微服务架构实践、容器技术带来的技术价值、微服务带来的挑战和解决目标等方面的总结经验分享给大家。
　　微服务大探险
　　软件架构是在考虑业务、技术能力、团队、可维护性、安全性、可靠性及可持续性等多重因素下对软件内部进行的划分。通过划分，让软件内部不同的部分之间能够相互鼓励，又能够相互协作，同时给用户提供最终的价值。但什么是微服务架构呢？ThoughtWorks首席咨询师王磊通过一个门户案例为大家解释了微服务架构的概念，以及它如何影响传统的软件架构设计。
　　一年前，该门户每签一个10万的合同所耗费的成本是3.5天。他们当时的结构是典型的三层架构，整个应用程序由一个40万行的代码库组成，后端有一个主动的。虽然使用三层架构的成本比较小，但随着代码和功能的增加，代码库不断膨胀，修改代码存在的风险很大，整个维护成本也变得越来越高。
　　每当开发人员提交代码后，所需的数据集成和构建需要50分钟，意味着每天8小时工作时间最多能有9次代码提交。但为了系统的稳定性，持续集成过程中要尽量避免提交代码，因此，整个团队的交付能力受到了限制。此外，从准备部署包到上线需要3天，3天后才能让用户真正用到部署包，才能实现价值。而如果增加新人，要开发新的环境，包括测试和产品环境，培养周期会很长。针对以上难题，ThoughtWorks制定了如何在团队中对系统进行改造从而满足业务需求的策略。
　　将现有的系统保护起来，把所有开发新功能的优先级都降下来，只需对系统做最紧急的修改，其他和部门进行协商，让团队保持新的和时间在重要的业务上。
　　功能剥离。通过定义新服务，在前端用一些代码的机制让用户逐渐访问新服务，可以达到从原有系统抽出小功能，让客户访问小功能。
　　数据解耦。对于庞大的系统，因为无法很快将所有系统换掉，所以为了保证系统仍然可用，要启用数据同步机制，让服务里的数据同步到原有数据库。
　　渐进替换。通过不断地运行以上策略，将原有系统的复杂功能抽离出来用新的方式来做。
　　目前，每签一个10万的合同所耗费的成本由3.5天变为1天，持续集成构建从50钟降低到18分钟，团队成员从10人降到7人，部署周期由3天降到2小时。
　　对于每个应用程序，可能有一组小的服务组成，每个服务运行在自己的进程中，服务与服务之间通过轻量级的机制进行交互。那么，如何使用微服务做系统改造呢？
　　为每个服务建立独立的环境，包括基础设施、持续集成环境、运维、监控、日志聚合、报警。
　　不断演进的微服务开发模板，发现问题及时修改，让模板更高效。
　　轻量级的协议。
　　消费者的契约测试，解决随着服务增多带来集成测试效率低的问题。
　　基础设施自管理，帮助管理自己需要的资源。
　　Container为微服务带来了什么？
　　七牛云CTO 韩拓从服务端的架构和运维两个方面介绍了Container和微服务带来的价值。他认为Container是基于内核的空间。一个的内核主要管理资源，把交给操作系统的内核，它把内存、CPU和硬盘等资源管理起来。Container进一步做隔离，这个隔离以进程为单位，让一个进程只能看到这个网卡收发的数据，但是看不到其他的网卡。
　　Container有以下几个名字空间。
　　网络的空间，它隔离了和网络相关的资源，如服务器上的网卡、IP地址、服务表等，之后这个进程在某个网络的空间内运行就看不到其他空间相关的网络资源。
　　文件系统，这个名字空间把这类资源也进行了隔离。一个进程运行时看到的根目录可能不是操作系统原生的根目录，看到的块设备也不是原来的块设备。
　　PID，每运行一个进程都有一个PID，现在内核里的名字空间，PID的资源也被隔离起来。
　　Container对系统调用做了权限的控制。例如一个进程启动的时候限制它的权限，让很多系统调用做不了。Container的作用包括镜像管理和运行实例的管理，还有输入输出的管理。
　　那么，Container对服务端架构有什么影响呢？
　　七牛CTO韩拓认为不管做什么架构，很重要的工作是换，去定义这个模块的边界，怎么工作、怎么测试及在生产环境如何部署。因此，从组件的角度看微服务化主要有以下三点。
　　组件划分的方式，Container以功能为单位来划分组件的边界。
　　组件物理边界，以前的边界有静态或动态的库，模块间的边界通常是函数调用。而微服务组件的物理边界是网络，这些组件都是独立的、可编译的进程(即每个单独的服务实例)，这些服务实例之间通过网络来沟通。
　　组件的依赖方式，以前是在编译期考虑怎么才能把ESC编译出来，只要编译出来，就能肯定依赖关系肯定被解决了。当微服务化之后，依赖方式的处理被延后了，延后到运行的时候，因此错误被延后了，组件间的依赖方式变复杂了。Container中组件间的依赖可通过渲染文件和环境变量等实现。
　　关于Container对运维的影响，主要是告别DevOps。作为勇敢的DevOps实践者，七牛认为，DevOps的核心是试图寻找一个合理的开发和运维的边界。有很多方法论寻找这个边界，DevOps是其中一种，主要将运维平台化，做监控平台、日志平台等。
　　在持续集成方面，以前的任何一行代码做了更变都要把整个业务重新做一遍，需要很长时间。微服务化之后，每个模块独立编译、独立打包、独立测试，其边界也很明确，代码的变更影响的是一个组件和服务，单独进行编译和测试的动作会很快。
　　部署和升级方面变得简单，可以独立地部署和升级。
　　资源规划方面，按峰值申请资源会存在资源浪费。微服务化后，可以按模块去扩容。对资源的规划更灵活和合理。尤其再结合Container，因为Container以进程为单位，它对资源的使用是竞争的，不需要提前规划。
　　网络方面，Container一般通过端口映射的方式做网络。
　　监控方面，业务的运行状态对运维来讲更透明，小的服务可以单独监控，一些问题出来之后可以做报警。但监控变多了，需要监控系统更智能。
　　最后在高可用方面，传统的架构会做成透明的。现在，高可用由外部的框架完成，例如在做服务间依赖时就可以做高可用，不仅屏蔽了服务在哪里，服务了多少人，而且还可以把服务是死是活的细节屏蔽掉。
　　Micro Service，Continuous Delivery and Docker
　　DaoCloud联合创始人&研发副总裁郭峰认为容器技术解决了原来PaaS技术不能解决的问题。于是他给大家展示了微服务带来的挑战，即如果将一个应用微服务化，那么很容易导致一台机器上跑很多程序。因为服务纠缠在一起，所以微服务需要运用自包含。DaoCloud的容器技术是把最古老的几个技术融合在一起，用了一个很方便的脚本化的工具，让大家用起来。它提供了标准化的镜像，不仅方便地用容器，而且可以方便地发布容器。
　　容器和虚拟机是什么关系呢？虚拟机有物理环境、有操作系统，但容器下面是server，上面跑应用程序和库，这样的架构使得容器的性能比虚拟机好很多。首先没有虚拟机的过程，直接把跑内核的进程跑到上。别人想发一个微服务，可以利用在镜像上面加一层，即使有很多镜像，有时多个镜像会一起依赖，会省资源和容量。那么，为什么容器是轻量级的？因为它只有应用和应用的依赖所打成的包，如果应用做了一点点修改，不需要完全打一个，在原有的运用上打一个补丁，把修改记下来即可。
　　上图是Docker的流程图， Dockerfile这个镜像可以运行在本机。在上面运行容器，等容器开发好并且测试通过了再把这个容器push到镜像仓库上。任何一个人都可以从镜像仓库上下载，下载后，Docker运行一套命令让行为一致。重要的是，Docker官方维护了DockerHA，所以Docker允许以镜像的方式发布Container，发布的Container像未来的VM，这个VM很轻量，大家可以把它pull下来，不管用什么物理硬件资源，都可以让Docker运行起来，而且运行结果和其他没有差别。Docker是如何做到自包含的呢？ Docker的自包含是它容器的本身包括了OS的版本，以及依赖的环境和客户，所有的都描述成Dockerfile。Docker可以帮助两类人――开发人员和运维人员，它跨越了开发和运维间的那道鸿沟。
　　仅仅自包含就做微服务是不够的，微服务要求把之前大系统的问题为很多简单的小问题，然后将每个简单的小问题用最合适的技术实现。但这导致现在有很多小应用，原来靠人工可以解决的事现在解决不了，比如做CI(持续集成)/CD(持续交付)。微服务化以后，会导致一个的应用CI很难做。
　　此外，他还向大家介绍了Docker的法宝。第一个是Docker Compose，如果应用不是单应用可以用同一方法描述应用和应用的依赖，然后上线。第二个是Volumes，可以共享文件。最后一个是环境变量，不管是微服务和微服务之间的依赖以及微服务运行时的依赖的环境变量也好，还是端口也好，都描述清楚，定义好后给运维人员。这是可复制的迭加过程，不仅把代码和运行做自包含变成一个镜像，而且镜像用运行的方式提供出来。运维人员不需要关心应用内部的逻辑，只需要关心模块的镜像以及如何将镜像运行起来，这样可以大大地减少运维成本。
　　Docker的应用与实践
　　来自京东的资深架构师季锡强分享了Docker的应用与实践。主要讲了Docker的系统整体架构及其技术实现、镜像部分、Container启动流程，还介绍了制作镜像命令的原理以及volume挂载的原理。
　　他为大家介绍了Docker的组件，Docker真正的实现主要是几个组件组成，第一层是镜像存储的模块，实现有很多种，比如device mapper、aufs以及btrfs。第二层是exec driver，主要是libcontainer及lxc。第三层是network driver，主要是主机以及网络命名空间，而Namespace支持ipc、mnt、pid、net、uts及user。组件CGroup主要做资源控制，涉及的方面有CPU、IO，IO可以不依赖于Namespace单独使用，和操作文件一样改一下值就可以。CGroup的限制主要是通过子系统来实现，相应的模块有IO、CPU等。而组件Device Mapper的实现有DM C thin provision。
　　上图是启动容器的流程。启动的命令请求首先会把设备mount到指定的挂载点上访问。启动go monitor会带着参数启动里面的命令，接下来会用Dockerinit做初始化，最终命令会进行系统调用，再exec执行。停止容器则比较粗暴，相当于Docker根据PID直接将容器中的进程杀掉，再做一些资源的释放，这样就完成了停止容器的流程。Docker启动的时候，如果Docker是意外死掉的(人为或者程序的破坏)，那么之前的程序不会消失，这时候Docker会把所有的容器kill掉，会把之前容器创建的操作信息保存在Docker的目录下。Docker将所有的容器都kill掉后，资源会被释放，这个时候就会触发一个永久性的bug。因为当容器重启的时候，会检查mount count，这个初始化的值是0，而Docker死掉后重启则会发现mount count不为0，所以会导致mount失败，导致出错;这个时候我们想启动容器的话，关键的动作是把设备释放并重新挂载到mount下。因此，告诫大家，如果Docker异常死掉了，要及时清理资源。
　　关于制作镜像的原理，你可以建立一个镜像生成一个容器，这个镜像可以分到某一个文件目录下，可以做一些直接的操作。首先mount上去，镜像原来的版本也会mount上去，遍历所有的文件看两者之间的状态是否有变化，然后打包，产生diff。这时要创建新的容器，因为已经获得了diff，接下来要创建一个新的镜像。创建新的镜像之前要拿到Container的基本镜像，这时要把这个镜像mount，就可以看到所有的文件。最后的操作是解压一个文件到一个新的snapshot，就相当于有一个新的镜像了。
　　最后，他对Docker做了一些总结，Docker主要用到CGroup的一部分子系统;Docker启动和停止之间有一个大Bug需要及时关注;commit要打包、解压文件，机器很高的时候commit会相当耗时。
　　以上是牛小七对本期开发者最佳实践日内容的概括性介绍，如需获取详细的演讲信息和往期内容回顾，可以访问活动专题。
　　「开发者最佳实践日」是由七牛发起并联合各方小伙伴为开发者举办的系列技术沙龙，关注开发者在实际应用中可能遇到的技术问题。于为勇于创新的开发者们提供行业内最前沿最热门的技术干货，以技术驱动应用创新，让更多的开发者享受技术带来的生活乐趣。
[ 责任编辑：凤城 ]
新经济、新业态环境下，数据量呈…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注ChinabyteShare on Twitter
Share on Google
Share on Facebook
Share on Weibo
Share on Instapaper
开始使用 Docker Hub
本节讲述了 Docker Hub 的快速入门,包括如何创建一个账户。
Docker Hub 存放着 Docker 及其组件的所有资源。Docker Hub 可以帮助你与同事之间协作，并获得功能完整的 Docker。为此，它提供的服务有：
Docker 镜像主机
用户认证
自动镜像构建和工作流程工具，如构建触发器和 web hooks
整合了 GitHub 和 BitBucket
为了使用 Docker Hub ,首先需要注册创建一个账户。别担心，创建一个账户很简单并且是免费的。
创建 Docker Hub 账户
这里有两种访问可以创建和注册一个 Docker Hub 账户：
1.通过网站，或者
2.通过命令行
通过网站注册
填写，选择您的用户名和密码并指定您的电子邮箱。你也可以报名参加 Docker 邮件列表，会有很多关于 Docker 的信息。
通过命令行
你可以通过使用命令行输入 docker login 命令来创建一个 Docker Hub 账号
$ sudo docker login
邮箱确认
一旦你填写完毕表格，请查看你的电子邮件，通过点击欢迎信息中的链接来激活您的账户。
登陆
在完成确认过程之后，您可以使用web控制台登陆
或者通过在命令行中输入 docker login 命令来登录：
$ sudo docker login
你的 Docker 账户现在已经生效，并随时可以使用。
下一步
下一步，让我们开始学习如何在 Docker 中运行 &hello word& 的应用。
阅读7-腾讯Gaia平台的Docker应用实践_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
7-腾讯Gaia平台的Docker应用实践
上传于||暂无简介
阅读已结束，如果下载本文需要使用2下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩16页未读，继续阅读
你可能喜欢深入理解docker graph driver - DeviceMapper (0/3) - 推酷
深入理解docker graph driver - DeviceMapper (0/3)
进入正题之前
首先思考个问题， Docker 并非第一个 Linux 容器解决方案，早在 Docker 之前就有 Warden 以及 LXC 等开源项目，为什么它们没这么火，无非都是上层包装和使用内核的 ns 以及 cgroup ，个人认为 Docker 在功能性上要比这两个项目走的更远一点， warden 或者 lxc 总体上所做的工作相对简单，基于这两个开源项目去 lanuch 一个容器，开发者需要做大量的工作，包括准备 / 制作 / 发布镜像等。而这些工作 Docker 已经帮你做好了，个人认为 Docker 最大的卖点在于类似 git 一样的镜像版本管理和发布，而这部分实现的基础在于 graphdriver 。
graph driver
这个事情我们要从头讲起 ...
所谓容器是什么，其实不过是一个普通进程，这个进程的特殊之处在于：
1 ）它可能是位于不同命名空间（ ns ）的 , 使进程加入不同的命名空间无非是使用 clone/unshare/setns 系统调用的其中一个，这个我们后续文章详细说明
2 ）它对资源的使用（ cpu,memory,diskio 等）可能受到 CGroup 资源控制的限制
封装这部分工作的逻辑在 docker 代码里命名是 execdriver ，具体实现可以是 libcontainer(native 方式 ) 或者 lxc
这个普通进程通过 execdriver 运行起来后如果希望他看起来像一个操作系统，那么我们需要一个 rootfs ，这个 rootfs 实际就是 linux 下 /dev,/usr,/lib,/bin,/etc 等文件目录结构，把这些东西打个包就是我们所说的镜像， Docker 的 graphdriver 负责镜像本地的管理和存储以及对运行中的容器生成镜像等工作。
这个有一个比较重要的问题，如果一台机器上运行 100 个这样的容器进程，每个进程用的是同一个 rootfs ，每个容器运行过程中可能对这个 rootfs 有各自的修改 , 比如改个 /etc 下的配置，装个可执行文件到 /bin 目录，每个进程都是这样的小修改 , 如果在主机上存储 100 份这个 rootfs 的拷贝，那么存储空间的浪费是巨大的，这时我们会希望系统只保存一份 rootfs ，然后每个容器共享这个拷贝，如果某个容器需要修改，则能够通过 CoW 机制只保存该容器修改的部分，之后针对这个容器如果需要生成镜像，则只需要计算和保存修改的部分与原有 rootfs 的差异，这样通过层层叠加的方式来管理整个镜像系统。实际上 docker 的 graphdriver 里面除了 vfs 外的其它驱动都是按这个方式工作的。
graph driver
Docker 提供的 graphdriver 主要有 btrfs,aufs,overlayfs(3.18 以上 kernel 支持 ),devicemapper,vfs
我们逐个分析下：
btrfs 文件系统本身支持快照功能，可以实现我们的需求，但是 btrfs 本身貌似目前还没有 productionready
aufs 文件系统是叠合文件系统，专门为了解决这种问题而生，可惜因为代码质量问题，一直被 linus 拒之门外，这样在很多发行版里都不会默认安装，用户使用需要自己编译对非 kernel 维护人员来说也比较麻烦。
overlayfs 文件系统也是叠合文件系统，但是需要 3.18 以上 kernel 版本，目前貌似 stable 的主流 Linux 发行版都还没到这个内核版本
结论是如果没有自己的 kernel 团队，那么目前唯一的选择似乎就是 devicemapper 了。
device mapper
简单的说 devicemapper 是位于内核通用块 blocklayer 部分的一个抽象层，帮助上层完成一些 IO 策略的灵活定制，在内核 IO 协议栈的层次关系如图：
实际上 devicemapper 相当于帮你做好了一个虚拟块设备，盘符路径是在 /dev/mapper/ 下，然后你来写一段内核代码，这段代码来定制你这个虚拟块设备的 IO 行为，这段代码模块就是 devicemapper target ，而 devicemapper 本身相当于一个框架，当然内核本身已经用这个框架实现了一些 target ，比如 dm-raid1 镜像 target 可以帮你完成设备的软 raid1 ， dm-snap 可以完成设备的快照，我们后续用的的也是内核实现好的 target ，分别是 dm-thin 和 dm-pool ，另外早期 facebook 开源的 flashcache 也是基于 devicemapper 开发。
现在我们来梳理下 dm 这个框架做的事情，逻辑如图：
devicemapper 设备在内核里通过 mapped_device 数据结构标识，代表一个虚拟的块设备，上层的读写请求进入 blocklayer 后会转变成 bio 数据结构，跟据所写的设备盘符找到相应的 mapped_device ，然后根据所写入 bio 的扇区信息查找一个叫 dm_table 的数据结构，该数据结构维护一个设备 IO 信息映射表，简单的说就是类似从多少扇区到多少扇区应用什么规则，而这个规则就是 dm_target ，我们具体写一个 dm 的 target 时就是来填充这个 dm_target （具体里面有一个 target_type 的数据结构，提供众多回调方法来灵活处理 bio ）提供的一些回调方法，之后上层的请求过来就可以按我们的规则完成指定的动作了。
最终我们的代码通过不同返回值来告知 dm
框架是否已处理完这个 bio
，如果处理完则框架会向上层返回 io
处理结果，或者我们可以通过修改 bio
的设备信息和扇区信息来完成 io
的重定向，也就是 remap
篇幅所限先写到这里，该篇整体算是一个引言，内容相对粗浅，后续会由浅入深
后续系列文章预告：
深入理解 DockerGraph Driver dm thin 及 thin-pool 的故事 (1/3)
深入理解 DockerGraph Driver docker dm 设备的使用与缺陷 (2/3)
深入理解 DockerGraph Driver overlayfs - dentry 的游戏 (3/3)
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
没有分页内容
图片无法显示
视频无法显示
与原文不一致