使用网易蜂巢部署jira6实战

jira是什么?

请参考官网和国内零售商介绍:

https://www.atlassian.com/software/jira/features

http://www.unlimax.com/jira.html

以及演示网站:

http://www.jira.cn/secure/Dashboard.jspa

如何部署?

物理机或云主机

使用物理服务器或者云主机(vps)部署过程,网上有很多教程,看起来十分复杂繁琐,这里列出来一些搜索到的教程文档供大家对比参考:

http://blog.itpub.net/26230597/viewspace-1275597/

http://www.jb51.net/LINUXjishu/84221.html

http://www.linuxdiyf.com/linux/10492.html

总结起来这些教程主要是教大家如何部署tomcat、Jdk、MySQL,以及下载jira源码,准备安装环境等前期步骤。

接下来我们再来看下在网易蜂巢容器云平台上如何部署jira6。

网易蜂巢

首先我们要准备一个jira6的docker镜像,这里我是通过google搜索“jira docker image”,找到的其他人已经编写好的放在github上的Dockerfile,我就尝试直接拿来用到网易蜂巢云平台里面,以下是具体的部署步骤,供大家参考(如无特殊说明,下面的步骤均在本地Linux系统上执行):

  1. 安装docker运行环境,我的是Ubuntu 14.04系统,执行命令 apt-get install docker.io ,为啥是docker.io不是docker?据说是因为Ubuntu源里有个桌面主题的包名称叫docker,其他Linux发行版也是类似,比如redhat系列可以参考这篇文章,当然你也可以直接从docker官网下载安装docker运行环境 curl -sSL https://get.docker.com/ | sh
  2. 下载Dockerfile,执行 git clone https://github.com/cptactionhank/docker-atlassian-jira.git ,切换到想要安装的jira版本的分支,比如我想安装的是6.3.6版本,执行 git checkout origin/6.3.6 -b jira636 即可
  3. 在docker-atlassian-jira目录下可以看到Dockerfile文件,jira系统的默认访问端口号可以通过修改Dockerfile中EXPOSE 8080这行来改变,执行 docker build -t jira:636 . ,这一步是制作docker image
  4. 如果一切顺利,docker image会制作完成,屏幕输出类似 Successfully built f84ca46ff33e ,恭喜你,你可以跳过下面的第5、6两步,直接进入第7步
  5. 如果你比较悲剧,制作失败了,一般原因都是下载jira安装包或者mysql-connector-java包失败导致的,至于为啥失败,原因是国内的网络环境比较差,这两个包都是从国外的服务器上下载的,如果不采用一些特殊手段,下载失败是很正常的,如果你遇到下载timeout之类的问题,建议手工下载相关安装包,建议使用国内的下载站点或者翻 – 墙,可能用迅雷等下载工具也是一个可行的方法
  6. 这里我是遇到了下载安装包失败的问题,我是使用国外的代理手工下载的jira6.3.6安装包和mysql-connector-java安装包,下载完毕后,手工修改Dockerfile,其实就是修改两行,把curl下载安装包步骤去掉,改为直接从本地下载(在jira压缩包目录执行python -m SimpleHTTPServer即可启动简单的http服务器),把 curl -Ls "http://www.atlassian.com/software/jira/downloads/binary/atlassian-jira-${JIRA_VERSION}.tar.gz" | tar -xz --directory "${JIRA_INSTALL}" --strip-components=1 --no-same-owner 改为 curl -Ls "http://本机ip:8000/atlassian-jira-${JIRA_VERSION}.tar.gz" | tar -xz --directory "${JIRA_INSTALL}" --strip-components=1 --no-same-owner  ,其中本机ip要替换为实际的ip,另外一个mysql-connector-java安装包也是同样的修改方法,另外要注意tar命令的解压参数需要从xz改为xf,之后重新执行第3步
  7. 执行 docker images 命令,你可以看到你刚刚制作的image,之后推送本地docker image到网易蜂巢镜像仓库,可以参考蜂巢的这篇文档,依次执行 docker login -u aspirer@163.com -p your-password -e aspirer@163.com hub.c.163.com 、 docker tag f84ca46ff33e hub.c.163.com/wang/jira:636 、 docker push hub.c.163.com/wang/jira:636 ,其中tag是你jira镜像的tag,不是java镜像那个,用户名也不是登录蜂巢控制台用的邮箱,而是网易蜂巢用户中心里面显示的那个用户名
  8. 等待镜像推送完毕后,会在屏幕输出类似 77e39ee82117: Image successfully pushed Digest: sha256:ef12633ff330b1301f86b30a6b3cd4d3db46c1f9f7551c26c76c94b4855a2950 信息

