持续交付的Mesos与Docker导入篇

变革这个词在当今的数字化时代司空见惯,IT技术每过一段时间就会有一起革新,从WEB2.0、虚拟化、云计算、大数据、微架构、DevOps再到今天的容器Docker与Mesos。

Docker的出现方便了应用的测试、部署、与升级,其将各种应用程序和它们所依赖的运行环境打包成标准的Container/Image,进而发布到不同的平台上运行。Docker的轻量级、快速部署、迁移方便的特性促进了DevOps的落地,借用容器,开发人员可以很方便的融入到产品的交付流程当中。

Mesos是软件定义数据中心的最佳实践,其理念用最通俗的话来讲就是,让运维人员操作数据中心就算操作一台服务器一样去操作,将数据中心中的CPU、内存、存储等资源统一在一台服务器内进行调度与管理。听起来非常的高大上,如果用技术化的语言来描述,Mesos是这样定义的,统一的集群资源管理与调度平台,将生产环境中的各种服务框架,部署在一个公共的集群中,共享集群中的资源,由Mesos对资源进行统一调度,提供给服务框架使用。Mesos的出现给IaaS、PaaS以及运维的管理提供了极大的便利。

在实践中,Mesos与Docker是最佳的伴侣,前者提供了资源的统一管理,后者实现了资源的隔离使用,有合有分,在不同的层次发挥着不同的效能。同时,Mesos与Docker又都有自己的技术生态圈,两者的生态圈又都相互的促进和推动。

§Marathon保证Mesos上的服务长期运行的框架,确保运行在Mesos上的服务一直运行,某台Mesos主机发生故障时自动迁移到其他服务器。

§Chronos服务循环运行作业调度框架,可以设定反复在特定的时间触发运行Mesos中的服务

§Mesos-DNS针对Mesos的基于DNS的服务发现机制,可以方便的发现容器运行位置,并进行管理调度

§Kubernetes集群级别的容器编排管理系统,能方便的管理跨集群运行的容器化应用,提供容器调度、部署、服务发现、扩展机制等功能

§Swarm用于创建Docker主机(运行Docker守护进程的服务器)集群的工具,使用Swarm操作集群,会使用户感觉就像是在一台主机上进行操作。

Mesos与Docker这对最佳伴侣为应用的持续交付带来了极大的便利,为应用的运维管理提供了很大的方便,两者在持续交付的解决方案中都起着至关重要的作用,如下图展示了Mesos与Docker在应用持续交付中的实践。其具体的过程可以描述如下:

o开发人员根据产品的需求进行代码的实现,将实现的代码提交到Git/SVN等代码管理仓库;

o测试人员通过Jenkins/Hudson等持续集成工具,对代码进行编译、打包、集成等,将代码打包成DockerImage提交到Docker镜像仓库;

o测试人员通过Mesos资源调度和Marathon平台,用新的DockerImage部署测试环境,测试人员在测试环境中对产品需求功能进行验证。如果不符合验证反馈给开发人员,由开发人员继续修正,如果已经符合要求会通知运维人员将代码部署到预发布或生产环境;

o运维人员接到测试已经验证通过的通知后,会利用新发布的Docker Image,将其部署到由Mesos调度管理的生产环境中;

o在生产环境运行过程中,运维人员可以通过Marathon等平台对环境进行一下业务的扩容及缩容操作,甚至一些故障的自动恢复等管理。

Mesos与Docker交付中应用案例

上述过程描述是基于比较传统标准的组织架构型的公司来描述的,有清晰角色分工的开发、测试、运维等角色人员;有部分公司已经实践DevOps的管理方式,开发运维合二为一,组织架构中的角色分工更简单简洁,其利用Mesos、Docker实现的持续交付过程会有一些大同小异,其具体的操作过程还是一样的,只是操作的人可能不同。

Mesos与Docker的出现应用快、持续、自动化的交付的落地消除了很多的屏障,带来了极大的便利。IT技术就是日新月异,我们能够选择的只有不断积极的拥抱。明天会更好,本篇是我们应用持续交付系列文章的导入篇,在后续会根据实践不断更新此系列,一起加速互联网敏捷运维。

时间: 11-08

持续交付的Mesos与Docker导入篇的相关文章

基于容器的持续交付管道

基于容器的持续交付管道 在过去的几篇d4d系列中,我给大家介绍了如何使用docker来支持asp.net core的应用开发,打包的场景.Asp.net core的跨平台开发能力为.net开发人员提供了使用容器进行应用开发的能力,今天这篇文章将对如何使用微软的全生命周期管理平台VSTS/TFS来构建基于容器的CI/CD管道来支持团队开发的场景. #1 前世今生 & 世界你好#2 容器化主机#3 在macOS上使用Visual Studio Code和Docker开发asp.net core和my

