Chef 使用 remote_file 获取 https 资源时的内部证书问题

使用Chef Cookbook来实现自动化安装软件包时,软件包可能存放在一个内部的https Web服务器上,这个https服务器的证书可能是自签名的,或者是内部CA签发的。如果我们使用remote_file来下载该资源,就会遇到ssl certificate verification错误。

如果是自签名证书,可以使用knife ssl把该证书下载到信任证书目录下,

$ knife ssl fetch https://<package repository>
# check again.
$ knife ssl check https://<package repository>

如果是基于内部CA签发,则需要把内部CA的公开证书放到证书目录下。可以是统一的全局目录,也可以是用户的chef-repo目录。从自动化服务器环境的角度来说,应该统一放到第一个目录下。

/opt/chef/embedded/ssl/certs
# or,
chef-repo/.chef/trusted_certs

验证方式同上。

Continue Reading

ITIL + DevOps: 让IT服务更有价值

ITIL的体系,流程,管理,四平八稳。 DevOps的协作,自动化,效率,充分发挥人的积极性和自动化工具的效率。

DevOps是实现ITIL描述的逻辑模型的更敏捷的方法学。

参考资料:

  1. InfoQ 明智地整合DevOps与ITIL http://www.infoq.com/cn/news/2013/05/integrate-devops-itil
  2. IBM DeveloperWorks 通过DevOps实现ITIL http://www.ibm.com/developerworks/cn/rational/d-implement-itil-devops/
  3. ITIL 与 DevOps 的对比 http://www.infoq.com/cn/news/2015/08/itil-vs-devops

Continue Reading

thedevopsfactory.com 学习笔记

thedevopsfactory.com是微软公司专门介绍DevOps的网站。本文是我通过该网站学习DevOps的笔记。

DevOps七大实践领域

  1. Automated Testing 自动化测试
  2. Continuous Integration 持续集成
  3. Infrastructure as code 基础设施代码化
  4. Application Performance Management 应用性能管理
  5. Continuous Delivery 持续交付
  6. Release Management 发布管理
  7. Configuration Management 配置管理

1. 自动化测试

相比手工测试,自动化测试极大提高了发现问题的效率,也避免了手工测试的不一致性,是DevOps高速运转的基石。

自动化测试应该包括所有类型的测试,包括单元测试、压力测试、集成测试等。

自动化测试可以是每次提交都触发,也可以是某种其他的规则触发。对于后一种情况,应该通过看板管理方法尽早发现并解决测试中发现的问题。

自动化测试意味着反复构建和测试,每天几十次高覆盖多类型的测试要能有效运行而且不阻碍开发人员,意味着自动测试必须在保证质量的前提下足够快。常见的解决办法是分布式并行测试。在 持续交付实践介绍 一文中,我们有提到过某月入百万美元的网站,每次数万个测试案例全部运行完毕的执行总时间是接近五个小时 …

Continue Reading

DevOps简史

本文翻译自:

  1. Richard Rapaport http://www.ca.com/us/rewrite/articles/devops/a-short-history-of-devops.html
  2. https://dzone.com/articles/devops-20

DevOps运动是如此的广泛,以至于让人吃惊它才出现了几年而已。其实它形成自一种基本的需要,基于一种简单的这些 - 当工作是协调的、协作的时候,它就是最凑效的。因此DevOps的发展如此之快。

DevOps是从更快地响应市场变化的努力中发展而来的。这种方法用来更快地将高质量的软件更新发布到用户手上。持续交付要求所有人,从开发、测试到用户体验、产品、运营,在整个过程中通过多个反馈回路有效协作。

下面是经典的直观介绍DevOps的图形(来源: https://dzone.com/articles/devops-20, 作者 Justin Baker):

经典DevOps交集图

作者Justin Baker将上图称作为DevOps 1.0,那么DevOps 2 …

Continue Reading

持续交付实践介绍

一天超过50次的持续交付

有一家月收入百万美元的互联网公司IMVU, 每天超过50次的部署代码到生产环境。 其员工Timothy Fitz发表的 文章 介绍了他们的网站服务的持续交付过程。支撑如此高频度部署的是其成熟的 自组织团队运作和高效的自动化测试与部署系统。每一次的代码提交都会触发测试, 跑完所有测试需要大约9分钟,代码部署到所有生产服务器需要大概6分钟。这个过程中 没有手工的测试。

那么质量是如何得到保障的?得益于测试套件的丰富与彻底。
  1. 整个测试套件包括一千多个文件,约一万四千个测试案例,串行执行大概需要4小时。分散到36台服务器并行测试,在理想状态下, 最短执行时间是 4*60/36, 即大约7分钟。
  2. 大约四分之一以上的测试时间是基于Selenium的页面模拟点击测试。剩下的时间是对服务 的功能测试和对代码模块的单元测试。
  3. 每次代码提交都要求跑所有的测试,而且要求错误率不得超过百万分之一次。 一天大概70次的全面测试,差不多意味着每天会遇到一次出错的情况。

持续交付意味着唯速度论? 既是,也不是。持续交付是在满足业务、市场、 质量要求的前提之下的越快越好。

如何开始持续交付?

Timothy Fitz在2012年底发表的 持续交付之路 介绍了如何开始持续交付, 用五个短句来描述:

  1. 开发人员尽早提交代码
  2. 每次提交都触发全面测试
  3. 自动化部署代码
  4. 生产环境监控与告警
  5. 出现错误要分析根本原因 …

Continue Reading

语义化版本管理

语义化版本管理是基于语义化版本号的版本管理规范。该规范约定了版本号的格式,升级版本号的要求等。 该规范着重强调了公开接口兼容性管理的要求,软件的公开接口需要有明确严格的文档或代码描述。 对于遵守该规范的软件包,用户根据其版本号就能知道新包是否与当前的版本兼容。这对于软件依赖包的升级管理非常重要。 因为引入不兼容的新包会导致应用出现问题。软件的模块化提供了大量可重用的软件包,极大提高了软件开发质量和效率,同时也带来了软件包依赖管理的困难。 语义化版本是简化软件包依赖管理的有效规范。

语义化版本规范约定的基本版本号格式为:

主版本号.次版本号.修订号

版本号升级的规则为:

  1. 主版本号:当新功能或修改导致接口不兼容的时候
  2. 次版本号: 当新增功能是向下兼容的时候
  3. 修订号: 当做了向下兼容的问题修复

主版本号升级后,次版本号和修订号重置为零。次版本号升级后,修订号重置为零。

在此基础上,可以再加上预备发布版本号, 比如 1.0.0-alpha.1, 1.0.0-beta.2。 预备版本号在版本依赖上的优先级低于其正式版本号, 比如1.0.0-alpha.1比 1.0.0要旧。

在此基础上,可以再加上编译信息, 比如 …

Continue Reading