下面的步骤需要在网易蜂巢的控制台页面进行操作:

  1. 登录后进入镜像仓库页面,可以看到一个名为 jira/636 的镜像,jira为镜像名,636为标签
  2. 进入容器管理页面,点击创建容器,选择自定义镜像jira/636,选择合适的规格(建议至少1G内存),填写容器名称及其他相关设置后,点击立即创建即可
  3. 之后在列表页面点击容器名称,查看容器详情,可以看到容器的公网IP地址
  4. 等待容器创建完毕后
  5. 创建完毕后,jira的相关目录位于 ENV JIRA_HOME /var/local/atlassian/jira ENV JIRA_INSTALL /usr/local/atlassian/jira ,这两个目录在Dockerfile中有声明

下面的步骤在浏览器里进行操作:

  1. 在浏览器打开容器的公网IP加上默认的8080端口号,即可访问到jira系统
  2. 之后你可以对jira系统进行各种设置

下面是一些建议:

  1. 在此我建议你不要着急进行配置操作,而是再创建一个网易蜂巢数据库实例,用来作为jira系统的数据库,来保障你的数据安全可靠
  2. 在网易蜂巢上创建数据库实例非常简单,也可以方便的创建数据库用户和库,并支持ip白名单和安全组,以及只读数据库实例,具体使用方法你可以参考这篇文档
  3. 之后配置jira的数据库为蜂巢数据库实例的地址即可,有个提示就是你可以使用内网IP来让jira系统访问你的数据库实例,加快访问速度,提升安全性

之后的jira配置过程我不再多说,网上有很多教程可以参考。

最后我要说明一点,jira是一个非常优秀的任务跟踪、流程管理软件,强烈建议大家能够购买使用正版软件,自觉抵制各类安装教程中提供的破解版本,减少因使用盗版软件带来的安全风险和系统不稳定因素。

 

用docker,就选网易蜂巢!

 

如果你想搞个国内好用稳定的vps或者云主机玩玩,或者想深入体验docker技术的魅力,或者你已经考虑把你的业务使用docker打包测试、发布上线,或者你很想摆脱无尽的繁琐的运维操作但不知从何下手,那欢迎你来体验网易蜂巢,我相信他会是您的明智选择!

如果您不相信,请往下看,本文将深入底层技术细节,全方位为您剖析网易蜂巢的开发人员对相关技术链的掌控程度,以此来证明他就是您的明智选择!

首先来一张大的框架图来表示下网易蜂巢的技术链概貌:

cloudcomb

最上面的肯定是用户了,目前用户可以通过web dashboard来访问网易蜂巢,对容器、服务、数据库等资源进行各种管理操作。

什么?你竟然还不知道网易蜂巢的dashboard地址在哪儿?那你真out了。。。

放心,我是不会告诉你地址是 http://c.163.com/

之后是dashboard,据我所知,网易蜂巢的dashboard是以简单实用为设计目标的,众所周知,网易是从门户起家的,交互、视觉、web设计开发向来是传统强项,设计出来的dashboard肯定不会差到哪里去,但具体是否能满足您的口味,就得您亲自使用一番才能体会到了。关于web有一个小故事可以给大家分享,某天一个视觉设计发现主页的某张图片中的两行大小不一的字没有居中对齐,据说差了几个像素,都能拿出来在内部开发群里吐槽一番,然后开发只能默默改掉,这种眼神我觉得够犀利,此等人才确定一定以及肯定能做出好产品(其实那张图片我看到过不下三次都没发现这种屑碎问题)。

