Nov 052018
 

这个其实是Openshift的应用商店,也有人理解成服务目录,基本都是相似的东西。

默认红帽装的应用,默认是从docker hub下载镜像,同时还是设置你的存储才能使用。

目前默认是采用Openshift的模板,或imagestream的应用,

oc get templates -n openshift

oc get is -n openshift
把默认的模板,镜像流删掉。
切换到Openshift 项目
oc project openshift
查看
oc get is  | awk '{print $1}' | grep -v NAME
oc get template  | awk '{print $1}' | grep -v NAME
直接运行删除命令就可以
oc delete is $(oc get is  | awk '{print $1}' | grep -v NAME)
oc delete template $(oc get template  | awk '{print $1}' | grep -v NAME)
导入jenkins的image stream
导入jenkins的template
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/jenkins-persistent-template.json

命令行下参加project

oc login
oc new-project cicd
oc new-app jenkins-persistent

参考地址

https://github.com/openshift/origin/tree/master/examples/jenkins

Oct 252018
 

很多朋友经常希望体验研究一下OpenShift,那么一台虚拟机怎么快速安装OpenShift,如果你不想折腾ansible的一堆参数的话。

对操作系统的要求,必须是CentOS 7.4以上。建议大家用CentOS 7.5,我是在上面测试的。脚本解决了国内安装因为网络原因导致的安装失败的问题。

我是在小米笔记本上,启动一个1Core,4G内存,系统盘100G虚拟机来安装,没任何压力。

升级操作系统,最小化安装就可以

yum upgrade

查看操作系统,记得重启操作系统

# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

安装git

yum -y install git

下载基于OpenShift-ansible改造过的代码

cd /root
git clone https://gitee.com/xhua/OpenshiftOneClick.git
cd OpenshiftOneClick/
git checkout 3.9

开始安装

bash deploy_openshift.sh

装完后,用户名和密码都是admin

Snap2

大概20分钟就可以装完。代码可以反复执行,如果网络的问题导致。我是连接手机联通4G安装,17分钟搞定。

想了解安装过程,可以查看日志,新打开一个ssh

tail -f /var/log/message

修改windows机器的host文件

C:\Windows\System32\Drivers\etc

192.168.100.10 os39.test.it.example.com
192.168.100.10 registry-console-default.apps.os39.test.it.example.com
192.168.100.10 jenkins-default.apps.os39.test.it.example.com

你更换ip地址就可以。如果你是使用公有云安装,那么这个ip地址,就是所谓的EIP,或者Floating IP。

访问地址

如果是公有云,安全组里记得打开8443端口

Sep 252018
 

在OpenShift,整整忙乎了一年,逐步一点一点完善整个CI 的工具链。根据我自己的理解和实践,我整理一下。

这些工具链,除了要感谢同事努力,帮忙验证这些工具是可用的,同时还需要感谢客户,正是因为这位客户的交流,给我们提了很多需求和想法,经过他的折磨,才有今天的这套相对比较完整的工具链。这也是我后续持续半年的投入来完善动力。

涉及的相关的技术,其实我同事已经分享到简书上,大家可以参考。

https://www.jianshu.com/u/15a6a6df3202

我是按照jenkins的运行的流程来介绍工具

  1. 在Jenkins创建一个Maven的job
  2. Gitlab的webhook,触发Jenkins里的job,jenkins的slave镜像启动,Maven已经集成到jenkins的slave镜像里。
  3. 从Gitlab拉取代码
  4. Jenkins调用SonarQube静态扫描代码
  5. Maven利用Nexus build jar包
  6. Maven利用Junit和TestNG自动化测试
  7. Jenkins Slave镜像完成相关工作,会把结果传到Jenkins的Master节点上,然后把slave节点销毁掉。
  8. 触发Openshift build 镜像,deploy环境
  9. UI自动化测试

对于ci的流程,不少工具会产生大量的数据,所以尽可能使用S3,对象存储来存储数据,这样可以避免磁盘撑破。流程里的工具,都采用OpenLdap来统一身份验证,授权在应用里进行。

下面的工具,全部容器化,跑在OpenShift上。整个环境的部署,从OpenShift安装,一直到工具链对接,跑完一个Java的demo测试,1天就可以完成,应该还是非常高效。

