关于云与持续集成杂谈

　　在网上看到了一款号称云时代的操做系统：数人云，简单看了一下其产品Demo：https://dashboard.shurenyun.com/cluster/listclusters ，瞬间以为很眼熟，有种似曾相识的感受，原来和我2012~2013年时候，在EISOO平台研发部门时候，为当时的云存储后端系统设计的那个管理后台第一版有点像。不过那时候还涉及到集群管理，节点管理等等，比这个更复杂一些，那个是供IT管理员使用的后台系统；

　　我2011年时候接触到Openstack，转眼之间，已是时隔四年多了。那时候的IaaS有OpenStack、CloudStack、Eucalyptus和OpenNebula，固然AWS另说。我当时经历过Openstack的D~G版本的迭代，不过目前Openstack已是L版本了，当时颇有兴趣继续深刻研究OpenStack，但惋惜，公司的决策层战略方向与定位决定了，最终主要作传统的私有云存储系统，当时对于像UCloud、七牛、UpCloud、青云等等互联网式的云服务并没有太多兴趣；EISOO注定了是一个相对传统和保守的公司，不过稳扎稳打也是其优点；与我的而言，对于感兴趣的东西，在当时的工做机会过程当中，不曾深刻研究，有点遗憾。

　　扯远了，回来，其实经历过云计算，也不算遗憾。我从08年接触到云计算的概念，就认为他在将来将会颇有用处，事实也确实如此，云计算的应用场景将愈来愈普遍。

　　云不只仅整合了物理资源、使得计算、存储、网络等资源获得虚拟化和更高效的使用，也节省了资源，固然这是IaaS。

　　而如今PaaS、SaaS也大行其道，当平台、软件等等都逐渐以服务化的方式提供出来的时候，这其实也是整个科技发展的一次大的重构。

　　云时代，服务化、少耦合，架构演进，毫无疑问，将在将来创造很是多的精彩，极大的改善人们的生活，创业环境，让一切变得简化，高效。

架构与测试的重要性

　　记得之前刚毕业的时候，参加过CMMI3过程改进事宜，接触过 RUP，统一软件过程的理念。RUP的理念对个人架构有很深的影响，RUP实际上是再讲下面这三个特色：

1. 用例和风险驱动Use Case and risk driven

2. 架构中心Architecture centric

3. 迭代和增量Iterative and incremental

　　RUP很注重架构，提倡以架构和风险驱动，该开始必定要作端到端的原型prototype；经过压测验证架构可行性，而后在原型基础上持续迭代和增量式开发，开发->测试->调整架构->开发，循环，以下图所示：

 

　　架构师作好框架以后，开发人员写代码，测试人员须要尽快对架构进行验证。纸上谈兵式作架构然后丢给团队的做法很是不靠谱（除非是已经很是清晰成熟的领域）。另外，作技术架构的都有点完美主义倾向，一开始每每喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能造成有效快速的反馈，产品不知足最终用户需求。

　　其实，架构一直在演进、代码一直在重构，测试一直在优化，才是一个好的循环。