接下来是kubernetes,kubernetes本身我就不过多介绍,但该项目的火热程度,完全不亚于当年的openstack,堪称开源云计算的未来之星。我这里重点说的是蜂巢技术人员对kubernetes的掌控程度,说到掌控程度,就不得不提到社区代码贡献量和质量,以及内部的二次开发量,这两部分肯定是最具有说服力的,这里我给出一个第三方统计机构的报告地址:http://stackalytics.com/?project_type=kubernetes-group&metric=commits&release=all,从这里可以看到commit数量网易全球排名第9,国内排名第2,仅次于华为,但是你要了解华为有多少人在专职做社区,网易仅仅是兼职把我们感觉有用的commit推到社区而已。内部二次开发我就不细说了,这部分一般都是公司的核心竞争力所在,代码量肯定是很大的,目前网易蜂巢的迭代频率是每个月两个版本,一个小版本一个大版本,快速迭代前进,以此来增加功能、提升性能、改进用户体验。

再接下来是OpenStack,网易蜂巢底层采用OpenStack来提供docker运行环境(kvm云主机),以此来保障租户间的完全隔离(包括网络和docker运行环境),蜂巢底层OpenStack团队在Essex版本就开始介入,并在F版本即发布上线网易私有云平台,目前已经稳定运行3年多,有过万台较大规格云主机为网易的各个互联网产品提供高质量服务,得到了公司各产品方的一致好评,OpenStack开发团队对采用的各组件(目前使用了nova、glance、keystone、neutron、cinder组件)的掌控程度,可以说是熟悉使用到的接口的每行代码,最好的成绩仅凭修复bug,就能跻身社区贡献量排名前50(G版本全球31、H版本全球42),国内前5,这些排名也可以在http://stackalytics.com/进行查看,当然这些贡献也仅仅是开发人员出于对开源项目的回馈以及自己的业余爱好而自发进行的,因为是做私有云,公司内部并没有相关的激励政策来鼓励开发人员进行类似开源贡献,当前随着OpenStack项目的愈发成熟稳定,网易在OpenStack社区的commit数量越来越少,但内部的二次开发却从未停止,这一切只为给docker提供一个稳定、高性能的运行环境。另外值得一提的是网易的SDN技术和云硬盘技术,虽然SDN是基于neutron实现的,但实际上已经是把neutron改的只剩下框架了,底层细节和实现完全是自己的二次开发,当然这也得益于OpenStack项目的高度可定制性,而云硬盘技术则是完全针对自主开发设计的,这两者的掌控程度就不用我再多费口舌了。

再下来就是Linux内核了,蜂巢的内核团队保障了网易内部成千上万台服务器的稳定运行,维护自己的内核发行版,及时跟进内核更新和bug修复,保证kvm云主机及物理机Linux内核的高性能高可靠运行。

最后是硬件、IDC、运营商网络,硬件我们是采用的Intel主流CPU,高性能SSD,内网万兆网卡及交换机,加上与网易长期合作的高度可控的优质IDC机房,多线BGP高出口带宽直接接入骨干网,这一切都是为了保证给用户带来极致的性能体验。

综上所述,网易蜂巢的开发运维团队有能力有信心掌控整个技术链条,与其他大多数没有自己底层核心技术的容器云提供商相比,我们的技术领先度是无可比拟的,相信随着网易蜂巢团队对容器云的持续深入理解、优化、改进,网易蜂巢必将成为国内容器云的佼佼者!

现在开始行动,选择网易蜂巢,升职加薪,当上CTO,迎娶白富美,从此走上人生巅峰,不再只是中国梦!

看完是否有点小激动?心动不如行动,现在注册充值1元即送30元代金券,赶快注册吧!

http://c.163.com/

网易蜂巢,给您的APP一个安稳的家!

个人wordpress博客转移到网易蜂巢实战

 

首先要在网易蜂巢容器云http://c.163.com/申请一个账号,目前有冲1元送30元代金券的促销活动,大家抓紧时间去注册体验吧!(已申请同学请忽略本段广告。。。)

第二步是在蜂巢平台上创建一个基于wordpress镜像的容器,步骤不详细描述,见下面的截图:

这里我选择的是按月付费模式,我选择的是小型(¥59/月),其实对于一个个人博客而言,每天个位数的UV(说的就是我,请不要鄙视我。。。),微小型的也足够了,不过谁让咱有钱任性呢!

容器名称我随便填了一个myblog,镜像选的是公共的wordpress镜像,要特别注意的是SSH密钥那部分,建议大家第一次创建容器的时候,导入一下自己常用的公钥上去使用,这样后续通过ssh登录容器的时候既安全又方便,我这里就导入了我的公钥上去(可以直接拷贝公钥内容,与Linux服务器上的authorized_keys文件的某一行内容相同,以ssh-rsa之类的开头,也可以直接上传公钥文件,但是要openssh格式的)。

