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

杨y 发表了文章 • 0 个评论 • 108 次浏览 • 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 个评论 • 101 次浏览 • 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 个评论 • 177 次浏览 • 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 个评论 • 157 次浏览 • 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 个评论 • 201 次浏览 • 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 个评论 • 205 次浏览 • 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

 
 

程序员工作中绕不开的9大问题,你遇到过几个?

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

 
 
最近朋友圈被《北京,有2000万人在假装生活》刷屏了,特大妹昨天的文章里说,作为一个程序猿,有了BUG就没有了生活。在工作中难免会遇到各种各样的问题,今天小数就列举程序员常见的9个问题,及解题思路,我们程序员从来不假装,哼!


1以用户为中心







在开发过程中,以用户为中心不是一个选项,而是要最优先考虑的事情,要知道水能载舟亦能覆舟,如果你不以甲方粑粑为中心,那么TA可能根本不Care你开发出来的产品,所以必须以用户为中心了解他们的需求。

解决办法:

与直面用户的人交谈:想要理解用户,就需与运营人员、用户体验师、设计师去交流,他们的洞察会给你的代码指明方向。

测试版本:如苹果这样的巨头公司在正式版上线之前,通常会发布Bata版本,观察用户的反应,通过反馈完善用户体验及修复BUG。


2调试








你以为你的应用会按照你以为的那样运行吗?NO!测试童鞋拿出一长串的BUG表单在你美梦的尽头等着你:Web表单上的取消按钮无法点击、错误消息上的语法不对等等,都会导致用户体验上的问题,有些BUG很容易调试,有些则不然,会减少开发工作的时间而且让人沮丧不已。

解决办法:

重写:在此过程中,理解它们为什么发生,进而解决问题。

得到帮助:当项目的工期将尽,很多程序员往往先恐慌后才去思考,如果没时间重写,可以让测试人员帮助一起调试。


3掌握最IN技术







俗话说:“落后就要挨打”,技术在不断发展,现有框架、工具、库等可能会很快过时,如前端框架通常1—2年就会更新迭代,从某种意义上说,新版本更高效使工作更容易,但也需要时间去适应。


解决办法:

花时间学习新系统:每天挤出20—30分钟的时间学习新工具的工作方式,如果认为新版本(工具)可以更好地工作,那么在业余时间去学习如何使用以改进工作流程。

跟上最新的趋势:将阅读作为每天必做的事情,哪怕工作繁忙,新趋势带来的帮助意义非凡,可以开发出更多的创新产品。


4沟通







程序员们大都是Shy Boy,换了新的工作和环境后和周遭同事不熟,会犹豫是否要与他们进行沟通,从代码到公司等等,很多程序员在某个时刻都面临着这个问题,不要觉得只要把自己的任务完成就没问题了,它可能会引发一些冲突。


解决办法:

积极主动:不要害怕向同事提问,尤其是在工作中遇到的任何问题,当向别人敞开心扉,也会更快地适应公司的文化,如果十分内向,那么提升自信是必须要做的事情。

提炼语言:有时候表达的不够准确直接,进而无法阐述问题,要从中吸取经验,练习话术,争取下次做的更好。

学习&分享:目前技术类型的线下活动越来越多,曾经很多害羞的程序员小伙伴都走上台分享技术经验同时也有不少善于总结的人开通了技术专栏,粉丝无数,惊不惊喜?开不开心?不如行动吧。

5时间预估






作为报价和项目时间表的基础,预估在开发中非常重要,程序员会被要求提供如调试代码在Sprint中完成某些特性工作所需的时间。你想获得更多的时间完成一项任务,给老板留下好印象,同时也提升了应用质量,不过你的团队可能会是另外一种看法,因为这样会拖慢进度。

解决办法:

分解任务:将任务进行拆分,是更容易和更好的管理办法,测试只在你工作中发现了十几个错误吗?将每个BUG看做一个迷你的任务,并预估完成每项任务可能需要花费的时间。

预留时间:给每个任务设定完成的时间框架,不过也要给自己一个缓冲,如任务通常需要20分钟,那么在将时间框架设定为30分钟。


6持续久坐






在开发过程中,长时间坐着也是工作的一部分,腰酸背痛腿抽筋这些毛病可能会来找你的麻烦,研究表明,每天坐5个小时以上会产生严重的健康风险,如心脑血管疾病和肥胖症(不禁摸了摸小肚腩),同时也会让人在白天感到更困倦。

解决办法:

站起来:站着工作可以减轻背部压力,改善血液循环,让人有效地进行工作,一些企业甚至投资于高度可调的办公桌,让员工更容易站着工作。

做运动:程序员会经常感到疲倦,没有动力,为了缓解压力,让身体接受一些锻炼,即便是工作前30分钟的散步或慢跑也能让人一整天工作得更好,如果没有时间,那就散散步,吃点东西或喝杯咖啡。


7安全问题







数据的价值极高,很多人愿意为数据花费很高的代价,(小数已经天天被推销、骚扰电话烦死惹。)而且竞争对手想窥探正在开发的秘密项目(如市场营销或企业软件)。

作为程序员,是保证客户信息不受威胁的依靠,但很多程序员将关注点放在代码的正确性而不是安全性上,黑客知道这一弱点,并一直在寻找渗透方式。

解决办法:

为SQL注入参数化查询:攻击者可以使用SQL注入来窃取数据,如用户的登录信息,为防止这种攻击,应在编程语言中使用参数化查询。

保持工作站安全:有威胁者未必在网上,如被解雇的员工可能会通过系统窃取或修改一个项目的数据报复老板,所以在使用完应用后,要从软件中注销。


8善用代码






程序员在某些时候不得不为别人创造的项目工作,如在开发时中需要编写另外一个开发人员编写的代码。

之前的程序员没向任何人交接工作就拍拍屁股走人离职了,或者虽然在职但忙的焦头烂额无法回答任何问题,最坏的情况是办公室政治,他们不愿意帮你弄清楚代码。


解决办法:

善用遗留代码:需要转变态度,如果有人将代码留下来,那么这些代码就是你的工作了。

花更多的时间阅读代码:花一些时间了解其他开发人员的工作、方法和风格,一旦完成这一操作,将会更容易适应。


9学会规划代码







得到新工作,想证明自己获得良好的第一印象,所以急于地找键盘,敲代码,但那些代码在你脑海里可能是有意义的,却与实际方向背道而驰。

解决办法:

从一个想法开始:每个应用都以一个想法开始,如你想要开发的应用可以提醒用户的约会时间,如此,可以让你更专注地写所要代码。

使用思维导图找出用户问题:有了想法后将它画出来,从产品将要解决的问题开始,把想法写在纸上,并为它创建子主题,如想法是用于提醒约会的应用,那么子主题可能就是用户需要它的原因(如:用户有太多的约会要留意。)
 
 
更多精彩文章:欢迎关注数人云公众号





  查看全部
 
 
最近朋友圈被《北京,有2000万人在假装生活》刷屏了,特大妹昨天的文章里说,作为一个程序猿,有了BUG就没有了生活。在工作中难免会遇到各种各样的问题,今天小数就列举程序员常见的9个问题,及解题思路,我们程序员从来不假装,哼!


1以用户为中心

1.jpg



在开发过程中,以用户为中心不是一个选项,而是要最优先考虑的事情,要知道水能载舟亦能覆舟,如果你不以甲方粑粑为中心,那么TA可能根本不Care你开发出来的产品,所以必须以用户为中心了解他们的需求。

解决办法:

与直面用户的人交谈:想要理解用户,就需与运营人员、用户体验师、设计师去交流,他们的洞察会给你的代码指明方向。

测试版本:如苹果这样的巨头公司在正式版上线之前,通常会发布Bata版本,观察用户的反应,通过反馈完善用户体验及修复BUG。


2调试


2.jpg



你以为你的应用会按照你以为的那样运行吗?NO!测试童鞋拿出一长串的BUG表单在你美梦的尽头等着你:Web表单上的取消按钮无法点击、错误消息上的语法不对等等,都会导致用户体验上的问题,有些BUG很容易调试,有些则不然,会减少开发工作的时间而且让人沮丧不已。

解决办法:

重写:在此过程中,理解它们为什么发生,进而解决问题。

得到帮助:当项目的工期将尽,很多程序员往往先恐慌后才去思考,如果没时间重写,可以让测试人员帮助一起调试。


3掌握最IN技术


3.jpg


俗话说:“落后就要挨打”,技术在不断发展,现有框架、工具、库等可能会很快过时,如前端框架通常1—2年就会更新迭代,从某种意义上说,新版本更高效使工作更容易,但也需要时间去适应。


解决办法:

花时间学习新系统:每天挤出20—30分钟的时间学习新工具的工作方式,如果认为新版本(工具)可以更好地工作,那么在业余时间去学习如何使用以改进工作流程。

跟上最新的趋势:将阅读作为每天必做的事情,哪怕工作繁忙,新趋势带来的帮助意义非凡,可以开发出更多的创新产品。


4沟通


4.jpg


程序员们大都是Shy Boy,换了新的工作和环境后和周遭同事不熟,会犹豫是否要与他们进行沟通,从代码到公司等等,很多程序员在某个时刻都面临着这个问题,不要觉得只要把自己的任务完成就没问题了,它可能会引发一些冲突。


解决办法:

积极主动:不要害怕向同事提问,尤其是在工作中遇到的任何问题,当向别人敞开心扉,也会更快地适应公司的文化,如果十分内向,那么提升自信是必须要做的事情。

提炼语言:有时候表达的不够准确直接,进而无法阐述问题,要从中吸取经验,练习话术,争取下次做的更好。

学习&分享:目前技术类型的线下活动越来越多,曾经很多害羞的程序员小伙伴都走上台分享技术经验同时也有不少善于总结的人开通了技术专栏,粉丝无数,惊不惊喜?开不开心?不如行动吧。

5时间预估

5.jpg


作为报价和项目时间表的基础,预估在开发中非常重要,程序员会被要求提供如调试代码在Sprint中完成某些特性工作所需的时间。你想获得更多的时间完成一项任务,给老板留下好印象,同时也提升了应用质量,不过你的团队可能会是另外一种看法,因为这样会拖慢进度。

解决办法:

分解任务:将任务进行拆分,是更容易和更好的管理办法,测试只在你工作中发现了十几个错误吗?将每个BUG看做一个迷你的任务,并预估完成每项任务可能需要花费的时间。

预留时间:给每个任务设定完成的时间框架,不过也要给自己一个缓冲,如任务通常需要20分钟,那么在将时间框架设定为30分钟。


6持续久坐

6.jpg


在开发过程中,长时间坐着也是工作的一部分,腰酸背痛腿抽筋这些毛病可能会来找你的麻烦,研究表明,每天坐5个小时以上会产生严重的健康风险,如心脑血管疾病和肥胖症(不禁摸了摸小肚腩),同时也会让人在白天感到更困倦。

解决办法:

站起来:站着工作可以减轻背部压力,改善血液循环,让人有效地进行工作,一些企业甚至投资于高度可调的办公桌,让员工更容易站着工作。

做运动:程序员会经常感到疲倦,没有动力,为了缓解压力,让身体接受一些锻炼,即便是工作前30分钟的散步或慢跑也能让人一整天工作得更好,如果没有时间,那就散散步,吃点东西或喝杯咖啡。


7安全问题


7.jpg


数据的价值极高,很多人愿意为数据花费很高的代价,(小数已经天天被推销、骚扰电话烦死惹。)而且竞争对手想窥探正在开发的秘密项目(如市场营销或企业软件)。

作为程序员,是保证客户信息不受威胁的依靠,但很多程序员将关注点放在代码的正确性而不是安全性上,黑客知道这一弱点,并一直在寻找渗透方式。

解决办法:

为SQL注入参数化查询:攻击者可以使用SQL注入来窃取数据,如用户的登录信息,为防止这种攻击,应在编程语言中使用参数化查询。

保持工作站安全:有威胁者未必在网上,如被解雇的员工可能会通过系统窃取或修改一个项目的数据报复老板,所以在使用完应用后,要从软件中注销。


8善用代码

8.jpg


程序员在某些时候不得不为别人创造的项目工作,如在开发时中需要编写另外一个开发人员编写的代码。

之前的程序员没向任何人交接工作就拍拍屁股走人离职了,或者虽然在职但忙的焦头烂额无法回答任何问题,最坏的情况是办公室政治,他们不愿意帮你弄清楚代码。


解决办法:

善用遗留代码:需要转变态度,如果有人将代码留下来,那么这些代码就是你的工作了。

花更多的时间阅读代码:花一些时间了解其他开发人员的工作、方法和风格,一旦完成这一操作,将会更容易适应。


9学会规划代码


9.jpg


