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

杨y 发表了文章 • 0 个评论 • 198 次浏览 • 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 个评论 • 178 次浏览 • 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 个评论 • 134 次浏览 • 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年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

致:正在选择CI平台的你(10大要素需把控)

杨y 发表了文章 • 0 个评论 • 151 次浏览 • 2017-07-21 18:58 • 来自相关话题

对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform 查看全部

QQ图片20170721185708.png


对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform

DevOps、敏捷开发、云计算,三剑客的小时代

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

前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three 查看全部
前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three

Serverless架构用这5大优势,挽救了后来7亿用户的Instagram

杨y 发表了文章 • 0 个评论 • 222 次浏览 • 2017-07-06 14:20 • 来自相关话题

数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗? 查看全部

微信图片_20170705144139.jpg


数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗?

crane现在不能部署

xds2000 回复了问题 • 2 人关注 • 1 个回复 • 655 次浏览 • 2017-05-11 01:22 • 来自相关话题

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 621 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps 新年计划清单:对失败的准备 say no

宁静胡同 发表了文章 • 0 个评论 • 456 次浏览 • 2016-12-28 19:30 • 来自相关话题

随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/ 查看全部
随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/

Docker 1.13最实用命令行:终于可以愉快地打扫房间了

宁静胡同 发表了文章 • 0 个评论 • 1301 次浏览 • 2016-12-16 10:35 • 来自相关话题

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^

在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:docker rm -f $(docker ps -aq)

强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
systemcontainerimagepluginsecret

Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:docker exec -it [container-name] [some-command]
exec 命令现在是 container 下面的一个子命令,这个命令相当于:docker container exec -it [container-name] [some-command]

个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:docker system prune

这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:docker container --help

在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:docker network prune
删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:docker volume prune
删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。docker image prune --force --all

这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/ 查看全部

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^



在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:
docker rm -f $(docker ps -aq)


强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
  • system
  • container
  • image
  • plugin
  • secret


Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:
docker exec -it [container-name] [some-command]

exec 命令现在是 container 下面的一个子命令,这个命令相当于:
docker container exec -it [container-name] [some-command]


个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:
docker system prune


这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:
docker container --help


在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:
docker network prune

删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:
docker volume prune

删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。
docker image prune --force --all


这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/