目录javascript
一、Spinnaker 介绍html
Spinnaker 是 Netflix 的开源项目,是一个持续交付平台,它定位于将产品快速且持续的部署到多种云平台上。Spinnaker 经过将发布和各个云平台解耦,来将部署流程流水线化,从而下降平台迁移或多云品台部署应用的复杂度,它自己内部支持 Google、AWS EC二、Microsoft Azure、Kubernetes和 OpenStack 等云平台,而且它能够无缝集成其余持续集成(CI)流程,如 git、Jenkins、Travis CI、Docker registry、cron 调度器等。简而言之,Spinnaker 是致力于提供在多种平台上实现开箱即用的集群管理和部署功能的平台。java
Spinnaker 官网 文档能够了解到,Spinnaker 主要包含两大块内容,集群管理和部署管理。node
集群管理主要用于管理云上的资源,它分为如下几个块:git
部署管理功能用于建立一个持续交付流程,它可分为管道和阶段两大部分。github
部署管理的核心是管道,在Spinnaker的定义中,管道由一系列的阶段(stages)组成。管道能够人工触发,也能够配置为自动触发,好比由 Jenkins Job 完成时、Docker Images 上传到仓库时,CRON 定时器、其余管道中的某一阶段。同时,管道能够配置参数和通知,能够在管道一些阶段上执行时发送邮件消息。Spinnaker 已经内置了一些阶段,如执行自定义脚本、触发 Jenkins 任务等。web
Spinnaker 支持精细的部署策略,好比 红/黑(蓝/绿)部署,多阶段环境部署,滚动红/黑策略,canary 发布等。用户能够为每一个环境使用不一样部署策略,好比,测试环境可使用红/黑策略,生产环境使用滚动红/黑策略,它封装好了必须的步骤,用户不须要复杂操做,就能够实现企业级上线。redis
二、环境、软件准备sql
Spinnaker 安装在 官网文档 中写的很详细,可使用一种全新的 CLI 工具 halyard,它帮助管理员更容易地安装,配置以及升级用于生产环境的 Spinnaker 实例,可是支持的是 Ubuntu 环境,并且部分资源依赖国外地址,SO 我尝试了一下,因为网络的缘由,安装过程当中没有可以继续下去。。。 因此,这里我选择了 Spinnaker GitHub 安装 Development 版本,配置虽然稍复杂一些,可是做为初试阶段,可以跑起来也是不错的。Development 版本目前只在 Ubuntu 14.04 LTS 和 Mac OS X 10.11 上测试过,因为手头没有现成的 Ubuntu 环境,就直接在本机 Mac OS 上尝试安装一下吧。docker
注意:Development 版本安装,须要获取 GitHub 源码编译安装,其中还须要拉取各个组件模块源码,因此须要安装好 Git。JDK八、Redis、Cassandra、Packer 是安装 Spinnaker 组件时须要依赖的。Jenkins 非必须安装,这里我下边须要演示集成 Jenkins,因此使用 Docker 快速安装一下。下边会详细介绍每一个组件的做用,以及安装方式。
三、安装 Development Spinnaker
安装 Spinnaker 以前,有必要详细描述一下 Spinnaker 架构所依赖的各个组件。
以上组件除了核心组件外,一些组价可选择配置是否启动,好比不作权限管理的话,Fiat 就能够不启动,不集成其余 CI 的话,那就能够不启动 Igor 组件等。这些均可以在配置文件中配置,下边会说到。Development 版本,各个组件独立服务运行,有各自的服务端口,且各个组件都有本身的独立的项目 GitHub 地址。
好了,讲了这么多 Spinnaker 相关的东西了,接下来开始安装 Spinnaker。
3.1 配置依赖环境
Spinnaker 平台须要依赖部分环境,因此为了防止下边安装过程当中出现错误,能够提早安装一下。
一、因为 Spinnaker 核心服务是由 SpringBoot 框架写的,因此须要安装 JDK8 二、Spinnaker 须要使用 Redis 存储数据,因此也须要安装。 三、Cassandra 是非关系型数据库存储,默认 Front50 组件和 Echo 组件配置使用该存储,也须要安装。 四、Packer 是开源的支持多平台建立镜像工具,rosco 组件配置使用该工具,也须要安装。
以上依赖环境能够去官网下载安装,我这里本机 JDK8 环境已经安装,其余的由于本机是 Mac OS 环境,那么我选择使用 homebrew 安装,很是方便。
$ brew install redis cassandra packer
安装完毕后,咱们启动 redis 和 cassandra,packer 不须要启动,Spinnaker 能够链接调用便可。
3.2 配置并安装 Spinnaker
# clone Spinnaker 代码
$ mkdir /Users/wanyang3/spinnaker $ cd /Users/wanyang3/spinnaker $ git clone https://github.com/spinnaker/spinnaker.git ... # clone Spinnaker 其余个组件代码 $ mkdir build $ cd build $ ../spinnaker/dev/refresh_source.sh --pull_origin ...
说明一下,Spinnaker 项目里面包含核心配置文件,但不包含各组件代码,因此须要建立 build
文件夹,并执行 refresh_source.sh
脚本,会依次 clone 各个组件代码,这里得花点时间了。执行完毕后,显示目录以下:
$ ls -alt /Users/wanyang3/spinnaker/build total 24 drwxr-xr-x 17 wanyang3 staff 578 11 23 14:49 . drwxr-xr-x 7 wanyang3 staff 238 11 28 15:43 .. -rw-r--r--@ 1 wanyang3 staff 6148 11 23 14:49 .DS_Store drwxr-xr-x 14 wanyang3 staff 476 11 17 14:32 citest drwxr-xr-x 45 wanyang3 staff 1530 11 17 14:46 clouddriver drwxr-xr-x 49 wanyang3 staff 1666 11 21 14:32 deck -rw-r--r-- 1 wanyang3 staff 175 11 17 16:24 dump.rdb drwxr-xr-x 32 wanyang3 staff 1088 11 17 15:14 echo drwxr-xr-x 30 wanyang3 staff 1020 11 17 14:32 fiat drwxr-xr-x 35 wanyang3 staff 1190 11 17 14:53 front50 drwxr-xr-x 25 wanyang3 staff 850 11 20 14:13 gate drwxr-xr-x 34 wanyang3 staff 1156 11 17 14:32 halyard drwxr-xr-x 24 wanyang3 staff 816 11 20 17:49 igor drwxr-xr-x 19 wanyang3 staff 646 11 22 11:57 logs drwxr-xr-x 49 wanyang3 staff 1666 11 17 15:11 orca drwxr-xr-x 25 wanyang3 staff 850 11 17 14:46 rosco drwxr-xr-x 18 wanyang3 staff 612 11 17 14:32 spinnaker-monitoring
接下来,咱们须要配置一下 Spinnaker。
$ cd /Users/wanyang3/spinnaker $ mkdir -p $HOME/.spinnaker $ touch $HOME/.spinnaker/spinnaker-local.yml $ chmod 600 $HOME/.spinnaker/spinnaker-local.yml $ cp spinnaker/config/spinnaker.yml $HOME/.spinnaker/spinnaker-local.yml # 修改配置文件 $ vim $HOME/.spinnaker/spinnaker-local.yml
注意:这里的文件 spinnaker-local.yml
是 Spinnaker 核心配置文件,这里能够配置各个组件是否启动或关闭,以及其余参数。同时 <spinnaker_dir>/spinnaker/config/*.yaml
这些配置文件都是各个组件启动时,须要加载的配置文件。这里咱们暂时不作修改,保持默认状态,下边演示功能时在作修改。
这里有必要在详细说一下,经过对 spinnaker-local.yml
配置文件的分析,Spinnaker 各个组件默认启动端口以下:
组件 |
端口 |
依赖组件 |
端口 |
---|---|---|---|
Clouddriver |
7002 |
Redis |
6379 |
Fiat |
7003 |
||
Front50 |
8080 |
Cassandra |
9042 |
Orca |
8083 |
||
Gate |
8084 |
||
Rosco |
8087 |
||
Igor |
8088 |
||
Echo |
8089 |
||
Deck |
9000 |
接下来能够启动 Spinnaker 服务了。
$ cd /Users/wanyang3/spinnaker/build $ ../spinnaker/dev/run_dev.sh [service]
注意:[service]
参数可指定一个或多个组件名称,若指定则只启动指定组件,若不指定,默认启动全部组件,这里咱们就不指定了,启动全部配置开启的组件。若是正常的话,能够看到输出日志中依次启动各个组件,而后执行 gradle 编译,最后完成启动 Spinnaker。
Starting clouddriver
Starting front50
Starting orca
Starting rosco
Starting echo
Starting igor
Waiting for clouddriver to start accepting requests on port 7002... ... :clouddriver-web:compileJava UP-TO-DATE :clouddriver-web:compileGroovy UP-TO-DATE :clouddriver-web:processResources UP-TO-DATE :clouddriver-web:classes UP-TO-DATE :clouddriver-web:findMainClass :clouddriver-web:bootRun ... 2017-11-28 17:34:06.440 INFO 6648 --- [ main] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: getUsingGET_2 2017-11-28 17:34:06.443 INFO 6648 --- [ main] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: listUsingGET_8 2017-11-28 17:34:06.445 INFO 6648 --- [ main] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: listUsingGET_9 2017-11-28 17:34:06.498 INFO 6648 --- [ main] c.n.s.c.listeners.OperationsTypeChecker : Found 0 cloud provider annotations: [] 2017-11-28 17:34:06.567 INFO 6648 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 7002 (http) 2017-11-28 17:34:06.578 INFO 6648 --- [ main] com.netflix.spinnaker.clouddriver.Main : Started Main in 19.568 seconds (JVM running for 22.055)
不过这里我发现了几个问题。
问题一:若是咱们启动以前未启动 Redis 服务,那么这里日志就会输出 redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
异常了。
问题二:本机测试时并无一次启动完全部服务,大部分能够正常启动,Fiat、Gate、Deck 三个组件未启动,Fiat 未启动能够理解,是由于配置文件中设置默认不启动。Gate、Deck 怎么还得本身去手动启动呢。。。
问题三:第一次启动时,发现 front50 未启动,报错相似 Can not find keyspaces 'front50'
这样,这是由于未在 Cassandra 中为建立 front50
的 keyspaces。可经过以下方式查看:
$ cqlsh
Connected to Test Cluster at 127.0.0.1:9042. [cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4] Use HELP for help. cqlsh> describe keyspaces; system_schema system system_traces system_auth system_distributed
能够执行一下命令建立:
cqlsh> CREATE KEYSPACE IF NOT EXISTS front50
WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 }; cqlsh> describe keyspaces; system_schema system front50 system_traces system_auth system_distributed
后来查看了下 Spinnaker 执行脚本,发现是有执行建立该 keyspaces 的代码的,不过好像我第一次安装的时候并无执行。。。
$ cat /Users/wanyang3/spinnaker/spinnaker/pylib/spinnaker/change_cassandra.py ... print 'Installing cassandra keyspaces...' os.system('cqlsh -f "/opt/spinnaker/cassandra/create_echo_keyspace.cql"') os.system('cqlsh -f "/opt/spinnaker/cassandra/create_front50_keyspace.cql"') ...
要是碰到没有执行安装 echo 和 front50 keyspace 致使这两个组件报错的话,能够手动执行一下,建立语句 Spinnaker 已经提供好了,cqlsh 客户端执行 <spinnaker_dir>/spinnaker/cassandra/*.sql
语句建立便可。
好了,如今大部分服务已经启动好了,可是 deck 和 gate 服务尚未启动起来呢!分别进入到 build 目录下 deck 和 gate 目录,先启动 gate 在启动 deck,由于 deck 中请求地址是直接链接 gate,而后 gate 网关在对请求作转发。
$ cd /Users/wanyang3/spinnaker/build/gate $ ./start_dev.sh
若是肯定组件是否启动成功呢?咱们能够简单的 lsof -i :<port>
查看端口状况 也能够分别查看各个组件的日志,看下各组件启动时是否有异常信息。
$ ls -alt /Users/wanyang3/spinnaker/build/logs total 46168 drwxr-xr-x 19 wanyang3 staff 646 11 22 11:57 . drwxr-xr-x 17 wanyang3 staff 578 11 29 09:23 .. -rw-r--r-- 1 wanyang3 staff 89 11 28 17:33 clouddriver.err -rw-r--r-- 1 wanyang3 staff 76945 11 29 09:53 clouddriver.log -rw-r--r-- 1 wanyang3 staff 2529 11 22 11:57 deck.err -rw-r--r-- 1 wanyang3 staff 3586 11 22 11:57 deck.log -rw-r--r-- 1 wanyang3 staff 507 11 28 17:33 echo.err -rw-r--r-- 1 wanyang3 staff 3408986 11 29 09:56 echo.log -rw-r--r-- 1 wanyang3 staff 0 11 17 14:40 fiat.err -rw-r--r-- 1 wanyang3 staff 788 11 28 17:33 front50.err -rw-r--r-- 1 wanyang3 staff 62153 11 28 17:34 front50.log -rw-r--r-- 1 wanyang3 staff 450 11 27 17:05 gate.err -rw-r--r-- 1 wanyang3 staff 2192698 11 27 17:05 gate.log -rw-r--r-- 1 wanyang3 staff 89 11 28 17:33 igor.err -rw-r--r-- 1 wanyang3 staff 17736046 11 29 09:56 igor.log -rw-r--r-- 1 wanyang3 staff 89 11 28 17:32 orca.err -rw-r--r-- 1 wanyang3 staff 63183 11 28 17:33 orca.log -rw-r--r-- 1 wanyang3 staff 89 11 28 17:33 rosco.err -rw-r--r-- 1 wanyang3 staff 41101 11 28 17:33 rosco.log
接下来启动 deck 组件,deck 启动的话,会稍微麻烦一下,能够参考 Deck GitHub Doc 文档说明操做。
首先须要安装依赖环境 node 和 yarn
$ brew install node yarn
这里咱们是本地搭建的 develop 版本,全部服务均为 localhost。上边说了,deck 先须要经过链接本地 gate 连将请求转发到对应组件上。因此能够经过以下方式启动 deck
API_HOST=http://localhost:8084 yarn run start
先稍等一会,这里会先执行编译,启动完毕以后,咱们就能够经过访问 http://localhost:9000
访问 Spinnaker deck 组件提供的 UI 页面了,页面简洁明了,很是好操做。
从上图能够看到,Spinnaker 主要的功能已经列出来了。并且这些功能是能够控制的,当扩展或中止了组件之后,UI 页面也会跟着展示出来,接入简单,可扩展性强。
四、演示 Spinnaker Pipeline
Spinnaker 的两个核心集群管理和部署管理,对于集群管理这块,它对国外经常使用的云平台集成的比较好,如 Google、AWS EC二、Microsoft Azure 等,由于手头没有相应的资源,这里暂时无法尝试,还要它支持 Kubernates,后期我将继续研究它如何跟 Kubernetes 结合完成集群管理,恰好最近在研究 Kubernetes,手头有搭建好的 k8s 集群。针对部署管理这块,Spinnaker 核心为三大块 Pipeline、Stage、Deployment Strategies,下边来详细演示一下 Spinnaker 提供的强大的 Pipeline 功能。
Spinnaker 平台,是按照 Project 项目分类,每一个项目包含多个 Application 应用,每一个应用里面包含多个 Pipelines ,每一个 Pipeline 包含多个 Stage 阶段,在每一个阶段中能够定义不一样的 Deployment Strategies 部署策略。总体是按照这种方式来定义的,这样既能够很好的先按照项目分类,而后能够根据项目中应用再次细分,最后落实到每一个应用的流程上,不一样的流程配置不一样的部署阶段和部署策略,从而使用户有一个很清晰的脉络来梳理并配置本身不一样业务的部署流程线。
4.1 建立 Project、Application
首先建立一个项目 project_test
,而后建立一个应用 app_test
,并将应用 app_test
跟 project_test
项目关联起来。
点击导航栏 “Projects” -> “Actions” -> “Create Project”,输入名称 project_test
,Application 下拉选择项先不选,由于咱们还没建立 Application,等建立完毕以后,在选择配置。
点击导航栏 “Applications” -> “Action” -> “Create Application”,输入名称 app_test
,选择代码仓库类型,默认有三种:stash、github、bitbucket。这里我选择 stash,配置本身搭建的 GitLab 代码仓库便可,若是项目托管在 github 或 bitbucket 上,可对应选择。下边实例端口处填写端口号,根据提示信息,是要填写该应用实例端口号,最终能够经过 IP + Port 方式访问该实例,相似 Kubernetes 中的 Pod。
最后,将 project_test
跟 app_test
关联起来,点击导航栏 “Projects” -> “project_test” -> “Project Configuration” -> “Applications”,下拉列表中选择 app_test
,点击 “Save” 保存便可。
4.2 建立 Pipeline
接下来建立 Pipeline,进入 app_test
详情页面,点击 “PIPELINES”,目前是没有任何信息的,点击 “+ Create”,弹框中选择类型为 Pipeline,输入流程名称,这里我命名为 first_pipeline
。由于第一次建立,下边 “Copy From” 选择没出来,后续在建立时,咱们也能够经过 “Copy From” 方式选择已存在的 Pipeline,很是方便就复制了一个同样配置的流程了。建立完毕后,就会出现详细配置 Pipeline State 的页面了。
4.3 配置 Configuration 项
刚开始这里只有一个 Configuration 选项,能够配置 Automated Triggers、Parameters、Notifications 等,这里说下 Automated Triggers 和 Parameters 这两个很是有用,咱们能够将此视为 Pipeline 启动前的一些初始化配置,好比启动须要的参数配置、自动触发配置等,为后续各阶段提供必要的信息。
Automated Triggers 自动触发,它提供 7 种类型的触发方式:
基本能知足咱们平常持续集成或交付的需求,固然每个类型都须要配置相应的参数,好比 Cron 类型,须要配置执行频率、启动时间等。
这里就不一一截图列举,能够亲自试验一下吧,每种类型的配置参数不同,一些参数若是须要下拉选择的时候没有可选项,说明在启动 Spinnaker 的时候,配置文件中没有配置,也或者是配置的信息不完整或不正确致使。例如 Jenkins 类型,选择 Master 的时候,若是没有在 $HOME/.spinnaker/spinnaker-local.yml
文件中配置 Jenkins 信息的话,那么这里就确定不会出现可选信息了。Docker Registry 中 Registry Name 选项也是同理。同时这些触发方式,能够组合使用的,添加多个 Automated Triggers 组合使用,效果杠杠的。
Parameters 参数,能够配置 Pipeline 参数,在流程启动是,会要求输入或选择对应的参数,而且在后续 Stage 中能够直接获取使用,这是很是有必要的,咱们使用 jenkins Job 时,有构建参数选项配置,这里若是咱们要触发对应的 Jenkins Job,那么能够把对应的必要参数设置在这里,后续 Stage 触发 Jenkins Job 时,构建参数赋值就能够直接经过表达式来获取了。
好比这里我设置 ci_version
和 branch
两个必填参数,而且 branch
带默认值,且可设置为可选参数。
4.3 配置各个 Stage 项
接下来,给 Pipeline 添加 Stage 了,实际应用中就须要咱们结合本身的业务逻辑,合理添加 Stage,来达到指望的持续集成交付功能啦。这里我作一个简单的的功能演示,先来一个 Manual Judgment 类型 Stage,作人工判断选择,根据启动者选择的类型,在分别执行对应的 Check Preconditions 类型 Stage,作先决条件检查,这里得用到表达式判断(下边会说到表达式),最后为每条路径配置不一样的类型的 Stage,这里一条使用 Wait 类型,等待固定秒后自动到下一个Stage 或结束,另外一条选择 Webhook 类型,调用一个 API 接口,正常返回后结束流程。下边一步步介绍每一个 Stage 配置,最终完成整个 Pipeline。
4.3.1 配置 Manual Judgment Stage
首先建立一个 Manual Judgment 类型的 Stage,来作人工判断选择,顾名思义就是执行 Pipeline 到该 Stage 的时候,会等待用户选择配置选项,Stage 才能够继续执行下去。鼠标点击 Configuration 选项,使其图标变绿(意味着对该选中项增长下一步 Stage,后续其余 Stage 增长 Stage 操做同样)。点击 “+ Add Stage”,下方区域 Type 选择 Manual Judgment,Name 名称我填写 “Manual Judgment Stage” 直观明了,Instructions 处填写该 Stage 的说明信息,实际应用中,一些必要的说明信息是颇有必要的,其余人操做该流程时好作参考提示,这里还支持 HTML 代码,因此我再次输入提示信息以下:
<div>请选择条件: <br> <ul> <li>develop environment: 开发环境,将执行 Wait Sate</li> <li>release environment:生产环境,将执行 Webhook Stage </li> </ul> </div>
这样就算其余人执行这个示例流程,到这一步也知道该如何选择了吧!接下来 Judgment Inputs 判断项,这里我添加两判断项 develop environment 和 release environment,启动 Pipeline 执行到该 Stage 时,会等待咱们选择判断项时,就会显示这两项。后续 Stage 也能够经过表达式获取到选择的值,来串联对应其余 Stage 很实用。填写完毕,点击 “Save Changes” 保存便可,以下图所示。
4.3.2 配置 Check Preconditions Stage
上边 Manual Judgment Stage 配置了两个 Judgment Inputs 判断项,接下来咱们建两个 Check Preconditions Stage 来分别对这两种判断项作条件检测,条件检测成功,则执行对应的后续 Stage 流程。点击 “Manual Judgment Stage” 使其变绿,点击 “+ Add Stage”,Type 选择 Check Preconditions,Name 名称我填写 “Check Preconditions develop” 说明是针对条件为 develop environment 类型的验证,Preconditions 条件配置处点击 “+ Add Precondition”,弹框 Edit Preconditions 以下图。
Check 处选择 Expression 表达式方式,而后在 Expression 文本域填写表达式 ${ #judgment('Manual Judgment Stage') == 'develop environment' }
,说明一下,这个表达式意思就是从名称为 “Manual Judgment Stage” 的 Judgment Stage 获取选择的值是否为 “develop environment”,若是条件匹配,则返回 true,继续执行当前 Stage 后续 Stage 流程,不然返回 False,执行前 Stage 的后续其余 Stage,若是未配置其余 Stage,则流程结束。Fail Pipeline 选项,若是勾选,则匹配不成功后,则直接结束流程。根据实际须要配置,这里我不勾选,由于该 Stage 判断不匹配的时候,咱们还须要执行另外一个判断 Stage 呢,可不能结束流程了。配置完毕,以下图。
接下来配置另外一个 Check Preconditions Stage,这里就不用在一步步建立了,能够直接复制 “Check Preconditions develop” ,而后修改下名称和表达式便可,是否是很方便。点击 “Manual Judgment Stage” 使其变绿,点击 “+ Copy existing stage”,弹框选择 “Check Preconditions develop”,点击 “Copy Stage” 便可完成建立,弹框以下图。
而后修改下 Name 为 “Check Preconditions release”,表达式处修改成 ${ #judgment('Manual Judgment Stage') == 'release environment' }
,保存便可。配置完毕,以下图。
4.3.3 配置 Wait Stage
配置好了 Check Preconditions Stage,接下来咱们为 “Check Preconditions develop” stage 配置后续 Stage,使其在验证成功后,能够继续执行下去。点击 “Check Preconditions develop” 使其变绿,点击 “+ Add Stage”,Type 选择 Wait,Name 名称我填写 “Wait Stage”,这个 Stage 什么都不干,等待固定时间后结束流程使用。Wait Time 设置等待秒数,这里我设置为30s。配置完毕,以下图。
4.3.4 配置 Webhook Stage
接下来为另外一个 “Check Preconditions release” Stage 配置后续 Stage,使其在验证成功后,能够继续下去。点击 “Check Preconditions release” 使其变绿,点击 “+ Add Stage”,Type 选择 Webhook,Webhook URL 为须要触发的 URL 地址,实际应用中用处很大,能够触发其余接口或者其余流程等等,并且能够配置解析返回值,进行状态判断,是否触发成功仍是失败,来 Fail Pipeline 或其余操做,这里我简单一点,触发 http://www.baidu.com
,Method 选择 Http 请求方式,支持 GET、HEAD、POST、PUT、DELETE 方式,选择了每一种方式以后,会出现对应该请求方式的其余参数配置,这里我选择 GET 方式,不须要配置其余参数。Wait for complation 等待完成配置,这下边有详细的解析返回值或返回状态的配置,也能够支持异步接口方式,好比提供一个获取状态 Staus 的 URL,而后配置对应信息,那么流程执行到此时,会请求异步接口并解析,直到返回状态匹配成功,才结束流程等,这里示例简单些,不配置了。配置完成后,以下图。
4.3.5 启动 Pipeline
好了,通过上边一系列的配置,一个简单的拥有 5 个 Stage 的 Pipeline 就完成了,接下来咱们启动一下 first_pipeline
试试效果吧!回到 app_test
应用的 PIPELINES 页面,咱们会看到咱们全部配置的 Pipeline 列表,找到对应 first_pipeline
的 Pipeline,点击后边 “Start Manual Execution” 按钮,会弹出启动确认框,若是流程 Configuration 项配置了参数或者 Trigger,这里会一并弹出,在填入对应的值后,就能够启动流程了。例如该流程,咱们配置了 Parameters 参数 ci_version
和 branch
参数,因此启动弹框以下图。
输入 ci_version
参数,以及选择 branch
参数后,点击 “RUN” 便可启动流程啦!启动后,咱们会发现按照以前的设计,流程会卡在第一个 Stage,等待咱们人工作判断,这里咱们先选择 “develop environment” 选项,继续到下一个 Stage 吧。
说明一下,这里能够鼠标悬停在第一个 Stage 上,就会显示配置的 Judgment Input 选项,以及 Instructions 说明,也能够点击 “Details” 下方显示详细信息,在此选择亦能够。
选择完毕后,流程会自动执行到下一个 Stage,流程会分别走到 “Check Preconditions develop” 和 “Check Preconditions release” Stage,而后作条件判断,还记得以前咱们配置的 Expression 吧,这里就起到做用了,咱们选择的是 “develop environment”, 那么验证 “Check Preconditions develop” 就会经过,直接继续到对应的下一个 Stage。验证 “Check Preconditions release” 失败,那么该节点状态就是 STOPPED 状态,不执行后续 Stage。
此时咱们能够看到流程已经到了 Wait Stage 了,这一步什么都不干,等待 30s 流程结束。在等待过程当中,也能够人为跳过等待时间,鼠标悬停该 Stage 上,会弹出跳过按钮。等待完毕后,该流程就成功结束啦!
OK,到目前为止,Pipeline 的一条路线能够成功执行了,接下来验证一下,选择 “release environment” 选项后,流程的另外一条路线执行状况吧!过程我就不在一一描述了,直接看结果吧!
OK,一样能够正常运行。Spinnaker Pipeline 还有不少使用高级的用法,好比它能够触发 Script 脚本、执行 Job、触发其余 Pipeline 运行、部署项目到配置的云平台等等,基本可以知足咱们平常业务需求哒!并且它还在持续更新中,相信之后能更方便更高效的接入更多平台。
五、演示 Spinnaker 集成 Jenkins
对于持续集成流程,咱们使用的比较多的开源工具 Jenkins,Spinnaker 设计中就可以很好的支持第三方工具,经过 Igor 组件就能很好的支持 Jenkins 等工具。下边咱们就演示一下 Spinnaker 如何集成 Jenkins 工具。
5.1 搭建并配置 Jenkins
由于 Spinnaker 自己启动时并无直接启动一个 Jenkins 服务,因此须要咱们本身启动一个 Jenkins 服务或 Jenkins 集群服务,而后将 Jenkins 信息配置到 Spinnaker 配置文件中,使其能够关联到对应 Jenkins,而后就能够在 Spinnaker 中尽情使用 Jenkins 服务啦!
Jenkins 服务搭建及配置,这里我就不在详细说了,具体能够参考以前文章 初试Jenkins2.0 Pipeline持续集成 前半部分 Jenkins 安装这块,讲的很详细。这里我用 Docker 方式在本地快速搭建一个 Jenkins 服务。
docker run -d -p 9090:8080 -p 50000:50000 -v /Users/wanyang3/jenkins_home:/var/jenkins_home jenkins
此时 Jenkins 服务就运行在本地 http://127.0.0.1:9090
上了,咱们配置管理员帐户 admin,密码 admin 为了后边配置 Spinnaker 使用。接下来咱们建立一个普通的测试 Job,名称为 maven_test
,参数化构建过程处咱们配置一个 ci_version
参数,目的很明显,就是为了接收上边 Pipeline 启动参数中的 ci_version
值,让他们可以串联起来。
而后,在源码管理处,配置咱们的代码仓库地址及分支 (这里分支也能够配置成参数,从 Spinnaker 启动参数中获取哈,这里就不演示了)。最后,咱们在配置一下构建,执行一个 shell,简单打印一下获取的参数,最后在执行一个 mvn clean
命令。
配置完成后,接下来就须要配置 Spinnaker config 文件,开启对 Jenkins 的支持以及配置 Jenkins 信息。
5.2 配置 Spinnaker config 集成 Jenkins
上边提到,Spinnaker 的配置文件为 $HOME/.spinnaker/spinnaker-local.yml
,那么咱们须要作一些修改。
$ vim $HOME/.spinnaker/spinnaker-local.yml ... igor: enabled: true # 这里默认为 false,修改成 true host: ${services.default.host} port: 8088 baseUrl: ${services.default.protocol}://${services.igor.host}:${services.igor.port} ... jenkins: enabled: ${services.igor.enabled:false} defaultMaster: name: Jenkins baseUrl: http://localhost:9090 # 配置上边启动的 Jenkins 服务地址 username: admin # 管理员用户名 password: admin # 管理员密码或管理员对应的 API Token ...
配置完成后,在 Run 一下 Spinnaker 服务,默认 Spinnaker 会检测各组件若是已经启动的话,将再也不重启。固然也能够先 Stop,而后在 Run 全部组件服务也能够。
$ cd /Users/wanyang3/spinnaker/build $ ../spinnaker/dev/stop_dev.sh [service] $ ../spinnaker/dev/run_dev.sh [service]
注意:重启服务后,若某些组件未启动,须要像上边同样,手动启动组件。上边咱们设置了 Igor 为 true,那么会自动启动起来,必定要保证 igor 能正常启动,不然无法集成 Jenkins。
5.3 配置 Jenkins Stage
咱们继续使用 first_pipeline
这个示例 Pipeline,简单的在 Wait Stage 后边追加一个 Jenkins Stage,让其执行上边配置的 Jenkins 名称为 maven_test
的 Job,而且将 参数 ci_version
传递过去。
点击 “Wait Stage” 使其变绿,点击 “+ Add Stage”,Type 选择 Jenkins,Master 处选择刚配置文件中定义的 name: Jenkins
Jenkins,这里也能够配置多个 Master,具体能够参考文档。Job 处选择 maven_test
,默认会拉取该 Jenkins 下全部 Job。 Job Parameters 这里就须要传递 ci_version
参数了,实际应用中,咱们是要动态获取启动参数中的参数配置,因此这里能够经过表达式 ${ parameters['ci_version']}
来获取参数。Wait for results 默认勾选,等待 Jenkins 的执行结果,Jenkins 执行完毕,才结束流程。配置完成后,以下图。
OK,配置完成。最后咱们在来启动一下 first_pipeline
,输入 ci_version
参数,选择 branch
参数启动,选择 “develop environment” 继续,执行完 “Check Preconditions develop” Stage,继续到 “Wait Stage” 等待 30s 后,执行 “Jenkins Stage”,可是执行失败了。。。 这是为啥? 看返回的报错信息是 403 No valid crumb was included in the request
,缘由是 Jenkins 默认开启防止跨站点请求伪造致使的,解决方案就是去 Jenkins —> 系统管理 —> 防止跨站点请求伪造处,去掉勾选便可。再次运行,就能够成功运行啦!
点击详情中 “Build #47” 连接,查看这次 Build Log,能够看到正常启动并传递参数。
...
[maven_test] $ /bin/sh -xe /tmp/hudson9078124639399895924.sh + echo ci_version: 1.0.1 ci_version: 1.0.1 + sleep 15s + echo hello this is maven-test job trgger by spinnaker hello this is maven-test job trgger by spinnaker [maven_test] $ /var/jenkins_home/tools/.repository/bin/mvn clean [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building qd_api 0.0.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ qd_api --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.809 s [INFO] Finished at: 2017-12-04T09:00:22+00:00 [INFO] Final Memory: 5M/59M [INFO] --------------