容器5大深坑莫要踩,5种实践出真知

杨y 发表了文章 • 0 个评论 • 26 次浏览 • 2017-09-13 18:52 • 来自相关话题

 

误区1:Docker是万灵药

Docker并不解决云端所有的问题,所以在容器技术中,需要对计划目标有合理地规划,若考虑采用Docker在平台中加一些特定的东西,那么请自问:目前平台有哪些衍变?若已经有了小的应用服务,可以使用Docker去解决一些问题,但不要试图让它解决全部问题。

在评估环境是否合适容器时,经常使用牛或宠物作为比喻,想要迁移到容器,需要的环境是能像对待牲口那样简单粗暴,而不是那种娇滴滴的宠物。若有一个高强度且密集的程序,并且要不断地为服务器梳理毛发(比喻,意思为比较脆弱,需要经常维护),那么就不适合迁移到容器当中。
 
误解2:Docker有明确的最佳实践

如同在其生命周期快速采用阶段的任何突破性技术一样,容器还没有一组清晰的最佳实践,本文文末将给出一个较好的实践,但仍不算最佳。

虽然并没有什么“最佳实践”,但需要知道做什么,如,早期的想法是不希望在Docker中托管一个数据库,但现在已经在Docker上运行了整个搜索引擎(又称庞大的数据库),并找到了让它工作的方法。

Docker现在充满了争议,但这不意味着要去避开它,而是做到理解前沿的新技术和所做的事情。不要害怕尝试不同的事务,需要明白它能产生的作用,如果善于思考需要解决的问题,并进行一些实践测试,可能就会学到很多适合本企业自身的知识,缺乏最佳实践可能是一种挑战,但同时也意味着可以不受限地跳出条条框框去思考,想出创造性的办法去解决老问题。

如果已经有了一个范围广泛且松散耦合的集合,就可以很好地运用容器去解决一些,但要是已经有了大量流程模式的挑战,并且应用管理方法都是非常传统的,就需要在尝试迁移之前将这些问题解决掉,在迁移到容器之前,需要致力于不可变的基础设施概念和实践。
 
误解3:Docker总是比虚拟机便宜

从某个角度去看,运行容器确实会比虚拟机要便宜,比如,有600个AWS实例,分别是1个CPU和4-5GB的RAM,那么可以使用Docker容器将其减少到100个实例,其中有32个CPU和64G的RAM,因为实例数量的减少就可以显著地降低成本。

对于一些用例来说这是正确且可行的,至少在短期内如此,但从长远角度去看,如同其他任何技术一样,也为应用容器技术花费了不少人力、物力成本,逐渐将其复杂化也带来了成本上的问题。

当大规模地运行容器时,为了方便管理容器极其资源,不得不投资管理和编排平台,就需要一个全新的技术堆栈,由于没有明确的最佳实践,可能会遇到一些反复出现的错误,造成时间和成本上的浪费。

这笔账不能简单地去通过对比其价格计算,需要大量的时间去确定优先级,并理解在运用容器需要的成本是多少。
 
误解4:容器可以像虚拟机一样

容器不仅仅是更小,更离散的虚拟机,而且也是完全独立的。所以若使用的是像虚拟机那样的容器,护着打算再Docker容器中构建虚拟机,那么还是建议就此罢手,因为可能会导致一些重大问题。

将Docker想象成一台3D打印机,输入需求→Poof→出现容器,现在这是一个整体和自包含对象而并非是可以编辑或删除的对象。如果某些项不正确或需要新项,不得不进行重复性工作。

当运用Docker容器时需要自问一下如:

集成应用真正的含义是什么

是否了解依赖关系

如果能自答出这些问题,并构建适合容器的新工作流程,那么就能很便捷地实现。
 
误解5:Docker与虚拟机具有相同的安全模型

很多人部署了Docker后,认为它具有与虚拟机相同的安全模型,但可惜地是并非如此,Docker虽与操作系统有关,但它并不是操作系统,很多人使用名为Core OS的缩放操作系统运行容器,除了运行Docker,其无法做更多的事情。应用通常仍然需要更传统的操作系统提供一些东西,例如,从一个Linux发行版(如Ubuntu)构建容器。

一整套的安全挑战出现在迁移到容器时。其中一些是因为“一个进程一个容器”的最初目标难以执行,所以人们找到了实际上容器一个非常重要的特征捷径和方法。

若闯入容器化的环境,当发生的事件导致安全问题时,需要建立告警,比如构建了一系列容器运行的Java应用,若除了Java之外任何操作都开始运行就应该告警。

值得注意的是,容器可以让人真正了解这些类型的告警,可以缩小查找内容,但编写这些规则应用它们以及随着时间推移去进行管理则是一项挑战。
 

Docker的5大实践

前文说过,Docker目前并没有什么“最佳实践”,但本文仍会给出5个实践来供以参考:

实践1:基于应用的日志记录

在基于应用的方法中,容器内的应用使用日志框架来处理日志记录过程,如一个Java应用可能会用Log4j 2去格式化和发送日志文件到远程服务器,并完成绕过Docker和操作系统。


虽然基于应用的日志记录使开发这对日志事件有了最大控制,但这种方法也会在应用过程中产生大量开销,对于哪些在更传统的应用环境工作的人来说可能是有用的,因为其允许开发者继续使用应用的日志框架,无需向主机添加日志功能。

Docker实际上意味着不仅记录应用和主机操作系统,还包括Docker服务。
 
实践2:使用数据卷


容器本质上是临时的,因此若挂掉,里面任何文件都会丢失,相反,容器必须将日志事件转发到集中式日志记录服务(比如日志记录),或将日志事件存储在一个数据卷中(被定义为容器内的一个标记目录,该目录存在保存持久或共享的数据)。


使用数据卷记录事件的好处有:由于它们链接到主机上的一个目录,所以日志数据仍然存在,并且可以与其他容器共享,减少了容器关闭时丢失数据的可能性。(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04) 
 

实践3:Docker日志驱动程序

在Docker中记录实践的方式是使用平台的日志记录驱动程序将日志事件转发到在主机上运行的Syslog实例。Docker日志驱动程序直接从容器的Stdout和Stderr输出入去日志事件,这消除了从日志文件读取和写入的需要,转化为性能增益。

但使用Docker日志驱动程序有一些缺点:

不允许日志解析,只能记录转发

Docker日志命令仅适用于日志驱动程序JSON文件

当TCP服务器无法访问时,容器终止。

(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04)
 

实践4:专用记录容器

此种方法的主要优点在于可在Docker环境中完全管理日志事件。由于专用日志记录容器能从其他容器收集日志事件,聚合它们,然后将事件存储或转发到第三方服务,因此此方法消除了对主机的依赖,附加优点有:

自动收集,监控和分析日志事件

自动缩放日志事件,无需配置

通过多个日志事件,统计信息和Docker API数据流检索日志。
 
实践5:侧面方法

Sidecar已成为管理微服务架构的流行方式,侧面的想法来源于摩托车侧车架如何附着在摩托车上的类比,有消息称:一个Sidecar作为第二个进程与服务一起运行,并提供了通过同类界面暴露的平台基础设施功能,例如通过HTTP的类似REST的API。从日志角度看,优点是每个容器都链接到自己的日志记录容器(应用容器保存日志事件和记录容器标签,并将其转发到Loggly的日志记录管理系统)。
 

总结

不得不说,Docker容器是一项非常具有潜力而且十分炫酷的新技术,实践出真知,去了解Docker如何适应应用自身整体的策略非常值得,当了解了容器这些深坑之后,就可以避开它,同时也多去技术社区和线下交流了解更多的方法模式,不断充实自身。 查看全部
 

误区1:Docker是万灵药

Docker并不解决云端所有的问题,所以在容器技术中,需要对计划目标有合理地规划,若考虑采用Docker在平台中加一些特定的东西,那么请自问:目前平台有哪些衍变?若已经有了小的应用服务,可以使用Docker去解决一些问题,但不要试图让它解决全部问题。

在评估环境是否合适容器时,经常使用牛或宠物作为比喻,想要迁移到容器,需要的环境是能像对待牲口那样简单粗暴,而不是那种娇滴滴的宠物。若有一个高强度且密集的程序,并且要不断地为服务器梳理毛发(比喻,意思为比较脆弱,需要经常维护),那么就不适合迁移到容器当中。
 
误解2:Docker有明确的最佳实践

如同在其生命周期快速采用阶段的任何突破性技术一样,容器还没有一组清晰的最佳实践,本文文末将给出一个较好的实践,但仍不算最佳。

虽然并没有什么“最佳实践”,但需要知道做什么,如,早期的想法是不希望在Docker中托管一个数据库,但现在已经在Docker上运行了整个搜索引擎(又称庞大的数据库),并找到了让它工作的方法。

Docker现在充满了争议,但这不意味着要去避开它,而是做到理解前沿的新技术和所做的事情。不要害怕尝试不同的事务,需要明白它能产生的作用,如果善于思考需要解决的问题,并进行一些实践测试,可能就会学到很多适合本企业自身的知识,缺乏最佳实践可能是一种挑战,但同时也意味着可以不受限地跳出条条框框去思考,想出创造性的办法去解决老问题。

如果已经有了一个范围广泛且松散耦合的集合,就可以很好地运用容器去解决一些,但要是已经有了大量流程模式的挑战,并且应用管理方法都是非常传统的,就需要在尝试迁移之前将这些问题解决掉,在迁移到容器之前,需要致力于不可变的基础设施概念和实践。
 
误解3:Docker总是比虚拟机便宜

从某个角度去看,运行容器确实会比虚拟机要便宜,比如,有600个AWS实例,分别是1个CPU和4-5GB的RAM,那么可以使用Docker容器将其减少到100个实例,其中有32个CPU和64G的RAM,因为实例数量的减少就可以显著地降低成本。

对于一些用例来说这是正确且可行的,至少在短期内如此,但从长远角度去看,如同其他任何技术一样,也为应用容器技术花费了不少人力、物力成本,逐渐将其复杂化也带来了成本上的问题。

当大规模地运行容器时,为了方便管理容器极其资源,不得不投资管理和编排平台,就需要一个全新的技术堆栈,由于没有明确的最佳实践,可能会遇到一些反复出现的错误,造成时间和成本上的浪费。

这笔账不能简单地去通过对比其价格计算,需要大量的时间去确定优先级,并理解在运用容器需要的成本是多少。
 
误解4:容器可以像虚拟机一样

容器不仅仅是更小,更离散的虚拟机,而且也是完全独立的。所以若使用的是像虚拟机那样的容器,护着打算再Docker容器中构建虚拟机,那么还是建议就此罢手,因为可能会导致一些重大问题。

将Docker想象成一台3D打印机,输入需求→Poof→出现容器,现在这是一个整体和自包含对象而并非是可以编辑或删除的对象。如果某些项不正确或需要新项,不得不进行重复性工作。

当运用Docker容器时需要自问一下如:

集成应用真正的含义是什么

是否了解依赖关系

如果能自答出这些问题,并构建适合容器的新工作流程,那么就能很便捷地实现。
 
误解5:Docker与虚拟机具有相同的安全模型

很多人部署了Docker后,认为它具有与虚拟机相同的安全模型,但可惜地是并非如此,Docker虽与操作系统有关,但它并不是操作系统,很多人使用名为Core OS的缩放操作系统运行容器,除了运行Docker,其无法做更多的事情。应用通常仍然需要更传统的操作系统提供一些东西,例如,从一个Linux发行版(如Ubuntu)构建容器。

一整套的安全挑战出现在迁移到容器时。其中一些是因为“一个进程一个容器”的最初目标难以执行,所以人们找到了实际上容器一个非常重要的特征捷径和方法。

若闯入容器化的环境,当发生的事件导致安全问题时,需要建立告警,比如构建了一系列容器运行的Java应用,若除了Java之外任何操作都开始运行就应该告警。

值得注意的是,容器可以让人真正了解这些类型的告警,可以缩小查找内容,但编写这些规则应用它们以及随着时间推移去进行管理则是一项挑战。
 

Docker的5大实践

前文说过,Docker目前并没有什么“最佳实践”,但本文仍会给出5个实践来供以参考:

实践1:基于应用的日志记录

在基于应用的方法中,容器内的应用使用日志框架来处理日志记录过程,如一个Java应用可能会用Log4j 2去格式化和发送日志文件到远程服务器,并完成绕过Docker和操作系统。


虽然基于应用的日志记录使开发这对日志事件有了最大控制,但这种方法也会在应用过程中产生大量开销,对于哪些在更传统的应用环境工作的人来说可能是有用的,因为其允许开发者继续使用应用的日志框架,无需向主机添加日志功能。

Docker实际上意味着不仅记录应用和主机操作系统,还包括Docker服务。
 
实践2:使用数据卷


容器本质上是临时的,因此若挂掉,里面任何文件都会丢失,相反,容器必须将日志事件转发到集中式日志记录服务(比如日志记录),或将日志事件存储在一个数据卷中(被定义为容器内的一个标记目录,该目录存在保存持久或共享的数据)。


使用数据卷记录事件的好处有:由于它们链接到主机上的一个目录,所以日志数据仍然存在,并且可以与其他容器共享,减少了容器关闭时丢失数据的可能性。(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04) 
 

实践3:Docker日志驱动程序

在Docker中记录实践的方式是使用平台的日志记录驱动程序将日志事件转发到在主机上运行的Syslog实例。Docker日志驱动程序直接从容器的Stdout和Stderr输出入去日志事件,这消除了从日志文件读取和写入的需要,转化为性能增益。

但使用Docker日志驱动程序有一些缺点:

不允许日志解析,只能记录转发

Docker日志命令仅适用于日志驱动程序JSON文件

当TCP服务器无法访问时,容器终止。

(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04)
 

实践4:专用记录容器

此种方法的主要优点在于可在Docker环境中完全管理日志事件。由于专用日志记录容器能从其他容器收集日志事件,聚合它们,然后将事件存储或转发到第三方服务,因此此方法消除了对主机的依赖,附加优点有:

自动收集,监控和分析日志事件

自动缩放日志事件,无需配置

通过多个日志事件,统计信息和Docker API数据流检索日志。
 
实践5:侧面方法

Sidecar已成为管理微服务架构的流行方式,侧面的想法来源于摩托车侧车架如何附着在摩托车上的类比,有消息称:一个Sidecar作为第二个进程与服务一起运行,并提供了通过同类界面暴露的平台基础设施功能,例如通过HTTP的类似REST的API。从日志角度看,优点是每个容器都链接到自己的日志记录容器(应用容器保存日志事件和记录容器标签,并将其转发到Loggly的日志记录管理系统)。
 

总结

不得不说,Docker容器是一项非常具有潜力而且十分炫酷的新技术,实践出真知,去了解Docker如何适应应用自身整体的策略非常值得,当了解了容器这些深坑之后,就可以避开它,同时也多去技术社区和线下交流了解更多的方法模式,不断充实自身。

当容器与CI/CD相遇,7个建议送给你

杨y 发表了文章 • 0 个评论 • 25 次浏览 • 2017-09-13 18:44 • 来自相关话题

小数之前给大家分享过很多关于CI/CD的内容,如《关于CI的服务器与最佳实践,这里有一些思考》、《用对这8种工具,CI/CD其实没那么难》那么当Docker和CI/CD一起会发生什么?请看今天分享的内容~

Docker是CI/CD的早期采用者,通过利用如GIT等源代码控制机制的正确集成,Jenkins可以在开发者每次提交代码时启动构建过程,此过程生成新的Docker镜像,可以在整个环境中立即生效,因此团队可以快速构建共享和部署应用。

用途:根据开发需求,自动配置环境及基础设施,并配备拥有自助服务的自动化工具。

企业所面临的挑战:
 
不可用的环境缺乏环境配置所需技能缺乏环境配置所需时间

什么是CI(持续集成)
 
CI是一种开发实践,开发者每天将代码集成到共享存储库中几次,支持将新功能与现有代码集成在一起,此集成的代码还可以确保运行时环境中没有错误,允许检查它与其他变更的反应。

目前用于CI最流行的工具是“Jenkins”,GIT用于源代码控制存储库,Jenkins可以从GIT存储库中提取最新的代码修订,并生成可以部署到服务器上的构建版本。
 
什么是持续交付



持续交付是指在给定的时间内将软件部署到任何环境的能力,包括二进制文件、配置和环境变更。
 
什么是持续部署(CD)



持续部署是开发团队在短周期内发布应用的一种方法,开发人员所做的任何变更都会被部署到生产环境中。
 
什么是Docker?



Docker是一个容器化平台,以容器的形式将应用及所有依赖项打包在一起,确保应用能够在任何环境中无缝地工作。
 
Docker如何帮助CI/CD



Docker可以帮助开发者构建代码并在任何环境中进行测试,以便尽早地在开发生命周期中获取BUG。Docker的优势在于:帮助简化流程、节省构建时间、并允许开发者并行地运行测试。


