Docker

使用Wercker进行持续构建与发布

本文介绍了wercker和它的基本用法,并用我GitHub上的magpie应用作为示例,讲解如何给GitHub项目增加wercker构建流程,并将生成的镜像自动上传到Docker Hub上。 注:本文参考了Cloud Native Go书中的”持续交付“章节。 CI工具 开源项目的构建离不开CI工具,你可能经常会在很多GitHub的开源项目首页上看到这样的东西: 这些图标都是CI工具提供的,可以直观的看到当前的构建状态,例如wercker中可以在Application-magpie-options中看到: 将文本框中的代码复制到你的项目的README文件中,就可以在项目主页上看到这样的标志了。 现在市面上有很多流行的CI/CD工具和DevOps工具有很多,这些工具提高了软件开发的效率,增加了开发人员的幸福感。这些工具有: 适用于GitHub上的开源项目,可以直接使用GitHub账户登陆,对于公开项目可以直接使用:Travis-ci、CircleCI、Wercker。从目前GitHub上开源项目的使用情况来看,Travis-ci的使用率更高一些。 适用于企业级的:Jenkins 不仅包括CI/CD功能的DevOps平台:JFrog、Spinnaker、Fabric8 Wercker简介 Wercker是一家为现代云服务提供容器化应用及微服务的快速开发、部署工具的初创企业,成立于2012年,总部位于荷兰阿姆斯特丹。其以容器为中心的平台可以对微服务和应用的开发进行自动化。开发者通过利用其命令行工具能够生成容器到桌面,然后自动生成应用并部署到各种云平台上面。其支持的平台包括Heroku、AWS以及Rackspace等。 Wercker于2016年获得450万美元A轮融资,此轮融资由Inkef Capital领投,Notion Capital跟投,融资所得将用于商业版产品的开发。此轮融资过后其总融资额为750万美元。 Wercker于2017年4月被Oracle甲骨文于收购。 为什么使用Wercker 所有的CI工具都可以在市面上获取,但为何要建议使用Wercker呢?依据云之道的准则评估了所有工具,发现Wercker正是我们需要的。 首先,无须在工作站中安装Wecker,仅安装一个命令行客户端即可,构建过程全部在云端进行。 其次,不用通过信用卡就可使用Wercker。当我们迫切希望简化流程时,这是一件令人赞叹的事。付款承诺这一条件大大增加了开发者的压力,这通常是不必要的。 最后,Wercker使用起来非常简单。它非常容易配置,不需要经过高级培训或拥有持续集成的博士学位,也不用制定专门的流程。 通过Wercker搭建CI环境只需经过三个基本步骤。 1.在Wercker网站中创建一个应用程序。 2.将wercker.yml添加到应用程序的代码库中。 3.选择打包和部署构建的位置。 如何使用 可以使用GitHub帐号直接登录Wercker,整个创建应用CI的流程一共3步。 一旦拥有了账户,那么只需简单地点击位于顶部的应用程序菜单,然后选择创建选项即可。如果系统提示是否要创建组织或应用程序,请选择应用程序。Wercker组织允许多个Wercker用户之间进行协作,而无须提供信用卡。下图为设置新应用程序的向导页面。 选择了GitHub中的repo之后,第二步配置访问权限,最后一步Wercker会尝试生成一个wercker.yml文件(后面会讨论)。不过至少对于Go应用程序来说,这个配置很少会满足要求,所以我们总是需要创建自己的Wercker配置文件。 安装Wercker命令行程序 这一步是可选的,如果你希望在本地进行wercker构建的话才需要在本地安装命令行程序。本地构建和云端构建都依赖于Docker的使用。基本上,代码会被置于所选择的docker镜像中(在wercker.yml中定义),然后再选择执行的内容和方法。 要在本地运行Wercker构建,需要使用Wercker CLI。有关如何安装和测试CLI的内容,请查看http://devcenter.wercker.com/docs/cli。Wercker更新文档的频率要比本书更高,所以请在本书中做个标记,然后根据Wercker网站的文档安装Wercker CLI。 如果已经正确安装了CLI,应该可以查询到CLI的版本,代码如下所示。 Version: 1.0.882 Compiled at: 2017-06-02 06:49:39 +0800 CST Git commit: da8bc056ed99e27b4b7a1b608078ddaf025a9dc4 No new version available 本地构建只要在项目的根目录下输入wercker build命令即可,wercker会自动下载依赖的docker镜像在本地运行所有构建流程。 创建Wercker配置文件wercker.yml Wercker配置文件是一个YAML文件,该文件必须在GitHub repo的最顶层目录,该文件主要包含三个部分,对应可用的三个主要管道。 — Dev:定义了开发管道的步骤列表。与所有管道一样,可以选定一个box用于构建,也可以全局指定一个box应用于所有管道。box可以是Wercker内置的预制Docker镜像之一,也可以是Docker Hub托管的任何Docker镜像。 — Build:定义了在Wercker构建期间要执行的步骤和脚本的列表。与许多其他服务(如Jenkins和TeamCity)不同,构建步骤位于代码库的配置文件中,而不是隐藏在服务配置里。 — Deploy:在这里可以定义构建的部署方式和位置。 Wercker中还有工作流的概念,通过使用分支、条件构建、多个部署目标和其他高级功能扩展了管道的功能,这些高级功能读着可以自己在wercker的网站中探索。 示例 我们以我用Go语言开发的管理yarn on docker集群的命令行工具magpie为例,讲解如何使用wercker自动构建,并产生docker镜像发布到Docker Hub中。

