当通信业遇到云计算（下）：实施
June 28th, 2011
上一篇文章 讲到，运营商开展云计算业务的第一步，是把计算资源云化并以IAAS的形式出租。现在我们就来看这件事要如何落地实施。
功能：IAAS要做什么
从用户感知的角度，IAAS意味着对几种关键计算资源的按需取用、按使用计费、弹性伸缩。这几种关键资源是存储（内存和外存）、计算（CPU）和网络（带宽和流量）。说白了，用户希望快速开通自己想要的机器和网络，让它投入运行。
从运营商的角度，提供IAAS意味着至少要实现几方面的能力：
- 虚拟化（Virtualization）：将现有的、大批量的计算能力（大型主机、磁盘阵列、千兆以太网）加以虚拟化，使之可以被重组为可出租的小单元。
- 监控（Monitoring）：在客户租用计算能力的过程中监控其使用情况，以便计费并及时发现异常事件。
- 计费（Billing）：根据用户对计算能力的使用情况对其收取费用。
这三方面能力实际上分别对应于IAAS服务的开通、使用和结束三个阶段。云计算平台的架构描述（例如 OpenStack的概念架构 ）可能包含更多模块，但它们最终是服务于这三个阶段的。
建设：如何打造IAAS平台
对应于前面提到的三项基本能力，运营商需要做以下几方面的工作来提供IAAS服务：
利用开源平台实现资源云化
现有资源的虚拟化已经有众多虚拟机产品（例如 VMWare 、KVM 、Xen ）可以实现，IAAS平台应该使用这些虚拟机产品作为底层驱动，在其上提供服务开通、监控、镜像管理等功能。对虚拟机产品的适配以及上述通用功能已经有多个开源平台实现，没有理由重新发明轮子。
在选择开源平台时需要考虑授权许可的问题：例如 桉树 的开源版本使用了 GPL协议 ，基于其上开发商业应用就会遇到授权问题；而基于 Apache协议 的 OpenStack 则没有类似问题。（详见 各种开源授权协议的比较 ）
集成账务/计费
OpenStack当前的文档 中明确指出：目前OpenStack尚未提供计费组件，并且由于云计算服务提供商大多有自己的计费系统，因此OpenStack关注的重点是与现有计费系统的集成。
与之类似，在选用其他开源（乃至商业）云计算平台时，与现有营帐/计费系统的整合都将是一块主要的定制开发工作量，也是厂商设计云计算平台时的重点之一。
定制用户界面
此处所说的“用户界面”是指“用户可感知的界面”，包括API、dashboard、portal等。需要将开源平台提供的用户界面定制为具有运营商特征的界面、甚至需要本地化，这是一块工作量较大、但技术难度较低的工作。
对于IAAS而言，API的重要性甚至超过图形用户界面，因为用户绝大部分的工作都将通过API进行。提供清晰、规范、利于自动化的API，对于用户的体验非常有益。
能力：对研发提出什么要求
对于真正要设计实施云计算平台的厂商而言，首先对开源云平台的经验是必不可少的。这种经验不仅局限于对平台本身技术特性的了解，采用开源云平台亲身实施私有云的经验也是弥足珍贵的，因为这些经验将有助于厂商开发出更便于使用的IAAS产品。
在开发的过程中，针对基础设施的自动化构建、自动化测试的能力也是不可或缺的。以欧洲为源头发起的DevOps运动提出了 Infrastructure as Code 的口号：在涉及大量基础设施的环境下，基础设施本身就应该被当做源代码来看待，需要良好的设计、优雅的编码、不断的重构、持续的集成和测试。在编写应用软件代码中积累的相关经验，在云计算平台的开发过程中同样能发挥价值。
云计算平台本身实际上也是一个面向公众用户的互联网产品，它也需要在 持续交付 中不断获取反馈、不断改进。实际上，开发云计算平台的厂商可以尝试 吃自己的狗粮 ，在企业内部部署并使用云计算平台提供IAAS服务，不失为及早获得真实用户反馈的一个好办法。
从业务和技术两方面来说，云计算都是一个全新的领域；但云计算平台也是一款软件，而软件开发最基本的设计原则仍然是保持不变的。充分利用已有的软件开发最佳实践（例如 敏捷软件开发 ），并保持开放的心态学习最新技术，传统通信行业的软件开发者和企业也能很快找到自己在云端的定位。
DevOps来了
April 16th, 2011
（本文系InfoQ中文站电子期刊 架构师[2011年四月刊] 之主编寄语 ）
经过几年的酝酿，敏捷和运维这两个领域终于各自受到了足够的重视，并顺理成章地有了交集。从2009年起，一阵被称为”DevOps”的风潮从欧洲发端，迅速席卷了北美和澳洲──现在以Flickr、Twitter为代表的一干互联网公司竞相以快速发布、频繁发布为荣：这厢Flickr做个PPT叫”每天10次部署”，那边Twitter就在演讲里有意无意地说”每天部署几十次”。一说起做互联网，你要是还在走俩月一个版本的发布周期呀，你都不好意思跟人打招呼──等你做出新版本，用户都跑竞争对手那儿去啦。
顾名思义，”DevOps”就是开发和运维要搞到一块去──每天部署十几次，这两组人是得搞到一块去，不然光是填流程单的时间都不够。凡是参与过流程改进的人都知道，”搞到一块去”这事永远都是说起来容易做起来难。开发和运维，工作的环境不同，沟通的方式不同，使用的工具不同，通常还隶属不同部门，没有点方法套路，说一句”你们要紧密协作”半点用都顶不上。不过，办法总比困难多：流程、技术、工具三管齐下，一点点改进现状，最终达到交付与运维紧密无间的企业文化，至少已经有先例告诉我们是可行的。
IT技术的潮流，向来是澳洲比英美慢两三年，中国又比澳洲慢两三年。于是很自然地，当别人开始热火朝天地讲DevOps，咱们这儿”敏捷运维”还是几家互联网巨头的王谢堂前燕。不过正因为这个潮流时差，也不难预测，两三年后”敏捷运维”一定会像今天的”敏捷”一样飞入百姓家。所以呢，咱们得从现在开始早做准备──比如看看本期《架构师》精选的几篇文章，先大概了解一下这”敏捷运维”讲的到底是个啥，然后开始做一点思考和分享。等更多企业开始意识到敏捷运维的重要性，咱不就已经成竹在胸了么。
Collaborate with Monitors
April 5th, 2011
( Copied from Continuous Delivery )
Every operations team has some way of monitoring their production environments. They might have OpenNMS, or one of the alternatives such as Nagios or HP’s Operations Manager. Perhaps they have created their own custom monitoring system. Whichever system they use, they will want your application to hook into it so that they know the moment any error condition occurs, and where to look for more details to determine what has gone wrong.
It is important to find out, right at the beginning of the project, how the operations team expects to monitor your application, and make it part of your release plan. What do they want to monitor? Where are they expecting your logs to be? What hooks should your application use to notify operations staff of malfunctions?
转战西安
March 28th, 2011
上周末公司AwayDay，所有人来了西安。去兵马俑，唯一的乐趣就是拍一大堆 同事的人像 。然后就留在西安了。
据说按照招聘网站的职位搜索，DevOps是2010年的大热门 ：虽说经常跟“Java”、“C”、“Ruby”之类的词汇同时出现，但“DevOps”是2010年增长最快的职位描述关键词。
然则，为什么 OPs的书 我还是读不出乐趣来呢？ITIL 这样的流程框架读起来实在是味同嚼蜡啊…
而且据 @DEVOPS_BORAT 说，每个优秀的DevOps背后，都藏着一个被热妞拒绝的悲催故事。
凌晨三点起来恢复系统有木有！！！ 新版本上线就当机有木有！！！ 敏捷！！！敏捷你妹啊！！！ OP都是折翼的天使啊！！！ 你伤不起啊！！！伤不起啊！！！
周六在 西安OpenParty 做了一个简单的DevOps介绍，还偶遇了 鲍老师 。其实说到DevOps的“怎么做”，很常用的 引入变化的技巧 仍然适用：
- Start small and build on trust and safety
- Create champions
- Use metrics to build confidence
- Celebrate success
- Exploit compelling events
有235人在用 1.HourFor.Me ，我也小celebrate一下。也～～
DevOps: How To Start
March 18th, 2011
(Stolen from Evan Bottcher )
How to assess the current situation?
I would start by drawing a big visual map of the path from developer check-in to production, including the likely integration of multiple streams of work. Have the teams estimate the time taken in each stage, likely delays etc. This can be quite enlightening when seen from a total value-stream view – as few people will have the whole picture at present.
Categorise time and effort as ‘value-add’ vs ‘non-value-add’. E.g. time in manually testing from scripted scenarios is non-value-add as a computer could do it more quickly. Manual testing for exploratory testing is probably value-add, if it is genuinely finding defects.
Metrics would be build times, deployment time, how long does it take to configure an environment. How many defects are found, how many are true defects, how many are configuration and environment?
How to shape an improvement plan for “last mile”?
Need to prioritise areas of concern from your map of the path to production. Root cause analysis should be done to understand the cause of delays and defects. Spend some time setting a vision for what the best path to production would look like for the customer, and build out a set of steps to implement those changes. E.g. “shift to trunk development”, “train staff in continuous integration”, “automate self-service production-like environment”.
Who is able to do this?
Need to quickly understand the source control, development practices, deployment environment and architecture in sufficient detail to be able to understand how to improve things. If it’s a unix target environment, best to understand something of that environment.
A generalised set of tools/tech/skills:
- automation (e.g. capistrano, ruby, bash, powershell etc.)
- source control, and methods to do trunk development and deployments (feature toggles and branch by abstraction)
- configuration management – chef, puppet, whatever you can apply to windows servers if that’s in scope
- understand the ops perspective – tools for monitoring, logging, plotting system performance and stability over time (nagios, ganglia, cactii in the open source area)
这个春天，我感觉运维们鸭梨很大
March 12th, 2011
壹、穷人的EC2自动快照
用两个简单的shell脚本加一个crontab就能每周（如果你愿意的话，每天也可以）备份EC2的机器。今天在Ubuntu上玩各种东西把环境玩复杂化以后，发现这个脚本蛮有用。
话说，实在没有什么理由，不到EC2搞台机器放自己的博客兼作翻墙梯啊…
贰、挪亚，不是方舟
这位John Vincent同志写了 一篇博客 论述…嗯，为什么有Chef和Puppet还不够。
Chef和Puppet管理有计划的变更，但你经常会做无计划的 偶发变更 ，而且你不太希望每次变更重启都得重启服务。所以，Vincent桑说，你需要…
Distributed coordination, dynamically reconfigurable code, elasticity and environment-aware applications.
然则，看完 Noah的README 就知道了。这就是RESTful的RMI…好吧，正确的思想永远都用得上，而且RESTful总比RMI要好那么一点点。
叁、飞禽走兽们
Nagios 是老牌的监控工具，十多年历史了。
Hadoop 这里好玩的东西不少，分布式文件系统 ，MapReduce ，还有 重新发明轮子的ZooKeeper 。
Sinatra ，快速做一个web server，不需要Rails那么庞大，比WEBrick容易写。
Redis ，又一个key-value store。加上 Ohm ，好了，NoSQL的对象持久化。
看一遍 Noah的使用场景 ，感到运维们鸭梨很大。
（还有一本 Hadoop的书 可我今天看不着…等明天翻墙再说吧。）
肆、来点音乐
Music as Data is a live programming language/environment based on Processing.org written in Clojure. It’s something like SuperCollider or Chuck but aims to be easier to hack/experiment live.
我喜欢他的网站。简约而不简单。
Chef学习手记之叁：红宝石菜谱
March 2nd, 2011
有了一台 基本的服务器 ，现在我就要在上面配置Rails服务器。当然这件事已经有人干过了，但我不想用别人的菜谱，再怎么说我也是 RubyWorks 的开发者…
（还有，我觉得Fedora还是不如Ubuntu好用，所以我偷偷把EC2的机器换成了Ubuntu 10.04。）
新建一个菜谱真容易，用knife一下子就搞定了：
$ knife cookbook create my_rails_gig
菜谱放在 #{chef-repo}/cookbooks/my_rails_gig 下面。首先要看的是 recipes/default.rb ，缺省菜色的做法就写在里面。在我开始做自己的配置之前，我得先保证Apache和 Passenger 都配好了。
# default.rb include_recipe "passenger_apache2::mod_rails"
然后涅，我要用“railsapp”这个用户来部署Rails应用──不可以用root来跑服务。所以我得确保有这个用户（以及它独占的一个组）。
# default.rb group 'rails' do group_name 'rails' action :create end user 'railsapp' do username 'railsapp' action :create end
接下来，按照我们RubyWorks的传统，Rails应用应该部署在 /var/rails 目录下面。所以要确保有这个目录。
# default.rb deploy_to = '/var/rails' directory deploy_to do owner "railsapp" group "rails" mode "0755" action :create end
现在是最挑战的部分：配置Passenger…但是只要是像我一样经验丰富的Rails服务器管理员，这个也小菜一碟_ Apache2那本菜谱 讲了怎么在Apache里做web_app，你只要调用就行：
# default.rb
web_app 'rails_app' do
template "rails_app.conf.erb"
docroot "#{deploy_to}/current/public"
server_name "#{MY_COOL_HOSTNAME}"
rails_env 'production'
end
唯一的trick就是 rails_app.conf.erb 这个template：我需要把它放在 templates/default 目录下（规则和Rails有点像）。别的么…就再没啥啦～～（不信就 看代码 ）噢对了，别忘了在这台机器的角色里加上新的菜色：
"run_list": [
"recipe[passenger_apache2::mod_rails]",
"recipe[my_rails_gig]"
],
噢也～菜谱写完开始做菜～先把菜谱上传到服务器：
$ knife cookbook upload my_rails_gig
再跑到我的服务器上执行一下 chef-client …这就好了。用 railsapp 用户到 /var/rails/current 下面建一个应用（为什么要“current”？问 Capistrano ）。浏览器访问80端口，看后台日志，Rails已经开始工作了。
嗯，虽说写自己的菜谱挺好玩的，不过 这个菜谱 很值得学习──其实很多菜谱都值得学习，所以…
（未完待续）
Show-off Too
February 28th, 2011
我也会画～～
Program? Me?
February 27th, 2011
这也不是新鲜事。这也不是中国特色。从前听的版本有几个：
- 业务分析师是不会写程序的。（所以 Cucumber 写出来要像自然语言。）
- 测试人员是不会写程序的。（所以 Selenium要有IDE 。）
- 界面设计人员是不会写程序的。（所以我们还得有个叫“前端程序员”的人用HTML+CSS把图片做成页面。）
- 项目经理是不会写程序的。（这个，大家都习以为常了…）
现在最新的版本是：系统管理员是不会写程序的，所以 Puppet 比 Chef 要好那么一点点（TWers请看这两天twswdev上的讨论），因为Puppet是声明性的DSL而Chef直接就是Ruby代码。Ruby代码会把笨笨的系统管理员吓倒云云。
扯淡。
所有这些人，只要还在从事软件开发相关的工作，他们都需要描述抽象的概念、把概念分别组织、用合适的词汇使概念描述可懂、关注概念中易变的部分和不变的部分、抽取概念中的共性、消除概念描述的重复。这个，就是编程。你可以逃避它，你可以拒绝学习它，但当你认真对待它，当你把它做好了，这就是编程。那时候你就会发现，Ruby是一种具有强大表现力因此更贴心的编程语言，HTML+CSS是比Photoshop更适合描述界面的语言 。
重点在于：如果你一直在用一种并非设计用于描述大量复杂抽象信息的表达方式来描述大量复杂抽象信息，你为什么不去学会一种本来就设计用来干这个的工具呢──那就是编程语言；另一方面，如果你并没有在描述大量复杂抽象信息，很可能你的工作可以被一个脚本取代。
毕竟，从前的系统管理员都是Perl和Shell的高手。现在突然说他们不会编程，这个对我来说实在太突兀了。
Chef学习手记之贰：基本套餐
February 20th, 2011
现在我要配置一台体面的Rails服务器。也许我会用它来跑 1.HourFor.me 。
要配置一台Rails服务器，首先要有一台服务器。于是我到 EC2 搞了一台服务器。EC2之于DevOps就像SourceForge之于轻量级J2EE：它让你有机会去尝试那些原来只有在超级大企业里才会出现的东西。你可以在自己家里、在业余时间积累经验，而且不花多少钱。我装了一台Fedora 8的机器。
在 学习手记之壹 里我说需要有一个Chef服务器。其实Chef有三种运行的方式：你自己装Chef服务器；压根不要Chef服务器（叫 Chef Solo ）；或者用OpsCode做你的Chef服务器。第三种方式蛮好，又不用自己多架台服务器，又可以在世界任何地方共享我的大餐。所以我就要这样做。
首先要在OpsCode注册，并创建一个组织（organization）。这部分蛮简单，照着网站的指示一步步做就行了。我创建了一个叫“thoughtworkers”的组织。创建组织的时候小心，有免费的plan可以用的。我现在还不需要收费plan那么强的功能。
紧跟着要搞定开发环境。我要在自己的机器上建一个 Chef Repository ，配置与Chef服务器连接的身份认证信息。基本上，按照 这个文档 来操作就可以了。
接下来要在EC2那台Fedora机器上安装Chef客户端。这也蛮简单，也有 一个文档 。其实关键就是要把RubyGems升级到1.3.7以上，然后就可以“gem install chef”啦。装好之后执行一下“chef-client”，应该会报错，需要从本地环境拷贝/etc/chef下面的client.rb和validation.pem去Fedora机器上。
现在可以写程序咯～在Chef Repository下面的roles目录里建一个base.json文件。先不管是Rails服务器还是Django服务器，我的体面服务器必须满足一些基本条件，比如有GCC啦，有Git啦，之类的。所以我在base.json里这样描述我的体面服务器：
{
"name": "base",
"default_attributes": {
"chef": {
"server_url": "https://api.opscode.com/organizations/thoughtworkers",
"cache_path": "/var/chef/cache",
"backup_path": "/var/chef/backup",
"validation_client_name": "thoughtworkers-validator",
"run_path": "/var/chef"
}
},
"json_class": "Chef::Role",
"run_list": [
"recipe[build-essential::default]",
"recipe[openssl::default]",
"recipe[chef::client]",
"recipe[chef::delete_validation]",
"recipe[git::default]"
],
"description": "Basic Server",
"chef_type": "role",
"override_attributes": {
}
}
然后涅…那台Fedora机器咋知道它自己应该有“base”这个角色呢？当然答案是它不知道。我得告诉它。Knife 是Chef的便利命令行工具。比如说，可以列出所有可管的节点（必须在Chef Repository目录下）：
$ knife node list # 下面是输出回显 [ "ip-10-130-9-17.ap-southeast-1.compute.internal", "jeffxiong3650" ]
有两台机器。下面这个是我自己的笔记本电脑，上面那个名字很长的就是在EC2的Fedora。我要让它知道，自己有“base”这个角色要扮演：
$ knife node run_list add \
ip-10-130-9-17.ap-southeast-1.compute.internal "role[base]"
# 下面是输出回显
{
"run_list": [
"role[base]"
]
}
好乖～现在ssh登录到Fedora上去，执行一把“chef-client”…体面的服务器就这样装好啦～试试git，没问题的说～嗯嗯，当然这只是第一步。接下来要配置好体面的Rails服务器才行呢。
（未完待续）