Docker还可以集成源代码控制管理工具,如GitHub和Jenkins等集成工具,开发者将代码提交到GitHub,测试使用Jenkins创建影响自动触发构建的代码,可以将此影响添加到Docker registry,以处理不同环境类型之间的不一致。
 
技术解决方案



没有Docker参与的典型CI:





 
开发者将代码提交到存储库,这些代码通常会在持续集成服务器上触发构建,构建过程可能会根据所构建的应用而不同,一般情况下,可以进行编译、运行测试用例、构建应用,然后将应用部署到服务器中。

通过Docker进行的CI:





 
在CI过程中安装Docker的方法是让CI服务器在构建应用后再构建Docker镜像,应用进入镜像内部,将镜像推到Docker Hub,在另一台主机上或QA/DEV/生产环境,从Docker Hub提取即将完成的构建,并运行应用的容器,在CI服务器中,甚至可以将编译和测试作为镜像构建的一部分运行。

好处:


 
 
消除不一致的环境设置问题任何运行Docker的机器都可以使用Docker镜像节省构建和设置过程中的时间允许并行测试

DevOps模式,开发可以专注于开发应用,而运维可以专注于部署

改进版本控制,通过改变Docker镜像来规范环境

本文作者有多年的持续部署(CD)经验,帮助很多公司实践及优化CD,以下是一些关于CI/CD的经验及建议:
 
No.1  使用工具:



虽然使用工具听起来很平常,但仍有一些公司没有使用工具,这对公司或个人没有益处,推荐使用Circle类似的工具,工作流方面也应该有一定的工具使用规划。

No.2  做单元测试:



需时刻提醒团队成员,持续部署只是应用于部署的持续集成,因此需要良好的单元测试覆盖率,如果还没有一个坚实的单元测试和持续集成的基础,那就是准备尚不完善。

No.3   做好监控:



BUG和回滚是不可避免的,通过查看生产中的数据,将系统放在适合的位置,可以知道何时进行了回滚或BUG传递,将其绑定到自动化回滚,因此如果有关键功能或指标出错,那么CD系统会自动回滚到稳定版本。
 
No.4   团队信任:



选择相信团队成员,容忍开发人员的错误,在认为合适的时候进行部署,并互相检查代码,将持续部署与分层权限的区域性结合在一起。


No.5   简化代码评审过程:



与上面所说的团队信任类似,团队应该检查代码变更,选择最有资格和洞察力的人去检查开发人员的代码。


No.6  让开发人员紧密参与生产操作:



没有成功地过度到持续部署的公司最常见的问题是开发团队是独立的,开发和运维应该在适合的时候互相参与到对方的工作当中,要让开发团队深入参与CD基础设施的建设和规划。


No.7  尽早测试:



团队需要不断地反馈,把测试目标看做是在正确的时间获得正确的反馈,因此在部署时才能知道什么是有效或错误的,越早发现BUG,就越容易修复,持续部署做的极好的公司都会有全面的单元测试和集成测试覆盖率。

结论:



持续测试也是一种开发实践,在一天的测试计划中,开发需要不断地将代码集成到共享存储库中,为了让开发团队能够检测出问题,自动化构建可以用来验证每个测试,若不遵循连续的方式,那么集成和修复BUG会消耗更长的时间。

为了提高应用开发过程的敏捷性,在企业中使用Docker简化和稳定了CI/CD,Docker容器的轻量级特性使其快速运转,并有助于快速测试,并且可以使用可重复的流程,创建类似环境产品。
  查看全部
小数之前给大家分享过很多关于CI/CD的内容,如《关于CI的服务器与最佳实践,这里有一些思考》、《用对这8种工具,CI/CD其实没那么难》那么当Docker和CI/CD一起会发生什么?请看今天分享的内容~

Docker是CI/CD的早期采用者,通过利用如GIT等源代码控制机制的正确集成,Jenkins可以在开发者每次提交代码时启动构建过程,此过程生成新的Docker镜像,可以在整个环境中立即生效,因此团队可以快速构建共享和部署应用。

用途:根据开发需求,自动配置环境及基础设施,并配备拥有自助服务的自动化工具。

企业所面临的挑战:
 
  • 不可用的环境
  • 缺乏环境配置所需技能
  • 缺乏环境配置所需时间


什么是CI(持续集成)
 
CI是一种开发实践,开发者每天将代码集成到共享存储库中几次,支持将新功能与现有代码集成在一起,此集成的代码还可以确保运行时环境中没有错误,允许检查它与其他变更的反应。

目前用于CI最流行的工具是“Jenkins”,GIT用于源代码控制存储库,Jenkins可以从GIT存储库中提取最新的代码修订,并生成可以部署到服务器上的构建版本。
 
什么是持续交付



持续交付是指在给定的时间内将软件部署到任何环境的能力,包括二进制文件、配置和环境变更。
 
什么是持续部署(CD)



持续部署是开发团队在短周期内发布应用的一种方法,开发人员所做的任何变更都会被部署到生产环境中。
 
什么是Docker?



Docker是一个容器化平台,以容器的形式将应用及所有依赖项打包在一起,确保应用能够在任何环境中无缝地工作。
 
Docker如何帮助CI/CD



Docker可以帮助开发者构建代码并在任何环境中进行测试,以便尽早地在开发生命周期中获取BUG。Docker的优势在于:帮助简化流程、节省构建时间、并允许开发者并行地运行测试。


Docker还可以集成源代码控制管理工具,如GitHub和Jenkins等集成工具,开发者将代码提交到GitHub,测试使用Jenkins创建影响自动触发构建的代码,可以将此影响添加到Docker registry,以处理不同环境类型之间的不一致。
 
技术解决方案



没有Docker参与的典型CI:

QQ图片20170913184107.png

 
开发者将代码提交到存储库,这些代码通常会在持续集成服务器上触发构建,构建过程可能会根据所构建的应用而不同,一般情况下,可以进行编译、运行测试用例、构建应用,然后将应用部署到服务器中。

通过Docker进行的CI:

2.png

 
在CI过程中安装Docker的方法是让CI服务器在构建应用后再构建Docker镜像,应用进入镜像内部,将镜像推到Docker Hub,在另一台主机上或QA/DEV/生产环境,从Docker Hub提取即将完成的构建,并运行应用的容器,在CI服务器中,甚至可以将编译和测试作为镜像构建的一部分运行。

好处:


 
 
  • 消除不一致的环境设置问题
  • 任何运行Docker的机器都可以使用Docker镜像
  • 节省构建和设置过程中的时间
  • 允许并行测试


DevOps模式,开发可以专注于开发应用,而运维可以专注于部署

改进版本控制,通过改变Docker镜像来规范环境

本文作者有多年的持续部署(CD)经验,帮助很多公司实践及优化CD,以下是一些关于CI/CD的经验及建议:
 
No.1  使用工具:



虽然使用工具听起来很平常,但仍有一些公司没有使用工具,这对公司或个人没有益处,推荐使用Circle类似的工具,工作流方面也应该有一定的工具使用规划。

No.2  做单元测试:



需时刻提醒团队成员,持续部署只是应用于部署的持续集成,因此需要良好的单元测试覆盖率,如果还没有一个坚实的单元测试和持续集成的基础,那就是准备尚不完善。

No.3   做好监控:



BUG和回滚是不可避免的,通过查看生产中的数据,将系统放在适合的位置,可以知道何时进行了回滚或BUG传递,将其绑定到自动化回滚,因此如果有关键功能或指标出错,那么CD系统会自动回滚到稳定版本。
 
No.4   团队信任:



选择相信团队成员,容忍开发人员的错误,在认为合适的时候进行部署,并互相检查代码,将持续部署与分层权限的区域性结合在一起。


No.5   简化代码评审过程:



与上面所说的团队信任类似,团队应该检查代码变更,选择最有资格和洞察力的人去检查开发人员的代码。


No.6  让开发人员紧密参与生产操作:



没有成功地过度到持续部署的公司最常见的问题是开发团队是独立的,开发和运维应该在适合的时候互相参与到对方的工作当中,要让开发团队深入参与CD基础设施的建设和规划。


No.7  尽早测试:



团队需要不断地反馈,把测试目标看做是在正确的时间获得正确的反馈,因此在部署时才能知道什么是有效或错误的,越早发现BUG,就越容易修复,持续部署做的极好的公司都会有全面的单元测试和集成测试覆盖率。

结论:



持续测试也是一种开发实践,在一天的测试计划中,开发需要不断地将代码集成到共享存储库中,为了让开发团队能够检测出问题,自动化构建可以用来验证每个测试,若不遵循连续的方式,那么集成和修复BUG会消耗更长的时间。

为了提高应用开发过程的敏捷性,在企业中使用Docker简化和稳定了CI/CD,Docker容器的轻量级特性使其快速运转,并有助于快速测试,并且可以使用可重复的流程,创建类似环境产品。
 

当K8S遇上微服务-京东金融PaaS平台思考与实践

杨y 发表了文章 • 0 个评论 • 66 次浏览 • 2017-08-29 10:51 • 来自相关话题

 8月19日的数人云Container Meetup上,张龙老师做了《基于Kubernetes的PaaS平台的设计和思考》的精彩分享,分别介绍了PaaS平台的意义,为什么选择Kubernetes,PaaS平台上的微服务架构应用,如何设计和快速构建PaaS平台,PaaS平台的功能组件这几个内容。

以下为现场实录内容——

今天跟大家分享下基于Kubernetes的PaaS平台设计和思考,主要分为五个部分:

PaaS平台的意义
为什么选择Kubernetes
PaaS平台上的微服务架构应用
PaaS平台架构设计
PaaS平台功能组件

PaaS平台的意义

很多公司技术支持岗位的工作,如配置域名,部署环境,修改复位配置,服务重启,扩容缩容,梳理和完善监控,根据开发的需要查找日志等工作,需要和开发进行大量的沟通,如什么是外网域名,什么是内网域名、A name、C name,防火墙规则该如何设定,操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点,导致沟通困难,效率很低。而且这样的需求还很多,把运维压的喘不过气,占用了几乎所有的时间,但是开发的需求可能还是迟迟不能满足。

这样的公司可能遇到了以下问题:

系统架构过于陈旧,性能、可靠性无法满足现有的需求;
原有IT架构不灵活,业务模块新增或变更带来巨大成本压力;
系统功能繁杂,结构紊乱,定制的代码与系统耦合性极高;
服务种类繁多,各种技术栈横行;
人员流动交接不充分,新接手的团队对部署环境不了解,只能做周边的修补,不敢迁移 。

如何才能解决?答案是流程化、标准化、自动化、平台化。

流程化

即主动梳理运维工作任务,形成标准化的操作流程,尤其是针对需要多人协作完成的任务,比如应用的发布部署,把流程固化到流程平台系统中,保证每个人执行都能按照流程严格执行,不会有哪些环节遗漏,而且当前的流程状态对所有人都可见,能清晰的看到谁正在处理,处理人也会更主动尽快的完成该任务。

标准化

从架构角度按照应用类别制定应用的部署标准,比如Web类型的应用,服务化的应用(我们内部用的JSF),或者是比较新的微服务的应用(Springboot等),部署脚本和工具平台按照约定好的规范进行设计开发,减少了因为应用种类繁多导致工具和平台的复杂。

自动化

早期写了非常多的脚本,任务执行机到要执行任务的服务器之间通过SSH免密钥认证,再根据需要批量执行命令。随着服务器规模和应用数量的扩张,很快脚本执行的方式无法满足业务发展,难以理解,同一个类型的任务多个脚本并存,存在误操作,缺乏清晰的操作历史记录和回滚机制,即使后续替换了如Puppet,Saltstack,Ansible这样的配置管理工具,但根本问题并没有解决。

※ 平台化

平台化是这次分享的重点,一定要在前面三条的基础上进行建设,如果没有清晰的流程,明确的标准,平台建设起来也只是自动化工具的集成,解决不了公司核心问题。

以下说的平台化内容主要是PaaS平台化,即主要从应用和中间件的角度,这里不讨论IaaS的内容。

PasS平台化将问题的关注点从基础资源上升到了应用层面,目标是提供一个帮助开发人员运行、管理应用的平台,让使用者更关注运行的代码(业务逻辑)。

PaaS能解决的问题:

应用聚合:如开发需要一个Redis,直接启动一个Redis容器即可
服务发现、快速伸缩、状态管理等
服务监控、恢复、容灾
费用统计:提供计算资源信息汇总,针对不同项目收费
安全管控:不管什么平台,安全都非常重要,例如A应用可以访问B,B不允许访问A以及安全审计等。
快速部署。

随着Docker容器技术的出现,让我们有了更合适的工具建设PaaS平台,具备了基于应用构建服务的能力。

在Docker容器调度框架上,我们又选择了Kubernetes平台。

为什么选择Kubernetes

先列一下目前三大主流的容器调度框架的功能和特点:

〓 Kubernetes

资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA。

〓 Mesos

Mesos是一个分布式内核,目前的发展方向是数据中心操作系统(DCOS),它同时支持 Marathon、 Kubernetes 和 Swarm 等多种框架,Mesosphere 也是 Kubernetes 生态的一员。

注意Marathon的技术栈是Scala语言,而Docker和Kubernetes的技术栈都是Go语言。

〓 Swarm

从Docker1.12版本开始,Swarm 随Docker一起默认安装发布,也由于随Docker引擎一起发布,无需额外安装,配置简单。

支持服务注册、服务发现,内置Overlay Network以及Load Balancer。

与Docker CLI非常类似的操作命令,对熟悉Docker的人非常容易上手学习。

每一种工具都有自己的核心理念。

Mesos理念是数据中心操作系统(DCOS),为了解决IaaS层的网络、计算和存储问题,所以Mesos的核心是解决物理资源层的问题。

Kubernetes的核心是如何解决自动部署,扩展和管理容器化(containerized)应用程序。

所以,个人认为Mesos和Kubernetes是两种维度,对于我们的场景来说,关心应用的状态多于物理资源层管理,因此更关心的是容器化应用程序管理,这是我们选择Kubernetes的主要原因。

另外选择Kubernetes还考虑了其它优势,如:

出身名门Google,其开发和设计受到了Google著名的Borg系统的影响;
GitHub上关注Kubernetes项目和提交代码的开发者非常多,社区活跃,如果遇到问题,通过社区咨询和解决 问题速度也会比较快。
Kubernetes可以很好的支持有状态的服务。

PaaS平台上的微服务架构应用

再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的,即我们PaaS平台上要运行的典型应用是什么样的。
 





 
用户端的请求进来以后,首先进入前端的Nginx服务器,再进入Zuul代理网管上,由Zuul将这些任务下发到不同的服务上去。Eureka集群作为注册中心服务,提供服务的发现和注册的功能。服务后端再去调用依赖的其他服务,数据库集群,Redis集群等服务。

微服务架构因为有注册中心自动解决了服务注册发现的问题,所以对内部服务来讲就不用依赖传统的负载均衡器等工具,很容易将各个服务Docker化,迁移到PaaS平台里统一管理。

PaaS平台架构设计
平台建设原则

在建设PaaS平台之前,参考《高效人士的七个习惯》设定了PaaS平台建设的原则:

以终为始:做一件事情要知道想达成什么样的目的,知道这个目的之后,就能够围绕这个目标采取一些措施。
知己解彼:作为一个运维人员,需要有一个比较大的知识面。只有如此才能够去制定一些适合自己的方案和产品。
积极主动:因为要做PaaS所以要把自己的主观能动性都调起来。
要事第一:上面说了很多PaaS相关的内容,由于时间、人员的限制。如何从众多的基础组建中挑选出来最重要的一些事情,着手建设。
双赢:做出来的系统最好是能够达到对开发、运维、公司都有利。
统合综效:对待同样的一件事,每个人都会有自己的见解。同时也要问同伴,要把所有的观点都收集起来做一个综合分析对比,以收到更好的效果。
持续更新:时刻提醒自己持续学习,拥抱变化,这样才能看到平台的不足。持续迭代出更好的产品。

基于以上的原则,我们团队勾勒了一个最小化的PaaS图:
 





 
最上面的Ingress服务跟传统的负载均衡器的功能类似,提供请求分发的功能。
Service相当于后端Pod的一个代理服务器,Service需要通过Ingress服务才能被外部Client访问。
Pod则相当于我们传统的一个服务。
最小化PaaS平台还用到了DNS组件,在内部服务运行起来之后,我们会通过DNS组件分配一个内部域名供访问时使用。

Kubernetes对外提供服务,用的是Lvs+Ingress,每次添加一个新的服务之后会调用一次DNS的API,按照规则生成一个内部域名供访问使用。

平台关键能力说明

应用持续部署

平台实现快速、可视化自动部署功能。支持对应用的快速、可视化部署。用户仅需在界面中选择相应的镜像和组件,并填写简单的配置信息,点击部署按钮,即可完成整个应用的安装或者升级。在测试环境可通过Jenkins,可实现应用的持续集成和全自动化升级,同时支持一键回滚和恢复发布功能。

应用弹性伸缩