Cloud Native Go - 基于Go和React的web云服务构建指南

(题图:北京植物园桃花 Mar 26,2016) Kevin Hoffman和Dan Nemeth著的《Cloud Native Go - 基于Go和React的web云原生应用构建指南》将由电子工业出版社出版。 简介 Cloud Native Go向开发人员展示如何构建大规模云应用程序,在满足当今客户的强大需求的同时还可以动态扩展来处理几乎任何规模的数据量、流量或用户。 Kevin Hoffman和Dan Nemeth详细描述了现代云原生应用程序,阐明了与快速、可靠的云原生开发相关的因素、规则和习惯。他们还介绍了Go这种“简单优雅”的高性能语言,它特别适合于云开发。 在本书中你将使用Go语言创建微服务,使用ReactJS和Flux添加前端Web组件,并掌握基于Go的高级云原生技术。Hoffman和Nemeth展示了如何使用Wercker、Docker和Dockerhub等工具构建持续交付管道; 自动推送应用程序到平台上; 并系统地监控生产中的应用程序性能。 学习“云之道”:为什么开发好的云软件基本上是关于心态和规则 了解为什么使用Go语言是云本地微服务开发的理想选择 规划支持持续交付和部署的云应用程序 设计服务生态系统,然后以test-first的方式构建它们 将正在进行的工作推送到云 使用事件源和CQRS模式来响应大规模和高吞吐量 安全的基于云的Web应用程序:做与不做的选择 使用第三方消息传递供应商创建响应式云应用程序 使用React和Flux构建大规模,云友好的GUI 监控云中的动态扩展,故障转移和容错 章节简介如下图。 关于作者 Kevin Hoffman通过现代化和以多种不同语言构建云原生服务的方式帮助企业将其应用程序引入云端。他10岁时开始编程,在重新组装的CommodoreVIC-20上自习BASIC。从那时起,他已经沉迷于构建软件,并花了很多时间学习语言、框架和模式。他已经构建了从遥控摄影无人机、仿生性安全系统、超低延迟金融应用程序到移动应用程序等一系列软件。他在构建需要与Pivotal Cloud Foundry配合使用的自定义组件时爱上了Go语言。 Kevin 是流行的幻想书系列(*The Sigilord Chronicles*,http://amzn.to/ 2fc8iES)的作者,他热切地期待着最终能够将自己对构建软件的热爱与对构建幻想世界的热爱结合起来。 Dan Nemeth目前在Pivotal担任咨询解决方案架构师,负责支持Pivotal Cloud Foundry。他从Commodore 64开始就一直在开发软件,从1995年起开始专业编码,使用ANSIC编写了用于本地ISP的CGI脚本。从那时起,他职业生涯的大部分时间里是作为独立顾问为从金融到制药行业提供解决方案,并使用当时流行的各种语言和框架。Dan最近接受了Go作为自己的归宿,并热情地将它用于所有的项目。 如果你发现Dan没在电脑前,他很可能就是在靠近安纳波利斯的水域玩帆船或飞钓。 下面先罗列下目录,以飨读者。 目录 云之道.. 1 云之道的优点.. 2 遵循简单.. 2 测试优先,测试一切.. 3 尽早发布,频繁发布.. 5 自动化一切.. 6

容器技术在大数据场景下的应用——Yarn on Docker

作者:宋净超 TalkingData云计算及大数据工程师 前言 我已就该话题已在2016年上海Qcon上发表过演讲,点此观看。 另外InfoQ网站上的文字版数据中心的Yarn on Docker集群方案,即本文。 项目代码开源在Github上:Magpie 当前数据中心存在的问题 数据中心中的应用一般独立部署,为了保证环境隔离与方便管理,保证应用最大资源 数据中心中普遍存在如下问题: 1.主机资源利用率低 2.部署和扩展复杂 3.资源隔离无法动态调整 4.无法快速响应业务 为何使用Yarnon Docker 彻底隔离队列  • 为了合理利用Hadoopyarn的资源,队列间会互相抢占计算资源,造成重要任务阻塞 • 根据部门申请的机器数量划分Yarn集群方便财务管理 • 更细粒度的资源分配 统一的资源分配 • 每个NodeManager和容器都可以限定CPU、内存资源 • Yarn资源划分精确到CPU核数和内存大小 弹性伸缩性服务 • 每个容器中运行一个NodeManager,增减yarn资源只需增减容器个数 • 可以指定每个NodeManager拥有的计算资源多少,按需申请资源 给我们带来什么好处?  Swarm统一集群资源调度  • 统一资源 • 增加Docker虚拟化层,降低运维成本 增加Hadoop集群资源利用率 • Fordatacenter:避免了静态资源隔离 • Forcluster:加强集群内部资源隔离  系统架构  比如数据中心中运行的Hadoop集群,我们将HDFS依然运行在物理机上,即DataNode依然部署在实体机器上,将Yarn计算层运行在Docker容器中,整个系统使用二层资源调度,Spark、Flinek、MapReduce等应用运行在Yarn上。   Swarm调度最底层的主机硬件资源,CPU和内存封装为Docker容器,容器中运行NodeManager,提供给Yarn集群,一个Swarm集群中可以运行多个Yarn集群,形成圈地式的Yarn计算集群。 具体流程 1.swarm node向swarm master注册主机资源并加入到swarmcluster中 2.swarm master向cluster申请资源请求启动容器 3.swarm根据调度策略选择在某个node上启动dockercontainer 4.swarm node的docker deamon根据容器启动参数启动相应资源大小的NodeManager 5.NodeManager自动向YARN的ResourceManager注册资源一个NodeManager资源添加完成。  Swarm为数据中心做容器即主机资源调度,每个swarmnode的节点结构如图: 一个Swarmnode就是一台物理机,每台主机上可以起多个同类型的dockercontainer,每个container的资源都有限制包括CPU、内存NodeManager容器只需要考虑本身进程占用的资源和需要给主机预留资源。假如主机是24核64G,我们可以分给一个容器5核12G,NodeManager占用4核10G的资源提供给Yarn。

Docker源码分析第一篇——代码结构

(题图:北京八达岭长城 Oct 1,2015) 前言 之前陆陆续续看过一点docker的源码,都未成体系,最近在研究Docker-17.03-CE,趁此机会研究下docker的源码,在网上找到一些相关资料,都比较过时了,发现*孙宏亮*大哥写过一本书叫《Docker源码分析》,而且之前也在InfoQ上陆续发过一些文章,虽然文章都比较老了,基于老的docker版本,但我认为依然有阅读的价值。起码能有这三方面收获: 一是培养阅读源码的思维方式,为自己阅读docker源码提供借鉴。 二是可以了解docker版本的来龙去脉。 三还可以作为Go语言项目开发作为借鉴。 下载地址 鉴于这本书已经发行一年半了了,基于的docker版本还是1.2.0,而如今都到了1.13.0(docker17.03的老版本号),应该很少有人买了吧,可以说这本书的纸质版本的生命周期也差不多了吧。如果有人感兴趣可以下载pdf版本看看,Docker源码解析-机械工业出版社-孙宏亮著-2015年8月(完整文字版,大小25.86M),Docker源码解析-看云整理版(文字版,有缩略,大小7.62M)。 Out-of-date 有一点必须再次强调一下,这本书中的docker源码分析是基于docker1.2.0,而这个版本的docker源码在github上已经无法下载到了,github上available的最低版本的docker源码是1.4.1。 顺便感叹一句,科技行业发展实在太快了,尤其是互联网,一本书能连续用上三年都不过时,如果这样的话那么这门技术恐怕都就要被淘汰了吧? 总体架构 Docker总体上是用的是Client/Server模式,所有的命令都可以通过RESTful接口传递。 整个Docker软件的架构中可以分成三个角色: Daemon:常驻后台运行的进程,接收客户端请求,管理docker容器。 Client:命令行终端,包装命令发送API请求。 Engine:真正处理客户端请求的后端程序。 代码结构 Docker的代码结构比较清晰,分成的目录比较多,有以下这些: api:定义API,使用了Swagger2.0这个工具来生成API,配置文件在api/swagger.yaml builder:用来build docker镜像的包,看来历史比较悠久了 bundles:这个包是在进行docker源码编译和开发环境搭建的时候用到的,编译生成的二进制文件都在这里。 cli:使用cobra工具生成的docker客户端命令行解析器。 client:接收cli的请求,调用RESTful API中的接口,向server端发送http请求。 cmd:其中包括docker和dockerd两个包,他们分别包含了客户端和服务端的main函数入口。 container:容器的配置管理,对不同的platform适配。 contrib:这个目录包括一些有用的脚本、镜像和其他非docker core中的部分。 daemon:这个包中将docker deamon运行时状态expose出来。 distribution:负责docker镜像的pull、push和镜像仓库的维护。 dockerversion:编译的时候自动生成的。 docs:文档。这个目录已经不再维护,文档在另一个仓库里https://github.com/docker/docker.github.io/。 experimental:从docker1.13.0版本起开始增加了实验特性。 hack:创建docker开发环境和编译打包时用到的脚本和配置文件。 image:用于构建docker镜像的。 integration-cli:集成测试 layer:管理 union file system driver上的read-only和read-write mounts。 libcontainerd:访问内核中的容器系统调用。 man:生成man pages。 migrate:将老版本的graph目录转换成新的metadata。 oci:Open Container Interface库 opts:命令行的选项库。 pkg: plugin:docker插件后端实现包。 profiles:里面有apparmor和seccomp两个目录。用于内核访问控制。 project:项目管理的一些说明文档。 reference:处理docker store中镜像的reference。 registry:docker registry的实现。 restartmanager:处理重启后的动作。 runconfig:配置格式解码和校验。 vendor:各种依赖包。 volume:docker volume的实现。 下一篇将讲解docker的各个功能模块和原理。

Contiv Ultimate-Docker17.03CE下思科docker网络插件contiv趟坑终极版

(题图:广州石牌桥 Aug 10,2014) 前几天写的几篇关于Contiv的文章已经把引入坑了😂 今天这篇文章将带领大家用正确的姿势编译和打包一个contiv netplugin。 请一定要在Linux环境中编译。docker中编译也会报错,最好还是搞个虚拟🐔吧,最好还有VPN能翻墙。 环境准备 我使用的是docker17.03-CE、安装了open vSwitch(这个包redhat的源里没有,需要自己的编译安装),如果你懒得编译可以用我编译的rpm包,点这里下载。 编译 这一步是很容易失败的,有人提过issue-779 具体步骤 创建一个link /go链接到你的GOPATH目录,下面编译的时候要用。 将源码的vender目录下的文件拷贝到$GOPATH/src目录。 执行编译 在netplugin目录下执行以下命令能够编译出二进制文件。 NET_CONTAINER_BUILD=1 make build 在你的/$GOPATH/bin目录下应该会有如下几个文件: contivk8s github-release godep golint misspell modelgen netcontiv netctl netmaster netplugin ⚠️编译过程中可能会遇到 有些包不存在或者需要翻墙下载。 打包 我们将其打包为docker plugin。 Makefile里用于创建plugin rootfs的命令是: host-pluginfs-create: @echo dev: creating a docker v2plugin rootfs ... sh scripts/v2plugin_rootfs.sh v2plugin_rootfs.sh这个脚本的内容: #!/bin/bash # Script to create the docker v2 plugin # run this script from contiv/netplugin directory echo "Creating rootfs for v2plugin ", ${CONTIV_V2PLUGIN_NAME} cat install/v2plugin/config.

Docker17.03-CE插件开发案例

(题图:杭州吴山步道旁的墙壁 Oct 16,2016) 当你看到这篇文章时,如果你也正在进行docker1.13+版本下的plugin开发,恭喜你也入坑了,如果你趟出坑,麻烦告诉你的方法,感恩不尽🙏 看了文章后你可能会觉得,官网上的可能是个假🌰。虽然官网上的文档写的有点不对,不过你使用docker-ssh-volume的开源代码自己去构建plugin的还是可以成功的! Docker plugin开发文档 首先docker官方给出了一个docker legacy plugin文档,这篇文章基本就是告诉你docker目前支持哪些插件,罗列了一系列连接,不过对不起,这些不是docker官方插件,有问题去找它们的开发者去吧😂 Docker plugin貌似开始使用了新的v2 plugin了,legacy版本的plugin可以能在后期被废弃。 从docker的源码plugin/store.go中可以看到: /* allowV1PluginsFallback determines daemon's support for V1 plugins. * When the time comes to remove support for V1 plugins, flipping * this bool is all that will be needed. */ const allowV1PluginsFallback bool = true /* defaultAPIVersion is the version of the plugin API for volume, network, IPAM and authz. This is a very stable API.

Docker 17.03-CE create plugin源码解析

(题图:故宫 Apr 3,2016) 继续上一篇Docker17.03-CE插件开发的🌰,今天来看下docker create plugin的源码。 cli/command/plugin/create.go Docker命令行docker plugin create调用的,使用的是cobra,这个命令行工具开发包很好用,推荐下。 执行这两个函数 func newCreateCommand(dockerCli *command.DockerCli) *cobra.Command //调用下面的函数,拼装成URL调用RESTful API接口 func runCreate(dockerCli *command.DockerCli, options pluginCreateOptions) error { ... if err = dockerCli.Client().PluginCreate(ctx, createCtx, createOptions); err != nil { return err } ... } 在api/server/router/plugin/plugin_routes.go中 func (pr *pluginRouter) createPlugin(ctx context.Context, w http.ResponseWriter, r *http.Request, vars map[string]string) error { ... if err := pr.backend.CreateFromContext(ctx, r.Body, options); err != nil { return err } ... } createPlugin这个方法定义在api/server/route/plugin/backen.

Docker v.s Kubernetes part2

(题图:河北承德兴隆县雾灵山京郊最佳星空拍摄点 July 9,2016) 本文是Docker v.s Kubernetes第二篇,续接上文Docker v.s Kuberntes Part1。 Kubernetes是典型的Master/Slave架构模式,本文简要的介绍kubenetes的架构和组件构成。 Kubernetes核心架构 master节点 apiserver:作为kubernetes系统的入口,封装了核心对象的增删改查操作,以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd(一个分布式强一致性的key/value存储)。 scheduler:负责集群的资源调度,为新建的Pod分配机器。这部分工作分出来变成一个组件,意味着可以很方便地替换成其他的调度器。 controller-manager:负责执行各种控制器,目前有两类: endpoint-controller:定期关联service和Pod(关联信息由endpoint对象维护),保证service到Pod的映射总是最新的。 replication-controller:定期关联replicationController和Pod,保证replicationController定义的复制数量与实际运行Pod的数量总是一致的。 node节点 kubelet:负责管控docker容器,如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的Pod,并根据Pod信息启动或停止相应的容器。同时,它也会接收apiserver的HTTP请求,汇报Pod的运行状态。 proxy:负责为Pod提供代理。它会定期从etcd获取所有的service,并根据service信息创建代理。当某个客户Pod要访问其他Pod时,访问请求会经过本机proxy做转发。 Kubernetes组件详细介绍 etcd 虽然不是Kubernetes的组件但是有必要提一下,etcd是一个分布式协同数据库,基于Go语言开发,CoreOS公司出品,使用raft一致性算法协同。Kubernetes的主数据库,在安装kubernetes之前就要先安装它,很多开源下项目都用到,老版本的docker swarm也用到了它。目前主要使用的是2.7.x版本,3.0+版本的API变化太大。 APIServer APIServer负责对外提供kubernetes API服务,它运行在master节点上。任何对资源的增删改查都要交给APIServer处理后才能提交给etcd。APIServer总体上由两部分组成:HTTP/HTTPS服务和一些功能性插件。这些功能性插件又分为两种:一部分与底层IaaS平台(Cloud Provide)相关;另一部分与资源管理控制(Admission Control)相关。 Scheduler Scheduler的作用是根据特定的调度算法将pod调度到node节点上,这一过程也被称为绑定。Scheduler调度器的输入是待调度的pod和可用的工作节点列表,输出则是一个已经绑定了pod的节点,这个节点是通过调度算法在工作节点列表中选择的最优节点。 工作节点从哪里来?工作节点并不是由Kubernetes创建,它是由IaaS平台创建,或者就是由用户管理的物理机或者虚拟机。但是Kubernetes会创建一个Node对象,用来描述这个工作节点。描述的具体信息由创建Node对象的配置文件给出。一旦用户创建节点的请求被成功处理,Kubernetes又会立即在内部创建一个node对象,再去检查该节点的健康状况。只有那些当前可用的node才会被认为是一个有效的节点并允许pod调度到上面运行。 工作节点可以通过资源配置文件或者kubectl命令行工具来创建。Kubernetes主要维护工作节点的两个属性:spec和status来描述一个工作节点的期望状态和当前状态。其中,所谓的当前状态信息由3个信息组成:HostIp、NodePhase和Node Condition。 工作节点的动态维护过程依靠Node Controller来完成,它是Kubernetes Controller Manager下属的一个控制器。它会一直不断的检查Kubernetes已知的每台node节点是否正常工作,如果一个之前已经失败的节点在这个检查循环中被检查为可以工作的,那么Node Controller会把这个节点添加到工作节点中,Node Controller会从工作节点中删除这个节点。 Controller Manager Controller Manager运行在集群的Master节点上,是基于pod API的一个独立服务,它重点实现service Endpoint(服务端点)的动态更新。管理着Kubernetes集群中各种控制节点,包括replication Controller和node Controller。 与APIServer相比,APIServer负责接受用户请求并创建对应的资源,而Controller Manager在系统中扮演的角色是在一旁旁默默的管控这些资源,确保他们永远保持在预期的状态。它采用各种管理器定时的对pod、节点等资源进行预设的检查,然后判断出于预期的是否一致,若不一致,则通知APIServer采取行动,比如重启、迁移、删除等。 kubelet kubelet组件工作在Kubernetes的node上,负责管理和维护在这台主机上运行着的所有容器。 kubelet与cAdvisor交互来抓取docker容器和主机的资源信息。 kubelet垃圾回收机制,包括容器垃圾回收和镜像垃圾回收。 kubelet工作节点状态同步。 kube-proxy kube-proxy提供两种功能: 提供算法将客服端流量负载均衡到service对应的一组后端pod。 使用etcd的watch机制,实现服务发现功能,维护一张从service到endpoint的映射关系,从而保证后端pod的IP变化不会对访问者的访问造成影响。

Docker v.s Kubernetes part1

(题图:杭州西湖 Oct 16,2016) 前言 这一系列文章是对比kubernetes 和docker两者之间的差异,鉴于我之前从docker1.10.3起开始使用docker,对原生docker的了解比较多,最近又正在看Kunernetes权威指南(第二版)这本书(P.S感谢电子工业出版社的编辑朋友赠送此书)。这系列文章不是为了比较孰优孰劣,适合自己的才是最好的。 此系列文章中所说的docker指的是*17.03-ce*版本。 概念性的差别 Kubernetes 了解一样东西首先要高屋建瓴的了解它的概念,kubernetes包括以下几种资源对象: Pod Service Volume Namespace ReplicaSet Deployment StatefulSet DaemonSet Job Docker Docker的资源对象相对于kubernetes来说就简单多了,只有以下几个: Service Node Stack Docker 就这么简单,使用一个*docker-compose.yml*即可以启动一系列服务。当然简单的好处是便于理解和管理,但是在功能方面就没有kubernetes那么强大了。 功能性差别 Kubernetes 资源限制 CPU 100m千分之一核为单位,绝对值,requests 和limits,超过这个值可能被杀掉,资源限制力度比docker更细。 Pod中有个最底层的pause 容器,其他业务容器共用他的IP,docker因为没有这层概念,所以没法共用IP,而是使用overlay网络同处于一个网络里来通信。 Kubernetes在rc中使用环境变量传递配置(1.3版本是这样的,后续版本还没有研究过) Kuberentes Label 可以在开始和动态的添加修改,所有的资源对象都有,这一点docker也有,但是资源调度因为没有kubernetes那么层级,所有还是相对比较弱一些。 Kubernetes对象选择机制继续通过label selector,用于对象调度。 Kubernetes中有一个比较特别的镜像,叫做google_containers/pause,这个镜像是用来实现Pod概念的。 HPA horizontal pod autoscaling 横向移动扩容,也是一种资源对象,根据负载变化情况针对性的调整pod目标副本数。 Kubernetes中有三个IP,Node,Pod,Cluster IP的关系比较复杂,docker中没有Cluster IP的概念。 持久化存储,在Kubernetes中有Persistent volume 只能是网络存储,不属于任何node,独立于pod之外,而docker只能使用volume plugin。 多租户管理,kubernetes中有`Namespace,docker暂时没有多租户管理功能。 总体来说Docker架构更加简单,使用起来也没有那么多的配置,只需要每个结点都安装docker即可,调度和管理功能没kubernetes那么复杂。但是kubernetes本身就是一个通用的数据中心管理工具,不仅可以用来管理docker,*pod*这个概念里就可以运行不仅是docker了。 以后的文章中将结合docker着重讲Kubernetes,基于1.3版本。

Contiv入坑指南-v2plugin

(题图:上海交通大学 Oct 22,2016) 继续趟昨天挖的坑。 昨天的issue-776已经得到@gkvijay的回复,原来是因为没有安装contiv/v2plugin的缘故,所以create contiv network失败,我需要自己build一个docker plugin。 查看下这个commit里面有build v2plugin的脚本更改,所以直接调用以下命令就可以build自己的v2plugin。 前提你需要先build出netctl、netmaster、netplugin三个二进制文件并保存到bin目录下,如果你没自己build直接下载release里面的文件保存进去也行。 编译v2plugin插件 修改config.json插件配置文件 { "manifestVersion": "v0", "description": "Contiv network plugin for Docker", "documentation": "https://contiv.github.io", "entrypoint": ["/startcontiv.sh"], "network": { "type": "host" }, "env": [ { "Description": "To enable debug mode, set to '-debug'", "Name": "dbg_flag", "Settable": [ "value" ], "Value": "-debug" }, { "Description": "VLAN uplink interface used by OVS", "Name": "iflist", "Settable": [ "value" ], "Value": "" }, { "Description": "Etcd or Consul cluster store url", "Name": "cluster_store", "Settable": [ "value" ], "Value": "etcd://172.

Contiv入坑指南-试用全记录

(题图:山东荣成滨海风力发电场 Jan 31,2017) 关于contiv的介绍请看我的上一篇文章Contiv Intro。 开发环境使用Vagrant搭建,昨天试用了下,真不知道它们是怎么想的,即然是docker插件为啥不直接在docker中开发呢,我有篇文章介绍如何搭建docker开发环境,可以在docker中开发docker,当然也可以用来开发contiv啊😄,只要下载一个docker镜像dockercore/docker:latest即可,不过有点大2.31G,使用阿里云的mirror下载倒是也划算,总比你自己部署一个开发环境节省时间。 Contiv概念解析 Contiv用于给容器创建和分配网路,可以创建策略管理容器的安全、带宽、优先级等,相当于一个SDN。 Group 按容器或Pod的功能给容器分配策略组,通常是按照容器/Pod的label来分组,应用组跟contiv的network不是一一对应的,可以很多应用组属于同一个network或IP subnet。 Polices 用来限定group的行为,contiv支持两种类型的policy: Bandwidth 限定应用组的资源使用上限 Isolation 资源组的访问权限 Group可以同时应用一个或多个policy,当有容器调度到该group里就会适用该group的policy。 Network IPv4或IPv6网络,可以配置subnet和gateway。 Contiv中的网络 在contiv中可以配置两种类型的网络 application network:容器使用的网络 infrastructure network:host namespace的虚拟网络,比如基础设施监控网络 网络封装 Contiv中有两种类型的网络封装 Routed:overlay topology和L3-routed BGP topology Bridged:layer2 VLAN Tenant Tenant提供contiv中的namespace隔离。一个tenant可以有很多个network,每个network都有个subnet。该tenant中的用户可以使用它的任意network和subnet的IP。 物理网络中的tenant称作虚拟路由转发(VRF)。Contiv使用VLAN和VXLAN ID来实现外部网络访问,这取决你使用的是layer2、layer3还是Cisco ACI。 Contiv下载 Contiv的编译安装比较复杂,我们直接下载github上的release-1.0.0-beta.3-03-08-2017.18-51-20.UTC文件解压获得二进制文件安装。 https://github.com/contiv/install/blob/master/README.md这个官方文档已经过时,不要看了。 如果试用可以的话,我会后续写contiv开发环境搭建的文章。 这个release是2017年3月8日发布的,就在我写这篇文章的前一天。有个最重要的更新是支持docker1.13 swarm mode。 官方安装文档 下载解压后会得到如下几个文件: contivk8s k8s专用的 contrib 文件夹,里面有个netctl的bash脚本 netcontiv 这个命令就一个-version选项用来查看contiv的版本😓 netctl contiv命令行工具,用来配置网络、策略、服务负载均衡,使用说明 netmaster contiv的主节点服务 netplugin 下面的安装中用到的只有netctl、netmaster和netplugin这三个二进制文件。

思科开源docker网络插件Contiv简介

(题图:北京蓝色港湾夜景 Feb 11,2017 元宵节) Contiv是思科开发的docker网络插件,从2015年就开源了,业界通常拿它和Calico比较。貌似Contiv以前还开发过volume plugin,现在销声匿迹了,只有netplugin仍在活跃开发。 容器网络插件 Calico 与 Contiv Netplugin深入比较 还有篇文章讲解了docker网络方案的改进 Contiv Netplugin 简介 Contiv Netplugin 是来自思科的解决方案。编程语言为 Go。它基于 OpenvSwitch,以插件化的形式支持容器访问网络,支持 VLAN,Vxlan,多租户,主机访问控制策略等。作为思科整体支持容器基础设施contiv项目的网络部分,最大的亮点在于容器被赋予了 SDN 能力,实现对容器更细粒度,更丰富的访问控制功能。另外,对 Docker CNM 网络模型的支持,并内置了 IPAM 接口,不仅仅提供了一容器一 IP,而且容器的网络信息被记录的容器配置中,伴随着容器的整个生命周期,减低因为状态不同步造成网络信息丢失的风险。有别于 CNI,这种内聚化的设计有利于减少对第三方模块的依赖。随着项目的发展,除了 Docker,还提供了对 Kubernetes 以及 Mesos 的支持,即 CNI 接口。 Netmaster 后台进程负责记录所有节点状态,保存网络信息,分配 IP 地址 Netplugin 后台进程作为每个宿主机上的 Agent 与 Docker 及 OVS 通信,处理来自 Docker 的请求,管理 OVS。Docker 方面接口为 remote driver,包括一系列 Docker 定义的 JSON-RPC(POST) 消息。OVS 方面接口为 remote ovsdb,也是 JSON-RPC 消息。以上消息都在 localhost 上处理。 集群管理依赖 etcd/serf

Docker技术选型

回顾历史 多少次我回过头看看走过的路,你还在小村旁。 去年基于docker1.11对Hadoop yarn进行了docker化改造,详情请看大数据集群虚拟化-Yarn on docker始末,我将这个事件命名为magpie,因为它就像是喜鹊一样收集着各种各样的资源搭建自己的小窝。magpie还是有很多事情可以做的,大数据集群的虚拟化也不会止步,它仅仅是对其做了初步的探索,对于资源利用率和管理方面的优化还有很长的路要走,Yarn本身就是做为大数据集群的资源管理调度角色出现的,一开始是为调度MapReduce,后来的spark、hive、tensrflow、HAWQ、slide等等不一而足陆续出现。但是用它来管理docker似乎还是有点过重,还不如用kubernetes、marathon、nomad、swarm等。 但是在微服务方面docker1.11的很多弊端或者说缺点就暴露了出来,首先docker1.11原生并不带cluster管理,需要配合·docker swarm、kubernetes、marathon等才能管理docker集群。之前的对于docker的使用方式基本就是按照虚拟机的方式使用的,固定IP有悖于微服务的原则。 我们基于docker1.11和shrike二层网络模式,还有shipyard来做集群管理,shipyard只是一个简单的docker集群管理的WebUI,基本都是调用docker API,唯一做了一点docker原生没有的功能就是scale容器,而且只支持到docker1.11,早已停止开发。我抛弃了shipyard,它的页面功能基本可有可无,我自己开发的magpie一样可以管理yarn on docker集群。 Docker Swarm有如下几个缺点 对于大规模集群的管理效率太低,当管理上百个node的时候经常出现有节点状态不同步的问题,比如主机重启后容器已经Exited了,但是master让然认为是Running状态,必须重启所有master节点才行。 没有中心化Node管理功能,必须登录到每台node上手动启停swarm-agent。 集群管理功能实在太太太简陋,查看所有node状态只能用docker info而且那个格式就不提了,shipyard里有处理这个格式的代码,我copy到了magpie里,彻底抛弃shipyard了。 Docker swarm的集群管理概念缺失,因为docker一开始设计的时候就不是用来管理集群的,所以出现了swarm,但是只能使用docker-compose来编排服务,但是无法在swarm集群中使用我们自定义的mynet网络,compose issue-4233,compose也已经被docker官方废弃(最近一年docker发展的太快了,原来用python写的compose已经被用go重构为libcompose直接集成到swarm mode里了),而且docker1.11里也没有像kubernetes那样service的单位,在docker1.11所有的管理都是基于docker容器的。 Docker Swarm的问题也是shipyard的问题,谁让shipyard直接调用docker的API呢。当然,在后续版本的docker里以上问题都已经不是问题,docker已经越来越像kubernetes,不论是在设计理念上还是在功能上,甚至还发行了企业版,以后每个月发布一个版本。 技术选型 主要对比Docker1.11和Docker17.03-ce版本。 首先有一点需要了解的是,docker1.12+带来的swarm mode,你可以使用一个命令直接启动一个复杂的stack,其中包括了服务编排和所有的服务配置,这是一个投票应用的例子。 下表对比了docker1.11和docker17.03-ce 版本 docker1.11 docker17.03-ce 基本单位 docker容器 docker容器、service、stack 服务编排 compose,不支持docker swarm的mynet网络 改造后的compose,支持stack中完整的服务编排 网络模型 Host、bridge、overlay、mynet 默认支持跨主机的overlay网络,创建单个容器时也可以attach到已有的overla网络中 插件 没有插件管理命令,但是可以手动创建和管理 有插件管理命令,可以手动创建和从docker hub中下载,上传插件到自己的私有镜像仓库 升级 不支持平滑升级,重启docker原来的容器也会停掉 可以停止docker engine但不影响已启动的容器 弹性伸缩 不支持 service内置功能 服务发现 监听docker event增删DNS 内置服务发现,根据DNS负载均衡 节点管理 手动启停 中心化管理node节点 服务升级 手动升级 service内置功能 负载均衡 本身不支持 Swarm mode内部DNS轮寻 基于以上对比,使用docker17.

Docker源码编译和开发环境搭建

看了下网上其他人写的docker开发环境搭建,要么是在ubuntu下搭建,要么就是使用官方说明的build docker-dev镜像的方式一步步搭建的,甚是繁琐,docker hub上有一个docker官方推出的dockercore/docker镜像,其实这就是官网上所说的docker-dev镜像,不过以前的那个deprecated了,使用目前这个镜像搭建docker开发环境是最快捷的了。 想要修改docker源码和做docker定制开发的同学可以参考下。 官方指导文档:https://docs.docker.com/opensource/code/ 设置docker开发环境:https://docs.docker.com/opensource/project/set-up-dev-env/ docker的编译实质上是在docker容器中运行docker。 因此在本地编译docker的前提是需要安装了docker,还需要用git把代码pull下来。 创建分支 为了方便以后给docker提交更改,我们从docker官方fork一个分支。 git clone https://github.com/rootsongjc/docker.git git config --local user.name "Jimmy Song" git config --local user.email "rootsongjc@gmail.com" git remote add upstream https://github.com/docker/docker.git git config --local -l git remote -v git checkout -b dry-run-test touch TEST.md vim TEST.md git status git add TEST.md git commit -am "Making a dry run test." git push --set-upstream origin dry-run-test 然后就可以在dry-run-test这个分支下工作了。 配置docker开发环境 官网上说需要先清空自己电脑上已有的容器和镜像。 docker开发环境本质上是创建一个docker镜像,镜像里包含了docker的所有开发运行环境,本地代码通过挂载的方式放到容器中运行,下面这条命令会自动创建这样一个镜像。 在dry-run-test分支下执行 make BIND_DIR=.

Docker Service Discovery

Prior to Docker 1.12 release, setting up Swarm cluster needed some sort of service discovery backend. There are multiple discovery backends available like hosted discovery service, using a static file describing the cluster, etcd, consul, zookeeper or using static list of IP address. Thanks to Docker 1.12 Swarm Mode, we don’t have to depend upon these external tools and complex configurations. Docker Engine 1.12 runs it’s own internal DNS service to route services by name.

Docker内置DNS

本文主要介绍了Docker容器的DNS配置及其注意点,重点对docker 1.10发布的embedded DNS server进行了源码分析,看看embedded DNS server到底是个啥,它是如何工作的。 Configure container DNS DNS in default bridge network Options Description -h HOSTNAME or –hostname=HOSTNAME 在该容器启动时,将HOSTNAME设置到容器内的/etc/hosts, /etc/hostname, /bin/bash提示中。 –link=CONTAINER_NAME or ID:ALIAS 在该容器启动时,将ALIAS和CONTAINER_NAME/ID对应的容器IP添加到/etc/hosts. 如果 CONTAINER_NAME/ID有多个IP地址 ? –dns=IP_ADDRESS… 在该容器启动时,将nameserver IP_ADDRESS添加到容器内的/etc/resolv.conf中。可以配置多个。 –dns-search=DOMAIN… 在该容器启动时,将DOMAIN添加到容器内/etc/resolv.conf的dns search列表中。可以配置多个。 –dns-opt=OPTION… 在该容器启动时,将OPTION添加到容器内/etc/resolv.conf中的options选项中,可以配置多个。 说明: 如果docker run时不含--dns=IP_ADDRESS..., --dns-search=DOMAIN..., or --dns-opt=OPTION...参数,docker daemon会将copy本主机的/etc/resolv.conf,然后对该copy进行处理(将那些/etc/resolv.conf中ping不通的nameserver项给抛弃),处理完成后留下的部分就作为该容器内部的/etc/resolv.conf。因此,如果你想利用宿主机中的/etc/resolv.conf配置的nameserver进行域名解析,那么你需要宿主机中该dns service配置一个宿主机内容器能ping通的IP。 如果宿主机的/etc/resolv.conf内容发生改变,docker daemon有一个对应的file change notifier会watch到这一变化,然后根据容器状态采取对应的措施: 如果容器状态为stopped,则立刻根据宿主机的/etc/resolv.