得到新工作,想证明自己获得良好的第一印象,所以急于地找键盘,敲代码,但那些代码在你脑海里可能是有意义的,却与实际方向背道而驰。

解决办法:

从一个想法开始:每个应用都以一个想法开始,如你想要开发的应用可以提醒用户的约会时间,如此,可以让你更专注地写所要代码。

使用思维导图找出用户问题:有了想法后将它画出来,从产品将要解决的问题开始,把想法写在纸上,并为它创建子主题,如想法是用于提醒约会的应用,那么子主题可能就是用户需要它的原因(如:用户有太多的约会要留意。)
 
 
更多精彩文章:欢迎关注数人云公众号

9.png

 

从0到1,打造DevOps易用工具链(精挑细选27种)

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

数人云:DevOps是一种文化,但创立或改变文化技术和工具必不可少,今天小数就和大家分享下覆盖整个生命周期的易用工具链。

DevOps操作上越来越成熟不是一蹴而就的,而是使用了一些新的工具,在团队内不仅改变了文化,同时也打破了沟通上的壁垒,进而开发出更好的应用,虽然仅靠工具还不够,但通过应用自动化,在提高了交付效率和质量的同时也促进了成员之间的协作。

对于如何构建DevOps工具链,没有标准的答案,而是要取决于团队规模和具体需求,这里从Netflix、Etsy,Dropbox等公司汲取了相关经验,分享一些在应用交付生命周期的每个阶段,一些受欢迎的工具。






构建工具
〓 项目管理

瀑布式开发要规划出所有的工作和每个版本的依赖关系,这与DevOps理念背道而驰,而敏捷开发,可以通过构建、测试应用收集用户反馈来降低风险提高可见性,这也是许多团队在Sprint(敏捷开发的四种会议)提出构建到发布用2—4周的时间。

当团队在每个Sprint时分享想法和计划时,要考虑之前Sprint的回顾反馈,不断优化方案。此后将这些构思上传到一些工具当中,可以跟踪项目的整体和每日进度。推荐的工具有:

Active Collab:基于Web、开源的协作开发与项目管理工具,可以利用它轻松地搭建一个包括团队和项目客户能够 在同一个项目上实现相互协作的环境

VersionOne:支持SaaS模式和本地安装模式,web客户端,支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。 Jira:被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Trello:由著名的软件工程师 Joel Spolsky 开发工作围绕“木板(board)”进行,同一小组的用户可以在这里创建待办事项列表(to do list)、创建任务,并分配给同事。

〓 代码&SCM系统

所有的构建都可以用代码来表示,在上线之前,需要测试和复查,并将其合并到一个版本控制库中的主分支当中,并在可以进行任何本地测试,推荐工具有:

GitHub:GitHub是一个基于web的Git或版本控制库。

Gitlab:提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki。

Bitbucket:源代码托管网站,采用Mercurial和Git作为分布式版本控制系统。

〓 CI平台

持续集成(CI)是现代软件开发的最佳实践,通过建立有效的持续集成环境可以减少集成问题、提高代码质量、改善团队成员之间的沟通和协作、快速迭代等,推荐的工具和平台有:

Jenkins:基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

CodeShip:部署快,易损耗、成本低。易用性比肩Travis,而更胜一筹的是集成了相当数量的选项,可以根据自身的工作流程和开发工具定制化CI/CD工作流。

Bamboo:具有开箱即用的特性,可在硬件上运营。Bamboo是一个聚焦企业级的解决方案,并且包含具有极强竞争力的特性、定价和技术支持等。可以部署在大规模生产环境中。

CodeFresh:虽然CodeFresh不是典型的CI/CD平台,但它提供了一种有趣的应用场景,在容器上使用CI/CD从而促进Docker,Kubernetes和云原生的发展前景。

〓 测试

为了实现DevOps所需的业务目标,为确保将代码推向生产是安全的,需要进行大量测试:单元测试、集成测试、验收测试等,测试完成后,还有大量开源和付费工具可以做一些其他事情,推荐的工具有:

JUnit:一个用于编写可重复测试的简单框架。

Mocha:简单、灵活有趣的JavaScript测试框架。

CircleCi:Web应用程序开发测试平台。

发布工具
〓 自动化部署

发布自动化工具应具备例如自动回滚等功能,在开始部署之前将模块复制到主机,如果企业规模较大,可以轻松地安装代理并将防火墙配置到服务器实例中。

许多团队还使用基于聊天的部署工作流,让机器人部署简单的命令。推荐的工具有:

Bamboo:采用自动化管理的构建代理模式,运行在各种专用服务器或云服务器上的代理实现了构建能力的即时动态扩展。通过与Jira集成可以实现完整的发布流程

Puppet:一个开源的软件自动化配置和部署工具,基于C/S架构的。服务器端保存着所有对客户端服务器的配置代码,在Puppet里面叫Manifest,客户端下载Manifest之后,可以根据Manifest对服务器进行配置,例如软件包管理,用户管理和文件管理等等。

Superviso:一个客户/服务器系统,允许用户监控和控制类似Unix的操作系统上的许多进程。

Forever:简单的CLI工具,用于确保给定的脚本连续运行。

监控工具
〓 部署监控

部署监控让高级别的发布进入和需求状态可视化,是理解服务健康与否的关键,确保CI服务器上发生的关键事件并及时告警。推荐的工具有:

Datadog:专门针对 DevOps 团队,从APP或者其他各种工具获取数据并提供数据可视化功能。将从基础设备和应用采集的数据统一处理并存储。

ElasticStack:一系列开源产品的合集,包括 Elasticsearch、Kibana、Logstash以及 Beats 等等,提供了很多数据分析领域的功能,如 Pipeline Aggregation。

〓 服务器监控

服务器监控提供了一个基础结构级别的视图,许多团队还使用日志聚合来深入研究特定问题,可以聚合及度量如:内存、CPU、负载均衡等,使工程师能在问题发生时迅速做出响应。推荐的工具有:

PagerDuty:能够在服务器出问题时发送提醒的软件。在发生问题时,提醒的方式包括屏幕显示、电话呼叫、短信通知、电邮通知等,而且在无人应答时还会自动将提醒级别提高。

Nagios:是一款开源的免费网络监视工具,能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员

Solarwinds:主要提供企业的网络管理和监控,可以帮助网管进行配置,监控和管理日趋复杂的系统和构建网络基础构架的流程。

〓 应用性能监控

应用性能监控为应用和业务服务的性能及可用性提供了代码级的可见性,让快速理解性能指标和满足服务SLA更加轻松。推荐的工具有:

DynaTrace:在整个生命周期过程中会对Web和非Web业务关键应用程序的监控、管理和优化方式进行转换。可快速解析性能问题并将问题范围隔离定位到确切的代码行。

AppDynamics:能提供端到端的、可视化驱动管理的的平台。核心理念是SEE可视化、ACT快速解决还有KNOW实时分析。

终极工具
〓 云

云计算目前的主要厂商是亚马逊的AWS、微软的Azure、Google的(GCP)。在PaaS层,可以访问和创建如数据库和分析之类的应用服务且不用考虑如操作系统、防火墙配置或存储之类的基础设施。

〓 Docker

Docker是一个开放的平台,将开发、传输和运行在容器这种隔离的环境中。容器封装了专用的文件系统、存储、CPU、RAM和其他需求的应用,保证这些应用在不虚拟化硬件的情况下持续运行且保持一致。Docker是可移植的、轻量级的,很容易进行安装。

〓 Swan

数人云Swan是基于Mesos实现的开源应用调度框架,帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

Swan Github地址 欢迎Star&Fork 查看全部
数人云:DevOps是一种文化,但创立或改变文化技术和工具必不可少,今天小数就和大家分享下覆盖整个生命周期的易用工具链。

DevOps操作上越来越成熟不是一蹴而就的,而是使用了一些新的工具,在团队内不仅改变了文化,同时也打破了沟通上的壁垒,进而开发出更好的应用,虽然仅靠工具还不够,但通过应用自动化,在提高了交付效率和质量的同时也促进了成员之间的协作。

对于如何构建DevOps工具链,没有标准的答案,而是要取决于团队规模和具体需求,这里从Netflix、Etsy,Dropbox等公司汲取了相关经验,分享一些在应用交付生命周期的每个阶段,一些受欢迎的工具。

1.png


构建工具
〓 项目管理

瀑布式开发要规划出所有的工作和每个版本的依赖关系,这与DevOps理念背道而驰,而敏捷开发,可以通过构建、测试应用收集用户反馈来降低风险提高可见性,这也是许多团队在Sprint(敏捷开发的四种会议)提出构建到发布用2—4周的时间。

当团队在每个Sprint时分享想法和计划时,要考虑之前Sprint的回顾反馈,不断优化方案。此后将这些构思上传到一些工具当中,可以跟踪项目的整体和每日进度。推荐的工具有:

Active Collab:基于Web、开源的协作开发与项目管理工具,可以利用它轻松地搭建一个包括团队和项目客户能够 在同一个项目上实现相互协作的环境

VersionOne:支持SaaS模式和本地安装模式,web客户端,支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。 Jira:被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Trello:由著名的软件工程师 Joel Spolsky 开发工作围绕“木板(board)”进行,同一小组的用户可以在这里创建待办事项列表(to do list)、创建任务,并分配给同事。

〓 代码&SCM系统

所有的构建都可以用代码来表示,在上线之前,需要测试和复查,并将其合并到一个版本控制库中的主分支当中,并在可以进行任何本地测试,推荐工具有:

GitHub:GitHub是一个基于web的Git或版本控制库。

Gitlab:提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki。

Bitbucket:源代码托管网站,采用Mercurial和Git作为分布式版本控制系统。

〓 CI平台

持续集成(CI)是现代软件开发的最佳实践,通过建立有效的持续集成环境可以减少集成问题、提高代码质量、改善团队成员之间的沟通和协作、快速迭代等,推荐的工具和平台有:

Jenkins:基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

CodeShip:部署快,易损耗、成本低。易用性比肩Travis,而更胜一筹的是集成了相当数量的选项,可以根据自身的工作流程和开发工具定制化CI/CD工作流。

Bamboo:具有开箱即用的特性,可在硬件上运营。Bamboo是一个聚焦企业级的解决方案,并且包含具有极强竞争力的特性、定价和技术支持等。可以部署在大规模生产环境中。

CodeFresh:虽然CodeFresh不是典型的CI/CD平台,但它提供了一种有趣的应用场景,在容器上使用CI/CD从而促进Docker,Kubernetes和云原生的发展前景。

〓 测试

为了实现DevOps所需的业务目标,为确保将代码推向生产是安全的,需要进行大量测试:单元测试、集成测试、验收测试等,测试完成后,还有大量开源和付费工具可以做一些其他事情,推荐的工具有:

JUnit:一个用于编写可重复测试的简单框架。

Mocha:简单、灵活有趣的JavaScript测试框架。

CircleCi:Web应用程序开发测试平台。

发布工具
〓 自动化部署

发布自动化工具应具备例如自动回滚等功能,在开始部署之前将模块复制到主机,如果企业规模较大,可以轻松地安装代理并将防火墙配置到服务器实例中。

许多团队还使用基于聊天的部署工作流,让机器人部署简单的命令。推荐的工具有:

Bamboo:采用自动化管理的构建代理模式,运行在各种专用服务器或云服务器上的代理实现了构建能力的即时动态扩展。通过与Jira集成可以实现完整的发布流程

Puppet:一个开源的软件自动化配置和部署工具,基于C/S架构的。服务器端保存着所有对客户端服务器的配置代码,在Puppet里面叫Manifest,客户端下载Manifest之后,可以根据Manifest对服务器进行配置,例如软件包管理,用户管理和文件管理等等。

Superviso:一个客户/服务器系统,允许用户监控和控制类似Unix的操作系统上的许多进程。

Forever:简单的CLI工具,用于确保给定的脚本连续运行。

监控工具
〓 部署监控

部署监控让高级别的发布进入和需求状态可视化,是理解服务健康与否的关键,确保CI服务器上发生的关键事件并及时告警。推荐的工具有:

Datadog:专门针对 DevOps 团队,从APP或者其他各种工具获取数据并提供数据可视化功能。将从基础设备和应用采集的数据统一处理并存储。

ElasticStack:一系列开源产品的合集,包括 Elasticsearch、Kibana、Logstash以及 Beats 等等,提供了很多数据分析领域的功能,如 Pipeline Aggregation。

〓 服务器监控

服务器监控提供了一个基础结构级别的视图,许多团队还使用日志聚合来深入研究特定问题,可以聚合及度量如:内存、CPU、负载均衡等,使工程师能在问题发生时迅速做出响应。推荐的工具有:

PagerDuty:能够在服务器出问题时发送提醒的软件。在发生问题时,提醒的方式包括屏幕显示、电话呼叫、短信通知、电邮通知等,而且在无人应答时还会自动将提醒级别提高。