构建具有需求预测和容器按需供给能力的弹性伸缩子系统,具有基于应用的负载和资源情况进行弹性伸缩能力,以应对互联网用户高并发的特点,应对流量冲击。其中,包括容器弹性伸缩、物理机弹性伸缩功能。

容器和组件的统一管理

从整体应用的角度出发,平台不仅管理镜像和容器,而是将一个应用涉及的所有组件均做了统一管理,比如对前端的DNS、负载均衡(F5/Nginx),后端数据库等的管理。通过对系统相关组件和容器统一管理,平台将可以实现系统的全局统一部署、配置、升级/回滚、监控、故障处理等功能。

高可靠性

容器的故障恢复,当服务器宕机时,平台系统会自动在其它服务器上重新启动容器并为其分配资源,从而达到秒级启动,恢复业务。保障业务不掉线,高可靠运行;镜像仓库的可靠性,通过将单机版的镜像仓库扩展成镜像仓库集群,从而提升性能,实现Registry的无状态化,便于实现服务的高可用性。

应用docker化封装

系统支持如下几类常见应用:Tomcat、Jboss、Nginx、Redis、Zookeeper等。

PaaS平台功能组件

具体实施时,主要有几个基础组件需要开发:

〓 镜像管理

实际运行的应用镜像由 “基础中间件镜像”+“应用包”+“配置” 自动构建,无需开发人员理解镜像概念和手动制作镜像;

〓 DNS管理

定制化公司内部使用的DNS管理平台,对公司的DNS进行统一管理;

〓 服务管理

需要定制化一套Kubernetes的Deployment模板,从Ingress到Service再到RC都定义在这套模板里面,方便对容器进行扩容、缩容、删除操作;

〓 服务内pod管理

属于Kubernetes自有范畴,查看Service内的Pod运行情况、Pod日志输出等功能;

〓 日志管理

将日志输出到公司的日志平台(如ELK平台),对接研发人员排查问题、数据埋点使用。

〓 监控管理

参考方案cadvisor+influxdb+grafana/ heapster+influxdb+grafana/Prometheus/zabbix.

一个中小企业做成这样后,日常运维的工作量即可大量减少,两三个人就能完成日常的应用运维工作,有兴趣地话可以去挑战一下。当然做完这些后,还只是一个小型的PaaS平台。

如果是再复杂一点的PaaS平台,应该还有哪些要继续做的呢?

环境管理:即一套平台管理多套不同的Kubernetes集群。安全管理、流程管理、计费管理等功能模块。

还有因为规模增加和更高的可靠性要求,对应的网络,IO等各种优化。

其实还有很多功能就不一一列举了,可以根据自己的实际情况添加功能模块,设计有自己公司特色的PaaS平台。 查看全部

QQ图片20170829100123.png

 8月19日的数人云Container Meetup上,张龙老师做了《基于Kubernetes的PaaS平台的设计和思考》的精彩分享,分别介绍了PaaS平台的意义,为什么选择Kubernetes,PaaS平台上的微服务架构应用,如何设计和快速构建PaaS平台,PaaS平台的功能组件这几个内容。

以下为现场实录内容——

今天跟大家分享下基于Kubernetes的PaaS平台设计和思考,主要分为五个部分:

PaaS平台的意义
为什么选择Kubernetes
PaaS平台上的微服务架构应用
PaaS平台架构设计
PaaS平台功能组件

PaaS平台的意义

很多公司技术支持岗位的工作,如配置域名,部署环境,修改复位配置,服务重启,扩容缩容,梳理和完善监控,根据开发的需要查找日志等工作,需要和开发进行大量的沟通,如什么是外网域名,什么是内网域名、A name、C name,防火墙规则该如何设定,操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点,导致沟通困难,效率很低。而且这样的需求还很多,把运维压的喘不过气,占用了几乎所有的时间,但是开发的需求可能还是迟迟不能满足。

这样的公司可能遇到了以下问题:

系统架构过于陈旧,性能、可靠性无法满足现有的需求;
原有IT架构不灵活,业务模块新增或变更带来巨大成本压力;
系统功能繁杂,结构紊乱,定制的代码与系统耦合性极高;
服务种类繁多,各种技术栈横行;
人员流动交接不充分,新接手的团队对部署环境不了解,只能做周边的修补,不敢迁移 。

如何才能解决?答案是流程化、标准化、自动化、平台化。

流程化

即主动梳理运维工作任务,形成标准化的操作流程,尤其是针对需要多人协作完成的任务,比如应用的发布部署,把流程固化到流程平台系统中,保证每个人执行都能按照流程严格执行,不会有哪些环节遗漏,而且当前的流程状态对所有人都可见,能清晰的看到谁正在处理,处理人也会更主动尽快的完成该任务。

标准化

从架构角度按照应用类别制定应用的部署标准,比如Web类型的应用,服务化的应用(我们内部用的JSF),或者是比较新的微服务的应用(Springboot等),部署脚本和工具平台按照约定好的规范进行设计开发,减少了因为应用种类繁多导致工具和平台的复杂。

自动化

早期写了非常多的脚本,任务执行机到要执行任务的服务器之间通过SSH免密钥认证,再根据需要批量执行命令。随着服务器规模和应用数量的扩张,很快脚本执行的方式无法满足业务发展,难以理解,同一个类型的任务多个脚本并存,存在误操作,缺乏清晰的操作历史记录和回滚机制,即使后续替换了如Puppet,Saltstack,Ansible这样的配置管理工具,但根本问题并没有解决。

※ 平台化

平台化是这次分享的重点,一定要在前面三条的基础上进行建设,如果没有清晰的流程,明确的标准,平台建设起来也只是自动化工具的集成,解决不了公司核心问题。

以下说的平台化内容主要是PaaS平台化,即主要从应用和中间件的角度,这里不讨论IaaS的内容。

PasS平台化将问题的关注点从基础资源上升到了应用层面,目标是提供一个帮助开发人员运行、管理应用的平台,让使用者更关注运行的代码(业务逻辑)。

PaaS能解决的问题:

应用聚合:如开发需要一个Redis,直接启动一个Redis容器即可
服务发现、快速伸缩、状态管理等
服务监控、恢复、容灾
费用统计:提供计算资源信息汇总,针对不同项目收费
安全管控:不管什么平台,安全都非常重要,例如A应用可以访问B,B不允许访问A以及安全审计等。
快速部署。

随着Docker容器技术的出现,让我们有了更合适的工具建设PaaS平台,具备了基于应用构建服务的能力。

在Docker容器调度框架上,我们又选择了Kubernetes平台。

为什么选择Kubernetes

先列一下目前三大主流的容器调度框架的功能和特点:

〓 Kubernetes

资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA。

〓 Mesos

Mesos是一个分布式内核,目前的发展方向是数据中心操作系统(DCOS),它同时支持 Marathon、 Kubernetes 和 Swarm 等多种框架,Mesosphere 也是 Kubernetes 生态的一员。

注意Marathon的技术栈是Scala语言,而Docker和Kubernetes的技术栈都是Go语言。

〓 Swarm

从Docker1.12版本开始,Swarm 随Docker一起默认安装发布,也由于随Docker引擎一起发布,无需额外安装,配置简单。

支持服务注册、服务发现,内置Overlay Network以及Load Balancer。

与Docker CLI非常类似的操作命令,对熟悉Docker的人非常容易上手学习。

每一种工具都有自己的核心理念。

Mesos理念是数据中心操作系统(DCOS),为了解决IaaS层的网络、计算和存储问题,所以Mesos的核心是解决物理资源层的问题。

Kubernetes的核心是如何解决自动部署,扩展和管理容器化(containerized)应用程序。

所以,个人认为Mesos和Kubernetes是两种维度,对于我们的场景来说,关心应用的状态多于物理资源层管理,因此更关心的是容器化应用程序管理,这是我们选择Kubernetes的主要原因。

另外选择Kubernetes还考虑了其它优势,如:

出身名门Google,其开发和设计受到了Google著名的Borg系统的影响;
GitHub上关注Kubernetes项目和提交代码的开发者非常多,社区活跃,如果遇到问题,通过社区咨询和解决 问题速度也会比较快。
Kubernetes可以很好的支持有状态的服务。

PaaS平台上的微服务架构应用

再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的,即我们PaaS平台上要运行的典型应用是什么样的。
 

1.png

 
用户端的请求进来以后,首先进入前端的Nginx服务器,再进入Zuul代理网管上,由Zuul将这些任务下发到不同的服务上去。Eureka集群作为注册中心服务,提供服务的发现和注册的功能。服务后端再去调用依赖的其他服务,数据库集群,Redis集群等服务。

微服务架构因为有注册中心自动解决了服务注册发现的问题,所以对内部服务来讲就不用依赖传统的负载均衡器等工具,很容易将各个服务Docker化,迁移到PaaS平台里统一管理。

PaaS平台架构设计
平台建设原则

在建设PaaS平台之前,参考《高效人士的七个习惯》设定了PaaS平台建设的原则:

以终为始:做一件事情要知道想达成什么样的目的,知道这个目的之后,就能够围绕这个目标采取一些措施。
知己解彼:作为一个运维人员,需要有一个比较大的知识面。只有如此才能够去制定一些适合自己的方案和产品。
积极主动:因为要做PaaS所以要把自己的主观能动性都调起来。
要事第一:上面说了很多PaaS相关的内容,由于时间、人员的限制。如何从众多的基础组建中挑选出来最重要的一些事情,着手建设。
双赢:做出来的系统最好是能够达到对开发、运维、公司都有利。
统合综效:对待同样的一件事,每个人都会有自己的见解。同时也要问同伴,要把所有的观点都收集起来做一个综合分析对比,以收到更好的效果。
持续更新:时刻提醒自己持续学习,拥抱变化,这样才能看到平台的不足。持续迭代出更好的产品。

基于以上的原则,我们团队勾勒了一个最小化的PaaS图:
 

2.png

 
最上面的Ingress服务跟传统的负载均衡器的功能类似,提供请求分发的功能。
Service相当于后端Pod的一个代理服务器,Service需要通过Ingress服务才能被外部Client访问。
Pod则相当于我们传统的一个服务。
最小化PaaS平台还用到了DNS组件,在内部服务运行起来之后,我们会通过DNS组件分配一个内部域名供访问时使用。

Kubernetes对外提供服务,用的是Lvs+Ingress,每次添加一个新的服务之后会调用一次DNS的API,按照规则生成一个内部域名供访问使用。

平台关键能力说明

应用持续部署

平台实现快速、可视化自动部署功能。支持对应用的快速、可视化部署。用户仅需在界面中选择相应的镜像和组件,并填写简单的配置信息,点击部署按钮,即可完成整个应用的安装或者升级。在测试环境可通过Jenkins,可实现应用的持续集成和全自动化升级,同时支持一键回滚和恢复发布功能。

应用弹性伸缩

构建具有需求预测和容器按需供给能力的弹性伸缩子系统,具有基于应用的负载和资源情况进行弹性伸缩能力,以应对互联网用户高并发的特点,应对流量冲击。其中,包括容器弹性伸缩、物理机弹性伸缩功能。

容器和组件的统一管理

从整体应用的角度出发,平台不仅管理镜像和容器,而是将一个应用涉及的所有组件均做了统一管理,比如对前端的DNS、负载均衡(F5/Nginx),后端数据库等的管理。通过对系统相关组件和容器统一管理,平台将可以实现系统的全局统一部署、配置、升级/回滚、监控、故障处理等功能。

高可靠性

容器的故障恢复,当服务器宕机时,平台系统会自动在其它服务器上重新启动容器并为其分配资源,从而达到秒级启动,恢复业务。保障业务不掉线,高可靠运行;镜像仓库的可靠性,通过将单机版的镜像仓库扩展成镜像仓库集群,从而提升性能,实现Registry的无状态化,便于实现服务的高可用性。

应用docker化封装

系统支持如下几类常见应用:Tomcat、Jboss、Nginx、Redis、Zookeeper等。

PaaS平台功能组件

具体实施时,主要有几个基础组件需要开发:

〓 镜像管理

实际运行的应用镜像由 “基础中间件镜像”+“应用包”+“配置” 自动构建,无需开发人员理解镜像概念和手动制作镜像;

〓 DNS管理

定制化公司内部使用的DNS管理平台,对公司的DNS进行统一管理;

〓 服务管理

需要定制化一套Kubernetes的Deployment模板,从Ingress到Service再到RC都定义在这套模板里面,方便对容器进行扩容、缩容、删除操作;

〓 服务内pod管理

属于Kubernetes自有范畴,查看Service内的Pod运行情况、Pod日志输出等功能;

〓 日志管理

将日志输出到公司的日志平台(如ELK平台),对接研发人员排查问题、数据埋点使用。

〓 监控管理

参考方案cadvisor+influxdb+grafana/ heapster+influxdb+grafana/Prometheus/zabbix.

一个中小企业做成这样后,日常运维的工作量即可大量减少,两三个人就能完成日常的应用运维工作,有兴趣地话可以去挑战一下。当然做完这些后,还只是一个小型的PaaS平台。

如果是再复杂一点的PaaS平台,应该还有哪些要继续做的呢?

环境管理:即一套平台管理多套不同的Kubernetes集群。安全管理、流程管理、计费管理等功能模块。

还有因为规模增加和更高的可靠性要求,对应的网络,IO等各种优化。

其实还有很多功能就不一一列举了,可以根据自己的实际情况添加功能模块,设计有自己公司特色的PaaS平台。

关于Docker Swarm&K8S,几大要素免踩坑

杨y 发表了文章 • 0 个评论 • 59 次浏览 • 2017-08-28 10:52 • 来自相关话题

 
数人云之前分享了《聊聊调度框架,K8S、Mesos、Swarm 一个都不能少》那么你是否仍在Docker和Kubernetes选择上陷入了困扰?所以不要担心,因为这也是很多人的苦恼,这两者都是非常优秀的容器服务,至于那种更好,其实在很大程度上取决于自身和团队的需求。

在深入研究前,我们需要了解什么是“容器”。

容器是轻量级、独立的镜像,可以用来实现软件,包含了成功运行应用所需的所有内容,工作方式类似于虚拟机(VM),但是它只包含必要的库和设置来执行应用。

Docker Swarm、Kubernetes都提供了相同基础设施中部署和隔离软件的容器,也有很好处理应用的方式,但这两者之间也有一些关键性的区别:

很多工程师,都喜欢在Docker Swarm上工作,因为它很容易使用和实现,但选择了Docker Swarm,它就会比Kubernetes更优秀吗?








需要先了解一下什么是Docker Swarm、Kubernetes。

Docker Swarm

Docker是一个开源平台,它可能意味着一个公司,一个容器平台或Docker集群,本文讨论的是容器技术,所以这里提到的Docker的意思其实是Docker Swarm,Docker Swarm是一个灵活的容器存储平台,以强大的易用性而著称,另一方面,Docker Swarm则完全是为了管理Docker引擎集群。








Kubernetes

Kubernetes是一个流行的开源容器存储程序,它是由谷歌建立的,用来管理其系统,这是一个开源的、可扩展的、强大的工具,可以处理容器,同时提供巨大的可伸缩性和自动化。

去年,作为热门游戏之一的Pokemon Go,也使用了Kubernetes来管理它们的产品和快速扩展,Pokemon Go的成功,自己快速地传播,让人切实地感受到了Kubernetes的力量。








对比

安全和设置

每个工具都有自己的安装和设置过程,想在云端或其他基础设置中管理容器 ,很大程度上取决于它是如何建立的,相比之下,Kubernetes对用户的友好度并不如Docker Swarm。

Kubernetes:当涉及到安装和设置时,它会给开发者出一些难题,首先,需要为每个操作系统(OS)重新配置,在线文档在这个过程中有很多的帮助,然而在构建定制环境时,可能会变得十分复杂,唯一的解决办法是:搜谷歌。Kubernetes不容易安装和设置的另一个关键原因在实现之前需要进行规划,需要花费大量的时间和精力去规划节点,而且要进行人工整合,因为它并不是所有的东西都可以自动化,这让Kubernetes难以管理。

Docker Swarm:得益于它的命令行界面(CLI),Docker Swarm很容易设置和管理,它使用CLI和GIT类似的语义,这使得应用开发者能够轻易地将新技术集成到工作流当中,与Kubernetes相比,在实现新操作系统、环境的容器时,无需学习新的东西。

综上所述,在安装和设置方面,Docker Swarm略胜一筹。

监控和日志

一旦部署了容器,下一步就是监控节点集群,Kubernetes和Docker Swarm都成功地提供了一个良好的监控和日志记录流程。

对于Kubernetes来说,监控和日志记录集群的方法不止一种,下面有一些方法以供参考:

监控:Grafana , Heapster , or Influx
日志记录:Kibana (ELK) or Elasticsearch

对于Docker Swarm来说,没有内置的库或进程来监控或记录,但是开发人员可以使用第三方应用来达到目的,第三方监控工具有:Sumo Logic , Retrace , Reimann , and DataDog。

伸缩和性能