身份统一认证

LDAP

其实打造一套工具链,面临了一个很现实的问题,如何统一不同工具的身份验证的问题。那么通过OpenLdap,基本是唯一办法,这是代价最小的方式,现在目前基本所有的应用,都支持ldap认证。

所以我们也花精力把OpenLdap跑起来,用来提供用户验证,当我设置允许该用户登录某个系统,用户用统一的用户名和密码,登录到不同的系统中。

第一个需要解决的系统,其实就是OpenShift平台的用户管理。用户在openldap上创建,用户的权限管理,在openshift设置。

OpenLdap在OpenShift平台部署,比较简单。

https://github.com/openshift/openldap

OpenShift上部署生产的OpenLdap,需要考虑不少东西,主从架构,估计还需要搞一个Operator,不过应该够用。

目前OpenLdap的用户管理,缺乏UI,这块我们自己开发一套OpenLdap管理的UI,当然也肯定是跑在OpenShift上。

项目管理

jira-vs-confluence

软件的项目管理,需求管理,这是在比较大的项目里的一个需求,另外还有项目的文档管理。

软件的开发,我们希望可以支持敏捷开发,实现看板的功能。还有就是issue的管理。关于issue,详细的介绍,大家可以http://www.ruanyifeng.com/blog/2017/08/issue.html   阮一峰介绍的很详细。

  1. Redmine
  2. Jira+confluence
  3. 禅道

上面三个软件,都能支持ldap的用户管理,我基本都折腾了一遍。最好的肯定是Jira+confluence。很多创业公司一成立,就直接把jira+confluence搭建起来,宁愿付费,也要使用,提高效率。

Jira和confluence官方提供docker镜像,你可以拿来修改一下就可以跑在OpenShift上。这个过程,基本就是体力活。当jira和confluence用起来后,存储需求比较大,其实应该考虑把数据放到S3上,减轻PaaS平台的存储压力。

禅道,基本是能满足我们使用需求。缺点就是一个孤岛,没法和外面的系统集成。

Redmine,老牌的开源项目管理软件,可以通过装上各种插件满足项目的需求。可以和gitlab对接。唯独社区不是很活跃,用ruby语言开发,感觉非常不可控。

对于Jira来说,其实可以作为一个公司的门户入口。如果你舍得投入的话,要有的功能都有。可以对接jenkins,Sonarqube。把各个软件的运行的信息,显示在jira的页面上。

持续集成工具

Jenkins-large

红帽的OpenShift上已经直接集成了Jenkins,而且用户是和OpenShift统一。可以启用jenkins的k8s插件,这样可以把jenkins的slave跑起来。当job在slave跑完后,会把相应的结果复制到master上,就会销毁掉。

jenkins的插件非常多,常用的gitlab对接,gitlab触发jenkins,jenkins和jira对接,jenkins的深入,其实就看你使用的插件的数量。

整个持续集成的重点,就在于Jenkins,jenkins是挺复杂,你需要投入时间了解他,不过好处就在于,好像基本没碰到什么bug。插件都能正常工作。

关于Jenkins启用k8s插件后,slave节点的配置

https://medium.com/muhammet-arslan/how-ive-created-scaled-and-distributed-jenkins-top-of-kubernetes-441db62b15cd

如果要提高jenkins的并发能力,用好slave,大家真的要好好看看。

使用的时候,有一个地方需要注意

https://github.com/jenkinsci/kubernetes-plugin

搜索 Over provisioning flags 。

这个地方也是需要注意,设置一下。

jenkins

项目构建工具

maven

对于java的开发人员来说,项目的构建工具:ANT,Maven和Gradle,ANT应该早已废弃。Gradle风头很猛,不过Maven在如今仍然是Java构建技术的事实标准。所以我们项目里,还是选择Maven作为构建工具。

大家可以简单理解,Maven,就是管理项目的依赖关系的工具。

Openshift内置的jenkins Slave镜像,默认就支持Maven。所以就非常方便。如果你希望用Gradle构建,那么还需要多做一点工作。

代码管理工具

gitlab

