spinnaker自动发布k8s部署应用<一>

一、准备环境

 

！docker-ce---17.06.2-ce

！k8s集群----1.11.1

！helm部署工具---helm-v2.10.0

！spinnaker-charts---spinnaker-0.5.0

环境准备参考我的其他两篇博文：

https://www.cnblogs.com/cuishuai/p/9485939.html

https://www.cnblogs.com/cuishuai/p/9525656.html

 

二、示例说明

由于本次只是验证spinnaker工作流程，所以采用GitHub、dockerhub两者结合做代码和镜像管理。主要使用的是dockerhub的自动构建功能，当然生产环境这一步我们直接放到私有仓库上去做，代码的话直接放到gitlab上面管理。

结合spinnaker强大的pipeline和rosco（构建 beta 镜像的组件，需要配置 Packer 组件使用）实现这个同样功能的发布流程，这个后续会在更博中写道。大致的发布流程：

 

如果生产应用的时候就将图中的github换成gitlab，dockerhub建议使用企业级的私有仓库harbor。这个具体会在后面进行讲解，本次只是spinnaker的一个发布流程和spinnaker的工作流程的理解。

 

三、部署

1、Github准备

首先需要创建一个github、dockerhub账号，这里就不详细介绍创建过程了。需要利用dockerhub的create automated build与github结合实现代码更新自动提交构建，本次构建过程参考的是https://www.spinnaker.io/guides/tutorials/codelabs/kubernetes-source-to-prod/ ，代码放在我的github上面https://github.com/cuishuaigit/spin-kub-demo.git。fork一份代码到自己的GitHub上面。然后进行一些简单的配置：

进入刚刚fork的spin-kub-demo项目，点击右上方的"Settings"---点击左侧栏上的"Integrations & services"---点击"Add service"在下拉菜单中选择"Docker"---选择Add service就完事了。结果如下图：

 

2、dockerhub准备

上面准备好github，接下来准备dockerhub。使用dockerhub自动构建镜像的过程之前已经写过一篇博文了：https://www.cnblogs.com/cuishuai/p/8483496.html，这里为了完整性，我在详细介绍一下dockerhub的"Create Automated

Build"的使用流程，首先登陆dockerhub，然后在"Create"的下拉菜单中选择"Creta Automated Build"---使用Github那个选项：

 

接下来选择github上刚刚fork创建的那个spin-kub-demo项目，选择后进入下面的配置页面:

 

master下面的那个branch表示排除master的任意分支, Docker Tag的位置留空表示与branch的name相同。branch name以服务版本号命名。当然为了演示方便直接使用master、latest。上面操作完成，点击Create，然后进入另外的配置页面，选择"Build Settings"----"Trigger"---"Ssave Changes".这样整个任务的准备工作就结束了。

 

3、spinnaker创建构建流程

　　3.1、前面部署的博文中介绍了详细的搭建及访问，这就不在详细介绍了。出于安全考虑，没有将ui暴漏在外网。我们使用的openvpn进行访问的，openvpn的搭建参考我的其他博文：https://www.cnblogs.com/cuishuai/p/7992477.html

输入访问地址进入ui，点击"Applications":

 

当然你的那个可能显示的和我这里不一样，那也没有关系。大致相同就好了，因为我这里还部署了其他的东西比如istio、nfs、prometheus等。

接下来开始创建一个Application。点击右侧的"Actions"在下拉菜单上选择"Create Application"进入New Application页面填写相关信息，Name处自己定义，我用的"skrdemo"，由于我已经创建过了skrdemo不能重复创建，所以图中使用skrDemo代替skrdemo。Owner  Email处填写自己的邮箱就好了，Repo Type处选择github，Repo Project处填写GitHub上刚刚fork的spin-kub-demo，Repo Name处填写自己的github，我这里是"cuishuaigit"，Instance Port处写80.：

 

后点击Create完成创建。

　　3.2、创建负载均衡策略（Load Balancer）

   skrdemo创建完毕，创建一个 Dev Load Balancer 负载均衡策略，进行 Dev 环境的部署。进入该应用详情页面，点击顶部导航栏 “LOAD BALANCERS”，进入负载均衡列表页面，默认是没有任何记录的。点击页面 “Create Load Balancer” 按钮，在创建负载均衡弹框页面填写信息，点击 “Create” 完成负载均衡策略的创建。这里 “Stack” 处填 dev，可以理解为作为测试环境使用标示，在 “Ports” 栏下边 “Target Port” 处填 8000，作为对外转发目标端口。“Advanced Settings” 栏下边 “Type” 处选择 ClusterIP，这里可选项有 ClusterIP、LoadBalancer、NodeType，针对不同的应用类型和平台，选择所支持的类型，这里我选择默认值 ClusterIP。