使用容器服务的最基本原理是它们提供的可伸缩性,这两个平台都是高度可伸缩的,并且在特定的时间支撑数千个容器,起初,Docker Swarm对大量的容器没有很好的支持,然而,在新的版本后,它就可以支持和Kubernetes的容器数量比肩,两个系统都支持1000个节点集群,这些集群可以支持多大3万个容器。

在性能方面,Kubernetes对Dokcer Swarm有良好的基础,然而,由独立机构完成研究表明,Docker Swarm可以比Kubernetes快5倍的速度去运转容器。

Kubernetes Docker Swarm
在市场上最成熟的解决方案。 Docker Swarm提供良好的特性,但受限于其API。
Kubernetes也在市场上最受欢迎的解决方案。 rDocker Swarm的市场Kubernetes相比相对较弱。
Kubernetes很难安装和配置。 Docker Swarm的设置和安装是很容易的。
Kubernetes提供内置的日志记录和监控工具。 Docker只支持第三方监控和日志记录工具。
自动定量的CPU利用率是一个很大的因素。 可以手动扩展服务。

结论

Kubernetes得到了开发者社区的广泛认可,尽管它的安装过程非常艰难,之所以受到欢迎的原因很大程度取决于它提供的灵活性,以及良好的谷歌背景,而Docker Swarm有一个小型的社区,增长略微缓慢。

Kubernetes的庞大社区意味着新的工具、特定和支持。若你是一个小的开发者,想要学习容器服务,那么Kubernetes会有大量的经验可以借鉴,很多志同道合的朋友可以一起学习,而Docker Swarm同样可以根据自身业务需求更深入了解。
原文作者:Damian Wolf 原文链接:https://dzone.com/articles/doc ... erral 查看全部
 
数人云之前分享了《聊聊调度框架,K8S、Mesos、Swarm 一个都不能少》那么你是否仍在Docker和Kubernetes选择上陷入了困扰?所以不要担心,因为这也是很多人的苦恼,这两者都是非常优秀的容器服务,至于那种更好,其实在很大程度上取决于自身和团队的需求。

在深入研究前,我们需要了解什么是“容器”。

容器是轻量级、独立的镜像,可以用来实现软件,包含了成功运行应用所需的所有内容,工作方式类似于虚拟机(VM),但是它只包含必要的库和设置来执行应用。

Docker Swarm、Kubernetes都提供了相同基础设施中部署和隔离软件的容器,也有很好处理应用的方式,但这两者之间也有一些关键性的区别:

很多工程师,都喜欢在Docker Swarm上工作,因为它很容易使用和实现,但选择了Docker Swarm,它就会比Kubernetes更优秀吗?

1.png




需要先了解一下什么是Docker Swarm、Kubernetes。

Docker Swarm

Docker是一个开源平台,它可能意味着一个公司,一个容器平台或Docker集群,本文讨论的是容器技术,所以这里提到的Docker的意思其实是Docker Swarm,Docker Swarm是一个灵活的容器存储平台,以强大的易用性而著称,另一方面,Docker Swarm则完全是为了管理Docker引擎集群。


2.png



Kubernetes

Kubernetes是一个流行的开源容器存储程序,它是由谷歌建立的,用来管理其系统,这是一个开源的、可扩展的、强大的工具,可以处理容器,同时提供巨大的可伸缩性和自动化。

去年,作为热门游戏之一的Pokemon Go,也使用了Kubernetes来管理它们的产品和快速扩展,Pokemon Go的成功,自己快速地传播,让人切实地感受到了Kubernetes的力量。


3.png



对比

安全和设置

每个工具都有自己的安装和设置过程,想在云端或其他基础设置中管理容器 ,很大程度上取决于它是如何建立的,相比之下,Kubernetes对用户的友好度并不如Docker Swarm。

Kubernetes:当涉及到安装和设置时,它会给开发者出一些难题,首先,需要为每个操作系统(OS)重新配置,在线文档在这个过程中有很多的帮助,然而在构建定制环境时,可能会变得十分复杂,唯一的解决办法是:搜谷歌。Kubernetes不容易安装和设置的另一个关键原因在实现之前需要进行规划,需要花费大量的时间和精力去规划节点,而且要进行人工整合,因为它并不是所有的东西都可以自动化,这让Kubernetes难以管理。

Docker Swarm:得益于它的命令行界面(CLI),Docker Swarm很容易设置和管理,它使用CLI和GIT类似的语义,这使得应用开发者能够轻易地将新技术集成到工作流当中,与Kubernetes相比,在实现新操作系统、环境的容器时,无需学习新的东西。

综上所述,在安装和设置方面,Docker Swarm略胜一筹。

监控和日志

一旦部署了容器,下一步就是监控节点集群,Kubernetes和Docker Swarm都成功地提供了一个良好的监控和日志记录流程。

对于Kubernetes来说,监控和日志记录集群的方法不止一种,下面有一些方法以供参考:

监控:Grafana , Heapster , or Influx
日志记录:Kibana (ELK) or Elasticsearch

对于Docker Swarm来说,没有内置的库或进程来监控或记录,但是开发人员可以使用第三方应用来达到目的,第三方监控工具有:Sumo Logic , Retrace , Reimann , and DataDog。

伸缩和性能

使用容器服务的最基本原理是它们提供的可伸缩性,这两个平台都是高度可伸缩的,并且在特定的时间支撑数千个容器,起初,Docker Swarm对大量的容器没有很好的支持,然而,在新的版本后,它就可以支持和Kubernetes的容器数量比肩,两个系统都支持1000个节点集群,这些集群可以支持多大3万个容器。

在性能方面,Kubernetes对Dokcer Swarm有良好的基础,然而,由独立机构完成研究表明,Docker Swarm可以比Kubernetes快5倍的速度去运转容器。

Kubernetes Docker Swarm
在市场上最成熟的解决方案。 Docker Swarm提供良好的特性,但受限于其API。
Kubernetes也在市场上最受欢迎的解决方案。 rDocker Swarm的市场Kubernetes相比相对较弱。
Kubernetes很难安装和配置。 Docker Swarm的设置和安装是很容易的。
Kubernetes提供内置的日志记录和监控工具。 Docker只支持第三方监控和日志记录工具。
自动定量的CPU利用率是一个很大的因素。 可以手动扩展服务。

结论

Kubernetes得到了开发者社区的广泛认可,尽管它的安装过程非常艰难,之所以受到欢迎的原因很大程度取决于它提供的灵活性,以及良好的谷歌背景,而Docker Swarm有一个小型的社区,增长略微缓慢。

Kubernetes的庞大社区意味着新的工具、特定和支持。若你是一个小的开发者,想要学习容器服务,那么Kubernetes会有大量的经验可以借鉴,很多志同道合的朋友可以一起学习,而Docker Swarm同样可以根据自身业务需求更深入了解。
  1. 原文作者:Damian Wolf 原文链接:https://dzone.com/articles/doc ... erral

双态IT驱动PaaS进阶 ,数人云产品体系全面升级EAMS

杨y 发表了文章 • 0 个评论 • 56 次浏览 • 2017-08-14 17:24 • 来自相关话题

 近日,数人云产品体系完成全面升级,在数据中心操作系统(DM/OS)的基础上,数人云产品延伸至对企业应用架构管理体系(EAMS)的支持和管理。有了 DM/OS 和 EAMS,数人云产品可以支持多种业务应用类型和模式,包括高并发应用开发框架、服务治理中心、容器中间件、云 CI/CD 平台等,为客户快速打造互联网应用提供系统支持。

▌轻量级容器立本,布局 PaaS 丰富产品线

自2013年开始,Docker 容器技术凭借轻量快速等特点,掀起了一股 Docker 热潮,受到行业热捧。和传统虚拟化技术相比,Docker 更加轻量,更容易实现动态迁移和设置,这为以轻量级容器为核心的新一代 PaaS 平台提供了爆发式增长的机会。数人云作为容器热潮中的领先者,依托容器技术打造的轻量级 PaaS 平台,旨在帮助企业客户输出 Google 等互联网企业的IT最佳实践。

在产品层面,数人云 DM/OS 数据中心操作系统,于成熟稳定的 Mesos 集群调度工具基础上,已升级支持 Kubernetes ,数人云产品体系现已支持当前多样化主流编排工具。

利用 DM/OS,用户可以快速整合不同环境下的主机资源,部署海量应用,通过多样化的编排工具,DM/OS 可以为用户的业务系统带来高可用的服务质量,快速的性能伸缩,高效的资源利用以及便捷的可视化管理和监控;支持多环境,可在多平台间无缝迁移。简化运维,打破开发和运维之间屏障,提升了开发部署维护的效率。

除了企业级产品,数人云还是国内推动开源技术的领先型创业公司,数人云2016年先后开源了基于 Swarmkit 的容器管理面板 Crane,Mesos 的调度器 Swan,开源化产品已成为数人云的重要标签。

数人云近期还发布了分布式调度平台 Octopus,打造高效可靠的弹性作业云,在分布式开发及智能化管理上小试牛刀,以及高并发应用开发框架 Squid,云 CI/CD 平台 Kelisa 等,数人云产品家族将陆续会有更多新产品面市,帮助客户降低开发运维复杂度,快速应对业务需求迭代。

数人云在帮助传统企业落地 DevOps 的过程中减少技术门槛,把企业内部开发和运营的界限打通,形成开发和运营团队之间更加协作、高效的关系。同时,SRE 作为 DevOps 思想在运维领域的具体实践,数人云借鉴 Google SRE 的实践经验,加上自身对 SRE 核心理念的深刻理解能力,为 SRE 在中国企业的落地提供重要参考,助力企业客户构建平台化的服务体系。

在客户层面,数人云近3年的持续耕耘收获丰富。目前,数人云已经服务了国内大型公共事业央企、大型股份制银行、城商行,以及快消等众多企业客户,不断在传统行业实现突破。数人云持续关注客户需求,深挖行业痛点,给客户交付出贴合需求和特性的行业容器云,帮助企业快速进入应用容器化阶段。

这其中值得一提的是,数人云与行业合作伙伴针对金融领域打造出金融容器云,帮助客户及时响应高并发等新型业务需求。借助容器技术,金融云使得应用的交付更加标准,消除了技术部署的局限性,提高了企业产品的交付及运维效率。云计算的竞争在不远的未来必然是生态的竞争,数人云也在携手合作伙伴共同构建基于容器的 PaaS 技术生态圈,与上下游伙伴一道开拓云计算生态市场。

▌在双态IT驱动下,升级为企业应用架构管理体系(EAMS)

IDC 相关报告显示,数字化转型已成为所有企业应对挑战的主要战略。预计到2018年,全球1000强中的67%和中国1000强中的50%的企业都将把数字化转型作为战略核心。在转型过程中,今天的企业客户在 IT 上面临传统应用和互联网新型应用双态并存的现状。

传统应用主要服务内部用户,业务需求明确、功能全面,覆盖广泛,大集成。同时,系统的刚性很强,难以应对业务的快速变化,无法支持互联网环境下快速变革的新业态。而企业不得不出招迎接的新兴互联网应用,服务外部客户和合作伙伴,呈现出需求变动快、独立分散、分布式进化、业务和 IT 无法分离,需要快速创新等特点。

面对复杂多变的竞争环境,企业IT建设既要面对数字化转型的落地,又要保证核心业务运营和互联网应用创新的协同发展。新IT也很难完全取代传统IT。有数据显示,只有60%左右的传统应用能够迁移到新IT架构平台上,这意味着,传统IT架构和新IT架构将长期并存。这也符合 Gartner 的数据,Gartner 认为,数字生态系统的运作需要一个由面向传统业务强调稳定性的IT和创新业务强调敏捷性的IT组成的双态IT模式。

基于企业客户所面临的数字化转型时代多样化的IT需求,以及对企业级IT应用现状的洞察,在稳态与敏态并重的双态IT驱动下,数人云产品体系全面升级为企业应用架构管理体系(EAMS),借助团队自身丰富的互联网应用架构经验,帮助企业客户建立以云计算为基础的轻型IT,实现敏捷化和自动化的IT,推动企业IT全面革新。



数人云认为,企业级IT最大的挑战在于是实现业务、应用、架构和IT管理这四者和谐统一—应用与业务的和谐,要求应用满足业务的功能性需求;架构与应用的和谐,要求架构满足应用的非功能性需求,诸如性能、稳定性、连续性、可移植性、可维护性等方面的需求;IT管理与业务、应用、架构的和谐,一方面要求采用新技术提升应用和架构对业务的支撑能力,另一方面要求采用新的方法提升IT管理能力,进而更好地让技术为业务服务。双态IT能够在企业数字化转型期间,利用稳态和敏态两种不同的IT模式实现对复杂多元的业务进行支撑。为实现双态IT下的业务、应用、架构和IT管理的四效合一,数人云从轻量容器云服务商升级为企业应用架构管理(EAMS)体系服务商,帮助企业IT架构适应业务转型和可持续发展的要求,向新IT转型。

数人云将产品体系升级为企业应用架构管理(EAMS)体系,旨在帮助企业保持传统IT优势的同时,赋以更好的敏捷性和自动化,跨过两者的鸿沟。从为用户带来高效快速服务性能的 DM/OS 数据中心操作系统到全面支持 Mesos、Kubernetes 等主流开源编排工具,从借鉴 Google DevOps 和 SRE 思想,让理念在中国企业落地开花,从轻量 Docker 技术小步快走到产品全面升级到企业应用架构管理体系,帮助传统企业构建真正意义上的灵动新IT。 查看全部

22.jpg

 近日,数人云产品体系完成全面升级,在数据中心操作系统(DM/OS)的基础上,数人云产品延伸至对企业应用架构管理体系(EAMS)的支持和管理。有了 DM/OS 和 EAMS,数人云产品可以支持多种业务应用类型和模式,包括高并发应用开发框架、服务治理中心、容器中间件、云 CI/CD 平台等,为客户快速打造互联网应用提供系统支持。

▌轻量级容器立本,布局 PaaS 丰富产品线

自2013年开始,Docker 容器技术凭借轻量快速等特点,掀起了一股 Docker 热潮,受到行业热捧。和传统虚拟化技术相比,Docker 更加轻量,更容易实现动态迁移和设置,这为以轻量级容器为核心的新一代 PaaS 平台提供了爆发式增长的机会。数人云作为容器热潮中的领先者,依托容器技术打造的轻量级 PaaS 平台,旨在帮助企业客户输出 Google 等互联网企业的IT最佳实践。

在产品层面,数人云 DM/OS 数据中心操作系统,于成熟稳定的 Mesos 集群调度工具基础上,已升级支持 Kubernetes ,数人云产品体系现已支持当前多样化主流编排工具。

利用 DM/OS,用户可以快速整合不同环境下的主机资源,部署海量应用,通过多样化的编排工具,DM/OS 可以为用户的业务系统带来高可用的服务质量,快速的性能伸缩,高效的资源利用以及便捷的可视化管理和监控;支持多环境,可在多平台间无缝迁移。简化运维,打破开发和运维之间屏障,提升了开发部署维护的效率。

除了企业级产品,数人云还是国内推动开源技术的领先型创业公司,数人云2016年先后开源了基于 Swarmkit 的容器管理面板 Crane,Mesos 的调度器 Swan,开源化产品已成为数人云的重要标签。

数人云近期还发布了分布式调度平台 Octopus,打造高效可靠的弹性作业云,在分布式开发及智能化管理上小试牛刀,以及高并发应用开发框架 Squid,云 CI/CD 平台 Kelisa 等,数人云产品家族将陆续会有更多新产品面市,帮助客户降低开发运维复杂度,快速应对业务需求迭代。

数人云在帮助传统企业落地 DevOps 的过程中减少技术门槛,把企业内部开发和运营的界限打通,形成开发和运营团队之间更加协作、高效的关系。同时,SRE 作为 DevOps 思想在运维领域的具体实践,数人云借鉴 Google SRE 的实践经验,加上自身对 SRE 核心理念的深刻理解能力,为 SRE 在中国企业的落地提供重要参考,助力企业客户构建平台化的服务体系。

在客户层面,数人云近3年的持续耕耘收获丰富。目前,数人云已经服务了国内大型公共事业央企、大型股份制银行、城商行,以及快消等众多企业客户,不断在传统行业实现突破。数人云持续关注客户需求,深挖行业痛点,给客户交付出贴合需求和特性的行业容器云,帮助企业快速进入应用容器化阶段。

这其中值得一提的是,数人云与行业合作伙伴针对金融领域打造出金融容器云,帮助客户及时响应高并发等新型业务需求。借助容器技术,金融云使得应用的交付更加标准,消除了技术部署的局限性,提高了企业产品的交付及运维效率。云计算的竞争在不远的未来必然是生态的竞争,数人云也在携手合作伙伴共同构建基于容器的 PaaS 技术生态圈,与上下游伙伴一道开拓云计算生态市场。

▌在双态IT驱动下,升级为企业应用架构管理体系(EAMS)

