在OpenShift，整整忙乎了一年，逐步一点一点完善整个CI 的工具链。根据我自己的理解和实践，我整理一下。
这些工具链，除了要感谢同事努力，帮忙验证这些工具是可用的，同时还需要感谢客户，正是因为这位客户的交流，给我们提了很多需求和想法，经过他的折磨，才有今天的这套相对比较完整的工具链。这也是我后续持续半年的投入来完善动力。
涉及的相关的技术，其实我同事已经分享到简书上，大家可以参考。
https://www.jianshu.com/u/15a6a6df3202
我是按照jenkins的运行的流程来介绍工具
- 在Jenkins创建一个Maven的job
- Gitlab的webhook，触发Jenkins里的job，jenkins的slave镜像启动，Maven已经集成到jenkins的slave镜像里。
- 从Gitlab拉取代码
- Jenkins调用SonarQube静态扫描代码
- Maven利用Nexus build jar包
- Maven利用Junit和TestNG自动化测试
- Jenkins Slave镜像完成相关工作，会把结果传到Jenkins的Master节点上，然后把slave节点销毁掉。
- 触发Openshift build 镜像，deploy环境
- UI自动化测试
对于ci的流程，不少工具会产生大量的数据，所以尽可能使用S3，对象存储来存储数据，这样可以避免磁盘撑破。流程里的工具，都采用OpenLdap来统一身份验证，授权在应用里进行。
下面的工具，全部容器化，跑在OpenShift上。整个环境的部署，从OpenShift安装，一直到工具链对接，跑完一个Java的demo测试，1天就可以完成，应该还是非常高效。
身份统一认证
其实打造一套工具链，面临了一个很现实的问题，如何统一不同工具的身份验证的问题。那么通过OpenLdap，基本是唯一办法，这是代价最小的方式，现在目前基本所有的应用，都支持ldap认证。
所以我们也花精力把OpenLdap跑起来，用来提供用户验证，当我设置允许该用户登录某个系统，用户用统一的用户名和密码，登录到不同的系统中。
第一个需要解决的系统，其实就是OpenShift平台的用户管理。用户在openldap上创建，用户的权限管理，在openshift设置。
OpenLdap在OpenShift平台部署，比较简单。
https://github.com/openshift/openldap
OpenShift上部署生产的OpenLdap，需要考虑不少东西，主从架构，估计还需要搞一个Operator，不过应该够用。
目前OpenLdap的用户管理，缺乏UI，这块我们自己开发一套OpenLdap管理的UI，当然也肯定是跑在OpenShift上。
项目管理
软件的项目管理，需求管理，这是在比较大的项目里的一个需求，另外还有项目的文档管理。
软件的开发，我们希望可以支持敏捷开发，实现看板的功能。还有就是issue的管理。关于issue，详细的介绍，大家可以http://www.ruanyifeng.com/blog/2017/08/issue.html 阮一峰介绍的很详细。
- Redmine
- Jira+confluence
- 禅道
上面三个软件，都能支持ldap的用户管理，我基本都折腾了一遍。最好的肯定是Jira+confluence。很多创业公司一成立，就直接把jira+confluence搭建起来，宁愿付费，也要使用，提高效率。
Jira和confluence官方提供docker镜像，你可以拿来修改一下就可以跑在OpenShift上。这个过程，基本就是体力活。当jira和confluence用起来后，存储需求比较大，其实应该考虑把数据放到S3上，减轻PaaS平台的存储压力。
禅道，基本是能满足我们使用需求。缺点就是一个孤岛，没法和外面的系统集成。
Redmine，老牌的开源项目管理软件，可以通过装上各种插件满足项目的需求。可以和gitlab对接。唯独社区不是很活跃，用ruby语言开发，感觉非常不可控。
对于Jira来说，其实可以作为一个公司的门户入口。如果你舍得投入的话，要有的功能都有。可以对接jenkins，Sonarqube。把各个软件的运行的信息，显示在jira的页面上。
持续集成工具
红帽的OpenShift上已经直接集成了Jenkins，而且用户是和OpenShift统一。可以启用jenkins的k8s插件，这样可以把jenkins的slave跑起来。当job在slave跑完后，会把相应的结果复制到master上，就会销毁掉。
jenkins的插件非常多，常用的gitlab对接，gitlab触发jenkins，jenkins和jira对接，jenkins的深入，其实就看你使用的插件的数量。
整个持续集成的重点，就在于Jenkins，jenkins是挺复杂，你需要投入时间了解他，不过好处就在于，好像基本没碰到什么bug。插件都能正常工作。
关于Jenkins启用k8s插件后，slave节点的配置
如果要提高jenkins的并发能力，用好slave，大家真的要好好看看。
使用的时候，有一个地方需要注意
https://github.com/jenkinsci/kubernetes-plugin
搜索 Over provisioning flags 。
这个地方也是需要注意，设置一下。
项目构建工具
对于java的开发人员来说，项目的构建工具：ANT，Maven和Gradle，ANT应该早已废弃。Gradle风头很猛，不过Maven在如今仍然是Java构建技术的事实标准。所以我们项目里，还是选择Maven作为构建工具。
大家可以简单理解，Maven，就是管理项目的依赖关系的工具。
Openshift内置的jenkins Slave镜像，默认就支持Maven。所以就非常方便。如果你希望用Gradle构建，那么还需要多做一点工作。
代码管理工具
其实这个悬念不多，建议直接使用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集成，也是没问题。
代码质量管理
代码扫描工具，基本目前大家都使用SonarQube。可以对没编译前的代码根据定义的规则，进行扫描，并且生成报告。
用户还能自定义规则，可以把公司的代码规范融入到规则里，一旦发现不规范的地方，马上提示。
Jenkins装上SonarQube插件，在流水线上，直接让SnoarQube进行代码的扫描。
另外SonarQube还能通过jira的插件，把报告显示在jira的UI上。
Openshift安装，红帽提供了一个模板：
https://github.com/OpenShiftDemos/sonarqube-openshift-docker
朋友问的最多的问题，关于如何自定义规则，参考这里基本就差不多。
https://github.com/SonarSource/sonar-custom-rules-examples
制品库
作为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构建的时候，就可以直接使用私有的仓库来构建，加快构建的速度。
测试框架
Maven本身并不是一个测试框架，Java世界中主流的测试框架为Junit和TestNG。Maven在构建执行到特定生命周期阶段的时候，通过插件maven-surefire-plugin来执行Junit或者TestNG的测试用例，也可以并行执行测试用例。该插件能很好的兼容Junit3、Junit4，unit5和TestNG。
https://www.baeldung.com/core-maven-plugins
配置管理中心
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
对于OpenShift来说，开发，测试，生产使用相同的镜像，就需要一个配置管理中心，集中管理各个不同的环境的配置文件。
UI自动化测试
zalenium是一个Selenium Grid扩展，可以理解为在k8s跑Selenium Grid的版本，实现在Firefox和Chrome中进行的UI自动测试。
Selenium Grid包括两种角色，类似master，slave的概念，可以实现1主多从。
- hub ：主节点，master节点
- node：分支节点，slave节点
测试管理
测试用例管理，测试计划管理，目前开源的工具，基本就是Testlink。可以和jira或者Redmine集成，把issue集成到上面。不过还无法在testlink里，指派issue给开发者。
展望
其实没完成和验证的东西，我是不想放在这里。不过有朋友专门来找我聊，问我还有啥进一步的想法，他考虑根据这个去招标。我是从来不隐瞒我的想法的，我就把我的一些我未来计划要做的工作整理一下。
压力测试
通过testNG的插件，就可以对应用进行功能测试，压力测试。不过大家常用的压力测试工具是jmeter。在OpenShift的部署，倒是简单。红帽的美女工程师有专门的blog https://eleanordare.com/ 和githuab代码，
https://github.com/eleanordare/jmeter-openshift-jenkins
需要的是投入精力研究jmeter的使用，如何写脚本。
安全动态扫描
sonarqube可以进行代码的静态扫描，就是对git仓库的代码直接扫描，发现一些基本的漏洞。安全的动态扫描，以往都是应用上线前，进行安全漏洞扫描。我们其实应该把漏洞扫描集成到我们的CI过程。
OWASP ZAP
https://github.com/rht-labs/owasp-zap-openshift
红帽已经把OpenShift集成做好了，剩下也是使用的问题。这个其实对企业还是很有价值的。另外Snoarqube也是有集成插件，可以把报告发过去。
代码Review专业工具
习惯OpenStack的代码review，其实用起gitlab的代码review功能，还是比较别扭。不过国内其实公司代码的Review机制其实还是没建立起来。真的要用代码review，还是需要Gerrit。
Gerrit和gitlab进行整合，并且Gerrit对接Jenkins，让提交代码没merge前，就可以跑测试，这个真的要花功夫去调试，才能玩得转。
目前Gerrit在Openshift上的使用案例不多，据说红帽内部是用Gerrit来做代码review。后续需要把这个实现，工具链才能算是完整。
自动化运维工具
估计很多朋友还没搞明白，为啥需要在DevOps工具链里集成红帽的Ansible Tower的管理工具。我们可以把我们日常运维的ansible roles用Tower管理起来。包括OpenShift自己的。
后续很多想法。如何做到更加自动化，其实都要依赖ansible。
当我们的项目架构评审完毕后，所有的需求，以往都是在一个wrod文档，Excel文档，通过手工的方式来把开发环境准备出来。这里面其实体力活很多，创建的数据库的密码是啥，URL是啥。有什么办法，可以把文档需求，自动化把开发环境初始化出来，并且把初始化的信息反馈回来到相应的页面里，这样大家就可以有一个统一的入口，查看相关的信息。不然运维人员项目多起来，也是会累死的，即使用了OpenShift。
OpenShift跑Tower，管理Ansible，也是红帽大力推动的一个方向。Tower的开源版本是Awx
https://github.com/ansible/awx
Openshift的安装
应用性能管理
应用的性能监控，一般会部署到生产环境中，了解应用的性能瓶颈。不过我的理解，如果在ci的过程，我能集成，这样测试人员，对应用的性能了解更加深入。开发的过程中，就关注性能，我感觉也是很有必要的。到底那个commit代码导致性能的下降，那么我们有一个直观的工具了解到，还是非常方便的。
不过很遗憾，我搜索半天，基本没看到相关的在CI过程使用pinpoint。那么在OpenShift的部署
https://github.com/makentenza/ocp-pinpoint-apm
也是出自红帽工程师，值得信赖。
JAEGER 这也是一个热门选择工具
https://github.com/jaegertracing/jaeger-openshift
openshift很多使用案例。
应用日志管理
红帽的OpenShift已经集成了EFK，可以通过这个来收集和查看整个平台的日志。不过由于微服务，导致应用的日志数量庞大，日志落盘后，收集，会导致很多性能的问题。
经过实践，自己开发的应用，我们都是直接让应用把日志log发送给Kafka，最后发送懂Elasearch上来查看。如果是一些比较轻的应用，例如jira，等，这些应用，你是不可能改变他的日志输出方式，那么我们就让他落盘，通过Fluntd来收集日志，通过kibana来查看。红帽的这套EFK是支持多租户，其实做的还是非常不错的。
kafka，elk这套工具，也是可以完整部署到Openshift上。
应用监控管理
OpenShift平台上，重点推荐普罗米修斯来作为监控。整个平台日后都会用普罗米修斯监控。那么针对应用的监控，我们是使用平台的普罗米修斯来监控，还是每个应用都部署一套普罗米修斯？
如果是比较轻的应用，那么我们就直接使用平台的普罗米修斯就可以。如果是很重的应用，例如需要集成Istio，那么基本就会建议项目本身部署一套普罗米修斯来做监控。这点其实和日志也比较类似。