后面剩下的就没什么说的了,直接点最下面的“立即创建”,然后稍微等待几分钟(目测1~3分钟左右),就可以使用你的容器了。

第三步是ssh登录到你的容器,比如我的容器的外网ip是106.*.*.106,那么我只需要在ssh客户端上加载我的私钥(对应于刚刚创建容器时指定的那个公钥),之后用root用户和22端口,即可登录到容器里面,然后你就可以为所欲为了。。。

第四步是导出你原来的博客的数据库,打包wordpress目录,

我之前用的是虚拟机,所以是手工创建的数据库,名称叫’wp’。

第五步是拷贝导出的数据库和wordpress目录到蜂巢容器myblog中,scp或者winscp之类的工具即可搞定。

第六步是恢复数据,蜂巢的wordpress镜像自动创建的数据库名称叫’wordpress’,与我原来的名称不同,这里我删掉这个数据库重新创建一个’wp’的库,这里没有输入数据库密码,因为网易蜂巢的wordpress镜像自动创建的数据库是没有密码的,如果需要你可以自行修改:

如果你的博客本来的数据库名称就是’wordpress’,那就什么都不需要做了,直接执行:

然后覆盖掉wordpress目录,网易蜂巢创建的wordpress目录是在/app下,

覆盖完之后,你可能要修改一下你的/app/wp-config.php这个配置文件,要把数据库的密码改下,或者你改掉蜂巢默认的空密码,改成你原来的db密码也行,这样就不用改这个配置文件了。除了数据库密码,可能还需要修改db地址,不过如果原本你就是在本地部署的db,那也没啥要改的了。

第七步是修改你的博客的域名记录,这里不再赘述,买过域名的同学肯定都知道怎么修改,只需要知道修改后的域名要指向到蜂巢容器的公网IP即可。

之后浏览器打开你博客网址即可恢复原样。

OpenStack tempest配置安装运行调试

安装

$ git clone https://github.com/openstack/tempest/ # 下载源码
$ pip install tempest # 安装tempest项目

如果pip install 报错,比如某个Python包版本冲突或者之类的,可以先执行下
$ pip install -r tempest/requirements.txt # 安装Python依赖包

然后再执行
$ pip install tempest

初始化

安装完毕要初始化配置,需要执行如下命令
$ tempest init my-tempest-env-01 # 初始化测试环境目录
此步骤相当于执行如下命令
$ mkdir my-tempest-env-01 && cd my-tempest-env-01 && tempest init

修改配置

初始化测试环境目录过程中,会在测试环境目录my-tempest-env-01下自动生成如下子目录
$ etc logs tempest_lock
其中etc目录下生成了tempest.conf.sample示例配置文件,我们修改好这个文件并重命名为tempest.conf,即可执行tempest测试,

下面是我修改完毕的配置文件和初始化完毕的示例配置文件的diff结果:

 

执行测试

”’执行测试需要在修改好配置文件的测试环境配置目录下进行。”’

执行全部测试用例

有好几种方式可以执行tempest测试:
$ testr run
并发测试:
$ testr run –parallel # 注意是双横杠
更多参数可以查看testr的帮助文档:
$ testr help run

也可以用:
$ nosetests -v tempest

执行完毕后会给出结果,例如:

Ran 767 (+766) tests in 2207.974s (+2207.726s)

FAILED (id=11, failures=118 (+118), skips=196)

执行部分用例

可以按照目录+文件+类+方法的方式执行某个特定用例,比如:
$ testr run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server
也可以仅执行某个文件中的所有用例,比如:
$ testr run tempest.api.compute.servers.test_servers_negative
或者一个类的所有用例:
$ testr run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON

还可以用python -m testtools.run来执行部分用例,比如:
$ python -m testtools.run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server
也可以用这种方式执行某个文件或者某个类的全部用例,用法与testr run相同。

nosetests命令执行部分用例的方法也是类似的,只不过要加上-s参数,比如:
$ nosetests -sv testtools.run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server

调试用例

如果某个用例执行出错,可能需要加入断点单步调试,可以用pdb调试库来完成调试工作,但我更建议用ipdb库来调试,这个库更智能易用,它的缺点是不是Python系统库,需要手工安装才能使用。