IDC 相关报告显示,数字化转型已成为所有企业应对挑战的主要战略。预计到2018年,全球1000强中的67%和中国1000强中的50%的企业都将把数字化转型作为战略核心。在转型过程中,今天的企业客户在 IT 上面临传统应用和互联网新型应用双态并存的现状。

传统应用主要服务内部用户,业务需求明确、功能全面,覆盖广泛,大集成。同时,系统的刚性很强,难以应对业务的快速变化,无法支持互联网环境下快速变革的新业态。而企业不得不出招迎接的新兴互联网应用,服务外部客户和合作伙伴,呈现出需求变动快、独立分散、分布式进化、业务和 IT 无法分离,需要快速创新等特点。

面对复杂多变的竞争环境,企业IT建设既要面对数字化转型的落地,又要保证核心业务运营和互联网应用创新的协同发展。新IT也很难完全取代传统IT。有数据显示,只有60%左右的传统应用能够迁移到新IT架构平台上,这意味着,传统IT架构和新IT架构将长期并存。这也符合 Gartner 的数据,Gartner 认为,数字生态系统的运作需要一个由面向传统业务强调稳定性的IT和创新业务强调敏捷性的IT组成的双态IT模式。

基于企业客户所面临的数字化转型时代多样化的IT需求,以及对企业级IT应用现状的洞察,在稳态与敏态并重的双态IT驱动下,数人云产品体系全面升级为企业应用架构管理体系(EAMS),借助团队自身丰富的互联网应用架构经验,帮助企业客户建立以云计算为基础的轻型IT,实现敏捷化和自动化的IT,推动企业IT全面革新。



数人云认为,企业级IT最大的挑战在于是实现业务、应用、架构和IT管理这四者和谐统一—应用与业务的和谐,要求应用满足业务的功能性需求;架构与应用的和谐,要求架构满足应用的非功能性需求,诸如性能、稳定性、连续性、可移植性、可维护性等方面的需求;IT管理与业务、应用、架构的和谐,一方面要求采用新技术提升应用和架构对业务的支撑能力,另一方面要求采用新的方法提升IT管理能力,进而更好地让技术为业务服务。双态IT能够在企业数字化转型期间,利用稳态和敏态两种不同的IT模式实现对复杂多元的业务进行支撑。为实现双态IT下的业务、应用、架构和IT管理的四效合一,数人云从轻量容器云服务商升级为企业应用架构管理(EAMS)体系服务商,帮助企业IT架构适应业务转型和可持续发展的要求,向新IT转型。

数人云将产品体系升级为企业应用架构管理(EAMS)体系,旨在帮助企业保持传统IT优势的同时,赋以更好的敏捷性和自动化,跨过两者的鸿沟。从为用户带来高效快速服务性能的 DM/OS 数据中心操作系统到全面支持 Mesos、Kubernetes 等主流开源编排工具,从借鉴 Google DevOps 和 SRE 思想,让理念在中国企业落地开花,从轻量 Docker 技术小步快走到产品全面升级到企业应用架构管理体系,帮助传统企业构建真正意义上的灵动新IT。

数人云与宇信数据签订战略合作协议,共建金融云生态圈

杨y 发表了文章 • 0 个评论 • 57 次浏览 • 2017-08-08 10:55 • 来自相关话题

近日,数人云与宇信数据在京签订战略合作协议,双方将在IT资源平台统一管理、 金融行业私有云、金融行业容器云等方面展开全面合作,共同建设可信的高端金融云平台-数信金融云,为金融客户实现业务云化的需求,打造新型的金融云生态圈。






在过去几年中,伴随着云计算产业的不断创新与兴起,云计算从概念走进深入实践,再加上互联网+对传统行业的颠覆性影响,中国用户“云化”需求快速提升,行业云应运而生。2017年6月,中国人民银行印发《中国金融业信息技术“十三五”发展规划》,规划中先后表示,重点推进云计算行业技术标准优化升级以及金融行业云计算技术应用研究。基于此,双方强强联合,共同推进国内金融行业云计算技术的创新和发展。

数人云作为国内领先的云计算开源技术实践者,致力于提高传统企业IT对业务的支撑能力,帮助客户统一管理资源和应用,通过DevOps&SRE一体化落地,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

宇信数据是国内金融IT服务领军企业北京宇信科技集团的控股子公司。作为专业的金融云服务公司,致力于为国内外金融机构提供IaaS、PaaS、SaaS等领域全方位,安全合规则的IT托管运营服务。

双方构建的金融云平台-数信金融云,是基于容器的PaaS平台,能够帮助金融客户实现应用全生命周期各个阶段的管理,缩短交付迭代周期,落地IT管理服务化、自动化、标准化,提升运维效率,还可以管理海量监控、日志等产生的各类数据,自动分配应用资源、统一管理资源和应用,提升IT对业务的支撑能力。

宇信科技集团董事长兼CEO洪卫东表示,宇信科技作为金融科技先锋者,早在十多年前就扎根于金融科技行业,是我国第一家在美国纳斯达克上市的金融IT服务企业,宇信数据作为宇信科技集团的子公司,此次与国内领先的轻量级PaaS平台服务商数人云达成战略合作,共同开拓中国金融行业云的市场发展,践行中国金融业在开源技术领域的进步与突破。

数人云CEO王璞对双方的合作则表示,国家政策打造了中国良好的云计算生态环境,国产化是IT需求的基础与前提,在此大环境下,云计算产业高速发展,未来,行业云将是传统行业的IT服务模式。行业云是私有云的自然演进模式,提供的不只是IT服务,更是提供业务服务,并与公有云形成相互补充。数信金融云平台是数人云和宇信数据重点打造的金融行业云平台,为金融机构提供安全可靠的行业云软件架构,对领导金融行业服务创新、构建云计算生态圈具有重要意义。

宇信科技集团董事、CFO、董秘兼宇信数据总经理戴士平对双方的合作表示,数信金融云平台的构建是个产业化项目,宇信数据希望通过与数人云的结盟,聚集产业链上下游开源云计算技术,依靠大家的力量将产业发展壮大,共同推进金融行业云计算技术研究与标准化发展。

关于数人云

数人云创始团队来自谷歌、红帽和惠普,在2017年1月公司宣布完成A+轮融资。作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。数人云重点聚焦打造基于容器的极轻量化PaaS平台,践行DevOps一体化理念和工具落地,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。

关于宇信数据

宇信数据成立于2010年3月,是北京宇信科技集团的控股子公司。宇信数据在成立伊始,就专注于金融业IT托管运营服务。目前已经具备完善的金融云服务能力,服务范围覆盖IaaS、PaaS、SaaS三大领域,并能够提供全渠道互联网金融平台、核心银行系统、小额贷款平台、新一代客服系统、营销分析平台等金融业最重要的IT基础产品。作为银监会外包合作组织的成员,宇信数据拥有符合监管要求的高等级数据中心,并建立了完善的运维支撑体系,能够7*24小时为客户提供全方位的金融云服务,满足金融业快速发展的业务需求。

欢迎加小数微信:xiaoshu062了解更多信息





  查看全部
近日,数人云与宇信数据在京签订战略合作协议,双方将在IT资源平台统一管理、 金融行业私有云、金融行业容器云等方面展开全面合作,共同建设可信的高端金融云平台-数信金融云,为金融客户实现业务云化的需求,打造新型的金融云生态圈。

QQ图片20170808095048.png


在过去几年中,伴随着云计算产业的不断创新与兴起,云计算从概念走进深入实践,再加上互联网+对传统行业的颠覆性影响,中国用户“云化”需求快速提升,行业云应运而生。2017年6月,中国人民银行印发《中国金融业信息技术“十三五”发展规划》,规划中先后表示,重点推进云计算行业技术标准优化升级以及金融行业云计算技术应用研究。基于此,双方强强联合,共同推进国内金融行业云计算技术的创新和发展。

数人云作为国内领先的云计算开源技术实践者,致力于提高传统企业IT对业务的支撑能力,帮助客户统一管理资源和应用,通过DevOps&SRE一体化落地,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。

宇信数据是国内金融IT服务领军企业北京宇信科技集团的控股子公司。作为专业的金融云服务公司,致力于为国内外金融机构提供IaaS、PaaS、SaaS等领域全方位,安全合规则的IT托管运营服务。

双方构建的金融云平台-数信金融云,是基于容器的PaaS平台,能够帮助金融客户实现应用全生命周期各个阶段的管理,缩短交付迭代周期,落地IT管理服务化、自动化、标准化,提升运维效率,还可以管理海量监控、日志等产生的各类数据,自动分配应用资源、统一管理资源和应用,提升IT对业务的支撑能力。

宇信科技集团董事长兼CEO洪卫东表示,宇信科技作为金融科技先锋者,早在十多年前就扎根于金融科技行业,是我国第一家在美国纳斯达克上市的金融IT服务企业,宇信数据作为宇信科技集团的子公司,此次与国内领先的轻量级PaaS平台服务商数人云达成战略合作,共同开拓中国金融行业云的市场发展,践行中国金融业在开源技术领域的进步与突破。

数人云CEO王璞对双方的合作则表示,国家政策打造了中国良好的云计算生态环境,国产化是IT需求的基础与前提,在此大环境下,云计算产业高速发展,未来,行业云将是传统行业的IT服务模式。行业云是私有云的自然演进模式,提供的不只是IT服务,更是提供业务服务,并与公有云形成相互补充。数信金融云平台是数人云和宇信数据重点打造的金融行业云平台,为金融机构提供安全可靠的行业云软件架构,对领导金融行业服务创新、构建云计算生态圈具有重要意义。

宇信科技集团董事、CFO、董秘兼宇信数据总经理戴士平对双方的合作表示,数信金融云平台的构建是个产业化项目,宇信数据希望通过与数人云的结盟,聚集产业链上下游开源云计算技术,依靠大家的力量将产业发展壮大,共同推进金融行业云计算技术研究与标准化发展。

关于数人云

数人云创始团队来自谷歌、红帽和惠普,在2017年1月公司宣布完成A+轮融资。作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。数人云重点聚焦打造基于容器的极轻量化PaaS平台,践行DevOps一体化理念和工具落地,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。

关于宇信数据

宇信数据成立于2010年3月,是北京宇信科技集团的控股子公司。宇信数据在成立伊始,就专注于金融业IT托管运营服务。目前已经具备完善的金融云服务能力,服务范围覆盖IaaS、PaaS、SaaS三大领域,并能够提供全渠道互联网金融平台、核心银行系统、小额贷款平台、新一代客服系统、营销分析平台等金融业最重要的IT基础产品。作为银监会外包合作组织的成员,宇信数据拥有符合监管要求的高等级数据中心,并建立了完善的运维支撑体系,能够7*24小时为客户提供全方位的金融云服务,满足金融业快速发展的业务需求。

欢迎加小数微信:xiaoshu062了解更多信息

QQ图片20170801103212.png

 

优势+工具+实践=DevOps&Docker的企业级落地

杨y 发表了文章 • 0 个评论 • 96 次浏览 • 2017-08-02 10:40 • 来自相关话题

识别二维码报名活动

8月19日,来自微软、数人云、京东、当当网的四位IT老兵,《一起吹响Container+集结号》,看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,在各个场景中与Container发生的碰撞与交互。
 
导读:DevOps&Docker已经逐步完成布道阶段,在越来越多的场景中应用并且获得显著的效果,本文将阐述了两者结合在一起的优势以及相关实践。
 
Docker通过模块化、平台独立性、高效资源利用和快速安装,颠覆了原有的应用部署交付等方法,帮助DevOps更好地落地,两者结合的优势有:

快速交付

实时更新应用

版本可靠

提高质量

敏捷环境
 

什么是DevOps

敏捷开发基于适应性应用开发、持续改进、持续交付,因此DevOps的目标是在应用交付的各个团队之间建立协作,并使应用交付过程自动化,从而不断地测试、部署和监控新发布的版本。

DevOps将开发和运维协调在一起,寻求自动化过程以保证应用的质量,通过DevOps模式,Docker可以构建从GitHub代码仓库到应用部署的一个持续交付的通道,从GitHub代码仓库到应用部署。
 
DevOps如何结合Docker
 
Docker容器通过镜像运行,可以在本地或者存储库(如Docker Hub)上使用,假设作为一个用例,MySQL数据库或其他数据库提供的新版本经常使用小BUG或补丁进行修复,如何在没有延迟的情况下为终端用户提供新版本?

Docker镜像与代码存储库相关联——一个GitHub代码仓库或其他一些存储库,如AWS coUNK mit,若开发人员从GitHub代码仓库构建Docker镜像,并使其在Docker Hub到最终用户,如果最终用户将Docker镜像部署为容器,那么会有以下几个单独运行的阶段:


1)将GitHub代码仓库构建到Docker镜像中(使用Docker构建命令)

2)测试Docker镜像(使用Docker run命令)

3)上传Docker镜像到Docker Hub(使用Docker推送命令)

4)终端用户下载Docker镜像(使用Docker pull命令)

5)终端用户运行一个Docker容器(使用Docker run命令)

6)终端用户部署一个应用(如,使用AWS弹性Beanstalk)

7)终端用户监控应用





 
当新的MySQL数据库在短时间内(可能仅仅一天),出现新的BUG,需要将过程重复。

但DevOps模式可以用于Docker镜像从GitHub到部署,且不需要用户或管理员进行干预。
 
DevOps的设计模式
 
DevOps的设计模式以持续集成、持续测试、持续交付和持续部署为中心,自动化、协作和持续监控是DevOps中使用的一些其他设计模式。

【持续集成】

持续集成是不断地将源代码集成到一个新的构建或发布的过程,源代码可以在本地存储中,也可以在GitHub或AWS CodeCommit中。

【持续测试】

连续测试新的构建或发布即持续测试,Jenkins之类的工具为持续测试提供了几个特性:在Jenkins的每个阶段都有用户去输入,它提供了一些插件,如Docker构建步骤插件,分别测试每个Docker应用阶段:运行容器、上传镜像、停止容器。

【持续交付】

持续交付为终端用户提供新的构建,以便在生产中部署,对于Docker应用,持续交付包括在Docker Hub或Amazon EC2容器等存储库中提供Docker镜像的每个新版本/标记。

【持续部署】

持续部署是不断地部署Docker镜像的最新版本,每当一个Docker镜像的新版本/标签可用时,Docker镜像就会被部署到生产环境中,Kubernetes 容器管理器已经提供了一些功能,如滚动更新,无需中断即可将Docker镜像升级到最新的服务,Jenkins滚动更新是自动化的,当Docker镜像的新版本/标签可用时,就会不断更新。

【持续监控】

持续监控可以监控正在运行应用的过程,类似于Sematext可以监控Docker应用,部署Sematext Docker代理来监控Kubernetes的集群指标并收集日志。

【自动化】

对于Docker应用,可以自动安装一些如Kubernetes这种非常复杂的工具,在其1.4版本中包含了名为Kubeadm的新工具,可以在Ubuntu和CentOS上自动安装Kubernetes上,但CoreOS上不支持Kubeadm工具。

【协作】

协作涉及到跨团队的工作和资源共享,如不同的开发团队可以在GitHub库中开发Docker镜像的不同版本代码,所有的Docker镜像标签都被构建并不断上传至Docker Hub,Jenkins提供了许多分支渠道项目,用于从GitHub存储库等存储库的多个分支中构建代码。
 
DevOps的工具
Jenkins




 
Jenkins是一种常用的自动化和持续交付工具,可用于不断地构建、测试和交付Docker镜像,Jenkins提供了几个可以与Docker一起使用的插件,如Docker插件,Docker构建步骤插件,Amazon EC2插件。

使用Amazon EC2插件,可以使用云配置为Jenkins的代理服务器动态提供实例。
Docker插件可以用来配置云,在Docker容器中运行Jenkins项目。
Docker构建步骤插件用于测试Docker镜像的各个阶段:构建镜像、运行容器、将镜像Push到 Docker Hub停止并删除Docker。
 
CodeCommit & CodeBuild & Elastic Beanstalk





 
AWS提供了一些DevOps工具:

CodeCommit是一个类似于GitHub的版本控制服务,用来存储和管理源代码文件,AWS CodeBuild用于构建和测试代码的DevOps工具,需要构建的代码可以从GitHub或coUNK mit持续集成,从CodeBuild中输出的Docker镜像可以上传到Docker Hub,也可以在构建完成时上传到Amazon EC2容器注册中心。

CodeBuild提供持续且自动化的过程用于构建、测试、交付阶段。

Elastic Beanstalk用于在云端部署和扩展Docker应用,提供了自动容量供应、负载均衡、容缩和监控,Beanstalk应用和环境可以从一个打包为ZIP文件的Dockerfile创建,该文件包含其他应用资源,或仅仅来自一个未打包的Dockerfile,或可以在Dockerrun.aws中制定Docker应用的配置,包括Docker镜像和环境变量。Json文件是Dockerrun.aws的例子,列出了多个容器的配置,其中一个用于MySQL数据库,另一个用户Nginx服务器:
 