其实这个悬念不多,建议直接使用gitlab就可以了。现在市场上还有好几个开源的代码管理仓库,功能都基本一致,不过最大的问题,就是和别的系统集成上,缺乏插件。

gitlab,作为代码仓库,至少需要和外面的系统对接:jira对接issue,对接jenkins。

gitlab也带CI的工具,不过我没有用,这也是大家比较诟病的一个功能,太重。不过还好,无非就是多用2g内存而已。

gitlab在OpenShift的部署,官方提供文档,照做就可以。

https://about.gitlab.com/2016/06/28/get-started-with-openshift-origin-3-and-gitlab/

gitlab的issue功能,可以关闭,直接集成到jira上,这样可以实现issue集中管理。

目前还没很好解决的问题就是无法通过ssh访问gitlab,只能是https的方式。后续再深入研究。ldap集成,也是没问题。

代码质量管理

Snap6

代码扫描工具,基本目前大家都使用SonarQube。可以对没编译前的代码根据定义的规则,进行扫描,并且生成报告。

用户还能自定义规则,可以把公司的代码规范融入到规则里,一旦发现不规范的地方,马上提示。

snoarqube

Jenkins装上SonarQube插件,在流水线上,直接让SnoarQube进行代码的扫描。

另外SonarQube还能通过jira的插件,把报告显示在jira的UI上。

Openshift安装,红帽提供了一个模板:

https://github.com/OpenShiftDemos/sonarqube-openshift-docker

朋友问的最多的问题,关于如何自定义规则,参考这里基本就差不多。

https://github.com/SonarSource/sonar-custom-rules-examples

制品库

nexus

作为Maven的私有仓库,目前选择是

  • JFrog’s Artifactory
  • Sonatype’s Nexus

Nexus3.x的版本,比2.x版本功能多很多,还可以提供yum源管理。可以大大加快企业内部的build速度。

需要考虑的一个问题就是Nexus的存储,如果可能,存放到S3上。

Nexus容器化,OpenShift运行,红帽直接提供官方的支持

https://docs.openshift.com/container-platform/3.5/dev_guide/app_tutorials/maven_tutorial.html

jenkins通过Maven构建的时候,就可以直接使用私有的仓库来构建,加快构建的速度。

测试框架

junit-testng

Maven本身并不是一个测试框架,Java世界中主流的测试框架为Junit和TestNG。Maven在构建执行到特定生命周期阶段的时候,通过插件maven-surefire-plugin来执行Junit或者TestNG的测试用例,也可以并行执行测试用例。该插件能很好的兼容Junit3、Junit4,unit5和TestNG。

https://www.baeldung.com/core-maven-plugins

配置管理中心

apollo

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。

对于OpenShift来说,开发,测试,生产使用相同的镜像,就需要一个配置管理中心,集中管理各个不同的环境的配置文件。

UI自动化测试

zalenium

zalenium是一个Selenium Grid扩展,可以理解为在k8s跑Selenium Grid的版本,实现在Firefox和Chrome中进行的UI自动测试。

Selenium Grid包括两种角色,类似master,slave的概念,可以实现1主多从。

  1. hub :主节点,master节点
  2. node:分支节点,slave节点

测试管理

testlink

测试用例管理,测试计划管理,目前开源的工具,基本就是Testlink。可以和jira或者Redmine集成,把issue集成到上面。不过还无法在testlink里,指派issue给开发者。

展望

其实没完成和验证的东西,我是不想放在这里。不过有朋友专门来找我聊,问我还有啥进一步的想法,他考虑根据这个去招标。我是从来不隐瞒我的想法的,我就把我的一些我未来计划要做的工作整理一下。

压力测试

jmeter1

通过testNG的插件,就可以对应用进行功能测试,压力测试。不过大家常用的压力测试工具是jmeter。在OpenShift的部署,倒是简单。红帽的美女工程师有专门的blog https://eleanordare.com/ 和githuab代码,

https://github.com/eleanordare/jmeter-openshift-jenkins

需要的是投入精力研究jmeter的使用,如何写脚本。

安全动态扫描

zap

sonarqube可以进行代码的静态扫描,就是对git仓库的代码直接扫描,发现一些基本的漏洞。安全的动态扫描,以往都是应用上线前,进行安全漏洞扫描。我们其实应该把漏洞扫描集成到我们的CI过程。