　　看看下面的这些，摘录了部分熟人云的描述(参考：http://doc.shurenyun.com/get-started/vocabulary.html)，部分文档以下：

微服务

微服务是一种新兴的应用软件架构，它经过一组服务的方式来构建一个应用，服务独立部署在不一样的进程中，不一样服务经过一些轻量级交互机制来通讯，例如 REST。每一个服务可独立扩展伸缩，而且定义了明确的边界，不一样的服务甚至能够采用不一样的编程语言来实现，由独立的团队来维护。

微服务架构有不少好处:

1. 经过将巨大的单体式应用分解为多个服务,解决了复杂性问题。在功能不变的状况下，应用被分解为多个可管理的分支或服务。每一个服务都有一个用 REST API 定义清楚的边界。微服务架构给采用单一编码方式很难实现的功能提供了模块化的解决方案，而单个服务很容易开发、理解和维护。
2. 这种架构使得每一个服务均可以由专门的开发团队进行开发。开发者能够自由选择开发技术，提供API服务。固然，许多公司试图避免混乱，只提供某些技 术选择。而后，这种自由意味着开发者不须要被迫使用项目初期所采用的过期技术，他们能够选择最新的技术。由于服务都是相对简单，因此即便用如今技术重写以 前代码也不是很困难的事情。
3. 微服务架构要求每一个微服务作到独立部署。开发者再也不须要协调其它服务部署对本服务的影响。这种改变能够加快部署速度。微服务架构模式使得持续化部署成为可能。
4. 微服务架构模式使得每一个服务能够独立地扩展。你能够根据每一个服务的业务量来部署知足其需求的规模。

服务发现

服务发现的基本思想是，任何一个应用的实例可以以编程的方式获取当前环境的细节，而新的实例能够嵌入到现有的应用环境而不须要人工干预。服务发现工 具一般是用全局可访问的存储信息注册表来实现，它存储了当前正在运行的实例或者服务的信息。大多数状况下，为了使这个配置具备容错与扩展能力，这个工具以 分布式形式存储在多个节点上。

服务发现减小或消除了组件之间的“手动”链接。当你把你的应用程序推送进生产环境的时候，全部的这些事情均可以配置：数据库服务器的主机和端 口，REST 服务的 URL 等等。在一个高可扩展的架构中，这些链接能够动态改变。一个新的后端能够被添加，一个数据库节点也能够被中止，你的应用须要适应这种动态环境。

数人云为用户提供了完备的服务发现能力：

1. TCP/HTTP
   根据服务端口协议的不一样，能够选择 TCP 转发或 HTTP 转发；

2. 对内/对外
   数人云不只提供传统的对外服务发现，还为分布式服务提供了对内服务发现；对外服务发现经过外部网关对外提供服务，若是是 HTTP 服务，须要配置域名或外网 IP；对内服务发现经过内部代理，将多实例的微服务端口映射为统一暴露的端口；

示例

搭建 wordpress 站点的过程当中，须要部署一个 Mysql server 和一个 Wordpress server。

• Mysql 自己的服务端口为3306，协议类型为 TCP；Mysql 服务须要对内部模块开放，开放端口仍然沿用3306。所以，对 Mysql 的应用地址配置以下所示。

数人云对内服务发现机制会自动将应用实例的地址映射为内部网关的地址。图中的“地址”一栏，即为访问 Mysql 所用的地址，其中 IP 为内部网关 IP。

• Wordpress 自己是一个 web 服务，其端口为默认 80，协议类型为 HTTP；Wordpress 服务须要对外部访问开放。
  若是外部网关配有可访问域名，则经过域名访问服务，开放端口为 80，不可修改。

若是外部网关没有配置域名，则经过 IP 访问服务，开放端口可选，这里为防止端口冲突，设为81。

数人云对外服务发现机制会自动将应用实例的地址映射为外部网关的地址。图中的“地址”一栏，即为访问 Wordpress 所用的地址，其中 IP 为外部网关 IP或域名。

容器服务

容器采用沙箱机制，相互之间不会有任何接口（相似 iPhone 的 app），几乎没有性能开销，能够很容易地在机器和数据中心中运行。最重要的是，他们不依赖于任何语言、框架以及系统。

Docker是一个开源的应用容器引擎，让开发者能够快速打包应用以及依赖包到一个可移植的容器中，而后发布到任何主流的 Linux 主机上。

数人云采用目前流行的Docker容器，基于 Mesos 集群调度工具，能轻松管理和调度成千上万个容器，作到秒级启动，秒级销毁，而且能作到大规模的负载均衡。

数人云提倡客户采用微服务架构，将微服务架构应用的服务进行容器化，做为云计算应用交付的标准。这样的好处是，不只能保持应用环境的一致性，让开发和运维等从烦杂的环境构建中解脱出来，还能够轻松作到容错性、高可用、横向扩展等特性。  

 

借助熟人云快速大件Jenkins储蓄集成环境，测试人员能够用获得：

Jenkins

Jenkins 是基于 Java 开发的一种持续集成 (CI) 工具，使用数人云部署 Jenkins 可以在作到快速搭建的同时，实现资源的动态调度，提升资源利用率。

下面讲述一下数人云上搭建 Jenkins 的架构和工做流程：

• Jenkins Master

  它负责提供整个 Jenkin 的设置、webui、工做流控制定制等。首先，将Jenkins-Master使用数人云发布，数人云会对其进行程序管理和健康检查，从而在应用程序因为 某些意外崩溃后自动恢复，保证了Jenkins-Master构建系统的全局高可用，使用数人云部署Jenkins使您的Jenkins应用运行在一个资 源池中，进一步实现了资源共享，提升了资源利用率。

• Jenkins Slave

  Jenkins利用在数人云上创建的集群资源，主要的目的是利用弹性资源分配来提升资源利用率，经过配置Jenkins-mesos-plugin 插件，Jenkins Master能够在做业构建时根据实际须要动态的申请Jenkins-Slave节点，并在构建完成后的一段时间后，将节点归还。

• Jenkins-mesos-plugin

  Jenkins-mesos-plugin是用插件模式挂载到Jenkins Master上的。主要目的是要把Jenkins-Master看成集群的调度器使用，能够调度用数人云创建的集群资源为Jenkins服务。

数人云注册&登陆&建立集群

由于数人云迭代很快，因此这里就不进行详细描述，最新数人云操做文档会在数人云用户手册中，须要参考的用户请点击：数人云用户手册

使用数人云部署 Jenkins

部署 Jenkins 应用很简单，下面是具体操做步骤：

选择应用管理，点击"新建应用"，按照以下提示，新建 Jenkins 应用：

• 填写应用名称：jenkins
• 选择集群：demo
• 添加应用镜像地址：testregistry.dataman.io/centos7/mesos-0.23.0-jdk8-jenkins1.628-master
• 填写镜像版本：app.v0.3
• 选择应用模式：HOST模式
• 选择应用类型：有状态应用
• 选择主机：主机下拉列表中选择任一合适IP便可
• 主机/容器目录配置： 数据挂载目录：/data/jenkins 容器目录：/var/lib/jenkins
• 选择容器规格：CPU：0.2 内存：512MB

高级设置：

• 点击添加环境变量，填写环境变量参数：

  Key: JAVA_OPTS      Value: -Xmx512M -Xms512M
    key: JENKINS_PORT   Value: 8002

填写完成以后，点击建立便可，建立完成后可看到应用部署状态等信息：

稍等片刻可看到应用已正常运行：

打开浏览器，在内部代理配置好的状况下访问 Jenkins，访问地址为：yourip:JENKINS_PORT，看到以下页面，则说明 Jenkins 应用已经成功运行。

Jenkins 数人云设置

若是咱们想要将Jenkins做为mesos的一个framework注册到mesos上，须要在成功启动 Jenkins以后对其插件进行设置。

设置 Jenkins-Mesos 分三层，点击左上角"系统管理"，而后在系统管理页面点击"系统设置"。

1. Jenkins 调用 Mesos 集群设置

2. Mesos native library path 设置 Mesos lib 库路径，通常在/usr/lib/libmesos.so，拷贝无效，必须安装 Mesos。

3. Mesos Master [hostname:port] 设置 Mesos-Master 地址加端口，若是单 Mesos-Master 模式，使用 mesos-master-ip:5050格式，若是是多 Mesos-Master 使用 zk://zk1:2181,zk2:2181,zk3:2181/mesos 格式
4. Framework Name 设置 Mesos Master 查看到的应用框架名称
5. Slave username 设置 Slave的名字
6. Checkpointing 设置检查
7. On-demand framework registration 设置是否在无任务的状况下，从 Mesos-Master 注销应用框架

1. Jenkins Slave 调用 Mesos-Slave 类型设置(可按资源)

2. Label String 设置 Slave 标签

3. Maximum number of Executors per Slave 每一个 Slave 能够同时执行几个任务
4. Mesos Offer Selection Attributes 选择在那些 Mesos Slave 标签资源上运行，格式{"clusterType":"标签"}

1. Jenkins Slave 调用 Docker 镜像设置

2. Docker Image 设置 Jenkins Slave 使用镜像

3. Networking - Bridge 设置网络模式，这里必定要设置网桥模式
4. Port Mapping -Container Port & Host Prot 设置容器端口关系，必须设置不然会致使 Mesos-DNS 因找不到端口映射崩溃，Host Port 默认设置为空(自动取)，不然必须设置在39000之后的Mesos Slave 选定端口内。
5. Volumes 挂载目录，必须挂载 slave.jar 和 docker in docker

后续

所使用的 Dockerfile 和启动脚本所有开源，并上传到熟人科技的GitHub，若是有兴趣的话，却是能够参与一下，https://github.com/Dataman-Cloud/OpenDockerFile/tree/master/jenkins。

 

一个基于 Jenkins 的持续集成集群环境已搭建完成，让咱们一块儿快速迭代产品吧，给用户不断带来一个个的小惊喜。