{
"AWSEBDockerrunVersion": 2,
"volumes": [
{
"name": "mysql-app",
"host": {
"sourcePath": "/var/app/current/mysql-app"
}
},
{
"name": "nginx-proxy-conf",
"host": {
"sourcePath": "/var/app/current/proxy/conf.d"
}
}
],
"containerDefinitions": [
{
"name": "mysql-app",
"image": "mysql",
"environment": [
{
"name": "MYSQL_ROOT_PASSWORD",
"value": "mysql"
},
{
"name": "MYSQL_ALLOW_EMPTY_PASSWORD",
"value": "yes"
},
{
"name": "MYSQL_DATABASE",
"value": "mysqldb"
},
{
"name": "MYSQL_PASSWORD",
"value": "mysql"
}
],
"essential": true,
"memory": 128,
"mountPoints": [
{
"sourceVolume": "mysql-app",
"containerPath": "/var/mysql",
"readOnly": true
}
]
},
{
"name": "nginx-proxy",
"image": "nginx",
"essential": true,
"memory": 128,
"portMappings": [
{
"hostPort": 80,
"containerPort": 80
}
],
"links": [
"mysql-app"
],
"mountPoints": [
{
"sourceVolume": "mysql-app",
"containerPath": "/var/mysql",
"readOnly": true
},
{
"sourceVolume": "nginx-proxy-conf",
"containerPath": "/etc/nginx/conf.d",
"readOnly": true
}
]
}
]
}Beanstalk应用程序部署的监控: 





 
DevOps&Docker的实践

Docker Datacenter提供让企业更容易建立内部CaaS环境,有助于企业应用交付。

Docker Datacenter(DDC)为企业提供了一种方法:可以让开发者轻松地部署应用,而不必担心从开发到生产的过程中产生的问题。

CaaS平台提供容器和集群编排,通过为DDC构建云端模板,开发者和IT操作人员可以将Dockerzed应用迁移到云端。

DDC包括Docker Universal Control Plane(UCP)、The Docker Trusted Registry (DTR) , 和The Commercially Supported (CS) Docker Engine 。





 
The Universal Control Plane

UCP是集群管理解决方案,可以安装在本地或虚拟私有云上,UCP公开了标准的Docker API,可以继续使用已知的工具管理集群,如仍然可以使用docker info 命令来查看集群的状态:
 
Containers: 15
Images: 10
ServerVersion: swarm/1.1.3
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
ucp: <UCP_IP>:<PORT>
└ Status: Healthy
└ Containers: 20
ucp-replica: <UCP_REPLICA>:<PORT>
└ Status: Healthy
└ Containers: 10使用Docker UCP,仍然可以管理基础设施的节点:应用、容器、网络、镜像等,Docker UCP有内置身份验证机制,支持LDAP和Active Directory及基于角色的访问控制(RBAC),确保只有授权用户能够访问并对集群进行更改。





 
UCP是一个容器化的应用,允许管理一组同一Docker集群的节点,UCP的核心组件是名为UCP代理的全局调度服务,运行后将使用其他CUP组件部署容器。

The Docker Trusted Registry

安全性是开发者在企业采用Docker所面临的最大挑战之一,认识到这一挑战以及企业需要继续在整个网络中简化安全性,Docker引入了Docker Trusted Registry(DTR)。

DTR使用的身份验证机制和Docker UCP相同将其内置,还支持RBAC,允许在必要时实现个性化的访问控制策略。

部署Docker Datacenter

运行DDC主要有两种选择:部署整个堆栈,包括UCP和DTR在AWS上生成模板,或在Linux服务器上手动操作,在本案例中,将使用Docker CaaS(容器作为服务)提供的第二个选择。

CaaS选项基本上是一个托管的SaaS解决方案,Docker引擎、UCP和DTR由Docker操作,容器节在服务器上运行,本文将链接到AWS环境作为案例,但其实也可以在本地环境中运行。

在AWS上部署节点集群

登录到您的DDC账户(可以注册试用Docer Datacenter版本)并在左侧菜单中寻找云设置选项,如下图所示,包含可以链接的支持公有云应用列表,用于创建和托管节点,可用Docker Datacenter进行管理。





 
选择AWS作为提供商,单击Plug-and-Play图表后,会出现对话框,需要进入Role Delegation ARN(请参阅:https://docs.docker.com/docker-cloud/infrastructure/link-aws/)
 
节点集群设置

链接到AWS环境后,进行基础设施设置,如下图所示:





 
点击创建后,将被重定向到配置页面——会被要求输入集群的配置参数:





 
集群名称没有限制,也适用于标签字段,允许提供关于想要创建集群的额外描述。

建议列表也随后出现,作为提供者,必须选择与自身账户链接的那个,字段本身只需要一个选择,而且不局限于创建托管在不同提供者的节点集群。

继续选择AWS区域和网络(VPC),如果将VPC默认设置为“Auto”那么所有的集群节点都将部署在一个新的自动创建的VPC中。

Type/Size字段用于配置每个节点的CPU和RAM数量,IAM角色可以不受影响,并保存默认值“None”剩下要配置的最后两个字段是磁盘大小和节点数量,本文中,设置了10G的磁盘空间并创建了3个节点。





 
点击启动节点集群后,将重定向到节点集群概览界面,可以跟踪集群的状态,成功部署节点集群,部署的状态就会出现在节点集群的名称下。

再次点击启动节点集群,能看到云提供商发生更改,因为已经与Docker Datacenter相连,所有创建的节点都将在那里托管,可以在云平台上用支持的方式进行监控。(参见Logz.ioDocker日志收集器用于集中监控Docker环境的方法:https://logz.io/blog/logz-io-docker-log-collector/)

跨节点集群部署服务

接下来会详细介绍如何跨节点集群部署服务,本文中将使用Nginx:





 
点击左侧菜单栏中的“服务”,将显示主视图的服务面板,而后点击右上角的“Create”按钮,将被重定向到部署获取权镜像的方式。

除了Jumpstart部分和公共镜像,还有一部分可以定义自己的存储库,从中提取镜像,这里将使用公开可用的镜像。





 
在搜索Docker Hub区域内的文本框中输入“Nginx”Enter后将看到与之匹配的可用镜像列表,选择第一项。

单击列表项中的“Select”按钮后,将重定向到Settings页面,部署策略对以下事情非常重要:

跨节点之间的负载均衡
当容器崩溃时的选项:自动重启和自动销毁
终止容器时的策略(此操作实际在终止时会破坏所有数据)
自动重新部署选项:当新镜像被推送或构建时自动重新部署服务





 
为其他面板与端口添加运行命令、内存限制和CPU有关限制,本文实例中保留默认值即可。

而后是Ports部分,可以在这里选择发布哪些端口,并对外部公开(以及哪些不公开),本案例中使用的是80和443。





 
接下来配置环境变量、和其他服务的链接,如把API作为单独的服务部署,NGINX服务器将请求重定向到API服务时,这些链接是有用的。

完成后,可以点击“创建和部署“按钮,将会重定向到服务概览页面,可以看到部署状态,前面步骤中输入的配置概述、容器、链接、环境变量,以及用于访问NGINX服务器的DSN节点等等。





 
如果单击节点中提供的链接,则会看到Nginx欢迎页面。 如前所述,除了连接AWS账户外,还支持内部节点,但都需要安装支持的操作系统,单击“在节点集群中自带节点”按钮,并在服务器中键入命令(在模式窗口内提供),并在数据中心内执行类似节点的操作。





 
原文作者: Deepak Vohra、Daniel Berman

原文链接: http://logz.io/blog/docker-dat ... -2017
  查看全部

微信图片_20170801172806.jpg

识别二维码报名活动

8月19日,来自微软、数人云、京东、当当网的四位IT老兵,《一起吹响Container+集结号》,看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,在各个场景中与Container发生的碰撞与交互。
 
导读:DevOps&Docker已经逐步完成布道阶段,在越来越多的场景中应用并且获得显著的效果,本文将阐述了两者结合在一起的优势以及相关实践。
 
Docker通过模块化、平台独立性、高效资源利用和快速安装,颠覆了原有的应用部署交付等方法,帮助DevOps更好地落地,两者结合的优势有:

快速交付

实时更新应用

版本可靠

提高质量

敏捷环境
 

什么是DevOps

敏捷开发基于适应性应用开发、持续改进、持续交付,因此DevOps的目标是在应用交付的各个团队之间建立协作,并使应用交付过程自动化,从而不断地测试、部署和监控新发布的版本。

DevOps将开发和运维协调在一起,寻求自动化过程以保证应用的质量,通过DevOps模式,Docker可以构建从GitHub代码仓库到应用部署的一个持续交付的通道,从GitHub代码仓库到应用部署。
 
DevOps如何结合Docker
 
Docker容器通过镜像运行,可以在本地或者存储库(如Docker Hub)上使用,假设作为一个用例,MySQL数据库或其他数据库提供的新版本经常使用小BUG或补丁进行修复,如何在没有延迟的情况下为终端用户提供新版本?

Docker镜像与代码存储库相关联——一个GitHub代码仓库或其他一些存储库,如AWS coUNK mit,若开发人员从GitHub代码仓库构建Docker镜像,并使其在Docker Hub到最终用户,如果最终用户将Docker镜像部署为容器,那么会有以下几个单独运行的阶段:


1)将GitHub代码仓库构建到Docker镜像中(使用Docker构建命令)

2)测试Docker镜像(使用Docker run命令)

3)上传Docker镜像到Docker Hub(使用Docker推送命令)

4)终端用户下载Docker镜像(使用Docker pull命令)

5)终端用户运行一个Docker容器(使用Docker run命令)

6)终端用户部署一个应用(如,使用AWS弹性Beanstalk)

7)终端用户监控应用

1.png

 
当新的MySQL数据库在短时间内(可能仅仅一天),出现新的BUG,需要将过程重复。

但DevOps模式可以用于Docker镜像从GitHub到部署,且不需要用户或管理员进行干预。
 
DevOps的设计模式
 
DevOps的设计模式以持续集成、持续测试、持续交付和持续部署为中心,自动化、协作和持续监控是DevOps中使用的一些其他设计模式。

【持续集成】

持续集成是不断地将源代码集成到一个新的构建或发布的过程,源代码可以在本地存储中,也可以在GitHub或AWS CodeCommit中。

【持续测试】

连续测试新的构建或发布即持续测试,Jenkins之类的工具为持续测试提供了几个特性:在Jenkins的每个阶段都有用户去输入,它提供了一些插件,如Docker构建步骤插件,分别测试每个Docker应用阶段:运行容器、上传镜像、停止容器。

【持续交付】

持续交付为终端用户提供新的构建,以便在生产中部署,对于Docker应用,持续交付包括在Docker Hub或Amazon EC2容器等存储库中提供Docker镜像的每个新版本/标记。

【持续部署】

持续部署是不断地部署Docker镜像的最新版本,每当一个Docker镜像的新版本/标签可用时,Docker镜像就会被部署到生产环境中,Kubernetes 容器管理器已经提供了一些功能,如滚动更新,无需中断即可将Docker镜像升级到最新的服务,Jenkins滚动更新是自动化的,当Docker镜像的新版本/标签可用时,就会不断更新。

【持续监控】

持续监控可以监控正在运行应用的过程,类似于Sematext可以监控Docker应用,部署Sematext Docker代理来监控Kubernetes的集群指标并收集日志。

【自动化】

对于Docker应用,可以自动安装一些如Kubernetes这种非常复杂的工具,在其1.4版本中包含了名为Kubeadm的新工具,可以在Ubuntu和CentOS上自动安装Kubernetes上,但CoreOS上不支持Kubeadm工具。

【协作】

协作涉及到跨团队的工作和资源共享,如不同的开发团队可以在GitHub库中开发Docker镜像的不同版本代码,所有的Docker镜像标签都被构建并不断上传至Docker Hub,Jenkins提供了许多分支渠道项目,用于从GitHub存储库等存储库的多个分支中构建代码。
 
DevOps的工具
Jenkins
QQ图片20170801180230.png

 
Jenkins是一种常用的自动化和持续交付工具,可用于不断地构建、测试和交付Docker镜像,Jenkins提供了几个可以与Docker一起使用的插件,如Docker插件,Docker构建步骤插件,Amazon EC2插件。

使用Amazon EC2插件,可以使用云配置为Jenkins的代理服务器动态提供实例。
Docker插件可以用来配置云,在Docker容器中运行Jenkins项目。
Docker构建步骤插件用于测试Docker镜像的各个阶段:构建镜像、运行容器、将镜像Push到 Docker Hub停止并删除Docker。
 
CodeCommit & CodeBuild & Elastic Beanstalk

QQ图片20170801180248.png

 
AWS提供了一些DevOps工具:

CodeCommit是一个类似于GitHub的版本控制服务,用来存储和管理源代码文件,AWS CodeBuild用于构建和测试代码的DevOps工具,需要构建的代码可以从GitHub或coUNK mit持续集成,从CodeBuild中输出的Docker镜像可以上传到Docker Hub,也可以在构建完成时上传到Amazon EC2容器注册中心。

CodeBuild提供持续且自动化的过程用于构建、测试、交付阶段。

Elastic Beanstalk用于在云端部署和扩展Docker应用,提供了自动容量供应、负载均衡、容缩和监控,Beanstalk应用和环境可以从一个打包为ZIP文件的Dockerfile创建,该文件包含其他应用资源,或仅仅来自一个未打包的Dockerfile,或可以在Dockerrun.aws中制定Docker应用的配置,包括Docker镜像和环境变量。Json文件是Dockerrun.aws的例子,列出了多个容器的配置,其中一个用于MySQL数据库,另一个用户Nginx服务器:
 
{
"AWSEBDockerrunVersion": 2,
"volumes": [
{
"name": "mysql-app",
"host": {
"sourcePath": "/var/app/current/mysql-app"
}
},
{
"name": "nginx-proxy-conf",
"host": {
"sourcePath": "/var/app/current/proxy/conf.d"
}
}
],
"containerDefinitions": [
{
"name": "mysql-app",
"image": "mysql",
"environment": [
{
"name": "MYSQL_ROOT_PASSWORD",
"value": "mysql"
},
{
"name": "MYSQL_ALLOW_EMPTY_PASSWORD",
"value": "yes"
},
{
"name": "MYSQL_DATABASE",
"value": "mysqldb"
},
{
"name": "MYSQL_PASSWORD",
"value": "mysql"
}
],
"essential": true,
"memory": 128,
"mountPoints": [
{
"sourceVolume": "mysql-app",
"containerPath": "/var/mysql",
"readOnly": true
}
]
},
{
"name": "nginx-proxy",
"image": "nginx",
"essential": true,
"memory": 128,
"portMappings": [
{
"hostPort": 80,
"containerPort": 80
}
],
"links": [
"mysql-app"
],
"mountPoints": [
{
"sourceVolume": "mysql-app",
"containerPath": "/var/mysql",
"readOnly": true
},
{
"sourceVolume": "nginx-proxy-conf",
"containerPath": "/etc/nginx/conf.d",
"readOnly": true
}
]
}
]
}
Beanstalk应用程序部署的监控: 

3.png

 
DevOps&Docker的实践

Docker Datacenter提供让企业更容易建立内部CaaS环境,有助于企业应用交付。

Docker Datacenter(DDC)为企业提供了一种方法:可以让开发者轻松地部署应用,而不必担心从开发到生产的过程中产生的问题。

CaaS平台提供容器和集群编排,通过为DDC构建云端模板,开发者和IT操作人员可以将Dockerzed应用迁移到云端。

DDC包括Docker Universal Control Plane(UCP)、The Docker Trusted Registry (DTR) , 和The Commercially Supported (CS) Docker Engine 。

4.png

 
The Universal Control Plane

UCP是集群管理解决方案,可以安装在本地或虚拟私有云上,UCP公开了标准的Docker API,可以继续使用已知的工具管理集群,如仍然可以使用docker info 命令来查看集群的状态:
 
Containers: 15
Images: 10
ServerVersion: swarm/1.1.3
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
ucp: <UCP_IP>:<PORT>
└ Status: Healthy
└ Containers: 20
ucp-replica: <UCP_REPLICA>:<PORT>
└ Status: Healthy
└ Containers: 10
使用Docker UCP,仍然可以管理基础设施的节点:应用、容器、网络、镜像等,Docker UCP有内置身份验证机制,支持LDAP和Active Directory及基于角色的访问控制(RBAC),确保只有授权用户能够访问并对集群进行更改。

5.png

 
UCP是一个容器化的应用,允许管理一组同一Docker集群的节点,UCP的核心组件是名为UCP代理的全局调度服务,运行后将使用其他CUP组件部署容器。

The Docker Trusted Registry

安全性是开发者在企业采用Docker所面临的最大挑战之一,认识到这一挑战以及企业需要继续在整个网络中简化安全性,Docker引入了Docker Trusted Registry(DTR)。

DTR使用的身份验证机制和Docker UCP相同将其内置,还支持RBAC,允许在必要时实现个性化的访问控制策略。

