Spinnaker介绍
Spinnaker通过将公布和各个云平台解耦，来将部署流程流水线化，从而减少平台迁移或多云平台部署应用的复杂度。它本身内部支持Google、AWS EC2、Microsoft Azure、Kubernetes和OpenStack等云平台，并且它能够无缝集成其它持续集成（CI）流程。如Git、Jenkins、Travis CI、Docker registry、cron调度器等。
应用管理
Spinnaker主要用于展示与管理你的云端资源。
先要了解一些关键的概念：Applications。Cluster，and Server Groups，通过Load balancers and firewalls将服务展示给用户。官方给的结构例如以下：
Application
定义了集群中一组的Cluster的集合。也包含了Firewalls与Load Balancers，存储了服务全部的部署相关的的信息。
Server Group
定义了一些基础的源比方（VM image、Docker image），以及一些基础的配置信息，一旦部署后。在容器中相应Kubernetes Pod的集合。
Cluster
Server Groups的有关联的集合。（Cluster中能够依照dev，prod的去创建不同的服务组），也能够理解为对于一个应用存在多个分支的情况。
Load Balancer
它在实例之间做负载均衡流量。您还能够为负载均衡器启用健康检查，灵活地定义健康标准并指定健康检查端点。有点相似于Kubernetes中Ingress。
Firewall
防火墙定义了网络流量訪问，定义了一些訪问的规则。如安全组等等。
页面预览
页面展演示样例如以下。还是比較精简的。能够在它的操作页面上看到项目以及应用的具体信息，还能够进行集群的伸缩、回滚、改动以及删除的操作。
部署管理
上图中。Infrastructure左側为Pipeline的设计：主要讲两块内容：Pipeline的创建以及基础功能，与部署的策略。
Pipeline
较强的Pipeline的能力：它的Pipeline能够复杂到无以复加，它还有非常强的表达式功能（兴许的操作中前面的參数均通过表达式获取）。
触发的方式：定时任务、人工触发、Jenkins job、Docker images。或者其它的Pipeline的步骤。
通知方式：Email、SMS or HipChat。
将全部的操作都融合到Pipeline中，比方回滚、金丝雀分析、关联CI等等。
部署策略
因为我们用的是Kubernetes Provider V2（Manifest Based）方式：可改动yaml中：spec.strategy.type。
Recreate，先将全部旧的Pod停止，然后再启动新的Pod相应当中的第一种方式。
RollingUpdate，即滚动升级。相应下图中另外一种方式。
Canary以下会单独的介绍当中的使用。
非常多人都是感觉这个非常难安装，事实上基本的原因还是墙的问题，仅仅要把这个攻克了就会方便非常多，官方的文档写的非常具体，并且Spinnaker的社区也非常的活跃，有问题均能够在上面进行提问。
安装提供的方式
Halyard安装方式（官方推荐安装方式）
Helm搭建Spinnaker平台
Development版本号安装
Helm方式若是须要自己定义一些个性化的内容会比較复杂，全然依赖于原始镜像，而Development须要对Spinnaker非常的熟悉，以及每一个版本号之间的相应关系均要了解。
Halyard方式安装注意点
Halyard代理的配置
部署机器选择vim /opt/halyard/bin/halyard
DEFAULT_JVM_OPTS='-Dhttp.proxyHost=192.168.102.10 -Dhttps.proxyPort=3128'
因为Spinnaker涉及的应用较多，以下会单独的介绍。须要消耗比較大的内存，官方推荐的配置例如以下：
18 GB of RAM
A 4 core CPU
Ubuntu 14.04, 16.04 or 18.04
Spinnaker安装步骤
Halyard下载以及安装。
选择云提供者：我选择的是Kubernetes Provider V2（Manifest Based），须要在部署Spinnaker的机器上完毕Kubernetes集群的认证，以及权限管理。
部署的时候选择安装环境：我选择的是Debian包的方式。
选择存储：官方推荐使用Minio。我选择的是Minio的方式。
选择安装的版本号：我当时最新的是V1.8.0。
接下来进行部署工作，初次部署时间较长，会连接代理下载相应的包。
全部下载与完毕后，查看相应的日志，就可以使用localhost:9000訪问就可以。
完毕以上的步骤则能够在Kubernetes上面部署相应的应用了。
涉及的组件
下图是Spinnaker的各个组件之间的关系。
Deck：面向用户UI界面组件，提供直观简单介绍的操作界面。可视化操作公布部署流程。
API：面向调用API组件，我们能够不使用提供的UI，直接调用API操作，由它后台帮我们执行公布等任务。
Gate：是API的网关组件，能够理解为代理。全部请求由其代理转发。
Rosco：是构建beta镜像的组件，须要配置Packer组件使用。
Orca：是核心流程引擎组件，用来管理流程。
Igor：是用来集成其它CI系统组件。如Jenkins等一个组件。
Echo：是通知系统组件。发送邮件等信息。
Front50：是存储管理组件。须要配置Redis、Cassandra等组件使用。
Cloud driver：是用来适配不同的云平台的组件。比方Kubernetes、Google、AWS EC2、Microsoft Azure等。
Fiat：是鉴权的组件。配置权限管理，支持OAuth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups等。
| 组件 | 端口 | 依赖组件 | 端口 |
| Clouddriver | 7002 | Minio | |
| Fiat | 7003 | Jenkins | |
| Front50 | 8080 | Ldap | |
| Orca | 8083 | GitHub | |
| Gate | 8084 | ||
| Rosco | 8087 | ||
| Igor | 8088 | ||
| Echo | 8089 | ||
| Deck | 9000 | ||
| Kayenta | 8090 |
例如以下Pipeline设计就是开发将版本号合到某一个分支后，通过Jenkins镜像构建。公布測试环境。进而自己主动化以及人工验证，在由人工推断是否须要公布到线上以及回滚。若是选择公布到线上则公布到prod环境。从而进行prod自己主动化的CI。若是选择回滚则回滚到上个版本号，从而进行dev自己主动化的CI。
Stage-configuration
设置触发的方式，定义全局变量，执行报告的通知方式，是Pipeline的起点。
Automated Triggers。当中支持多种触发的方式：定时任务Corn，Git，Jenkins，Docker Registry。Travis，Pipeline，Webhook等触发方式，从而能够满足我们自己主动回调的功能。
Parameters，此处定义的全局变量会在整个Pipeline中使用${ parameters['branch']}得到。这样大大的简化了我们设计Pipeline的通用性。
Notifications。这里通知支持：SMS。Email，HipChat等等的方式。
我们使用了邮件通知的功能：须要在echo的配置文件里添加发件邮箱的基本信息。
Stage-jenkins
调用Jenkins来执行相关的任务。当中Jenkins的服务信息存在放hal的配置文件里（例如以下展示），Spinnaker可自己主动以同步Jenkins的Job以及參数等等的信息。执行后能够看到相应的Job ID以及状态：
执行完毕后展演示样例如以下。我们能够查看相关的build的信息，以及此stage执行的相关信息。点击build能够跳到相应的Jenkins的Job查看相关的任务信息。
Stage-deploy
因为我们配置Spinnaker的时候採用的是Kubernetes Provider V2方式。我们的公布均採用yaml的方式来实现，能够将文件存放在GitHub中或者直接在页面上进行配置。同一时候yaml中文件支持了非常多的參数化，这样大大的方便了我们日常的使用。
Halyard关联Kubernetes的配置信息：因为我们採用的云服务是Kubernetes，配置的时候须要将部署Spinnaker的机器对Kubernetes集群做认证。
Spinnaker公布信息展示：此处Manifest Source支持參数化形式，相似于我们写入的yaml部署文件。可是这里支持參数化的方式。
具体的配置项例如以下：
- apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: '${ parameters.deployName }-deployment'
namespace: dev
spec:
replicas: 2
template:
metadata:
labels:
name: '${ parameters.deployName }-deployment'
spec:
containers:
- image: >-
192.168.105.2:5000/${ parameters.imageSource }/${
parameters.deployName }:${ parameters.imageversion }
name: '${ parameters.deployName }-deployment'
ports:
- containerPort: 8080
imagePullSecrets:
- name: registrypullsecret
- apiVersion: v1
kind: Service
metadata:
name: '${ parameters.deployName }-service'
namespace: dev
spec:
ports:
- port: 8080
targetPort: 8080
selector:
name: '${ parameters.deployName }-deployment'
- apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: '${ parameters.deployName }-ingress'
namespace: dev
spec:
rules:
- host: '${ parameters.deployName }-dev.ingress.dev.yohocorp.com'
http:
paths:
- backend:
serviceName: '${ parameters.deployName }-service'
servicePort: 8080
path: /
Stage-Webhook
Webhook我们能够做一些简单的环境验证以及去调用其它的服务的功能，它自身也提供了一些结果的验证功能，支持多种请求的方式。
执行结果的演示样例：
Stage-Manual Judgment
Spinnaker配置信息。用于人工的逻辑推断，添加Pipeline的控制性（比方公布到线上须要測试人员认证以及领导审批），内容支持多种语法表达的方式。
执行结果的演示样例：
Stage-Check Preconditions
上边Manual Judgment Stage配置了两个Judgment Inputs推断项。接下来我们建两个Check Preconditions Stage来分别对这两种推断项做条件检測，条件检測成功，则执行相应的兴许Stage流程。
比方上面的操作。若是选择公布到prod。则执行公布到线上的分支，若是选择执行回滚的操作则进行回滚相关的分支。
Spinnaker配置信息：
执行结果的演示样例：如上图中我选择了rollback。
则prod分支推断为失败，会堵塞后面的stage执行。
Stage-Undo Rollout（Manifest）
若是我们公布发现出现故障。也能够设计回滚的stage。Spinnaker的回滚极其的方便，在我们的日常部署中。每一个版本号都会存在相应的部署记录，例如以下所看到的：
Spinnaker Pipeline配置信息：回滚的Pipeline描写叙述中我们须要选择相应的deployment的回滚信息，以及回滚的版本号数量。
执行结果的演示样例：
Stage-Canary Analysis
金丝雀部署方式：在我们公布新版本号时引入部分流量到Canary的服务中，Kayenta会读取Spinnaker中配置的Prometheus中收集的指标。比方内存，CPU，接口超时时间，失败率等等通过Kayenta中Netflix ACA Judge来进行分析与推断。将分析的结果存于S3中，终于会给出这段时间的终于结果。
Canary分析主要经过例如以下四个步骤：
验证数据
清理数据
比对指标
分数计算
设计的模型例如以下：
执行结果的设计与展示：
我们须要相应用开启Canary的配置。
创建出Baseline与Canary的deployment由同一个Service指向这两个deployment。
我们这里採用读取Prometheus的指标，须要在hal中添加Prometheus配置。
Metric能够直接匹配Prometheus的指标。
须要配置收集指标以及指标的权重：
在Pipeline中指定收集分析的频率以及须要指定的源，同一时候能够配置scoring从而覆盖模板中的配置。
每次分析的执行记录：
结果展演示样例如以下，因为我们设置的目标是75，所以pipeline的结果判定为失败。
我们是腾讯云的客户，採用腾讯云容器服务主要看重以下几个方面：
Kubernetes在自搭建的集群中。要实现Overlay网络，在腾讯云的环境里。它本身就是软件定义网络VPC，所以它在网络上的实现能够做到在容器环境里和原生的VM网络一样的快，没有不论什么的性能牺牲。
应用型负载均衡器和Kubernetes里的Ingress相关联，对于须要外部訪问的服务能够高速的创建。
腾讯云的云储存能够被Kubernetes管理，便于持久化的操作。
腾讯云的部署以及告警也对外提供了服务与接口，能够更好的查看与监控相关的Node与Pod的情况。
腾讯云日志服务非常好的与容器进行融合，能够方便的收集与检索日志。
下图是我们在线上以及灰度环境的公布示意图。
为了容灾我们使用了北京二区与北京三区两个集群。若是须要灰度验证时。则将线上北京三区的权重改动为0，这样通过灰度负载均衡器就可以到达新版本号应用。日常使用中二区与三区均同一时候提供挂服务。
Q：为什么没有和CI结合在一起？使用这个比較重的Spannaker有什么优势？A：能够和CI进行结合。比方Webhook的方式，或者採用Jenkins调度的方式。优势在于能够和非常多云平台进行结合。并且他的Pipeline比較的完美，參数化程度非常高。
Q：眼下IaaS仅仅支持OpenStack和国外的公有云厂商，国内的云服务商假设要支持的话，底层须要怎么做呢（管理云主机而不是容器）？自己实现的话easy吗？怎么入手？A：眼下我们主要使用Spinnaker用来管理容器这部分的内容，对于国内的云厂商Spinnaker支持都不是非常的好。像LB，安全策略这些都不可在Spinnaker上面控制。若是须要研究能够查看Cloud driver这个组件的功能。
Q：Spinnaker能不能在Pipeline里通过http API获取一个deployment yaml进行deploy，这个yaml可能是动态生成的？A：部署服务有两种方式：1. 在Spinnaker的UI中直接填入Manifest Source。事实上就是相应的deployment YAML。仅仅只是这里能够写入Pipeline的參数。2. 能够从GitHub中拉取相应的文件，来部署。
Q：Spannaker的安全性方面怎么控制？A：Spinnaker中Fiat是鉴权的组件。配置权限管理。Auth、SAML、LDAP、GitHub teams、Azure Groups、 Google Groups，我们就採用LDAP，登陆后会在上面显示相应的登陆人员。
Q： deploy和test以及rollback能够跟helm chart集成吗？A：我认为是能够，非常笨的方法终于都是能够借助于Jenkins来实现，可是Spinnaker的回滚与部署技术非常强大，在页面上点击就能够进行高速的版本号回滚与部署。
Q： Spannaker之前的截图看到也有对部分用户开发的功能。用Spannaker之后还须要Istio吗？A：这两个有不同的功能。【对部分用户开发的功能】这个是依靠创建不同的service以及Ingress来实现的，他的路由能力肯定没有Istio强悍，并且也不具备熔断等等的技术。我们线下这么创建主要为了方便开发者进行高速的部署与调试。