Dev Load Balancer 创建完毕后，接下来我们创建一下 Prod Load Balancer 用来进行 Prod 环境的部署。创建过程同上操作，主要修改 “Stack” 为 prod，并且在 “Advanced Settings” 栏下边 “Type” 处选择 NodeType，其他保持一致。 

 

 

　　3.3创建服务组（Server Group）

   skrdemo应用的 Load Balancers 创建完毕，接下来我们创建一个 Dev Service Group 服务组，点击导航栏 “CLUSTERS”，进入集群列表页面，默认也是没有任何记录的。点击 “Create Service Group” 按钮，在创建服务组弹框页面填写信息，点击 “Create” 完成服务组的创建。这里 “Stack” 处依填 dev，“Containers” 处填写容器 Docker 镜像地址，这里我们直接使用上边配置的个人 DockerHub 仓库镜像，Spinnaker 会自动拉取所有版本镜像列表供选择，这里我选择 index.docker.io/fastop/spin-kub-demo:latest 作为测试镜像。“Load Balancers” 处选择上边创建的 skrdemo-dev 负载均衡策略。“Replicas” 栏下方 “Capacity” 处填 1，意味着该服务组将启动 1 个由该容器镜像启动的 Pod 实例。“Port” 栏 “Container Port” 处填写为 8000，保持跟 Load Balancers Target 端口一致，“Container” 栏下方 “name” 修改为 skrdemo。点击 “Probes” 栏，点击 “Enable Readiness Probe” 按钮来添加探测，修改 “Port” 为 8000，这里 “Readiness Probe” 为服务是否准备就绪的探测。 

 

 

注意：这里如果在 Containers 栏下拉选择 image 时没有自己项目的镜像列表，只有 library 的话，需要修改 values.yaml 配置自己的 DockerHub 仓库，当然也可以使用其他私有仓库配置。

 

服务组创建完成就会自动拉去镜像，并创建服务，访问方式和deck的访问方式相同，找到相应服务的pod名称，端口为8000，使用kubectl  port-forward  pod名称  8888:8000,在配置nginx服务：

server{
listen 82;
server_name 0.0.0.0;
location / {
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;

}

}

就可以通过内网代理访问服务，：

这个页面是github上项目的content目录下面的index.html展示的内容：

 

四、spinnaker自动部署（pipeline）

1、创建dev环境的自动deploy

点击 skrdmo 应用页的导航栏 “PIPELINES”，点击页面右上角 “Create” 按钮，弹框中 “Type” 选择 Pipeline，“Pipeline Name” 处填写 Deploy to Dev，点击 “Create” 按钮完成创建。

 

进入到 Deploy to Dev 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Docker Registry，“Registry Name” 栏会加载 values.yaml 文件中仓库配置的账户名称，这里我选择 dockerhub，“Organization” 栏会加载选择的 Registry 下配置的所属组织列表，这里我选择自己的账户 fastop，“Image” 栏选择要触发的镜像，这里我选择 fastop/spin-kube-demo 镜像，“Tag” 栏这里不填，意思就是匹配任何新的 Tag。以上配置的作用就是，当我们的 DockerHub 仓库中fastop/spin-kube-demo 有新的镜像生成时，会自动触发该流程启动。

 

接下来点击 “Add Stage” 按钮，增加一个节点，该节点执行部署镜像到 Dev 环境。“Type” 栏选择 Deploy，“Stage Name” 栏填写 Deploy to Dev，如下图所示。

 

“Deploy Configuration” 栏下点击 “Add Server Group” 在弹框中 “Copy configuration from” 可以选择之前我们创建的服务组 demo-dev，点击 “Use This Template” 按钮，进入到配置部署集群弹框页面。

 

配置部署集群弹框页面跟之前创建的服务组 skrdemo-dev 一样，不过有一个地方需要修改一下，在 “Container” 栏下边 “Image” 选择 Image from Trigger(s) 这一项，意思是跟 “Automated Triggers” 那里镜像保持一致，页面其他配置保持不变，最后点击"Add",完成添加

 

 最后，添加一个节点，目的是为了销毁之前的 demo-dev 服务组（上边已经启动的 demo-dev 服务组）。点击 “Add Stage” 按钮，“Type” 栏选择 Destory Server Group，“Destroy Server Group Configuration” 栏下 “Namespaces” 选择 default，“Cluster” 选择 demo-dev，“Target” 选择 Previous Server Group。选择 default Namespaces，因为之前的 demo-dev 服务组就是使用的 default 命名空间，如果我们不太清楚选择哪个，可以点击下方 “Toggle for list of existing clusters” 链接，就会过滤掉其他 Namespaces。Target 处一定要选择 Previous Server Group，意思是销毁掉之前的服务组，这里别选错了，最后点击"Save Changes"保存pipeline。