部署Docker Datacenter

运行DDC主要有两种选择:部署整个堆栈,包括UCP和DTR在AWS上生成模板,或在Linux服务器上手动操作,在本案例中,将使用Docker CaaS(容器作为服务)提供的第二个选择。

CaaS选项基本上是一个托管的SaaS解决方案,Docker引擎、UCP和DTR由Docker操作,容器节在服务器上运行,本文将链接到AWS环境作为案例,但其实也可以在本地环境中运行。

在AWS上部署节点集群

登录到您的DDC账户(可以注册试用Docer Datacenter版本)并在左侧菜单中寻找云设置选项,如下图所示,包含可以链接的支持公有云应用列表,用于创建和托管节点,可用Docker Datacenter进行管理。

6.png

 
选择AWS作为提供商,单击Plug-and-Play图表后,会出现对话框,需要进入Role Delegation ARN(请参阅:https://docs.docker.com/docker-cloud/infrastructure/link-aws/)
 
节点集群设置

链接到AWS环境后,进行基础设施设置,如下图所示:

7.png

 
点击创建后,将被重定向到配置页面——会被要求输入集群的配置参数:

8.png

 
集群名称没有限制,也适用于标签字段,允许提供关于想要创建集群的额外描述。

建议列表也随后出现,作为提供者,必须选择与自身账户链接的那个,字段本身只需要一个选择,而且不局限于创建托管在不同提供者的节点集群。

继续选择AWS区域和网络(VPC),如果将VPC默认设置为“Auto”那么所有的集群节点都将部署在一个新的自动创建的VPC中。

Type/Size字段用于配置每个节点的CPU和RAM数量,IAM角色可以不受影响,并保存默认值“None”剩下要配置的最后两个字段是磁盘大小和节点数量,本文中,设置了10G的磁盘空间并创建了3个节点。

9.png

 
点击启动节点集群后,将重定向到节点集群概览界面,可以跟踪集群的状态,成功部署节点集群,部署的状态就会出现在节点集群的名称下。

再次点击启动节点集群,能看到云提供商发生更改,因为已经与Docker Datacenter相连,所有创建的节点都将在那里托管,可以在云平台上用支持的方式进行监控。(参见Logz.ioDocker日志收集器用于集中监控Docker环境的方法:https://logz.io/blog/logz-io-docker-log-collector/

跨节点集群部署服务

接下来会详细介绍如何跨节点集群部署服务,本文中将使用Nginx:

10.png

 
点击左侧菜单栏中的“服务”,将显示主视图的服务面板,而后点击右上角的“Create”按钮,将被重定向到部署获取权镜像的方式。

除了Jumpstart部分和公共镜像,还有一部分可以定义自己的存储库,从中提取镜像,这里将使用公开可用的镜像。

11.png

 
在搜索Docker Hub区域内的文本框中输入“Nginx”Enter后将看到与之匹配的可用镜像列表,选择第一项。

单击列表项中的“Select”按钮后,将重定向到Settings页面,部署策略对以下事情非常重要:

跨节点之间的负载均衡
当容器崩溃时的选项:自动重启和自动销毁
终止容器时的策略(此操作实际在终止时会破坏所有数据)
自动重新部署选项:当新镜像被推送或构建时自动重新部署服务

12.png

 
为其他面板与端口添加运行命令、内存限制和CPU有关限制,本文实例中保留默认值即可。

而后是Ports部分,可以在这里选择发布哪些端口,并对外部公开(以及哪些不公开),本案例中使用的是80和443。

13.png

 
接下来配置环境变量、和其他服务的链接,如把API作为单独的服务部署,NGINX服务器将请求重定向到API服务时,这些链接是有用的。

完成后,可以点击“创建和部署“按钮,将会重定向到服务概览页面,可以看到部署状态,前面步骤中输入的配置概述、容器、链接、环境变量,以及用于访问NGINX服务器的DSN节点等等。

14.png

 
如果单击节点中提供的链接,则会看到Nginx欢迎页面。 如前所述,除了连接AWS账户外,还支持内部节点,但都需要安装支持的操作系统,单击“在节点集群中自带节点”按钮,并在服务器中键入命令(在模式窗口内提供),并在数据中心内执行类似节点的操作。

15.png

 
原文作者: Deepak Vohra、Daniel Berman

原文链接: http://logz.io/blog/docker-dat ... -2017
 

Meetup北京报名开启|一起吹响Container+集结号

杨y 发表了文章 • 0 个评论 • 81 次浏览 • 2017-08-01 10:30 • 来自相关话题

Container技术在国内的落地实践,

已进阶Container+

8月阅兵仪式,一睹超强装备的风采,

技术圈也不落人后,

本次Meetup邀请到来自微软、当当、数人云的技术大牛以及一位神秘嘉宾,

共同来一场Container的大阅兵,

看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,

在各个场景中与Container发生的碰撞与交互。

吹着空调唠唠嗑,一起开启夏日清凉模式!
 
 
往期实录传送门:
 
DevOps&SRE深圳站资料全收录:

1)数人云王璞:《SRE在传统企业中的落地实践》

2)优维王津银:《DevOps与传统的融合落地实践及案例分析》

3)腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》

4)演讲视频回放:http://www.itdks.com/dakashuo/playback/404


DevOps&SRE北京站资料全收录:

1)数人云邱戈川:《不以敏捷开发为基础的DevOps都是耍流氓》

2)优维黄星玲:《教你如何打造易用DevOps工具链》

3)演讲视频回放:http://www.itdks.com/dakashuo/playback/908
 
分享嘉宾





林昭明/数人云技术总监
 
曾在亚信科技平台架构部、阿里巴巴B2B业务平台部,唯品会基础架构部,担任技术总监或技术专家角色。

主要技术研究方向是高并发、高性能的技术架构应用,微服务、大数据、云计算等。

15年IT老兵,长期负责电信级别支撑系统和互联网高并发行业的技术架构工作,具有丰富的大型软件系统技术架构和项目实施经验。


分享主题:《数人云分布式任务调度平台Octopus实践》
 





高洪涛/当当系统架构师
 
 
当当系统架构师,技术委员会成员,分布式存储技术专家,Oracle DBA OCP。有丰富的数据存储,管理经验。从2013年开始从事大规模分布式存储系统的设计与研发工作,参与大型云平台数据中间层建设工作,2015年加入当当。目前从事Elastic-Job-Cloud的设计,研发与运维工作。

分享主题:《当当基于Mesos的DevOps实践》

微软及神秘嘉宾持续更新中……
 
活动议程
 
13:30-14:00  签到
14:00-14:40   微软嘉宾分享
14:40-15:20  林昭明@数人云  《数人云分布式任务调度平台Octopus实践》
15:20-16:00   高洪涛@当当网  《当当基于Mesos的DevOps实践》
16:00-16:40  神秘嘉宾分享
16:40-17:00  自由交流
 
时间地点
 
8月19日(周六)下午14:00-17:00
北京海淀区中关村E世界A座B2 P2联合创业办公社
 
报名链接
点击报名
 
 

更多活动信息,欢迎关注数人云微信公众号




  查看全部
微信.jpg

Container技术在国内的落地实践,

已进阶Container+

8月阅兵仪式,一睹超强装备的风采,

技术圈也不落人后,

本次Meetup邀请到来自微软、当当、数人云的技术大牛以及一位神秘嘉宾,

共同来一场Container的大阅兵,

看Serverless、DevOps、微服务、CI/CD、分布式调度任务等技术,

在各个场景中与Container发生的碰撞与交互。

吹着空调唠唠嗑,一起开启夏日清凉模式!
 
 
往期实录传送门:
 
DevOps&SRE深圳站资料全收录:

1)数人云王璞:《SRE在传统企业中的落地实践》

2)优维王津银:《DevOps与传统的融合落地实践及案例分析》

3)腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》

4)演讲视频回放:http://www.itdks.com/dakashuo/playback/404


DevOps&SRE北京站资料全收录:

1)数人云邱戈川:《不以敏捷开发为基础的DevOps都是耍流氓》

2)优维黄星玲:《教你如何打造易用DevOps工具链》

3)演讲视频回放:http://www.itdks.com/dakashuo/playback/908
 
分享嘉宾

SR.png

林昭明/数人云技术总监
 
曾在亚信科技平台架构部、阿里巴巴B2B业务平台部,唯品会基础架构部,担任技术总监或技术专家角色。

主要技术研究方向是高并发、高性能的技术架构应用,微服务、大数据、云计算等。

15年IT老兵,长期负责电信级别支撑系统和互联网高并发行业的技术架构工作,具有丰富的大型软件系统技术架构和项目实施经验。


分享主题:《数人云分布式任务调度平台Octopus实践》
 

DD.png

高洪涛/当当系统架构师
 
 
当当系统架构师,技术委员会成员,分布式存储技术专家,Oracle DBA OCP。有丰富的数据存储,管理经验。从2013年开始从事大规模分布式存储系统的设计与研发工作,参与大型云平台数据中间层建设工作,2015年加入当当。目前从事Elastic-Job-Cloud的设计,研发与运维工作。

分享主题:《当当基于Mesos的DevOps实践》

微软及神秘嘉宾持续更新中……
 
活动议程
 
13:30-14:00  签到
14:00-14:40   微软嘉宾分享
14:40-15:20  林昭明@数人云  《数人云分布式任务调度平台Octopus实践》
15:20-16:00   高洪涛@当当网  《当当基于Mesos的DevOps实践》
16:00-16:40  神秘嘉宾分享
16:40-17:00  自由交流
 
时间地点
 
8月19日(周六)下午14:00-17:00
北京海淀区中关村E世界A座B2 P2联合创业办公社
 
报名链接
点击报名
 
 

更多活动信息,欢迎关注数人云微信公众号
QQ图片20170801103212.png

 

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

杨y 发表了文章 • 0 个评论 • 102 次浏览 • 2017-07-28 12:38 • 来自相关话题

数人云微信公众号后台回复“715活动”获取PPT






△扫码关注数人云微信公众号

7.15 上海·37℃ ☼

DevOps&SRE超越传统运维之道

由于之前的场地旁边装修,为了让大家有更好的体验,我们临时更换了场地,非常感谢顶着酷暑来参加活动的小伙伴们,现场座无虚席,小数心里美美哒:)












参会的小伙伴认真地做着笔记,会后惊喜地发现任聪同学写了一篇会议纪要,征得作者同意,小数把内容分享出来共勉,手动给这位同学点赞! 以下是这份笔记的详细内容:

参加DevOps&SRE运维会议纪要
参会简介

本人主要工作是开发,偶尔也会兼职管理下运维发布之事,但是对现代化DevOps不是很熟悉,因此此次参会的主要目的是了解他人是如何做DevOps的以及获取一些技术与工具的信息和运用,以便应用于工作当中。此次会议讲述了一些工作流程与理念、包括自研自动化工具等,这些让我还是有一点似懂非懂的感觉,但是还是有一些收获的(纯属个人总结,若有偏差欢迎指正):

理念

人是没有程序靠谱的,大量重复性工作,对人来说可能会犯错和误操作,而验证后的程序基本上不会出现这种问题。

人不是机器,需要休息。正如世界上没有完全一样的两个人,不同的人做的同样的事结果也不会一样。

一般情况,人的效率比不上程序、机器人(人与车赛跑,与AI下棋,都是一批高智商的人和团队协作出来的结果,若人肉PK,没有意义)。

运维工作有据可循,或者说在开发的配合下是有一定流程,因此这件事才比较容易交给程序去做(有创造性的要看AI的发展),因此我觉得现代化DevOps中的几个核心点是:标准化、流程化、自动化、简单化。像传统制造行业中的流水线一样,开发与运维依据几个核心点的指导下去配合完成工作,因此优维科技的刘劲辉说:DevOps是一种文化和精神,是组织的一种方式,是持续的学习。

提到的工具、框架简单介绍

Jenkins

一款持续集成的工具,能够通过代码Push等事件触发编译发布动作,可以减轻部署发布的工作,减少分布周期提高发布次数,能够及早的发现问题,节省项目的时间和成本,保证代码质量。

RobotFramework

RobotFramework是一款自动化测试框架,优维科技的测试框架在此工具上进行了二次开发。其大概方法是,编写接口按照规范注解注释@Param接口方法,自动生成测试代码,测试用例的数据作为代码进行维护,并且能通过面板看到测试用例运行的情况,出现问题会进行邮件通知。