Nagios:是一款开源的免费网络监视工具,能有效监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员

Solarwinds:主要提供企业的网络管理和监控,可以帮助网管进行配置,监控和管理日趋复杂的系统和构建网络基础构架的流程。

〓 应用性能监控

应用性能监控为应用和业务服务的性能及可用性提供了代码级的可见性,让快速理解性能指标和满足服务SLA更加轻松。推荐的工具有:

DynaTrace:在整个生命周期过程中会对Web和非Web业务关键应用程序的监控、管理和优化方式进行转换。可快速解析性能问题并将问题范围隔离定位到确切的代码行。

AppDynamics:能提供端到端的、可视化驱动管理的的平台。核心理念是SEE可视化、ACT快速解决还有KNOW实时分析。

终极工具
〓 云

云计算目前的主要厂商是亚马逊的AWS、微软的Azure、Google的(GCP)。在PaaS层,可以访问和创建如数据库和分析之类的应用服务且不用考虑如操作系统、防火墙配置或存储之类的基础设施。

〓 Docker

Docker是一个开放的平台,将开发、传输和运行在容器这种隔离的环境中。容器封装了专用的文件系统、存储、CPU、RAM和其他需求的应用,保证这些应用在不虚拟化硬件的情况下持续运行且保持一致。Docker是可移植的、轻量级的,很容易进行安装。

〓 Swan

数人云Swan是基于Mesos实现的开源应用调度框架,帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

Swan Github地址 欢迎Star&Fork

关于CI的服务器与最佳实践,这里有一些思考

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

CI是敏捷和DevOps关键性的一步,数人云最近给大家分享了《致:正在选择CI平台的你(10大要素需把控)》今天的文章将讨论如何使用CI服务器创建高质量产品以及相关扩展插件和指标度量。最后针对业内标准规则进行了自我思考。

CI服务器

拥有自动化的构建系统,是实现CI唯一强制性要求。但在实践中,除了自动化构建系统外,还可以安装和配置“CI服务器”。

概述

CI服务器是大脑,在幕后工作,无缝地将各种行业标准实践整合到CI实现过程中。

下图是个典型的CI工作流,包含6个阶段,从代码检入开始,直到向企业内不同的人员提供反馈信息。







启动过程

通常,开发人员将代码签入源存储库时,CI流程就会启动。

CI工作流也可以通过其他方式触发,下面列举几个方法——
手动:用户通过CI服务器管理控制台或脚本手动执行时。
计划:预先配置的时间表,如某个夜间构建。
触发:每次提交到源代码版本控制系统。
夜间构建通常会对代码执行更大检查和更久时间。

获取最新代码

流程的第二步,CI服务器从源控件获取最新代码,可以通过轮询或推送机制实现。
在轮询机制中,CI服务器配置为源控制服务器,不断地在固定时间间隔内对给定的位置进行轮询,检测任何新的代码更改,一旦检测到,会从源控制服务器下载最新的代码副本到磁盘上。

推送机制中,源控制系统由一个:“钩子”提供给CI服务器,当开发者向提交更改时,调用“钩子”,并让CI服务器了解更改是可用的。
构建
源代码一般独立于构建,即必要的构建脚本与源代码共存,最新的代码在前面步骤中被详细地获取,绑定的脚本会触发构建。