””’如果要加入断点单步调试,需要使用python -m testtools.run方法来执行被调试的用例,否则可能导致断点无法进入,也就没办法进行单步调试了,切记切记!!!!!。””’

调试的第一步是在被调试的用例里面加上断点(下面以tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server用例为例进行说明,这里使用的是ipdb,pdb也是类似):

 

之后用python -m testtools.run跑起来这个用例即可进入断点调试模式。

ipdb库安装

执行如下命令即可:
$ pip install ipdb

git&pip代理设置

git配置http代理,只能用来下载https://github.com/aspirer/dotfiles.git这种http或者https协议的代码库,不能用于git协议。
下面的方法全局生效(家目录下的.gitconfig文件增加如下内容)。

如果只希望代理某个git库,可以只修改库目录下的~/dotfiles/.git/config文件。

pip代理:

在家目录下的~/pip/pip.conf里面加入如下内容:

 

写给儿子<10>

又一年马上要过去了,你也已经上幼儿园好久了,不过最近一个多月,都没上学

最近一段时间你一直咳嗽,持续了两个多月,这两个多月可把我和你妈妈烦坏了

一开始你有点咳嗽,我们都觉得吃点止咳药,过段时间就好了,于是就去诊所开了点药,吃了几天没啥效果

后来就开始去各种医院,吃各种药,还是不怎么好,这个阶段至少去了3个地方看了3次,每次回来就要吃差不多一周的药

再后来你就开始发烧了,而且还是高烧,这个把爸爸妈妈吓坏了,于是第二天就去了儿童医院,挂了名医号(挂号费一次150),医生让抽血化验,还要拍X片,后来医生说,感染了肺炎,是通过X片看出来的,验血好像没啥用,之前也验过,都正常的

之后就开始了输水,抗生素,连续8天,都是爸爸妈妈爷爷照顾你,你妈还请了几天假,而且本来已经交钱的,全家台湾游,也因为你生病没去,后来总算是不咳嗽了

可惜好景不长,没过3天就又开始有点咳了,这次更担心了,也不知道该怎么办

去儿童医院肯定又要打抗生素,已经这么多天了,手上都不能打了,每次打都哭的不行,也不想给你打了

商量来商量去,趁不怎么严重,赶紧去看中医吧,就去了以前妈妈怀你的时候那个中医哪里看,你妈妈怀你3个月不到的时候,感冒了,也不敢吃药,但是又比较严重,只能去看了中医,结果吃了3天的中药就好了

去了之后医生给你听了下,看了下舌苔,看了下病历,问了问症状,就开了3天中药回来吃,还问你中药能不能吃的下,我说你最厉害了,很苦的冲剂都能喝,医生就说,那应该没啥问题。

回来妈妈给你熬好了,你喝了一口就不想喝了。。。

不过还好,你妈早给你买了蜂蜜,一口中药,一口蜂蜜,总算喝了好几次

头一天吃完,没啥效果,咳嗽还是老样子,第二天吃完,晚上不咳了,感觉好点了,吃了3天,基本好了,效果很明显,不过还是鼻塞,流鼻涕,就又去看了一次,这次改了几种药材,又是3天的中药,回来吃完,就完全好了,那个医生果然厉害

我以前上高中的时候,有段时间也是咳嗽低烧,你奶奶就带我去看了中医,吃了几天就好了,看起来中医对这种伤风感冒咳嗽之类西药不容易除根的常见病,还是很有疗效的。

总体来说,你还是很棒的,偶尔生气发脾气也很让人头疼,下面就是你发脾气的视频记录。。。

虚拟化技术的过去现在和未来

看似题目比较大,其实谈论的东西不多,只想借机感慨下软硬件技术的进步速度,这也是为啥搞IT的人都必须持续学习持续进步的原因之一,新东西太多,一不小心就落后时代了。。。

最开始的时候是VMware搞的全软件模拟的全虚拟化技术,性能不好,开销大,但开了x86虚拟化的技术先河,所以VMware是虚拟化技术的老前辈

后来Intel看到了商机,就想着把软件虚拟化遇到的困难用硬件来搞定,于是VT技术就诞生了