云端基于Docker的微服务与持续交付实践

云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Swarm Docker Swarm mode 微服务支持(Docker集群架构体系) Docker的发展趋势和前沿成果 在Docker技术方面还是很佩服大牛的,所以赶紧写下笔记,追随大神的脚步. 阿里云资深专家易立,技术就不说了,他比其他直播间硬生生多讲了半个多点,于情于理还是万分感谢本次分享的(可惜devOp

运维与持续交付

在互联网的产品开发时代,产品迭代越来越频繁,"从功能开发完成直到成功部署"这一阶段被称为软件开发"最后一公里". 对于持续部署,@湾区日报 这样评论: 一个团队工程技术水平高低,直接反映在部署代码上.我碰到其他公司的人,都喜欢问你们怎么部署代码的,非常大开眼界.你很难相信,很多(有一定规模的)公司仍然是人肉 SSH 到十几.二十台机器上 git pull.手动重启服务器,部署一次代码几个小时 -- 这么原始,活该加班:) 持续部署(continuous deploy

[转载]持续交付和DevOps的前世今生

作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新概念风起云勇的时代. 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”... ... OK,就这四个啦: “敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”. 先让我们在Wikiped

OpenShift中的持续交付

上一文中讲述了如何在AWS下搭建OpenShift集群.这篇文章将目光转向如何在OpenShift中实现CI/CD以及产品环境的部署. 持续交付 如果要打造一个持续交付的流水线,首先要考虑多环境的问题.一般一个应用程序会有多个环境,比如开发环境.集成测试环境.系统测试环境.用户验收测试环境.类生产环境.生产环境.如何在OpenShift中隔离并建立对这些环境的部署流程有多种方案可以选择. 同一个project中使用label和唯一名称来区分不同的环境: 集群中的不同project来隔离环境: 跨

持续集成(二)工具搭建篇—内网邮件服务器搭建

在我们的持续构建中,项目构建中出现错误提醒,或者开发人员之间的沟通交流,进度汇报的事务,都是离不开一个通信工具,那就是邮件.在我们的项目开发中如果使用第三方的邮件平台,这肯定不是最好的选择,因为第三方的邮件需要外网的支持,但是外网又不是特别的可靠,假如外网链接出现了问题,这样就会不必要的延误我们的工期.再或者很多项目都是保密项目,在开发中只能用内网.但是不用邮件吧又不行.为了解决这个头疼的问题,我们的内网邮件服务器工具就出现了,只要用它安装在我们的服务器上,配置好账户,配置好客户端,在内网里就可

[持续交付实践] 基于 sonarqube 的代码检查平台实现

前言 公司此前用的一直是的SonarQube5.1(2015年版本,为兼容jdk6和jdk7的项目一直没有升级),最近为了pipeline的集成刚刚升级到了最新的SonarQube6.5版本.网上对SonarQube6的介绍比较少,这里重点先介绍下SonarQube6以后的一些新增特性.1.代码问题重新分级,将问题分为bug.漏洞.坏味道:将代码检查结果从可靠性.安全性.可维护性几个角度进行问题分类和风险分级.2.更丰富的代码检查规则,更友好的问题处理曲线展示,更清晰的质量阈和代码规则定制.3.

CI(持续集成)CD(持续交付)

持续集成实践: 1.保持单一代码仓库 2.自动化构建项目 3.使项目拥有自测试的能力 4.成员每天上传代码 5.每次上传需要在集成机上构建主线项目 6.立即修复出错的构想流程 7.保证构建效率 8.将项目克隆,在产品环境下测试 9.让可执行文件简单易得 10.每个人可以看到过程 11.自动化部署 持续交付:  ——————————DeploymentPipeline 1.持续集成软件 2.构建可执行文件 3.执行自动化测试 4.可执行文件产品化(接近产品上线级别)

持续交付之三——持续集成

其他持续交付相关文章:<持续交付>系列文章目录 第三章 持续集成 1. 引言 持续集成的目标是让软件一直处于可工作的状态 2. 实现持续集成 2.1. 准备工作 版本控制 自动化构建 团队共识 2.2. 一个基本的持续集成系统 开发人员使用持续集成服务的简单流程 查看一下是否有构建正在运行,如果有的话,等它完事,如果它失败了,就和团队的其他人把他一起修复,然后再提交代码 一旦构建完成且测试完全通过,就从版本控制库中将该版本的代码更新到自己的开发环境上 在自己的开发机上执行构建脚本,运行测试,以