此时可以试验一下配置是否生效，直接修改github上的代码，做一个提交指定docker  tag，这样就会自动触发pipeline构建：

如图所示，红框标记出的结果，表示可以自动触发更新。

 

2、创建验证流程

接下来，我们创建一个新的流程，为了验证 deploy to dev 流程是否部署成功。点击 “Create” 按钮，弹框中 “Pipeline Name” 栏填 Verity deploy dev，进入到 Verity deploy dev 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Pipeline，“Pipeline” 栏选择 deploy to dev 流程，“Pipeline Status” 栏勾选 successful，意思是当 deploy to dev 流程成功执行后，将自动触发该流程。

 

 然后添加一个stage，目的是让流程暂停，等待人工验证本次部署实例是否成功。点击 “Add Stage” 按钮，“Type” 栏选择 Manual Judgment，“Instructions” 栏输入 <b>Manual Judgment Verity if “skrdemo-dev” server run ok</b> 对该流程做一下简要的说明信息（支持 Html ），"Judgement Inputs"可以自己定义一个操作来继续后面的stage或者停止本次有问题的构建，我这里定义了输入"ok"继续后面的操作。

这里只是模拟了简单的人工决策，具体需要结合测试反馈、和一些服务状态来判断是否进行下一步构建。

3、创建prod的自动deploy

创建一个新的流程，目的是当 Verity Deploy-Dev 流程人工验证通过后，执行自动化部署到 Prod 环境中去。点击 “Create” 按钮，弹框中 “Pipeline Name” 栏填 deploy to prod，进入到 deploy to prod 流程设置页面，在 “Automated Triggers” 栏下点击 “Add Trigger”，“Type” 栏选择 Pipeline，“Pipeline” 栏选择 Verity deploy dev 流程，“Pipeline Status” 栏勾选 successful，意思是当 Verity deploy dev 流程成功执行后，将自动触发该流程。

 

 

 

然后添加一个stage，目的是从集群中找到最新的镜像，既然是自动化部署，dev 环境 Image 已经测试完毕，那么就不需要再指定部署哪一个镜像了，直接从集群中查找最新的哪个镜像就是本次要部署的镜像了。点击 “Add Stage” 按钮，“Type” 栏选择 Find Image from Cluster，“Find Image from Cluster Configuration” 栏下 “Namespace” 选择 default，“Cluster” 栏选择镜像所在集群 skrdemo-dev，“Server Group Selection” 栏选择 Newest，表示最新的服务组。“Image Name Pattern” 栏填 .*，这里说明一下，此处用来过滤镜像名称匹配，当单个 Pod 中部署多个不同镜像时使用，这里我们只有一个镜像，所以可以使用 .* 匹配所有，点击"Add"保存。

接着添加一个stage用于将查找到的镜像部署到 Prod 环境中去。点击 “Add Stage” 按钮，“Type” 栏选择 Deploy，“Stage Name” 栏输入 deploy to prod，“Deploy Configuration” 栏下点击 “Add Server Group” 按钮，弹出选择服务组对话框,点击"Add"保存。

 

 

 

配置部署集群弹框页面跟之前创建的服务组 skrdemo-dev 一样，不过这次要修改三个地方，第一个地方 “Stack” 栏修改为 prod；第二个地方 “Load Balancers” 栏删除原 demo-dev 并选择 skrdemo-prod；第三个地方 “Container” 栏下边 “Image” 选择 Find Image Result(s) skrdemo-dev.* 这一项，意思是跟上一节点中查找 Image 结果保持一致，页面其他配置保持不变，点击"Add"保存

 

 

最后我们添加一个stage，目的是当新的部署完成后，Prod 环境中老版本的该实例将废弃掉不再接入流量。点击 “Add Stage” 按钮，“Type” 栏选择 Disable Cluster，“Disable Cluster Configuration” 栏下 “Namespaces” 处继续选择 default，“Cluster” 处填写 skrdemo-prod，注意：这里没法使用点击 “Toggle for list of existing clusters” 链接方式过滤 namespace，因为暂时只有 skrdemo-dev 集群运行中，skrdemo-prod 服务组还未创建，没法选择，这里只能手动填写，填写完成记得点击"Save Changes"保存。

 

4、运行验证流程

通过上面的操作我们创建了delay to dev-->Verity deploy dev-->deploy to prod整个流程，代码提交后自动构建。

由于前面验证自动发布触发构建dev的时候使用了，test为tag，现在在github上新建一个branch，名为sndz：

 

触发构建后，中间有个人工决策，选中"ok"点击"Continue"继续后面的构建。

 

 

完全发布完成后显示如下图：

 

 

五、访问测试

dev和prod环境结果都是如下图：

看一下github上的代码：

证明部署成功！

转载于:https://www.cnblogs.com/cuishuai/p/9551712.html