搞定了CPU之后,开始解决内存虚拟化问题,搞定了内存,开始解决网卡、显卡等传统硬件不支持硬件虚拟化问题

总而言之,虚拟化技术的发展过程,其实就是以Intel为代表的硬件芯片公司逐步解决硬件虚拟化缺陷的技术进化过程

当今虚拟化技术基本已经把内存、CPU硬件虚拟化技术实现的比较完美(10%以内的性能损耗),但在网卡、显卡虚拟化技术方面,还有很大的提升空间,尤其是显卡虚拟化,到目前为止还没有完善成熟的解决方案

但网络的虚拟化,其实更多的企业是用软件方式解决的,所谓的软件定义网络技术(SDN),基于openvswitch、openflow等软件交换机、相关协议来搞定,也已经有很大规模的现实应用,性能方面一般来说可以满足需求,尤其是在性价比方面,SDN技术更具优势,当然在这方面,Intel也不是毫无作为,他搞了SRIOV、DPDK等技术,来分别从硬件、软件两个方面提升网络虚拟化的性能

但是显卡虚拟化确实还有很大的改进空间,NVIDIA等公司也在努力

KVM、Xen、VMware等虚拟化技术平台,就是针对各种硬件虚拟化技术进行封装的,所以各家的性能来对比,基本不会有太大的差距,所不同的是软件的稳定程度和生态圈的成熟度

说完了传统的虚拟化技术,我们再聊聊最近很火的容器虚拟化技术

容器也是很老的一个概念了,最近之所以能火起来,还是因为docker这个东西,它给我们带来的最大的好处就是服务或者业务部署的标准化和便利性,你如果要发布一个应用,几乎不用再用传统的打包(deb、rpm等)、自动化运维(puppet等)等技术来去部署或者说发布你的应用,二是只需要一个简单的符合一定格式的文本文件即可

更重要的是,官方还提供了一个镜像市场(当然也有很多非官方的),你可以免费的从里面挑选适合你的各种镜像或者说服务发布文本,从而方便的部署你想要的应用或业务,这里我们可以对比下手机操作系统(Android、IOS、WP),为啥IOS能率先成功,Android能紧随其后,而WP却始终不能流行起来,原因很大程度上都是因为应用市场的活跃度

docker等容器技术的有点有很多,除了上面提到的标准化和便利性之外,还有高性能这个同样十分讨论人喜欢的优点,它能做到几乎与原生系统一致的性能

但它的缺点也是很让人郁闷的,那就是隔离性比较差,虽然Linux内核一直在优化改进,但毕竟还和KVM等完整虚拟化技术有很大的差距,于是aws、阿里云等云计算巨头也不得不采用折中方案,把docker等容器技术跑在用户自己的虚拟机里面,来解决隔离性问题

由此可见,传统技术和新兴技术都各有优劣,硬件巨头Intel为了体现其硬件的能力,开始在相关技术改进上发力,正在试验性的推出Clear Linux和Clear Container技术,分别改进传统虚拟化技术的性能、资源占用问题和容器技术的安全性问题,大有一统天下之势,其实目前也只有Intel有实力做到这点

但是国人也不甘示弱,从另外的角度来融合传统虚拟化和新兴容器技术,结合彼此的优势来打造无短板的虚拟化技术,这就是https://hyper.sh/,从技术上来说,hyper.sh没有特别高深,其原理简单来说就是把kvm虚拟化技术所用到的引导系统(BIOS)从传统的引导比较耗时的BIOS系统改为十分迅速的qboot,并且把guest os的内核(也就是虚拟机镜像的操作系统)简化到极致,基本上就是专门为docker主机而打造的内核,其他无关的东西统统裁剪掉,做到了启动速度和guest os本身资源占用的大幅降低,具体数据可以参考他们官网的文档资料。更难能可贵的是,这个技术是国人提出并实现的。

Clear Linux和hyper的区别可以参考infoq的这篇采访记录:http://www.infoq.com/cn/news/2015/06/Hyper-Hypervisor-Docker

从功能上来讲,hyper方案只能支持docker,相比Intel的Clear Linux,适用场景明显受到很大限制,但至少他做到了速度、性能和安全的相对均衡。

上述两种技术基本都可以做到在常见的服务器上,不到1s启动一台虚拟机,基本可以达到人类可感知的普通用户态进程的启动速度。相比我们当前普通云主机动辄几十秒甚至几分钟的速度而言,是一个质的飞跃。