OWASP ZAP

https://github.com/rht-labs/owasp-zap-openshift

红帽已经把OpenShift集成做好了,剩下也是使用的问题。这个其实对企业还是很有价值的。另外Snoarqube也是有集成插件,可以把报告发过去。

代码Review专业工具

gerrit

习惯OpenStack的代码review,其实用起gitlab的代码review功能,还是比较别扭。不过国内其实公司代码的Review机制其实还是没建立起来。真的要用代码review,还是需要Gerrit。

Gerrit和gitlab进行整合,并且Gerrit对接Jenkins,让提交代码没merge前,就可以跑测试,这个真的要花功夫去调试,才能玩得转。

目前Gerrit在Openshift上的使用案例不多,据说红帽内部是用Gerrit来做代码review。后续需要把这个实现,工具链才能算是完整。

自动化运维工具

tower

估计很多朋友还没搞明白,为啥需要在DevOps工具链里集成红帽的Ansible Tower的管理工具。我们可以把我们日常运维的ansible roles用Tower管理起来。包括OpenShift自己的。

后续很多想法。如何做到更加自动化,其实都要依赖ansible。

当我们的项目架构评审完毕后,所有的需求,以往都是在一个wrod文档,Excel文档,通过手工的方式来把开发环境准备出来。这里面其实体力活很多,创建的数据库的密码是啥,URL是啥。有什么办法,可以把文档需求,自动化把开发环境初始化出来,并且把初始化的信息反馈回来到相应的页面里,这样大家就可以有一个统一的入口,查看相关的信息。不然运维人员项目多起来,也是会累死的,即使用了OpenShift。

OpenShift跑Tower,管理Ansible,也是红帽大力推动的一个方向。Tower的开源版本是Awx

https://github.com/ansible/awx

Openshift的安装

https://developers.redhat.com/blog/2017/10/16/guide-starting-use-awx-top-openshift-upstream-red-hat-ansible-tower/

应用性能管理

pinpoint

应用的性能监控,一般会部署到生产环境中,了解应用的性能瓶颈。不过我的理解,如果在ci的过程,我能集成,这样测试人员,对应用的性能了解更加深入。开发的过程中,就关注性能,我感觉也是很有必要的。到底那个commit代码导致性能的下降,那么我们有一个直观的工具了解到,还是非常方便的。

不过很遗憾,我搜索半天,基本没看到相关的在CI过程使用pinpoint。那么在OpenShift的部署

https://github.com/makentenza/ocp-pinpoint-apm

也是出自红帽工程师,值得信赖。

JAEGER 这也是一个热门选择工具

https://github.com/jaegertracing/jaeger-openshift

openshift很多使用案例。

应用日志管理

Snap12

红帽的OpenShift已经集成了EFK,可以通过这个来收集和查看整个平台的日志。不过由于微服务,导致应用的日志数量庞大,日志落盘后,收集,会导致很多性能的问题。

经过实践,自己开发的应用,我们都是直接让应用把日志log发送给Kafka,最后发送懂Elasearch上来查看。如果是一些比较轻的应用,例如jira,等,这些应用,你是不可能改变他的日志输出方式,那么我们就让他落盘,通过Fluntd来收集日志,通过kibana来查看。红帽的这套EFK是支持多租户,其实做的还是非常不错的。

kafka,elk这套工具,也是可以完整部署到Openshift上。

应用监控管理

普罗米修斯

OpenShift平台上,重点推荐普罗米修斯来作为监控。整个平台日后都会用普罗米修斯监控。那么针对应用的监控,我们是使用平台的普罗米修斯来监控,还是每个应用都部署一套普罗米修斯?

如果是比较轻的应用,那么我们就直接使用平台的普罗米修斯就可以。如果是很重的应用,例如需要集成Istio,那么基本就会建议项目本身部署一套普罗米修斯来做监控。这点其实和日志也比较类似。

Sep 192018
 

七年之痒这个词,大家经常说,不过起源,估计就不是谁都清楚。这是梦露的一部影片的名字,后来大家发现无论是企业,家庭,甚至政府,都在第七年时间段上面临各种麻烦。