洋葱登录(https://www.yangcong.com/)

洋葱登录是一款管理用户员工身份验证的产品,能够帮助企业提升员工权限的安全度,京东无线运维中的权限管理就是根据洋葱登录的功能来重构的。

Git-Flow

基于Git的强大分支能力所构建的一套软件开发工作流,通过分支与标签来进行版本管理。

详细英文介绍:(https://www.atlassian.com/git/ ... flows)

中文资料:(http://blog.jobbole.com/76843/)

数人云分享监控系统图

对于自动化来说,日志查询、监控、告警是极其重要和合理的,人不需要参与到工程中,但要掌握情况以便出现突发问题能及时有效的处理,下面这张图是数人云讲师分享的基于实践序列数据的监控系统图。






总结

本次会议主要偏向运维工作中的一些实际内容,几位讲师尽心尽责地分享切身感受,虽然我站在开发的角度,但还是有所收获,因为理念和一些工具是通用的。

分享人:任聪@上海咯叽网络科技有限公司

原文链接:http://www.jianshu.com/p/7f7d591852b8

收获了知识才是最重要的,也欢迎各位小伙伴在后续的活动中将心得笔记通过小数分享给大家~

嘉宾分享
(微信后台回复“715活动”获取PPT)






 
△张保珠@数人云 《SRE之道下金融行业的落地实践过程》






△刘劲辉@优维科技 《优维科技,内部产品研发DevOps实践》






△于绮@京东 《从传统运维到DevOps的落地经验及思考》







△周炎@东方财富网 《传统行业-运维人员如何应对企业DevOps转型》

数人云、优维科技、中生代——

感谢大家参与《DevOps&SRE超越传统运维之道·上海站》,

数人云微信公众号后台回复“715活动”获取PPT,

注意尊重嘉宾原创内容,

切勿滥传播,

敬请期待文字和视频整理: )

Ps:因内部信息不方便分享,故东方财富网和优维科技的PPT暂不外放,敬请谅解。





  查看全部
1.png


数人云微信公众号后台回复“715活动”获取PPT

10.png


△扫码关注数人云微信公众号

7.15 上海·37℃ ☼

DevOps&SRE超越传统运维之道

由于之前的场地旁边装修,为了让大家有更好的体验,我们临时更换了场地,非常感谢顶着酷暑来参加活动的小伙伴们,现场座无虚席,小数心里美美哒:)

2.png


3.png



参会的小伙伴认真地做着笔记,会后惊喜地发现任聪同学写了一篇会议纪要,征得作者同意,小数把内容分享出来共勉,手动给这位同学点赞! 以下是这份笔记的详细内容:

参加DevOps&SRE运维会议纪要
参会简介


本人主要工作是开发,偶尔也会兼职管理下运维发布之事,但是对现代化DevOps不是很熟悉,因此此次参会的主要目的是了解他人是如何做DevOps的以及获取一些技术与工具的信息和运用,以便应用于工作当中。此次会议讲述了一些工作流程与理念、包括自研自动化工具等,这些让我还是有一点似懂非懂的感觉,但是还是有一些收获的(纯属个人总结,若有偏差欢迎指正):

理念

人是没有程序靠谱的,大量重复性工作,对人来说可能会犯错和误操作,而验证后的程序基本上不会出现这种问题。

人不是机器,需要休息。正如世界上没有完全一样的两个人,不同的人做的同样的事结果也不会一样。

一般情况,人的效率比不上程序、机器人(人与车赛跑,与AI下棋,都是一批高智商的人和团队协作出来的结果,若人肉PK,没有意义)。

运维工作有据可循,或者说在开发的配合下是有一定流程,因此这件事才比较容易交给程序去做(有创造性的要看AI的发展),因此我觉得现代化DevOps中的几个核心点是:标准化、流程化、自动化、简单化。像传统制造行业中的流水线一样,开发与运维依据几个核心点的指导下去配合完成工作,因此优维科技的刘劲辉说:DevOps是一种文化和精神,是组织的一种方式,是持续的学习。

提到的工具、框架简单介绍

Jenkins

一款持续集成的工具,能够通过代码Push等事件触发编译发布动作,可以减轻部署发布的工作,减少分布周期提高发布次数,能够及早的发现问题,节省项目的时间和成本,保证代码质量。

RobotFramework

RobotFramework是一款自动化测试框架,优维科技的测试框架在此工具上进行了二次开发。其大概方法是,编写接口按照规范注解注释@Param接口方法,自动生成测试代码,测试用例的数据作为代码进行维护,并且能通过面板看到测试用例运行的情况,出现问题会进行邮件通知。

洋葱登录(https://www.yangcong.com/

洋葱登录是一款管理用户员工身份验证的产品,能够帮助企业提升员工权限的安全度,京东无线运维中的权限管理就是根据洋葱登录的功能来重构的。

Git-Flow

基于Git的强大分支能力所构建的一套软件开发工作流,通过分支与标签来进行版本管理。

详细英文介绍:(https://www.atlassian.com/git/ ... flows

中文资料:(http://blog.jobbole.com/76843/

数人云分享监控系统图

对于自动化来说,日志查询、监控、告警是极其重要和合理的,人不需要参与到工程中,但要掌握情况以便出现突发问题能及时有效的处理,下面这张图是数人云讲师分享的基于实践序列数据的监控系统图。

4.png


总结

本次会议主要偏向运维工作中的一些实际内容,几位讲师尽心尽责地分享切身感受,虽然我站在开发的角度,但还是有所收获,因为理念和一些工具是通用的。

分享人:任聪@上海咯叽网络科技有限公司

原文链接:http://www.jianshu.com/p/7f7d591852b8

收获了知识才是最重要的,也欢迎各位小伙伴在后续的活动中将心得笔记通过小数分享给大家~

嘉宾分享
(微信后台回复“715活动”获取PPT)


5.png

 
△张保珠@数人云 《SRE之道下金融行业的落地实践过程》

6.png


△刘劲辉@优维科技 《优维科技,内部产品研发DevOps实践》

7.png


△于绮@京东 《从传统运维到DevOps的落地经验及思考》


8.png


△周炎@东方财富网 《传统行业-运维人员如何应对企业DevOps转型》

数人云、优维科技、中生代——

感谢大家参与《DevOps&SRE超越传统运维之道·上海站》,

数人云微信公众号后台回复“715活动”获取PPT,

注意尊重嘉宾原创内容,

切勿滥传播,

敬请期待文字和视频整理: )

Ps:因内部信息不方便分享,故东方财富网和优维科技的PPT暂不外放,敬请谅解。

9.png

 

实践|SRE遇上金融老干部,解决发布协调&监控告警两大难题

杨y 发表了文章 • 0 个评论 • 111 次浏览 • 2017-07-28 12:29 • 来自相关话题

7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上,数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。






今天主要跟大家分享数人云SRE的落地实践,因为目标客户主要是金融行业,所以基于ITSM特性,介绍实际场景中的发布协调和监控告警。

SRE核心理念






SRE是谷歌十数年运维过程中演练出来的模式,在实践过程中积累了很多经验,跟传统运维有一些区别。是建立在DevOps的思想上的运维方面具体实践。






SRE岗位工作职责有:

应急相应
日常运维
工程研发

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别: 1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

2)日常运维包括容量规划、性能监控、并更管理。

3)工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化,自动化运维是长期目标,也是热点内容。






SRE的工作原则: 拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

自动化&简单化:开发的主要目的。

金融行业ITSM特性






金融行业在ITSM的特性主要是分级管理,工作模式上,运维和开发完全隔离,但这是DevOps思想尚未达成的表现。运维团队规模是线性增长的,如上线一个系统时都会分配1—2个运维人员进行跟进。不管从网络还是资源分配上,他们的职责更多在应急事件处理和常规变更上。

证监会和银监会有合规运维的要求,比如两地三个数据中心,这是金融行业比较明显的特性。






传统模式和SRE的区别—— 传统模式:易招聘,传统行业招聘的运维首先是会Shell,Python等脚本编写,在自动化运维工具上会有新要求,过往经验积累如曾解决的事故,应对的问题。

SRE:难招聘,相对新兴的岗位,很难找到完全匹配的人才;会有开发上的要求,强调自动化,包括在自动化工具里做编程性的内容,团队协作等等。






接下来分享SRE在两个客户实际场景的落地:某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图,资源供给层是基于数人云的PaaS平台,以Docker容器化管理做资源调动,应用调度分别基于Mesos和Marathon,目前数人云也开源了名为Swan(Mesos调度器,Github地址:https://github.com/Dataman-Cloud/swan 欢迎Star&Fork)的应用调度系统,目标是把Marathon替换掉。而后是软件技术架构层,对应公司里的架构部门,包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE,也有接近于用户数使用的APP SRE,所以个人理解这是长期的建设过程。

实践—发布协调






发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

金融行业里系统较多,包括信贷、信审等等诸多应用,系统逻辑也比较复杂。开发测试环境如物理环境完全隔离,和互联网行业不同。互联网行业,都是在线发布,测试环境也许就是生产环境,采用灰度发布或者蓝绿发布模式去做。

上线协调需要同时面对多个外包团队,外包团队人员相对不可控,导致沟通成本较高。

规模大的系统发布上线周期长。

如何解决以上问题,达到发布进入可控,降低发布失败率,缩短发布时间周期?






上述问题,在SRE的思想中,首先要建立发布协调团队。目前SRE工程师只能自行培养。团队推荐构成:项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主,不断Check系统或者产品开展工作。






团队的职责包括:审核新产品和内部服务,确保预期的性能指标和非性能指标。根据发布的任务进度,负责发布过程中技术相关问题,以及协调外包公司的开发进度等等。

最重要的是要做到发布过程中的守门员,系统是否上线要由发布协调团队决定。






团队在整个服务生命周期过程中,不同阶段,都要进行会议审核才能继续开展工作。会议根据发布的检查列表包括三个方面:架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构,部署架构,包括请求数据流的顺序,检查负载均衡,日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告做容量预估,以及峰值,比如微信活动比较多,所以会根据预估峰值的公司预算出来需要的资源,再落实到容器上,制定详细计划保障发布的成功率。

制定发布计划,确保成功。






在SRE的指导中,每件事都要落实到工具当中,由工具去检查每个事项是否落实到位。当时做了发布平台,包括PipeLine、Jenkins,通过其调用负载均衡上的配置F5和配置中心,以及服务注册中心的机制。所有的发布事项基于容器云平台,功能模块包括变更管理、发布管理、流程模板及发布过程监控。






上图是发布平台项目大盘图,可以看到项目在发布流程中执行情况——成功率和失败率。没有发布平台前,整个上线过程管理人员不能实时看到发布具体情况,是卡在网络还是某一个服务上,因此进度不可控。

有了这样的运维大盘后,整个发布过程能进行可视化跟踪,关键节点需要人工审核。

具体的发布步骤:

第一,检查F5里面的配置
第二,人工检查
第三,上传程序包,配置项管理
最后,重启容器再进行人工检查

整体过程都体现了SRE思想,发布平台的每个步骤均可通过界面配置完成,中间关键点由人工参与,目的是保障产品上线的成功率,避免在上线过程中手动配置产生问题,导致回滚事件发生。






有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

实践—监控告警






监控作为一个垂直系统,在数人云的产品体系中举足轻重。监控的重要性深有体会,我们在某金融公司SRE团队中有1—2名监控专员,专员主要职责是维护监控系统。一个是甲方内部人员,另一个是数人云的同事。

监控主要解决的问题: 首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。






上图为监控系统架构图,基于Prometheus的时序数据库,红线为监控的数据流向,因是Mesos框架,所以左边会看到Mesos运算节点上的监控项。通过容器化的Cadvisor组件收集主机和该主机所有容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件,支持Webhook方式,通过短信、邮件形式告警。为了事后总结,需将一些告警事件存在数据库中。

绿线主要体现在日志收集和关键字告警,日志收集通过容器化的Logstash组件,首先收集容器内部的中间件,如Tomcat等Web中间件的日志,也能收集应用日志,根据需要会把一些信息丢到Kafka里面,通过大数据平台做在线日志分析。






日志关键字告警是通过自研组件在日志传输过程中过滤关键字进行事件告警。

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。






在SRE体系里很明确提到了监控的4大黄金指标:延迟、流量、错误、饱和度:

延迟:监控服务的API以及URL的访问时间,直接配置某一个服务的URL,后台不断去访问,包括访问时间的预值,超过时间发出告警。

流量:负载均衡请求的连接数。

错误:监控HTTP请求返回码和日志中异常关键字。

饱和度:根据不同的系统,如内存资源性系统监控内存使用率,IO读写使用比较高,监控资源IO情况。

以上指标要在运维的过程中不断优化,如一些告警可能是网络原因进而产生其他问题,如网络交换机出现问题,直接挂掉平台的Marathon组件,应用上很明显是第三方服务调用,接连会产生很多问题,要把共性问题聚合,减少误告警次数。但减少误告警也可能会把有效告警卡掉,也值得思考。






故障跟踪和事后总结类似,人工操作会延长恢复时间,告警发生时一般由一个人处理,随着时间延长而升级策略,如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主,处女座强迫症为辅,做好





事故总结非常重要,解决不意味着结束,要追溯原因,如交换机重启,导致Marathon的一些问题,总结后发现,最好的解决办法是交换机重启时通知运维,停掉相关组件,交换机恢复后,再启动,如此不影响业务的实际运行。

要从失败中学习,把告警的事件做记录建立知识库,发生问题时方便检索,快速找到解决方案,要总结解决某个事故时如何更快发现问题所在,建立反馈机制,在SRE监控过程中,不断跟产品做实时反馈,包括连接池的使用情况等,鼓励主动测试,平时运维不会发生的事,尽可能想办法去看结果。

目标定位






SRE目标定位内容很多,在各个行业落地时不尽相同,所以要基于现实,拥抱变化,为了更好应对事故,坚持做推演和演练,在事故总结方面对产品做建言,故此在工具的研发上也会有决策权。
 
更多精彩文章,欢迎关注数人云公众号:





 
  查看全部
1.png


7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上,数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。

2.png


今天主要跟大家分享数人云SRE的落地实践,因为目标客户主要是金融行业,所以基于ITSM特性,介绍实际场景中的发布协调和监控告警。

SRE核心理念

3.png


SRE是谷歌十数年运维过程中演练出来的模式,在实践过程中积累了很多经验,跟传统运维有一些区别。是建立在DevOps的思想上的运维方面具体实践。

4.png


SRE岗位工作职责有:

应急相应
日常运维
工程研发

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别: 1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

2)日常运维包括容量规划、性能监控、并更管理。

3)工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化,自动化运维是长期目标,也是热点内容。

5.png


SRE的工作原则: 拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

自动化&简单化:开发的主要目的。

金融行业ITSM特性

6.png


金融行业在ITSM的特性主要是分级管理,工作模式上,运维和开发完全隔离,但这是DevOps思想尚未达成的表现。运维团队规模是线性增长的,如上线一个系统时都会分配1—2个运维人员进行跟进。不管从网络还是资源分配上,他们的职责更多在应急事件处理和常规变更上。

证监会和银监会有合规运维的要求,比如两地三个数据中心,这是金融行业比较明显的特性。

7.png


传统模式和SRE的区别—— 传统模式:易招聘,传统行业招聘的运维首先是会Shell,Python等脚本编写,在自动化运维工具上会有新要求,过往经验积累如曾解决的事故,应对的问题。

SRE:难招聘,相对新兴的岗位,很难找到完全匹配的人才;会有开发上的要求,强调自动化,包括在自动化工具里做编程性的内容,团队协作等等。

8.png


接下来分享SRE在两个客户实际场景的落地:某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图,资源供给层是基于数人云的PaaS平台,以Docker容器化管理做资源调动,应用调度分别基于Mesos和Marathon,目前数人云也开源了名为Swan(Mesos调度器,Github地址:https://github.com/Dataman-Cloud/swan 欢迎Star&Fork)的应用调度系统,目标是把Marathon替换掉。而后是软件技术架构层,对应公司里的架构部门,包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE,也有接近于用户数使用的APP SRE,所以个人理解这是长期的建设过程。

实践—发布协调

9.png


发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

金融行业里系统较多,包括信贷、信审等等诸多应用,系统逻辑也比较复杂。开发测试环境如物理环境完全隔离,和互联网行业不同。互联网行业,都是在线发布,测试环境也许就是生产环境,采用灰度发布或者蓝绿发布模式去做。

上线协调需要同时面对多个外包团队,外包团队人员相对不可控,导致沟通成本较高。

规模大的系统发布上线周期长。

如何解决以上问题,达到发布进入可控,降低发布失败率,缩短发布时间周期?

10.png


上述问题,在SRE的思想中,首先要建立发布协调团队。目前SRE工程师只能自行培养。团队推荐构成:项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主,不断Check系统或者产品开展工作。

11.png


团队的职责包括:审核新产品和内部服务,确保预期的性能指标和非性能指标。根据发布的任务进度,负责发布过程中技术相关问题,以及协调外包公司的开发进度等等。

最重要的是要做到发布过程中的守门员,系统是否上线要由发布协调团队决定。

12.png


团队在整个服务生命周期过程中,不同阶段,都要进行会议审核才能继续开展工作。会议根据发布的检查列表包括三个方面:架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构,部署架构,包括请求数据流的顺序,检查负载均衡,日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告做容量预估,以及峰值,比如微信活动比较多,所以会根据预估峰值的公司预算出来需要的资源,再落实到容器上,制定详细计划保障发布的成功率。

制定发布计划,确保成功。

13.png


在SRE的指导中,每件事都要落实到工具当中,由工具去检查每个事项是否落实到位。当时做了发布平台,包括PipeLine、Jenkins,通过其调用负载均衡上的配置F5和配置中心,以及服务注册中心的机制。所有的发布事项基于容器云平台,功能模块包括变更管理、发布管理、流程模板及发布过程监控。

14.png


上图是发布平台项目大盘图,可以看到项目在发布流程中执行情况——成功率和失败率。没有发布平台前,整个上线过程管理人员不能实时看到发布具体情况,是卡在网络还是某一个服务上,因此进度不可控。

有了这样的运维大盘后,整个发布过程能进行可视化跟踪,关键节点需要人工审核。

具体的发布步骤:

第一,检查F5里面的配置
第二,人工检查
第三,上传程序包,配置项管理
最后,重启容器再进行人工检查

整体过程都体现了SRE思想,发布平台的每个步骤均可通过界面配置完成,中间关键点由人工参与,目的是保障产品上线的成功率,避免在上线过程中手动配置产生问题,导致回滚事件发生。

15.png


有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

实践—监控告警

16.png


监控作为一个垂直系统,在数人云的产品体系中举足轻重。监控的重要性深有体会,我们在某金融公司SRE团队中有1—2名监控专员,专员主要职责是维护监控系统。一个是甲方内部人员,另一个是数人云的同事。

监控主要解决的问题: 首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。

17.png


上图为监控系统架构图,基于Prometheus的时序数据库,红线为监控的数据流向,因是Mesos框架,所以左边会看到Mesos运算节点上的监控项。通过容器化的Cadvisor组件收集主机和该主机所有容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件,支持Webhook方式,通过短信、邮件形式告警。为了事后总结,需将一些告警事件存在数据库中。

绿线主要体现在日志收集和关键字告警,日志收集通过容器化的Logstash组件,首先收集容器内部的中间件,如Tomcat等Web中间件的日志,也能收集应用日志,根据需要会把一些信息丢到Kafka里面,通过大数据平台做在线日志分析。

18.png


日志关键字告警是通过自研组件在日志传输过程中过滤关键字进行事件告警。

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。

19.png


在SRE体系里很明确提到了监控的4大黄金指标:延迟、流量、错误、饱和度:

延迟:监控服务的API以及URL的访问时间,直接配置某一个服务的URL,后台不断去访问,包括访问时间的预值,超过时间发出告警。

流量:负载均衡请求的连接数。

错误:监控HTTP请求返回码和日志中异常关键字。

饱和度:根据不同的系统,如内存资源性系统监控内存使用率,IO读写使用比较高,监控资源IO情况。

以上指标要在运维的过程中不断优化,如一些告警可能是网络原因进而产生其他问题,如网络交换机出现问题,直接挂掉平台的Marathon组件,应用上很明显是第三方服务调用,接连会产生很多问题,要把共性问题聚合,减少误告警次数。但减少误告警也可能会把有效告警卡掉,也值得思考。

20.png


故障跟踪和事后总结类似,人工操作会延长恢复时间,告警发生时一般由一个人处理,随着时间延长而升级策略,如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主,处女座强迫症为辅,做好
21.png


事故总结非常重要,解决不意味着结束,要追溯原因,如交换机重启,导致Marathon的一些问题,总结后发现,最好的解决办法是交换机重启时通知运维,停掉相关组件,交换机恢复后,再启动,如此不影响业务的实际运行。

要从失败中学习,把告警的事件做记录建立知识库,发生问题时方便检索,快速找到解决方案,要总结解决某个事故时如何更快发现问题所在,建立反馈机制,在SRE监控过程中,不断跟产品做实时反馈,包括连接池的使用情况等,鼓励主动测试,平时运维不会发生的事,尽可能想办法去看结果。

目标定位

22.png


SRE目标定位内容很多,在各个行业落地时不尽相同,所以要基于现实,拥抱变化,为了更好应对事故,坚持做推演和演练,在事故总结方面对产品做建言,故此在工具的研发上也会有决策权。
 
更多精彩文章,欢迎关注数人云公众号:

9.png