对于Java项目,通常构建自动化脚本使用Maven或分级。使用不支持内置依赖管理的构建系统并不常见,在不需要依赖管理的情况下,Make 使用了在Unix系统中广泛使用的构建机制。
有很多构建工具可以使用,Wiki列出了一些:(https://en.wikipedia.org/wiki/ ... tware)

执行测试

在此过程中执行单元测试和集成测试,这些测试和代码一般捆绑在一起。

基于Java的系统,测试使用类似于Junit的测试框架执行,允许对测试依赖项进行简单的模拟。

某些编程技术自带测试运行器框架,如Spring的Spring Junit运行器、Java EE中的Arquillian等。

在CI服务器上运行测试有以下几点:
曾经遇到过测试在一台机器上传递,但在另一台上失效的情况吗?通过在集中的服务器上运行测试,消除了测试环境的问题。

测试会立即执行每个更改,若有代码破坏预期行为能被快速发现。

很多团队并行处理特性,甚至团队成员在全球范围内分布,每次开发者向存储库提交代码,任何故障都能即刻识别和修复。
结果
CI过程的最后有两种结果:构建和测试失败或通过。

每个嵌入都是经过验证的,并且确保不会破坏现有的代码,代码被合并到主干中,会被构建和测试,允许减少主线代码被破坏的时间。

一般情况下,CI服务器失败会发送电子邮件(给整体团队或只负责以前签入的人),可以快速看到失败的状况,并且尽快采取纠正措施。

CI服务器还凸显了最近构建的状态,以及最近几个构建在红-绿-琥珀光指示器上的状态,例如,Jenkins使用了下面的构建指示器:







CI服务器插件

上一节介绍了CI的基本工作流程,但大多数企业会使用它完成更多任务,通过安装各种插件扩展CI服务器,开拓行为,下面介绍一些常用的扩展:

技术债务与代码质量

在应用中引入的任何变化都会增加系统复杂和无序性被称之为“技术债务”,当新代码引入系统时会增加技术债务,如果被忽视太久,越来越多的新功能被紧凑的最后期限所填满,此时想要在可控范围内几乎不可能,这将对应用的生产效率和可维护性造成负面影响。

迭代开发、自动化检测、和CI的使用来监控每个签入技术债务是控制技术债务的唯一方法。

如SonarQube工具,采用识别代码质量和跟踪技术债务的开源平台,可以轻松地集成到任何CI服务器中,为技术债务提供实时数据。

其不仅仅衡量技术债务,也度量并涵盖了代码质量的7个核心:







SonarQube在简单的WEB中展现分析结果,是非常有用的工具,不仅是开发者,对于管理其他非技术的人也是如此。 













了解更多请参考:
管理技术债务:http://softwareyoga.com/managing-technical-debt/
Sonarqube:https://www.sonarqube.org/
Codacy:https://www.codacy.com/
语义

对于开发者来说,引入CI在另一个重要的方面非常具有价值——可以衡量代码质量——语义及常见的反模式。

静态代码工具可以作为CI过程的一部分,以深入了解代码的健康度,历史数据也可以存储,从而在一段时间内提供质量度量。可以为两个提交作比较,确定每个提交的债务度量标准。

很多工具可以静态地分析代码并计算质量度量的多样性,同时可以被集成到CI服务器中自动运行,例如:
CheckstyleFindbugsSonar
更详尽地工具请参考:https://en.wikipedia.org/wiki/ ... lysis

代码评审

开发者在特性分支上工作,并尽可能频繁地提交代码。

代码分析工具(如:Sonar)可以在CI服务器中执行自动代码检测,然后每个开发者负责处理提交时生成的评论注释。

自动代码审查基于一组预定义的规则,是发现潜在技术问题很好的方法,这些规则可以从主流的开发语言中下载。

解决了自动化评审意见,会进行同行代码评审,捕捉那些不能用自动化审查的问题,如验证业务需求、体系结构问题、代码易读性、扩展性等。

如果有一定数量的人没对代码进行审查,CI服务器可以配置成阻止对主线分支任何的提交,常见办法是在主线分支中强制要求每个提交至少2个审核员,Java的项目中,常见工具是Gerrit。

更多代码审核工具请参考:https://en.wikipedia.org/wiki/ ... eview

Headless Testing

若想在CI服务器上运行UI测试,必须依赖于Headless(Headless:在缺少显示屏、键盘或者鼠标时的系统配置)测试,因为浏览器没有显示,这意味着要在没有图形用户界面的情况下运行UI测试,需要类似于流行WEB浏览器的Headless浏览器,通过命令行界面执行,并具有UI元素的内存模式。内存中的模型用于模拟UI交互,如,在UI中单击一个按钮即可模拟内存中的模型对象。

Selenium测试工具可以用于无头测试,如Phantom JS的Headless浏览器也被广泛应用,在构建中引入这些测试,CI服务器能够验证失败的UI。

安装CI服务器

CI服务器主要有三种:
独立托管私有云
独立的CI服务器安装在一台机器上进行,通常用于小型项目或少于10人的开发团队。

托管的CI服务器可以在公有云上使用,大多数情况下,都与CI服务器可以访问的基于云的源控制系统相连接。这些公司都不希望维护CI或无法维护的公司使用,对于中等规模的团队,是非常可行的选择。

私有云是想要完全控制和基于安全考虑的大公司使用的,多个CI服务器代理配置在高性能服务器的集合中,以支持数百个开发者繁重工作负载。

一些被广泛使用的CI服务器:
JenkinsTravis CITeamCityCruiseControl
更多CI服务器请参考:https://en.wikipedia.org/wiki/ ... tware

CI最佳实践

Martin Fowler(国际著名面向对象分析设计、UML、模式等方面的专家,敏捷开发方法的创始人之一)在他关于CI的白皮书中提到了为任何CI设置的一些关键实践。这些建议已经成为多年来CI的最佳实践。

这里将根据文章作者的见解来审视每一种最佳实践。

维护单个源存储库

“提倡使用版本控制系统实现项目的源代码,所有与构建项目相关的都应存放在存储库中,在此实践中,约定系统应该从一个新的签出中构建,不需要额外依赖项,极限开发倡导者Martin Fowler提到,在使用工具支持分支的情况下,应尽量减少分支的使用,更倾向于进行集成而不是同时维护多个版本的应用,主线(或主干),应该是应用的工作版本。”

提示

原则并非一定按照字面上只需一个单一的存储库,关键是拥有在存储库中构建项目所需的所有相关工件,该项目应该从一个新的签出中进行构建,而不需要额外的依赖项或手动步骤。

“项目”的定义取决于自身,如果代码库很小,或者代码所构建的逻辑模块组件,那么就意味着是完整可交付的产品。

观点

实践中建议不要在版本控制系统中使用分支,相反,建议只开发项目的某个分支,且让其一直处于开发阶段。

本文作者不同意这种说法,在多数企业中,有许多分支需要同时并行开发,企业需要支持产品的前一个版本,修复BUG,而其他团队成员则开始着手下一个版本的工作,所以需要在代码库中使用多个分支。

自动化构建

“单个命令应该具备构建系统的能力,许多构建工具如Make,已经存在多年,其他近期的工具经常用于CI环境中,构建的自动化应该包括自动化集成,包括部署到类似产品的环境中,在许多情况下构建本本不仅编译二进制文件,还生成文档、网站页面、统计信息和分发介质(如Debian DEB、Red Hat RPM或Windows MSI文件)”

提示

构建的自动化应该包括:编译代码、执行单元测试和集成测试,以及许多工具——代码质量检测、语义检测、测量技术债务等,多数现代构建工具都支持这些额外集成,并且用于开发CI环境。

在实际项目中,不同的团队负责开发系统不同部分,都有自己的存储库,因此这种情况几乎不可能发生,将整个产品进行自动化构建没有必要,为系统单独部分开发构建自动化就足够。

观点

定义CI的目的除了自动化构建过程外,是否还有投资CI的意思?作为CI的一部分,打算度量哪些标准?很多人将CI设置看做开发者的工具。

CI不是敏捷或DevOps,只是整体过程的工具之一,敏捷或DevOps已经超越了开发技术层面,升华成一种文化。

构建自测

“构建代码后,所有测试都应运行以确认它如开发者的预期一样。”

提示

代码至少要包含单元测试,如Junit框架可以模拟依赖关系。

特定组件与其他模块是不应该交互的,要确保独立运行。

观点

单元测试应该测试行为,而不是实现细节,例如,不要去在乎如何计算汽车的速度,只要使用的方法和工具是正确的即可。

许多测试框架允许断言模拟对象,如测试模拟对象是否被调用,是否在特定的参数中传递等,除非测试实现本身是主要关注点,否则应将其弱化。

保持快速构建

“构建需要快速完成,因此如果集成有问题,会很快被识别。”








提示

应该以更快地执行测试为目标,所以需要做比其他类型更多的单元测试。

避免在单元测试中使用数据库,如果可以,也要必满在集成测试中使用。通常需要集成测试使用另一种数据源,指向内存中的数据库。如果不可避免,每次测试前都需刷新数据库,确保数据处于已知状态,并且测试会以一致的数据开始。

注意

不要依赖大量的UI测试,其非常脆弱,需要大量维护,建议使用如Selenium类似的UI测试框架来缓解UI测试的一些问题,如屏幕上更改UI元素的位置、处理UI事件等。

自动化部署

“很多CI系统允许在构建完成后运行脚本,可以编写一个脚本将应用部署到每个人都可以查看的实时测试服务器上,此种思维方式进一步发展是CD(持续部署),要求将应用直接部署到生产中,需要额外的自动化防止BUG和回滚。”

观点

不是所有的项目都需要自动化部署,如果生产站点是由同一家公司托管,那么在CD中投资更加有利,CD是CI的下一个逻辑步骤。

不是所有提交的结果都是可交付的产品,在敏捷社区中每个构建都是可交付的产品是常见的误解,可交付的产品与工作应用是不同的概念。

原文作者:Deepak Karanth 
原文链接:https://dzone.com/articles/con ... tices 查看全部


头图.jpg



CI是敏捷和DevOps关键性的一步,数人云最近给大家分享了《致:正在选择CI平台的你(10大要素需把控)》今天的文章将讨论如何使用CI服务器创建高质量产品以及相关扩展插件和指标度量。最后针对业内标准规则进行了自我思考。

CI服务器

拥有自动化的构建系统,是实现CI唯一强制性要求。但在实践中,除了自动化构建系统外,还可以安装和配置“CI服务器”。

概述

CI服务器是大脑,在幕后工作,无缝地将各种行业标准实践整合到CI实现过程中。

下图是个典型的CI工作流,包含6个阶段,从代码检入开始,直到向企业内不同的人员提供反馈信息。

1.jpg



启动过程

通常,开发人员将代码签入源存储库时,CI流程就会启动。

CI工作流也可以通过其他方式触发,下面列举几个方法——
手动:用户通过CI服务器管理控制台或脚本手动执行时。
计划:预先配置的时间表,如某个夜间构建。
触发:每次提交到源代码版本控制系统。
夜间构建通常会对代码执行更大检查和更久时间。

获取最新代码

流程的第二步,CI服务器从源控件获取最新代码,可以通过轮询或推送机制实现。
在轮询机制中,CI服务器配置为源控制服务器,不断地在固定时间间隔内对给定的位置进行轮询,检测任何新的代码更改,一旦检测到,会从源控制服务器下载最新的代码副本到磁盘上。

推送机制中,源控制系统由一个:“钩子”提供给CI服务器,当开发者向提交更改时,调用“钩子”,并让CI服务器了解更改是可用的。
构建
源代码一般独立于构建,即必要的构建脚本与源代码共存,最新的代码在前面步骤中被详细地获取,绑定的脚本会触发构建。

对于Java项目,通常构建自动化脚本使用Maven或分级。使用不支持内置依赖管理的构建系统并不常见,在不需要依赖管理的情况下,Make 使用了在Unix系统中广泛使用的构建机制。
有很多构建工具可以使用,Wiki列出了一些:(https://en.wikipedia.org/wiki/ ... tware

执行测试

在此过程中执行单元测试和集成测试,这些测试和代码一般捆绑在一起。

基于Java的系统,测试使用类似于Junit的测试框架执行,允许对测试依赖项进行简单的模拟。

某些编程技术自带测试运行器框架,如Spring的Spring Junit运行器、Java EE中的Arquillian等。

在CI服务器上运行测试有以下几点:
曾经遇到过测试在一台机器上传递,但在另一台上失效的情况吗?通过在集中的服务器上运行测试,消除了测试环境的问题。

测试会立即执行每个更改,若有代码破坏预期行为能被快速发现。

很多团队并行处理特性,甚至团队成员在全球范围内分布,每次开发者向存储库提交代码,任何故障都能即刻识别和修复。
结果
CI过程的最后有两种结果:构建和测试失败或通过。

每个嵌入都是经过验证的,并且确保不会破坏现有的代码,代码被合并到主干中,会被构建和测试,允许减少主线代码被破坏的时间。

一般情况下,CI服务器失败会发送电子邮件(给整体团队或只负责以前签入的人),可以快速看到失败的状况,并且尽快采取纠正措施。

CI服务器还凸显了最近构建的状态,以及最近几个构建在红-绿-琥珀光指示器上的状态,例如,Jenkins使用了下面的构建指示器:

2.jpg



CI服务器插件

上一节介绍了CI的基本工作流程,但大多数企业会使用它完成更多任务,通过安装各种插件扩展CI服务器,开拓行为,下面介绍一些常用的扩展:

技术债务与代码质量

在应用中引入的任何变化都会增加系统复杂和无序性被称之为“技术债务”,当新代码引入系统时会增加技术债务,如果被忽视太久,越来越多的新功能被紧凑的最后期限所填满,此时想要在可控范围内几乎不可能,这将对应用的生产效率和可维护性造成负面影响。

迭代开发、自动化检测、和CI的使用来监控每个签入技术债务是控制技术债务的唯一方法。

如SonarQube工具,采用识别代码质量和跟踪技术债务的开源平台,可以轻松地集成到任何CI服务器中,为技术债务提供实时数据。

其不仅仅衡量技术债务,也度量并涵盖了代码质量的7个核心:

3.jpg



SonarQube在简单的WEB中展现分析结果,是非常有用的工具,不仅是开发者,对于管理其他非技术的人也是如此。 


4.jpg


5.jpg



了解更多请参考:
管理技术债务:http://softwareyoga.com/managing-technical-debt/
Sonarqube:https://www.sonarqube.org/
Codacy:https://www.codacy.com/
语义

对于开发者来说,引入CI在另一个重要的方面非常具有价值——可以衡量代码质量——语义及常见的反模式。

静态代码工具可以作为CI过程的一部分,以深入了解代码的健康度,历史数据也可以存储,从而在一段时间内提供质量度量。可以为两个提交作比较,确定每个提交的债务度量标准。

很多工具可以静态地分析代码并计算质量度量的多样性,同时可以被集成到CI服务器中自动运行,例如:
  • Checkstyle
  • Findbugs
  • Sonar

更详尽地工具请参考:https://en.wikipedia.org/wiki/ ... lysis

代码评审

开发者在特性分支上工作,并尽可能频繁地提交代码。

代码分析工具(如:Sonar)可以在CI服务器中执行自动代码检测,然后每个开发者负责处理提交时生成的评论注释。

自动代码审查基于一组预定义的规则,是发现潜在技术问题很好的方法,这些规则可以从主流的开发语言中下载。

解决了自动化评审意见,会进行同行代码评审,捕捉那些不能用自动化审查的问题,如验证业务需求、体系结构问题、代码易读性、扩展性等。

如果有一定数量的人没对代码进行审查,CI服务器可以配置成阻止对主线分支任何的提交,常见办法是在主线分支中强制要求每个提交至少2个审核员,Java的项目中,常见工具是Gerrit。

更多代码审核工具请参考:https://en.wikipedia.org/wiki/ ... eview

Headless Testing

若想在CI服务器上运行UI测试,必须依赖于Headless(Headless:在缺少显示屏、键盘或者鼠标时的系统配置)测试,因为浏览器没有显示,这意味着要在没有图形用户界面的情况下运行UI测试,需要类似于流行WEB浏览器的Headless浏览器,通过命令行界面执行,并具有UI元素的内存模式。内存中的模型用于模拟UI交互,如,在UI中单击一个按钮即可模拟内存中的模型对象。

Selenium测试工具可以用于无头测试,如Phantom JS的Headless浏览器也被广泛应用,在构建中引入这些测试,CI服务器能够验证失败的UI。

安装CI服务器

CI服务器主要有三种:
  • 独立
  • 托管
  • 私有云

独立的CI服务器安装在一台机器上进行,通常用于小型项目或少于10人的开发团队。

托管的CI服务器可以在公有云上使用,大多数情况下,都与CI服务器可以访问的基于云的源控制系统相连接。这些公司都不希望维护CI或无法维护的公司使用,对于中等规模的团队,是非常可行的选择。

私有云是想要完全控制和基于安全考虑的大公司使用的,多个CI服务器代理配置在高性能服务器的集合中,以支持数百个开发者繁重工作负载。

一些被广泛使用的CI服务器:
  • Jenkins
  • Travis CI
  • TeamCity
  • CruiseControl

更多CI服务器请参考:https://en.wikipedia.org/wiki/ ... tware

CI最佳实践

Martin Fowler(国际著名面向对象分析设计、UML、模式等方面的专家,敏捷开发方法的创始人之一)在他关于CI的白皮书中提到了为任何CI设置的一些关键实践。这些建议已经成为多年来CI的最佳实践。

这里将根据文章作者的见解来审视每一种最佳实践。

维护单个源存储库

“提倡使用版本控制系统实现项目的源代码,所有与构建项目相关的都应存放在存储库中,在此实践中,约定系统应该从一个新的签出中构建,不需要额外依赖项,极限开发倡导者Martin Fowler提到,在使用工具支持分支的情况下,应尽量减少分支的使用,更倾向于进行集成而不是同时维护多个版本的应用,主线(或主干),应该是应用的工作版本。”

提示

原则并非一定按照字面上只需一个单一的存储库,关键是拥有在存储库中构建项目所需的所有相关工件,该项目应该从一个新的签出中进行构建,而不需要额外的依赖项或手动步骤。

“项目”的定义取决于自身,如果代码库很小,或者代码所构建的逻辑模块组件,那么就意味着是完整可交付的产品。

观点

实践中建议不要在版本控制系统中使用分支,相反,建议只开发项目的某个分支,且让其一直处于开发阶段。

本文作者不同意这种说法,在多数企业中,有许多分支需要同时并行开发,企业需要支持产品的前一个版本,修复BUG,而其他团队成员则开始着手下一个版本的工作,所以需要在代码库中使用多个分支。

自动化构建

“单个命令应该具备构建系统的能力,许多构建工具如Make,已经存在多年,其他近期的工具经常用于CI环境中,构建的自动化应该包括自动化集成,包括部署到类似产品的环境中,在许多情况下构建本本不仅编译二进制文件,还生成文档、网站页面、统计信息和分发介质(如Debian DEB、Red Hat RPM或Windows MSI文件)”

提示

构建的自动化应该包括:编译代码、执行单元测试和集成测试,以及许多工具——代码质量检测、语义检测、测量技术债务等,多数现代构建工具都支持这些额外集成,并且用于开发CI环境。

在实际项目中,不同的团队负责开发系统不同部分,都有自己的存储库,因此这种情况几乎不可能发生,将整个产品进行自动化构建没有必要,为系统单独部分开发构建自动化就足够。

观点

定义CI的目的除了自动化构建过程外,是否还有投资CI的意思?作为CI的一部分,打算度量哪些标准?很多人将CI设置看做开发者的工具。

CI不是敏捷或DevOps,只是整体过程的工具之一,敏捷或DevOps已经超越了开发技术层面,升华成一种文化。

构建自测

“构建代码后,所有测试都应运行以确认它如开发者的预期一样。”

提示

代码至少要包含单元测试,如Junit框架可以模拟依赖关系。

特定组件与其他模块是不应该交互的,要确保独立运行。

观点

单元测试应该测试行为,而不是实现细节,例如,不要去在乎如何计算汽车的速度,只要使用的方法和工具是正确的即可。

许多测试框架允许断言模拟对象,如测试模拟对象是否被调用,是否在特定的参数中传递等,除非测试实现本身是主要关注点,否则应将其弱化。

保持快速构建

“构建需要快速完成,因此如果集成有问题,会很快被识别。”


6.jpg



提示

应该以更快地执行测试为目标,所以需要做比其他类型更多的单元测试。

避免在单元测试中使用数据库,如果可以,也要必满在集成测试中使用。通常需要集成测试使用另一种数据源,指向内存中的数据库。如果不可避免,每次测试前都需刷新数据库,确保数据处于已知状态,并且测试会以一致的数据开始。

注意

不要依赖大量的UI测试,其非常脆弱,需要大量维护,建议使用如Selenium类似的UI测试框架来缓解UI测试的一些问题,如屏幕上更改UI元素的位置、处理UI事件等。

自动化部署

“很多CI系统允许在构建完成后运行脚本,可以编写一个脚本将应用部署到每个人都可以查看的实时测试服务器上,此种思维方式进一步发展是CD(持续部署),要求将应用直接部署到生产中,需要额外的自动化防止BUG和回滚。”

观点

不是所有的项目都需要自动化部署,如果生产站点是由同一家公司托管,那么在CD中投资更加有利,CD是CI的下一个逻辑步骤。

不是所有提交的结果都是可交付的产品,在敏捷社区中每个构建都是可交付的产品是常见的误解,可交付的产品与工作应用是不同的概念。

原文作者:Deepak Karanth 
原文链接:https://dzone.com/articles/con ... tices

中国开源云联盟第二次全会7月26日在北京召开

杨y 发表了文章 • 0 个评论 • 126 次浏览 • 2017-07-25 17:50 • 来自相关话题

由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)


指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆






(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。 查看全部

924663e96e42fc508f69f4359ba852ef.jpg


由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)



指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆

1111.png


(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。