OpenStack存在的问题,其实已经不是痒,就挠一下。基本上是已经无药可救。

逐步没落

我是2010年七月份,入职世纪互联云快线公司,开始搞云计算,公司是IDC,所以也就非常关注美国的IDC领头羊Rackspace,那时候在美国,Rackspace云计算是排名第二的,基本上是中国IDC的学习偶像。

非常巧合,我入职的时候,Rackspace和NASA推出OpenStack的项目。所以也就从哪个时候,一直跟着这个项目,一直走到2017年7月份,OpenStack的china Day,真的整整七年。见证了OpenStack整整7年,从零开始到巅峰,走向下坡路的过程。

现在已经离开OpenStack整整一年,回过头来看看,OpenStack到底有啥问题,遇到什么麻烦呢?屁股决定脑袋,我现在的屁股,应该也可以让我说的清楚一点。

经常有朋友问我未来OpenStack的发展趋势,我就用这张OpenStack邮件列表数量统计图来回答这个问题

邮件列表

图片来源:https://openstack.markmail.org/

现在邮件列表的活跃度,2016年到达巅峰,逐步在下降。基本上也是可以代表OpenStack的热度和发展状况的。这种下降的趋势,其实目前来看,还是很难逆转。

OpenStack社区真正干活,写代码的人,数量多少呢?估计已经不超过20人在全职干活。应该不到巅峰时刻的百分之十。

都不挣钱

其实我思考过,OpenStack存在的各种问题,不过归根结底,就是厂商根本就不挣钱。以前一个笑话,就是OpenStack最大的赢家是OpenStack基金会,每年入账1000万美金。

用开源软件来实现企业的盈利,这个无论是国外还是国内,都是非常有挑战性的问题。历史上,linux内核,就红帽实现的盈利。Hadoop的生态圈,至少有2家公司上市。那么对于OpenStack厂商来说,基本还是零。

国内的OpenStack市场,如果从2015年算起,经历了3年的发展和摸索,国内的OpenStack创业公司,基本都已经沦落为高级人力外包的公司。整个OpenStack的市场规模,也不足以支撑OpenStack创业公司的估值。这也导致从2016年,mirantis放弃Pure OpenStack厂商后,国内的厂商也都已经都布其后尘。

从现在看来,OpenStack创业公司上市套现的机会越来越少,也就导致OpenStack投资者也就没啥好日子。

很多朋友抱怨OpenStack很多不成熟的地方,不过说实话,就算把OpenStack做的完美,其实也是无法解决当前的困境,无法盈利。国内OpenStack厂商,最有想法,产品思维的两个厂商,是最先阵亡的,刻通和有云。

TC不作为

OpenStack基金会成立,专门有一个TC,技术委员会,负责OpenStack的技术方向,经过几年的发展,基本已经成为的养老院和老油条。

从2015搞的big tent,大帐篷项目,就是信心过于膨胀,项目从10个暴涨到50多个,不到1年的时间,问题就暴露出来。

谁都不能保证自己的决策不出错,但是出错,不做调整,就是作死。自从2016年Mirantis退出后,OpenStack大量项目出现没人玩的情况下,TC没做任何的事情。

一直到今天,OpenStack项目还是在不断增加,项目参与人手在不断减少。大量的僵尸项目,没人愿意站出来当丑人,直接把项目砍掉。

对比CNCF基金会,目前据说有500多个项目在排队等待孵化批准,批准进入孵化阶段门槛都是非常高,更别说毕业。

企业用户收益差

这点上,在我做容器,paas后,感受更加深刻。对于IaaS来说,他应该是可以给企业带来的效率的提升,资源的节省。不过这个如果和vmware比起来,就基本没啥优势。

国内的私有云市场,主要的客户群体是政府和国企。使用OpenStack的目的,并不是为了提高企业的竞争力,而是更多为了自主创新。

真正尝试使用OpenStack的企业,带来最大的好处,估计是技术人员的能力得到很大的提升。但是给企业的本身带来哪些改变呢?资源的节省,效率的提升,其实公司是没有感觉的。

企业目前使用资源的方式,还是资源创建者和使用者分开,无法真正实现自服务。运维负责创建虚拟机,开发者负责使用。