就我个人而言,我比较看好Intel的Clear Linux技术,如果后续能后做到与当前kvm虚拟化技术一样稳定成熟,其应用前景不可限量。

而对于docker技术,也将有他的一席之地,但肯定不会一统天下,因为他的适用场景还是受限的,如果做到适应所有场景,又失去了其与kvm技术对比的优势,尤其是一旦Clear Linux技术成熟后,docker的速度优势将不复存在。

但docker的服务发布能力却是Clear Linux所不具备的,也是他征服开发者的一把利器,这也是他能在未来的虚拟化江湖占有一席之地的本钱,除非Intel也做出一套类似的东西并且更加优秀才能与之抗衡,不过我相信这不是Intel的发展战略方向,而且即使他真的做了,估计也会跟windows phone的结局一般让人惋惜,有时候技术的niubility并不能决定他的流行程度和生死,更多的要考虑人的因素,就像docker还不能被很多公司的技术、运维人员接受一样。

 

第一天上学

开学前一天,妈妈在被单上绣名字,不过羲字太难绣了,妈妈放弃,改成绣名字拼音首字母WYX。。。

 

早上7点多,还在睡觉呢,不想起床。。。

 

爸爸妈妈带着到学校了

 

开始上课了,还有好吃的

 

第一天放学视频访谈

 

 

 

 

第一天是被爷爷接回家的。

第二天上学,开始有点不情愿,说不想上学了。。。

不过还是乖乖的跟妈妈去了,但是不让爷爷送。。。

二次开发功能清单保存方案

问题描述

当前我们云主机服务提供了很多功能,包括比较大的功能和很多琐碎的功能,这些功能有些是openstack官方提供的,有些是我们二次开发实现的,如果我们不打算合并社区新版本,这个问题并不严重,基本所有功能都在代码里面,随版本发布,基本不会发生功能丢失问题,但是一旦要升级到官方更新的版本,移植代码过程中,很容易就会发生功能丢失问题,由于没有完整的功能清单,QA回归测试也很难完整的发现这类问题,尤其是那些对外不提供API接口的功能更容易遗漏。

对于openstack官方提供的功能,官方release notes会把API或者功能变更列出来,我们可以据此获知官方功能的变动,所以没有功能清单一般来说问题不大,只要保证API接口不变即可。

另外我们的API文档已经维护的很规范,自从改进维护方式之后,基本没有发生过API遗漏或忘记更新的问题,这也是我们可以参考的一种可靠的文档维护方式。

解决方案

受影响的项目

初期仅维护云主机使用的开源项目:nova、cinder、keystone、glance,后续根据需要来决定是否把自研项目:umbrella、sentry等纳入管理。

功能清单内容

包含所有非官方改动,基本包含了所有非cherry-pick社区代码的改动。

开发流程变动

为此打算参考我们的API文档维护方式以及openstack社区新功能开发流程,把功能清单放到git仓库里面进行管理,类似当前的API文档维护方式:

  1. 开发人员提交功能代码到gerrit(nova、cinder等git仓库)
  2. 开发人员提交API文档改动gerrit(doc-api git仓库)
  3. review人员对代码和文档进行评审,通过后将代码和API文档改动一起合入仓库,不通过则由开发人员继续修改(只有代码和文档都review通过才能同时入库,代码或文档不能单独合入)

在上述流程中加入功能清单文档改动提交gerrit步骤,也即:

  1. 开发人员提交功能代码到gerrit
  2. 开发人员提交API文档改动到gerrit(如有API变动)
  3. 开发人员提交功能清单文档改动到gerrit(如有功能变动)
  4. 上述3种改动要同时入库,不可单独合入
  5. 对于开发人员不确定是否需要提交功能清单改动的开发任务,由review人员负责确定。

process

功能清单保存方式

初步考虑把功能清单文档放入各个项目的doc目录下,新建netease目录,如nova\doc\netease\features.rst,以rst(reStructuredText)格式文档保存,Jenkins中增加文档编译项目,入库后自动拷贝编译结果到文档服务器相关目录,以供查看。

也即除保存位置不同外其他流程与API文档保存方式相同。

功能清单初始化

针对目前已有的功能,我会整理一份清单出来,大家后续只关注新增功能即可。