Rancher upgrade webhook之CI/CD
概述
结合大家CI/CD的应用场景,本篇Blog旨在介绍如何通过Rancher的webhook微服务来实现CI/CD的联动。
流程介绍
本次实践的主要流程如下:
-
CI/CD console从代码托管、配置中心、第三方依赖平台拉取应用相应的代码,配置、依赖、并构建应用镜像。
-
将构建好的应用镜像推送到镜像仓库。
-
通过Rancher Server暴露出来的API/UI/CLI创建并启动应用栈。
-
在Rancher Server上创建upgrade类型的webhook。
-
更新应用、重新构建应用镜像,同时推送到镜像仓库。
-
触发Dev环境的webhook,完成Dev环境的服务升级。
-
Dev环境验证升级是否成功,应用是否正常。
-
触发Beta环境的webhook,完成Beta环境的服务升级。
-
Beta环境验证升级是否成功,应用是否正常。
-
出发Prod环境的webhook,完成Prod环境的服务升级。
-
Prod环境验证升级是否成功,应用是否正常。
webhook介绍
Rancher webhook的服务流程大致如下:
-
router根据用户提交过来的method和url初始化对应的handler。
-
handler解析请求参数里面的key和projectid初始化对应的webhook driver。
-
driver调用升级接口,返回并相应触发webhook的请求。
环境准备
Platform
Mac,Windows,Linux,Docker Cloud,AWS,Azure均可部署。
本次准备的平台是Ubuntu发行版(14.04),为了兼容docker,选择linux发行版的时候内核需控制在3.10以上。
Docker
-
根据用户选择的平台安装docker引擎,安装指导可参考官方文档,搭配Rancher使用,docker引擎版本最优选择1.12.6或者1.13.1。
-
本次准备的docker引擎版本是1.12.6。
Rancher
CI/CD
Build应用镜像
示例应用基于NGX官方镜像build,修改了NGX welcome页面信息
Push应用镜像
推送NGX应用镜像到指定的远程镜像仓库
创建Stack&Service
通过API创建webapp stack,NGX service,命令行如下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | curl -u "xxx:xxx" \ -X POST \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "description" : "validate the upgrade service using webhook" , "name" : "webapp" , "system" : false , "dockerCompose" : "version: '2' \nservices:\n NGX:\n image: anzersy/nginx: 20170801 \n stdin_open: true \n tty: true \n cpuset: \" 0 \"\n ports:\n - 8787 : 80 /tcp\n cpu_shares: 1024 \n labels:\n io.rancher.container.pull_image: always\n servicename: nginx", "rancherCompose" : "version: '2'\nservices:\n NGX:\n scale: 1\n start_on_create: true" , "binding" : null , "startOnCreate" : true } ' ' http: //a.b.c.d:e/v2-beta/projects/1a107/stacks' |
验证服务
打开浏览器,访问NGX服务,确认应用的内容。
创建webhook
进入webhook创建页面,通过UI为Dev,Beta,Prod 环境创建service upgrade webhook。
(注意设置好对应的镜像TAG和服务标签)
更新并push应用镜像
更新NGX应用、构建镜像,并推送到远程仓库。
触发upgrade webhook
触发upgrade webhoook,实现服务自动升级。
1 2 3 4 5 6 7 8 9 10 11 12 | curl -u "xxx:xxx" \ -X POST \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "push_data" : { "tag" : "20170801" }, "repository" : { "repo_name" : "anzersy/nginx" } } ' ' http: //a.b.c.d:e/v1- |
验证更新
打开浏览器,访问NGX服务,验证服务升级内容是否正常。
CD
循环3.7&3.8的步骤,完成并验证测试环境和线上环境的持续部署。
原文来源:Rancher Labs
9月27日,北京海航万豪酒店,容器技术大会Container Day 2017即将举行。
CloudStack之父、海航科技技术总监、华为PaaS部门部长、恒丰银行科技部总经理、阿里云PaaS工程总监、民生保险CIO······均已加入豪华讲师套餐!
11家已容器落地企业,15位真·云计算大咖,13场纯·技术演讲,结合实战场景,聚焦落地经验。免费参会+超高规格,详细议程及注册链接请戳
本文转自 RancherLabs 51CTO博客,原文链接:http://blog.51cto.com/12462495/1955094

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
mysql5.6主从复制与基于amoeba实现读写分离
Mysql5.6主从复制 1、特性分析说明: mysql 5.6支持多线程复制的机制并且mysql 5.6还引用了GTID的概念,使得其复制功能的配置、监控及管理变得更加易于实现,且更加健壮。 TID:事务的ID号:也就是说在mysql复制中每一个事务都有自己的ID号(随机数) GTID:全局事务ID,在整个事务架构中每一个事务ID号是唯一的,不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同的,这就是全局事务ID。 全局事务ID是怎么生成的?简单来讲是由mysql服务器自动管理的,在mysql5.6以后每一个mysql服务器都有一个全局唯一的ID号叫做uuid,而GTID就是由当前节点的UUID(一个128位的随机数)和为当前节点生成的随机数(TID)组成的,因此只要UUID不同再在此基础上保证事务ID不同就保证全局不一样了。 全局事务ID有何用处?简单来讲GTID能够保证让一个从服务器到其他的从服务器哪里实现数据复制而且能够实现数据整合的。GTID在分布式架构中可以保证数据的一致性。从而也实现了mysql的高可用性。 GTID相关操作:默认情况下将一个事务记录...
- 下一篇
Rancher如何对接Ceph-RBD块存储
概要 演示环境说明 整个测试环境由以下2台本地虚拟机组成,相关信息说明如下: 引言 Librbd(RBD)是Ceph提供的块存储库,其利用Rados提供的API实现对卷的管理和操作。就目前而言,在Ceph支持的三种接口Posix(CephFS)、块存储(Librbd)和对象存储(RadosGW)接口中,块存储是目前最稳定且达到生产环境要求的接口。Ceph 块设备是精简配置的、大小可调且将数据条带化存储到集群内多个OSD 。Ceph 块设备利用 RADOS 的多种能力,如快照、复制和一致性。Ceph 的 RADOS 块设备(RBD)使用内核模块或 librbd 库与 OSD 交互。 Rancher-RBD安装 Ceph 服务端安装 如果没有Ceph 服务器,可以通过容器运行一个Ceph 服务器 DEMO环境: 1 2 dockerrun-d--net=host-v/etc/ceph:/etc/ceph-eMON_IP= 192.168 . 1.11 -e CEPH_PUBLIC_NETWORK= 192.168 . 1.0 / 24 ceph/demo:tag-build-master-...
相关文章
文章评论
共有0条评论来说两句吧...