当用户无法在使用OpenStack中真正受益,那么放弃就是早晚的事情。

其实我当初走PaaS的时候,对PaaS能给企业带来什么好处,还是有疑问的。不过经过不到半年的使用,就能真正感受到Docker,PaaS平台给企业带来的好处,效率的提升,资源的节省,真的一个数量级别的提升。

K8S and PaaS

容器,Docker对OpenStack来说,其实还不能构成威胁。但是K8S,和PaaS的成熟,确实让OpenStack看不到未来。

很多用户受到IaaS,PaaS,SaaS三层架构的影响,认为PaaS就应该跑在IaaS上面,当年一位朋友,还专门去找新浪的SAE部门的老大,确认新浪的PaaS是跑在IaaS上,还是物理机器上。

其实根本不用纠结这个问题,PaaS和IaaS其实是一个松耦合的,PaaS完全可以直接跑在物理机器上。

我经常问容器厂商一个问题,到目前为止,哪些应用是无法跑在容器上的。必须要跑在VM上呢?其实真的没有,或者真的很少,很少。

Snap4

未来的企业数据中心,很可能是PaaS,K8S的天下。

OpenStack其实就算不犯任何的错误,在k8s出现后,其实都很难改变他的下坡路的趋势,无非是让下降平滑一点而已。

技术不是问题

最近好几篇文章,讨论OpenStack,说OpenStack技术复杂,有哪些短板。其实我 是看着OpenStack过来的。我可以说,目前阶段的OpenStack,技术上,还是过得去的。

几大核心项目,提供计算,存储,网络的功能,还是很稳定的。借助OpenStack容器化部署工具,kolla,不仅仅把OpenStack部署好,日志EFK都会部署的很好,目前kolla的社区普罗米修斯已经基本整合好了,再打磨一个版本,应该就用了。

长期用户纠结所谓升级的问题,也顺利解决,甚至可以实现某个组件的降级,例如neutron,你可以上以前版本,因为sdn兼容的原因。

我曾经很霸气回答友商提问,你的OpenStack和我的有啥区别问题。我说我给用户提供的OpenStack,让用户自己可以升级。

kolla即使做的那么优秀,我整整参与了2年,也无法挽救OpenStack的衰退。

Sep 102018
 

公有云的公司讨论的两大热门话题,我想第一是计费,第二应该就是应用商店。IaaS厂商都在想办法做一个应用商店,很可惜,基本都失败了。

当年我曾经也是一个产品经理,调研过各大厂商的应用商店。这里我就做一个总结

虚拟机年代

镜像

把应用放到镜像里,这是最容易想到的应用商店,虚拟机启动后,做的配置,技术上还是可以实现。AWS在2010年的时候,应该就是差不多这种情况。

AWS上有大量的应用的镜像,你启动后,就可以使用,看起来是很方便。不过其实也就是自己使用,很难满足复杂的场景,基本都是 all in one。而且软件的版本,是一个噩梦,一个版本一个镜像,真的受不了。

脚本

很多人自然就想到,base的镜像都是一样,在虚拟机启动的时候,运行相关的脚本,来部署相关的软件。cloud-init,基本就是这个用途。

在国外的网络速度的情况,基本不是问题。不过在国内,基本就没戏了。而且这种方式,还是单机版本,复杂点,就基本没办法。

开发模式

有专门针对开发者的应用商店,因为开发者,有不同版本的需求,就简单lamp为例,php版本,mysql的版本,apache的版本,排列组合太多了,如何解决这个问题呢?

把软件都放到虚拟机里,用户选择需要什么版本,就启动相应的组件。这方面,bitnami做的应该是最好的。这家公司,从2011年开始到现在,做了8年,也在不断改进。

Agent模式

为了应用商店能投入生产,能部署复杂的应用,支持灵活的定义,web和数据库,可以合并部署,也可以分开部署。那么就有人想到使用agent来实现。

rightscale,国外著名的云管厂商,就是通过植入一个agent,来对虚拟机进行应用的部署,类似配置管理工具,这样就非常灵活,基本可以实现软件的全生命周期的管理。

通过agent,你可以实现对应用进行监控。那么对于IaaS来说,如果所谓弹性扩展,只考虑cpu,内存,那么是很胡扯的。