阿里云IoT应用案例

10月 31, 2019 发布在 architecture

最近半年一直在尝试传统行业物联网相关技术和战略规划，结合阿里云和阿里云IoT平台，初步实现了几个主要业务功能，整理分享如下：

1. 背景

核心诉求是终端设备接入物联网：一方面是为了数据的远程交互，另一方面是数据的收集和应用

目前终端种类繁多，未统一平台和标准，操作系统覆盖Windows、Android、Linux. 而IoT模组又依据主流通讯技术分成2G、3G、4G和NB-IoT，不同通讯技术的模组使用的协议不尽相同，这对于终端仪器开发的同学来说是个痛点，各个操作系统和开发语言均需对接IoT模组，一旦模组被更换，又需要重新匹配新的协议。

数据接收端也不好过，不同的运营商有自己的IoT平台，管理物联网卡和数据收发。更有运营商强制要求指定型号的模组只能用自家平台进行数据管理（如移远 BC95-5 只能使用电信Easy IoT平台）。应用系统开发需要维护多个运营商IoT平台，接口亦需开发多套。

所以我们想设计一套解决方案，在满足核心诉求的前提下，减少终端和应用系统接入IoT的难度。

2. 架构

阿里提供了一套Link Kit SDK，如下图所示，用于终端快速接入阿里云IoT平台

Link Kit SDK首先是支持多语言及跨平台的，支持MQTT、CoAP、HTTP/S协议，数据直接对接阿里云IoT平台，“没有中间运营商赚差价”，对于不支持TCP/UDP的终端，阿里也提供了网关做统一收发，这就让架构精简了不少。但依然存在一些没填平的坑：

终端开发仍需要学习 Link Kit SDK，而应用开发需要学习阿里云AIoT平台
SDK支持的协议只能发送到阿里云IoT平台，数据转储也只能发送到MQ、RDS等阿里云的SaaS或PaaS。同时目前首国家与运营商的政策，某些模组只能接入运营自己的平台（前文提到的BC95-5），云服务商并不能通吃
SDK需三元组注册，注册分两种，但不论哪一种都比较麻烦，批量的设备更希望动态注册
- 一机一密：在设备上烧写设备的ProductKey、DeviceName、DeviceSecret，然后适配相应的HAL并调用SDK提供的连接云端的函数即可，这种方式要求对设备的产线工具进行一定的修改，需要对每个设备烧写不同的DeviceName和DeviceSecret；
- 一型一密：设备上烧写设备的ProductKey、ProductSecret，每个设备需要具备自己的唯一标识并将该标识预先上传到阿里云IoT物联网平台，然后调用SDK提供的函数连接云端。这种方式每个设备上烧写的信息是固定的ProductKey、ProductSecret

最终设计了一套基于阿里云IoT且更为通用的解决方案架构

我们根据不同的操作系统、不同的开发语言做中间件，中间件再调用Link Kit SDK，同时中间件实现动态注册和封装一些面向上位机的标准化业务接口，如数据通讯、文件下载、远程控制等。对于不能接入阿里云IoT的模组，中间件还需要直接对接到运营商平台。

对于终端设备上位机来说，中间件就是SDK，他们只需按需调用标准化的业务接口，无需关注IoT模组、协议即可快速接入IoT平台。而对于后台系统，我们也从阿里云IoT平台和运营商平台收集数据，进行标准化后再输出给应用系统。从而实现双向快速接入IoT.

3. 技术

3.1 阿里云MQ的设计和使用

中间件包含阿里云IoT和运营商直连两部分，这里我们只讨论阿里云IoT平台这一块，数据流转方式如下图所示，其中SDK服务端订阅模式支持的语言有限，使用场景有限，根据终端数量和TPS，最终选择了规则引擎转发到RocketMQ

阿里云IoT平台目前在国内只有华东2有节点，但平台的规则引擎可以转发到任意一个区域节点，比如我们的RocketMQ实例在华南区，又因为RocketMQ的Topic、Tag机制如下图所示：

所以整体方案架构为：

一个应用实例可以开一个RocketMQ消费者/生产者，用一个GID，其集群也是同一个GID
消费者、生产者可注册或订阅多个Topic
用DeviceID作为Tag用于区分是哪个终端发的消息
在物联网平台需针对物联网平台的产品Topic设置转发规则到RocketMQ

3.2 rocketmq-client-go踩坑

由于我们技术栈是Go系，阿里云IoT平台的MQ是Rocket，原生只支持Java和C++，HTTP协议虽然通用，但效率过于低下，Go的SDK是社区版，阿里云支持有限。经过一番摸索，也算是填平了几个大坑。

首先Go的SDK分原生和非原生，非原生是cgo加RocketMQ C++SDK，在 https://github.com/apache/rocketmq-client-go 的Master分支下，使用时间较久，稳定性较高，但编译麻烦。

原生在 https://github.com/apache/rocketmq-client-go native分支下，是纯go，无需SDK，看上去更像是个完美解决方案，但native尚在开发阶段，支持的功能少，作者也不建议在生产环境使用。

最后我们还是选择使用非原生版本，需要提醒的是当前（2019.11），github的用户文档会产生一些干扰和误解，官方指导是下载RocketMQ的C++版本和GCC，并提供了一个编译后的bin文件，但这个bin文件版本已经过期了，不能对应最新的rocketmq-client-go （1.2.2 与 1.2.4），虽然程序能跑起来，但是会产生很多影响功能的问题。

正确的做法是参考阿里云的文档 https://help.aliyun.com/document_detail/140296.html?spm=a2c4g.11186623.6.619.7fb56e2bIv135O ，官方提供了不同系统环境下的GCC、CGO及SDK的安装方式。由于我们用的K8S，所以使用了Docker镜像并通过Dockerfile来完成RocketMQ的使用。

// 安装 gcc
wget https://ons-client-sdk.oss-cn-hangzhou.aliyuncs.com/cpp-rpm/debian/cgo/rocketmq_2.0.0_amd64.deb
dpkg -i rocketmq_2.0.0_amd64.deb
// golang:1.13 默认安装了cgo

4. 功能

4.1 注册

上文也说到阿里云IoT的设备注册可以批量烧录，也可以分配三元组。但对于批量设备注册，还需一套完整的动态解决方案。语雀社区也给了一些思路 https://www.yuque.com/cloud-dev/iot-tech/qtg9m9

方案是通过调用阿里云IoT平台的API来实现动态分配三元组的。根据中间件的设计需求，我们调整了时序图如下所示：

首先是设备启用和新增，应用后台可以新增设备，新增一个设备ID并传递给阿里云IoT平台用于申请三元组，注意设备ID必须唯一，应用平台需控制，不允许出现相同的设备ID传递到IoT平台，否则数据会紊乱。新增、启用设备主要是应用后台申请三元组并存储在应用系统的DB中。

当应用系统申请到三元组后，中间件才能使用，否则会拿不到三元组从而导致无法注册到IoT平台。中间件一旦启动，会调用应用系统的注册接口，注意这部分请求不是通过Link Kit SDK去实现的，所以需要中间件实现一个HTTP（S）的请求。通过这个请求，中间件把仪器端的设备ID传递给应用系统（设备ID与应用系统添加的一致），应用系统将DB中的三元组返回给中间件，中间件再使用三元组完成阿里云IoT平台的注册。

最后，当应用系统想停止某个仪器设备，就可以在应用后台调用停用设备的接口，则应用后台会通知阿里云IoT删除对应的三元组，并删除应用系统DB的三元组数据。中间件就会因为三元组的丢失，不能再向后台发送数据。

4.2 软件更新（非ota）

软件更新这块，阿里云提供了官方的OTA方案，我们并没有完全去使用，一方面考虑方案的灵活性，另一方面OTA目前还不算特别成熟。我们是基于阿里云OSS和IoT平台来实现软件的远程更新。

首先是应用系统针对软件有一个版本管理，包括软件包的上传（上传至OSS）。

然后是推送功能，推送功能可以让用户选择在线的仪器，则应用后台会向选中仪器的中间件发送一条消息，标识有软件更新，并提供下载连接（OSS/CDN下载连接）。

中间件收到消息后，静默下载升级包到本地临时文件，并校验安装包完整性。

当安装包下载完整无误，再通知上位机，并传递本地路径。

最后用户执行或自动策略执行升级文件，完成升级。

同理，任何文件格式的传输都可以采用这种方式，比如配置文件等。

4.3 远程控制

远程控制这块，有现成的轮子 https://github.com/zhaojh329/rtty ，主要想通过远程的ssh，实现故障快速定位，降低运维成本。这里就不再多说了。

以上就是我们近期在IoT实践中的部分总结。

评论和共享

《阿里巴巴中台战略思想与架构实践》笔记

5月 28, 2019 发布在 architecture

1. 共享服务体系搭建

ESB解决异构系统之间的交互
去中心化分布式服务框架除了对于 SOA 特性的实现和满足外，相比中心化服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为中心点带来平台能力难扩展问题，以及潜在的雪崩影响
关于雪崩
- 企业服务总线架构一旦遇到上面所提到的“雪崩”事故后，故障恢复的时间和成本都非常高昂。因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式则是首先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，再开放服务请求，这样才能恢复系统的运行。但因为着急恢复系统，没有来得及定位之前造成开始服务实例出问题的根本原因，这样的系统恢复运行其实处于一个“脆弱”的状态，之前造成服务实例宕机的问题可能让“雪崩”事故再次上演。
微服务架构的典型特征
- 分布式组成的系统
- 按照业务划分也不是按照技术划分
- 做有生命的产品而不是项目
- 智能化服务端点与傻瓜式服务编排
- 自动化运维
- 系统容错
- 服务快速演化
关于微服务的”微”
- “微服务”中的这个“微”字给很多人带来了很多误解。从字面意思上，“微”会让人联想到一个微服务就应该是功能足够单一，甚至出现一个服务的实现可能只需要几十或者上百行代码的说法，这应该是最误导人的观点。从技术角度出发，确实可以通过简短的代码实现功能单一的服务，但从一个整体架构考虑，如果是以这样的方式实现各个微服务，则在整个服务体系范畴当中包含太多功能边界，那么对于服务运营的分工和边界就很难界定，给服务接下来的持续运营和维护带来困扰；另外拆分过于细化的服务，势必将带来大量无谓的分布式事务调用，给业务的实现带来额外的工作量和风险。

2. 服务中心建设

服务中心一定是不断发展的
尝试服务化 - 全面服务化 - 服务平台化
服务中心的多样性
- 接口：API
- 工具：配置服务、管理服务
- 数据：大数据分析
服务中心可以进一步划分
服务中心和业务不一定一一对应
服务中心划分原则
- 三个方面
  - 设计
  - 运营
  - 工程
- 四个原则
  - 高内聚低耦合
  - 数据完整性
  - 业务可运营
  - 持续渐进

3. 数据拆分

数据尽可能平均拆分（用户订单和子订单Hash方案）
如果是按照订单ID取模的方式，比如按64取模，则可以保证主订单数据以及相关的子订单、订单详情数据平均落入到后端的64个数据库中，原则上很好地满足了数据尽可能平均拆分的原则。
通过采用买家用户ID哈希取模的方式，比如也是按64取模，技术上则也能保证订单数据拆分到后端的64个数据库中，但这里就会出现一个业务场景中带来的一个问题，就是如果有些卖家是交易量非常大的（这样的群体不在少数），那这些卖家产生的订单数据量（特别是订单详情表的数据量）会比其他卖家要多出不少，也就是会出现数据不平均的现象
尽可能减少事务边界
所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量，上面示例中就是事务边界大的典型示例，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来以下弊端：
系统锁冲突概率高
系统难以扩展
整体性能差
异构索引表避免全表扫描
即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是互联网公司很多时候都采用的一个解决思路：拿空间换时间

4. 异步化

业务流程异步化：MQ
数据库事务异步化：解决平台性能的核心问题
- 大事务拆分小事务
- 降低资源被锁造成的性能瓶颈
事务与柔性事务
BASE是指基本可用（BasicallyAvailable）、柔性状态（SoftState）、最终一致性（EventualConsistency）
- “基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
- “柔性状态”是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQLReplication的异步复制也是一种柔性状态体现。
- “最终一致性”是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
ACID与BASE区别
- ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型；BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

5. 数字化运营（异常追踪和定位）

在每个应用集群的运行环境中，每当应用中进行了远程服务调用、缓存、数据库访问等操作时，都会生成相关的访问日志并保存到应用所在的服务器上。
在每一个URL请求都会生成一个全局唯一的ID，鹰眼平台中称为TraceID，这个ID会出现在该请求中所有服务调用、数据库、缓存、消息服务访问时生成的所有日志中。
TraceID一般包含：
- IP地址：在淘宝环境可直接映射到前端应用。
- 创建时间：在存储时用于分区。
- 顺序数：用于链路采样。

6. 平台稳定性

限流和降级
相当于电路上的保险丝，当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台处理能力范围内的业务请求。
压测
- 被压测的单机的关键指标（CPU利用率、系统整体负载、QPS、响应时间等）达到的阀值水位后即自动停止压测，以免对生产环境产生大的影响。
- 基础数据抽取：模拟尽可能真实
- 链路和模型：用户的行为不同，代表链路，参数，模型不同，需要综合考虑模拟真实行为
- 影子表：数据的隔离是全链路压测诞生阶段的一大难题。全链路压测的链路有读有写，并且在线上进行，为了不污染到线上的正常数据，全链路压测在同一个数据库的实例上对数据库表建同样结构的影子表来进行数据的隔离。
- 安全机制：全链路压测的安全机制分两层：第一层是安全的监控和保护，建立非法流量的监控机制，正常用户访问不了测试数据，测试账户也访问不了正常数据，防止数据错乱；并且设置压测引擎集群的白名单，防止恶意访问；第二层是对压测流量的安全过滤，针对压测流量放松安全策略，使得压测流量不被判别为攻击流量。

7. 服务化野蛮生长面临的问题

服务的数量和业务覆盖越来越大
怎么样才能非常高效地找到我需要的服务，并能快速地接入和使用起来？当团队和业务规模小的时候，面对面的交流是最有效的方式，但是当到达一定的数量级的时候，通过人与人之间的互通有无肯定不可行了。
应用和业务架构越分越细，服务越来越专业化，跨领域理解的成本越来越高
服务安全控制层缺乏
应用不知道哪些下游业务在使用，升级或变更时与依赖方沟通花费大量时间
服务被未授权的业务方调用
随意发布服务
开发体验不友好，产品接入时，开发使用手册，文档建设差
整体服务缺乏一个统一的服务治理层
- 在线化
- 数据化

评论和共享

浅谈数字化转型

4月 23, 2019 发布在 architecture

我们探讨数字化生存，数字化转型，那么何为数字化转型？为什么要转型？如何去做转型？这是我们探讨话题的最根本的问题。我将结合自身工作经验和行业案例，浅谈这三个问题，旨在抛砖引玉。

什么是数字化转型

我们谈转型，这是一个过程，有始有终。那么数字化转型是从哪转到哪？一般来讲，我们认为是从信息化技术也就是IT，转型到数字化技术DT.

IT与DT最直观的区别是，IT是落后于需求的，而DT是领先于需求的。如何理解这一说法，这里举一个例子：

信息化时代，企业上OA、ERP、CRM等信息化系统，一般采用外购软件或者第三方现场实施，要求通过信息化系统满足和适配工作中现有的实际需求，且大部分情况是一锤子买卖。但业务不是一成不变，当需求发生改变时，大多数企业选择的是忽略改变或者越过系统，这就导致在2018年以前，绝大部分上信息化系统的企业，包括政府机关，他们的信息化推进极为缓慢。在IT阶段中，业务与技术分离，技术人员处于支持者的角色。企业需要什么，IT就做什么，这就是为什么IT是落后于需求。
数字化时代，企业有团队有能力自己搭建开发信息化系统，并根据业务发展持续不断的优化完善系统。积累大量数据，通过BI、AI手段指导市场和探索新业务。最近几年，云服务商直接与政府合作，广东、杭州开展的一系列数字政务都能让大家感受到数字化时代快速发展的力量。几乎在一夜之间，社保公积金可以刷脸查询；身份证明、婚姻证明可以联网互通；异地可以办理出入境等等。在DT阶段，技术人员以运营作为首要目标和角色。能通过数字化手段帮企业做啥，这就是为什么说DT领先于需求。

为什么要数字化转型

当人们都在谈论一个话题时，我们说它是一个趋势。那么这个势是如何形成的？

早在1998年，互联网开始进入中国家庭，以其为代表的就是大家熟知的QQ。很快，互联网的热潮席卷全球。人们发现，互联网的出现，极大降低了人与人之间的交互成本，提高了沟通效率，增加了更多的交流方式。后来，互联网的思维逐渐融合进企业，信息化、自动化、无纸化将电脑、网络和系统带进了大大小小的公司。这是互联网的第一个十年，也是信息化时代的开始。
到了2008年，智能手机的出现进一步扩大互联网的范围。终端的引入让更多设想变成现实。对于互联网企业，移动游戏、移动支付、移动应用开辟了新的业务、衍生和积攒了新的技术。而对于传统行业，在2013年提出的互联网+思路，将移动互联网的技术进一步结合实际产业中的设备和业务，形成互联网+家居、互联网+汽车、互联网+安防，直至后来成为物联网IoT。一旦网络深入到终端，企业就自然而然积累了大量数据，因为数据的来源不再单单是企业中的人，而是设备，是终端用户。所以必然会面临如何处理和利用这些数据。这是互联网的第二个十年，移动互联网时代、大数据时代，也是数字化时代的开始。
2018年，云计算日趋成熟稳定，人工智能开始走入生活。这是大数据时代的积淀。互联网将能够给传统行业乃至日常生活提供更多力量。我们所能见到的，阿里巴巴在双11中不断磨练和打造的阿里云给12306提供基础设施和技术服务后，春运抢票不再会遇到网站崩溃和异常；图像识别和语音识别作为人工智能的最普遍应用，已经在语音助手、身份识别、拍照优化等各个领域崭露头角。这是互联网的第三个十年，是智能化时代的开始。

信息化是为了帮助企业提高效率，信息化打通了人与人沟通的环节；移动技术和物联网将信息化覆盖到终端设备打通了人与物交互的环节；因为有了互联网和物联网，我们就有了足够多的的数据，就要去分析和利用数据；最终从宏观的人为参与的BI演化到微观的机器自主学习的AI。所以说，数字化转型不单单是企业为了求发展，归根到底是生存之战。它是事物发展的必然趋势，物竞天择，适者生存。

如何数字化转型

从数字化的发展历史中，我提到了互联网的三个十年，这也对应着数字化转型的三个阶段：

业务数据化
数据业务化
业务智能化

那么如何在这三个阶段过渡去做数字化转型，我仅从技术角度谈谈自己的看法：

云计算：利用云计算作为数字化转型的基础平台是大众普遍认知。但为什么要上云？上云为企业提供了数字化建设绝大部分必须的服务。好比我要做饭，但买菜、摘菜、洗菜、切菜、炒菜、摆盘这些必要的工序少不了，锅碗瓢盆筷子刀叉这些必要的工具也少不了。而云计算恰恰就像是一桶方便面，只需要加好调料在开水里泡一下，就成了。它极大降低了门槛，方便企业利用云平台快速实现业务。但是，要想成为一个好厨师，练就一身好厨艺，也不能一直指望做泡面。基本功早晚都要练，我们的最终目的是，把自己的产品打造成下一个云，为别人提供服务。这才是上云的意义。
人才团队建设：上文说IT时代，技术人员是支持角色。DT时代，IT要转变身份为运营角色，IT要懂业务发展，而不仅仅只懂业务现状。对于传统制造型企业，由于自身业务已经足够庞大，可以组织者在适当的时机，以内部的一两个现有小型信息项目做试点，打造一支跨部门、跨职能的小型团队，并从维护系统逐步过渡到自主研发，持续优化，在这个过程中逐步实施敏捷开发、CI/CD、DevOps等技术方法，积累经验。九层之台，起于累土，纵然我们能借助外力，也切忌犯信息化时代的错误，一支懂业务，有技术，能满足企业发展的要求并持续改进的团队才是数字化转型的核武器。

传统企业转型要点

上文也提到，传统企业不同于互联网企业技术积淀扎实，也不同于新兴企业可以推倒一切从头开始。复杂的业务流程、庞大的体量决定了传统企业的数字化转型注定不是一件容易事。我个人认为，传统企业做转型，需要考虑以下几点：

企业内部力量：数字化转型的核心是将原本的技术支持变成持续运营。对于技术人员来说，需要对企业业务有深刻的理解和认识。这就在一定程度上限制了第三方或者外界力量的影响。企业自己培养数字化时代的人才符合切身利益，也符合长远发展规划。吸收符合公司业务发展要求，并能在转型中做出重大贡献的外来人才，属于可遇而不可求。
质量、效率和成本：质量、效率和成本是传统企业的核心价值观。在技术腾飞发展的今天，不少解决方案提供商都会鼓吹各种新技术、新方案。对于传统企业，可以尝试，可以探索。但只要牵扯到落地，就一定要结合这三个核心价值观，提高质量、提高效率、降低成本。
并行造桥：传统企业信息化底子薄，本来就处于技术劣势。一步一步稳扎稳打去弥补缺陷，且不说在数字化时代弯道超车，要赶上平均水平也较为吃力。不少成功的解决方案案例提倡双模，两步走方式，即信息化团队求稳，加紧完善企业内部信息化平台建设；数字化团队应用新技术，探索新业务；如同造桥和挖隧道，同时从两边开始，提高效率。

传统行业在数字化、智能化领域的探索实践，对公司在互联网新时代的发展有着重要意义，这不是一道选择题，而是生存题。

评论和共享

近期开发问题汇总

1月 22, 2019 发布在 program

一、跨域

1. 为什么会存在跨域

是浏览器的同源策略引起的

2. 什么是同源策略

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制
浏览器默认开启同源策略

3. 如何定义同源

http://store.company.com/dir/page.html 同源检测

URL	结果	原因
`http://store.company.com/dir2/other.html`	成功
`http://store.company.com/dir/inner/another.html`	成功
`https://store.company.com/secure.html`	失败	不同协议 ( https和http )
`http://store.company.com:81/dir/etc.html`	失败	不同端口 ( 81和80)
`http://news.company.com/dir/other.html`	失败	不同域名 ( news和store )

4. 同源策略存在的意义是什么

它是一个基本的安全机制
没有同源策略会出现“跨站伪造请求”和“跨Frame DOM查询”等安全问题

5. CSRF跨域请求伪造

用户登录网站A，用户的登录信息会作为cookie存在本地
用户重新打开网站A，浏览器会判断本地cookie，如果存在站点A的cookie，发送给服务器，服务器判断cookie可用，则自动登录，这是一般登录场景的正常逻辑
用户登录网站A后，登录网站B，B就可以通过本地cookie请求网站A，然后伪造用户向网站A发送请求，这就是CSRF
设置同源策略则可禁止网站B直接请求网站A
但同源只是一个基本的安全机制，通过其他手段获取cookie仍可绕过同源策略，这就要求服务需要综合使用多种安全策略，如设置cookie为http only，使用https协议防止抓包，防止其他网络攻击获取cookie信息

6. 跨站Frame DOM查询

攻击者自建网站B，使用iframe嵌套某网站A

用户登录网站B，发现页面整体与网站A一致，登录信息后，攻击者可在站点B获取站点A的DOM

// HTML
<iframe name="yinhang" src="www.yinhang.com"></iframe>
// JS
// 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node}，我还拿不到你刚刚输入的账号密码吗`)

使用同源策略就可以禁止网站B获取网站A的DOM

7. XSS跨站脚本攻击

“跨站脚本攻击”容易和“跨域请求伪造”混淆
XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些代码，嵌入到web页面中去

如下示例

# 服务直接显示用户传入的name参数
# 如传入tom，输出tom
http://127.0.0.1:8080/get?name=tom
# 传入一个js代码
http://127.0.0.1:8080/get?name=<script>alert(2)</script>
# 正常应该输出<script>alert(2)</script>
# 但服务端却执行了js，弹窗显示2

预防XSS的手段比较简单，但常疏忽：对于用户的任何输入都要做严格检查和过滤，输出做转义和替换

8. 如何解决跨域

既然同源是默认安全策略，但在实际开发中又不得不面临localhost和端口与服务IP PORT不同，如何解决跨域问题

JSONP（前端）
- JSON With Padding，动态创建\标签，利用其src不受同源策略的约束来跨域访问，通过回调获取信息
- 由于\的src是GET方式，所以JSONP也仅支持GET方式的请求
代理（前端）
- 既然是同源检测不通过，那就创造一个同源条件
- 通过nginx或者其他web host，反向代理，先满足端口和协议相同，再通过修改hosts，满足域名相同
- 可以支持所有请求方式

CORS（后台）

跨站资源分享 Cross-Origin Resource Sharing，是W3C的标准，也是AJAX跨域请求的根本解决方法
服务配置 Access-Control-Allow-Origin 属性，类似白名单，来规定哪些源可以跨域访问服务，注意，既然是解决跨域问题，它对域名、协议、端口都是敏感的
1
Access-Control-Allow-Origin: "http://localhost:9099","https://baidu.com","http://baidu.com"

CORS还有一些其他相关属性

# 后端是否接收cookie
Access-Control-Allow-Credentials: true/false 
# 后端可接收的请求方法
Access-Control-Request-Method: "PUT,POST,GET,DELETE,OPTIONS"
# 后端可接受的头部
Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept"

需要注意，如果Access-Control-Allow-Credentials设置为true，意味着可发送cookie到后台，那么Access-Control-Allow-Origin就不可以设置为星号” * “，必须指定明确的域名，结合CSRF想想为何要这样做？

9. Origin和Referer

HTTP Referer是header的一部分，会告诉服务器请求是从哪里来的
Referer一般用于防盗链，比如图片服务器限制白名单为 http://a.b.com ，用户盗图到网站 http://x.y.com ，则Referer与白名单不匹配，无法访问图片
Referer和Origin一样，可以通过hosts或者其他方式伪造

【参考】

http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

https://segmentfault.com/a/1190000015597029

二、REST Ful

1. 什么是REST Ful

Representational State Transfer 表述状态转移
REST Ful 是REST风格的设计，它不是标准，只提供了一组设计原则和约束条件，基于这个风格可以让交互更简洁，更有层次，更利于实现缓存
利用浏览器的5种HTTP方法（GET、POST、PUT、PATCH、DELETE）来实现不同类型的请求，如读取、新增、修改、删除
利用HTTP的状态返回码来标识返回状态，如200代表成功，404代表资源不存在，500代表内部错误，304代表缓存等等

2. 什么是简单请求

CORS 将请求方法分成两类，简单请求和非简单请求
请求方法是下列方法之一
- GET
- HEAD
- POST
HTTP头信息不超过一下几种字段
- Accept
- Accept-Language
- Content-Language
- Content-Type
  - application/x-www-form-urlencoded
  - multipart/form-data
  - text/plain
简单请求中，浏览器和服务器之间只请求一次

3. 什么是非简单请求

不是符合简单请求条件的，就是非简单请求
如以下请求方法，包含但不限于
- PUT
- PATCH
- DELETE
如以下头部信息，包含但不限于
- Content-Type
  - application/json
非简单请求需要先试用OPTIONS方法发起一个预检，如果通过才发送请求，浏览器和服务器之间可能请求两次

4. 如何实践REST Ful

URL设计

所有的资源都是宾语，复数，如 students、teachers

所有的请求方式都是动词，如GET代表查询，POST代表新增，PUT代表修改，PATCH代表局部修改（某些客户端不支持该方法），DELETE代表删除

# 查询学生列表
GET /students
# 查询id为3的学生
GET /students/3
# 查询性别为男的学生
GET /students?sex=male    
# 新增学生
POST /students
Content-Type: application/json
Body: { "name":"张三", "age":15, "sex","male"}
# 修改id为3的学生信息
PUT /students/3
Content-Type: application/json
Body: { "name":"李四", "age":15, "sex","male"}
# 删除id为3的学生
DELETE /students/3

切记不要将资源设计成动宾结构，如
1
2
GET /getAllStudents
POST /addStudents
REST Ful要求设计之初就要考虑资源和请求的关系，如果资源设计不当，会造成接口变成REST Ful Like
想一想，用户登录该怎么设计？

状态码

利用HTTP状态码作为状态返回

1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误

其中304状态可配合缓存使用

服务器回应
- 发生错误就不能返回2xx的状态码
- 返回的格式必须和请求的Content-Type格式一致，如Content-Type是application/json，那返回也要是json，不能是纯文本

PS：不要为了REST Ful而REST Ful ！！！

5. 如何用复杂条件进行查询

我们要查询people这个资源，姓名包含“赵”，年龄在15-35之间，性别为女，那在REST Ful设计的接口下如何查询

GET + Body，事实上GET方法也可以有Body，但看起来不是那么REST Ful
用POST来查询，同样，看起来不是那么REST Ful
POST + GET
- 建立一个资源 queries，来存储查询条件
- 查询前先发送POST请求，传入查询条件如“ name=*赵* & minAge=15 & maxAge=35 & sex=女 ”
- POST返回查询条件的ID，如 123456
- 浏览器再通过GET，传入123456进行查询，可配合状态返回码304利用缓存

6. 手机浏览器HTTPS协议问题

项目中遇到问题，开发环境可用手机发送请求，而公网环境不能用手机发送

开发环境使用http协议，并通过fiddler代理，手机与开发机同网络并使用fiddler作为代理，请求通过代理发送，可成功通讯
公网环境使用http协议，DNS解析，手机与服务器不同网络，请求不可达，无返回，HTTP Status为0

经过排查，问题为：

多数手机浏览器要求非简单请求必须为HTTPS协议
若前端页面是HTTPS协议，后端服务也必须为HTTPS协议，否则会有告警提醒
SSL证书必须有效，私有证书需先在手机安装
注意检查SSL证书，如果是通用域名，一般为二级域名通用，如 *.xx.com，若后端服务或前端页面是三级以上域名，如api.yy.xx.com，则SSL证书不适用

【参考】

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

https://www.runoob.com/w3cnote/restful-architecture.html

三、分布式服务

1. 什么是分布式服务

服务、应用有多个副本，部署在相同或不同的节点，作为一个整体对外提供功能

2. 如何在分布式服务下使用存储

需求：用户登录后，cookie存在本地，session放在服务器，以后登录可用cookie匹配服务端的session，验证用户信息

分布式架构下的问题：若用户第一次访问，被分配到Server1，那么session记录在Server1上，当用户第二次访问，被分配到Server2，并没有记录session，会导致验证失败

如何解决：

使用负载均衡的会话保持，让同一个用户的访问在一段时间内都被分配到同一个Server。但超时后仍有问题。
使用共享存储，所有的Server不再将session保存到服务器本地，而是保存到同一个缓存或数据库，可以从根本上解决问题

PS：分布式架构下，切记使用本地存储！！！

3. 如何在分布式服务下使用定时消费任务

需求：服务每10分钟轮询数据库X表，存在数据则拷贝到Y表并删除X表的原记录

分布式架构下的问题：Server1发现X表有数据，拷贝到Y表，还没来得及删除，Server2也发现X表有数据，拷贝到Y表。Y表重复产生数据

如何解决：

使用锁
使用信号机制
使用MQ

4. 如何处理分布式事务

https://www.cnblogs.com/bigben0123/p/9453830.html

数据库事务的ACID
- A 原子性
- C 一致性
- I 隔离性
- D 持久性
分布式事务的CAP
- C 一致性
- A 可用性
- P 分区容错性
分布式事务的CAP不可同时满足
银行转账问题
- 北京的A给上海的B转100块
- 北京服务，A的账户-100
- 上海服务，B的账户+100
- 若上海的服务出现问题，A损失100，但B没有收到
- 若北京的服务出现问题，A的账户没有扣钱
如何解决分布式事务
- 本地消息表
- MQ事务

评论和共享

在Kubernetes上搭建RabbitMQ Cluster

10月 09, 2018 发布在 architecture

为了在Kubernetes上搭建RabbitMQ3.7.X Cluster，踩爆无数坑，官方整合了第三方开源项目但没有完整demo，网上的post都是RabbitMQ 3.6.X旧版的部署方案，几经周折，最终弄明白在Kubernetes集群下，基于Kubernetes Discovery，使用hostname方式部署RabbitMQ3.7.X Cluster，总结如下：

1. IP模式

rabbitmq-peer-discovery-k8s是RabbitMQ官方基于第三方开源项目rabbitmq-autocluster开发，对3.7.X版本提供的Kubernetes下的同行发现插件，但官方只提供了一个基于IP模式的demo

kind: Service
apiVersion: v1
metadata:
  namespace: test-rabbitmq
  name: rabbitmq
  labels:
    app: rabbitmq
    type: LoadBalancer  
spec:
  type: NodePort
  ports:
   - name: http
     protocol: TCP
     port: 15672
     targetPort: 15672
     nodePort: 31672
   - name: amqp
     protocol: TCP
     port: 5672
     targetPort: 5672
     nodePort: 30672
  selector:
    app: rabbitmq
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-config
  namespace: test-rabbitmq
data:
  enabled_plugins: |
      [rabbitmq_management,rabbitmq_peer_discovery_k8s].
  rabbitmq.conf: |
      ## Cluster formation. See http://www.rabbitmq.com/cluster-formation.html to learn more.
      cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
      cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
      ## Should RabbitMQ node name be computed from the pod's hostname or IP address?
      ## IP addresses are not stable, so using [stable] hostnames is recommended when possible.
      ## Set to "hostname" to use pod hostnames.
      ## When this value is changed, so should the variable used to set the RABBITMQ_NODENAME
      ## environment variable.
      cluster_formation.k8s.address_type = ip
      ## How often should node cleanup checks run?
      cluster_formation.node_cleanup.interval = 30
      ## Set to false if automatic removal of unknown/absent nodes
      ## is desired. This can be dangerous, see
      ##  * http://www.rabbitmq.com/cluster-formation.html#node-health-checks-and-cleanup
      ##  * https://groups.google.com/forum/#!msg/rabbitmq-users/wuOfzEywHXo/k8z_HWIkBgAJ
      cluster_formation.node_cleanup.only_log_warning = true
      cluster_partition_handling = autoheal
      ## See http://www.rabbitmq.com/ha.html#master-migration-data-locality
      queue_master_locator=min-masters
      ## See http://www.rabbitmq.com/access-control.html#loopback-users
      loopback_users.guest = false
   
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: rabbitmq
  namespace: test-rabbitmq
spec:
  serviceName: rabbitmq
  replicas: 3
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      serviceAccountName: rabbitmq
      terminationGracePeriodSeconds: 10
      containers:        
      - name: rabbitmq-k8s
        image: rabbitmq:3.7
        volumeMounts:
          - name: config-volume
            mountPath: /etc/rabbitmq
        ports:
          - name: http
            protocol: TCP
            containerPort: 15672
          - name: amqp
            protocol: TCP
            containerPort: 5672
        livenessProbe:
          exec:
            command: ["rabbitmqctl", "status"]
          initialDelaySeconds: 60
          periodSeconds: 60
          timeoutSeconds: 10
        readinessProbe:
          exec:
            command: ["rabbitmqctl", "status"]
          initialDelaySeconds: 20
          periodSeconds: 60
          timeoutSeconds: 10
        imagePullPolicy: Always
        env:
          - name: MY_POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          - name: RABBITMQ_USE_LONGNAME
            value: "true"
          # See a note on cluster_formation.k8s.address_type in the config file section
          - name: RABBITMQ_NODENAME
            value: "rabbit@$(MY_POD_IP)"
          - name: K8S_SERVICE_NAME
            value: "rabbitmq"
          - name: RABBITMQ_ERLANG_COOKIE
            value: "mycookie" 
      volumes:
        - name: config-volume
          configMap:
            name: rabbitmq-config
            items:
            - key: rabbitmq.conf
              path: rabbitmq.conf
            - key: enabled_plugins
              path: enabled_plugins

在ConfigMap配置项中，指明 cluster_formation.k8s.address_type = ip，也就是说RabbitMQ Node的命名和访问地址是以IP地址作为区分，如rabbit@172.0.5.1

但这样的配置会产生比较大的问题，如果我们使用pv和pvc去做数据的持久化，那么每个节点的配置和数据存储都会放在rabbit@172.0.5.1这样的文件夹下，而Kubernetes集群中，Pod的IP都是不稳定的，当有RabbitMQ Node的Pod挂掉后，重新创建的Pod IP可能会变，这就会使得节点的配置和数据全部丢失。

所以我们更希望RabbitMQ Node的命名是以一定规则编写的相对稳定的名称，如rabbit@rabbit-0，这就需要修改 cluster_formation.k8s.address_type = hostname，以启用hostname模式。

但直接修改address_type 并不能满足要求，注释部分也描述了“Set to hostname to use pod hostnames. When this value is changed, so should the variable used to set the RABBITMQ_NODENAME”。那么RABBITMQ_NODENAME该如何设置，就必须先要了解如何用hostname访问pod

2. Pod与Service的DNS

Kubernetes官方讲述了如何用hostname访问service和pod：dns-pod-service，

其中对于service，可以直接使用my-svc.my-namespace.svc.cluster.local进行访问；而对于pod，则需使用pod-ip-address.my-namespace.pod.cluster.local进行访问，但这里却仍显式的应用到了pod的ip。我们希望脱离ip对pod进行访问，很不幸的是，pod确实无法直接通过hostname访问，不过却有个曲线救国的方案。

apiVersion: v1
kind: Service
metadata:
  name: default-subdomain # 和pod的subdomain相同
spec:
  selector:
    name: busybox
  clusterIP: None  # clusterIP: None表示这是一个headless service
  ports:
  - name: foo # 没啥用
    port: 1234
    targetPort: 1234
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1 # 默认使用metadata.name作为hostname，也可指定设置
  subdomain: default-subdomain
  containers:
  - image: busybox
    command:
      - sleep
      - "3600"
    name: busybox

如上面代码所示，我们需要一个headless service来作为中介，这样就可以使用busybox-1.default-subdomain.default.svc.cluster.local来访问pod了（hostname.subdomain.my-namespace.svc.cluster.local）

3. Statefulset 与Headless Service

了解了如何用hostname访问Pod还不足以解决问题，在RabbitMQ的配置中，我们使用的是StatefulSet，那么StatefulSet如何用Headless Service去做Pod的hostname访问呢？

Kubernetes（StatefulSets在1.9版本后已经是一个稳定功能）官方也给出了详细的说明：statefulset

Demo和注释如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None # 是一个headless service
  selector:
    app: nginx
---
apiVersion: apps/v1 # 需要注意如果是apps/v1，.spec.selector.matchLabels和.spec.template.metadata.labels要相同；如果是apps/v1beta，可以省略.spec.selector.matchLabels
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 需要与 .spec.template.metadata.labels 相同，但无需与headless service name相同
  serviceName: "nginx" # 需要与headless service name相同
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx #  需要与 .spec.selector.matchLabels 相同，但无需与headless service name相同
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web

需要特别注意的是，网上很多例子的StatefulSet用的apps/v1beta

4. hostname模式

在我查找的众多资料中，在Kubernetes中

讲RabbitMQ 3.6.X部署的，https://www.kubernetes.org.cn/2629.html 这篇讲的比较清楚

讲RabbitMQ 3.7.X部署的，https://habr.com/company/eastbanctech/blog/419817 这篇俄文的Post讲的比较清楚，但它也是用的apps/v1beta，同时有大量的重复配置，不知道哪些可用哪些无用，还有一个最致命的问题是按照它的配置部署后，readinessProbe老报错，说DNS解析出现问题。几经折腾，才明白因为用Headless Service去做Pod的hostname访问，需要等Pod和Service都启动后才能访问，而readiness探针还没等DNS正常就去探查服务是否可用，所以才会误认为服务不可达，最终无法启动Pod。解决办法是给Headless Service设置publishNotReadyAddresses: true

我的配置文件如下所示：

apiVersion: v1
kind: Namespace
metadata:
  name: rabbitmq
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: rabbitmq 
  namespace: rabbitmq 
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: endpoint-reader
  namespace: rabbitmq 
rules:
- apiGroups: [""]
  resources: ["endpoints"]
  verbs: ["get"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: endpoint-reader
  namespace: rabbitmq
subjects:
- kind: ServiceAccount
  name: rabbitmq
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: endpoint-reader
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: rabbitmq-data
    labels:
      release: rabbitmq-data
    namespace: rabbitmq
spec:
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /rabbit
      server: xxxxx  # nas地址
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rabbitmq-data-claim
  namespace: rabbitmq
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 10Gi
  selector:
    matchLabels:
      release: rabbitmq-data
---
# headless service 用于使用hostname访问pod
kind: Service
apiVersion: v1
metadata:
  name: rabbitmq-headless
  namespace: rabbitmq
spec:
  clusterIP: None
  # publishNotReadyAddresses, when set to true, indicates that DNS implementations must publish the notReadyAddresses of subsets for the Endpoints associated with the Service. The default value is false. The primary use case for setting this field is to use a StatefulSet's Headless Service to propagate SRV records for its Pods without respect to their readiness for purpose of peer discovery. This field will replace the service.alpha.kubernetes.io/tolerate-unready-endpoints when that annotation is deprecated and all clients have been converted to use this field.
  # 由于使用DNS访问Pod需Pod和Headless service启动之后才能访问，publishNotReadyAddresses设置成true，防止readinessProbe在服务没启动时找不到DNS
  publishNotReadyAddresses: true 
  ports: 
   - name: amqp
     port: 5672
   - name: http
     port: 15672
  selector:
    app: rabbitmq
---
# 用于暴露dashboard到外网
kind: Service
apiVersion: v1
metadata:
  namespace: rabbitmq
  name: rabbitmq-service
spec:
  type: NodePort
  ports:
   - name: http
     protocol: TCP
     port: 15672
     targetPort: 15672
     nodePort: 15672
   - name: amqp
     protocol: TCP
     port: 5672
     targetPort: 5672
  selector:
    app: rabbitmq
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-config
  namespace: rabbitmq
data:
  enabled_plugins: |
      [rabbitmq_management,rabbitmq_peer_discovery_k8s].
  rabbitmq.conf: |
      cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
      cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
      cluster_formation.k8s.address_type = hostname
      cluster_formation.node_cleanup.interval = 10
      cluster_formation.node_cleanup.only_log_warning = true
      cluster_partition_handling = autoheal
      queue_master_locator=min-masters
      loopback_users.guest = false
      cluster_formation.randomized_startup_delay_range.min = 0
      cluster_formation.randomized_startup_delay_range.max = 2
      # 必须设置service_name，否则Pod无法正常启动，这里设置后可以不设置statefulset下env中的K8S_SERVICE_NAME变量
      cluster_formation.k8s.service_name = rabbitmq-headless
      # 必须设置hostname_suffix，否则节点不能成为集群
      cluster_formation.k8s.hostname_suffix = .rabbitmq-headless.rabbitmq.svc.cluster.local
      # 内存上限
      vm_memory_high_watermark.absolute = 1.6GB
      # 硬盘上限
      disk_free_limit.absolute = 2GB
---
# 使用apps/v1版本代替apps/v1beta
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: rabbitmq
  namespace: rabbitmq
spec:
  serviceName: rabbitmq-headless   # 必须与headless service的name相同，用于hostname传播访问pod
  selector:
    matchLabels:
      app: rabbitmq # 在apps/v1中，需与 .spec.template.metadata.label 相同，用于hostname传播访问pod，而在apps/v1beta中无需这样做
  replicas: 3
  template:
    metadata:
      labels:
        app: rabbitmq  # 在apps/v1中，需与 .spec.selector.matchLabels 相同
      # 设置podAntiAffinity
      annotations:
        scheduler.alpha.kubernetes.io/affinity: >
            {
              "podAntiAffinity": {
                "requiredDuringSchedulingIgnoredDuringExecution": [{
                  "labelSelector": {
                    "matchExpressions": [{
                      "key": "app",
                      "operator": "In",
                      "values": ["rabbitmq"]
                    }]
                  },
                  "topologyKey": "kubernetes.io/hostname"
                }]
              }
            }
    spec:
      serviceAccountName: rabbitmq
      terminationGracePeriodSeconds: 10
      containers:        
      - name: rabbitmq
        image: registry-vpc.cn-shenzhen.aliyuncs.com/heygears/rabbitmq:3.7
        resources:
          limits:
            cpu: 0.5
            memory: 2Gi
          requests:
            cpu: 0.3
            memory: 2Gi
        volumeMounts:
          - name: config-volume
            mountPath: /etc/rabbitmq
          - name: rabbitmq-data
            mountPath: /var/lib/rabbitmq/mnesia
        ports:
          - name: http
            protocol: TCP
            containerPort: 15672
          - name: amqp
            protocol: TCP
            containerPort: 5672
        livenessProbe:
          exec:
            command: ["rabbitmqctl", "status"]
          initialDelaySeconds: 60
          periodSeconds: 60
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command: ["rabbitmqctl", "status"]
          initialDelaySeconds: 20
          periodSeconds: 60
          timeoutSeconds: 5
        imagePullPolicy: Always
        env:
          - name: HOSTNAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: RABBITMQ_USE_LONGNAME
            value: "true"
          - name: RABBITMQ_NODENAME
            value: "rabbit@$(HOSTNAME).rabbitmq-headless.rabbitmq.svc.cluster.local"
          # 若在ConfigMap中设置了service_name，则此处无需再次设置
          # - name: K8S_SERVICE_NAME
          #   value: "rabbitmq-headless"
          - name: RABBITMQ_ERLANG_COOKIE
            value: "mycookie" 
      volumes:
        - name: config-volume
          configMap:
            name: rabbitmq-config
            items:
            - key: rabbitmq.conf
              path: rabbitmq.conf
            - key: enabled_plugins
              path: enabled_plugins
        - name: rabbitmq-data
          persistentVolumeClaim:
            claimName: rabbitmq-data-claim

至此，终于在Kubernetes上部署完成RabbitMQ Cluster 3.7.X

评论和共享

阿里云Kubernetes实战3--DevOps

8月 07, 2018 发布在 architecture

一、一机多Jenkins Slave

由于业务需要，我们的自动化测试需要基于windows做web功能测试，每一个测试任务独占一个windows用户桌面，所以我们首先要给Jenkins配置几个Windows的Slave Node.在我之前的post《持续集成CI实施指南三–jenkins集成测试》中详细讲解了给Jenkins添加Node的方法步骤。本篇无需重复，但这里主要讲的是，如何在一台Windows服务器上搭建多个Jenkins Node，供多用户使用。

在目标机上建立多个用户，如下图所示：
用Administrator用户安装JDK
在Jenkins的节点管理建立三个Node，分别为WinTester01、WinTester02、WinTester03，配置如下
在目标机的Administrator，用IE打开Jenkins并进入节点管理，在WinTester01、WinTester02、WinTester03中分别点击“Launch”启动Slave
确认启动成功后，点击“File”下的“Install as service”
三个Slave都启动后，可以在服务管理器看到
除了Jenkins Slave1无需配置，Slave2和Slave3都需要右键进入属性，修改登录用户分别为JenkinsSlave2和JenkinsSlave3

通过上面的配置，可以在一台目标机部署三个用户对应三个Jenkins Slave以满足我们的业务需求。

二、二次开发Jenkins 钉钉通知插件

在整个DevOps的业务流程图上，我们想使用钉钉作为通知方式，相比邮件而言，实时性和扩展性都很高。在2018年4月，Jenkins的钉钉通知插件有两款，分别是Dingding JSON Pusher和Dingding notification plugin，前者长期未更新，已经不能使用，后者可以在非Pipeline模式下使用，对于Pipeline则有一些问题。虽然目前，Dingding notification plugin已经更新到1.9版本并支持了Pipeline，但在当时，我们不得不在1.4版本的基础上做二次开发。

整体开发经过参考《Jenkins项目实战之-钉钉提醒插件二次开发举例》，总体来说还是比较简单：

修改”src/main/java/com/ztbsuper/dingtalk/DingTalkNotifier.java”，钉钉的消息API类型有文本、link、markdown、card等，我们这里把通知接口改成文本类型

public class DingTalkNotifier extends Notifier implements SimpleBuildStep {
    private String accessToken;
    private String message;
    private String imageUrl;
    private String messageUrl;
    @DataBoundConstructor
    public DingTalkNotifier(String accessToken, String message, String imageUrl, String messageUrl) {
        this.accessToken = accessToken; //钉钉的accesstoken
        this.message = message;    //消息主体
        this.imageUrl = imageUrl;  //缩略图
        this.messageUrl = messageUrl;  //消息的链接来源，一般是jenkins的build url
    }
    public String getAccessToken() {
        return accessToken;
    }
    public String getMessage() {
        return message;
    }
    public String getImageUrl() {
        return imageUrl;
    }
    public String getMessageUrl() {
        return messageUrl;
    }
    @Override
    public void perform(@Nonnull Run<?, ?> run, @Nonnull FilePath filePath, @Nonnull Launcher launcher, @Nonnull TaskListener taskListener) throws InterruptedException, IOException {
        String buildInfo = run.getFullDisplayName();
        if (!StringUtils.isBlank(message)) {
            sendMessage(LinkMessage.builder()
                    .title(buildInfo)
                    .picUrl(imageUrl)
                    .text(message)
                    .messageUrl(messageUrl)
                    .build());
        }
    }
    private void sendMessage(DingMessage message) {
        DingTalkClient dingTalkClient = DingTalkClient.getInstance();
        try {
            dingTalkClient.sendMessage(accessToken, message);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    @Override
    public BuildStepMonitor getRequiredMonitorService() {
        return BuildStepMonitor.NONE;
    }
    @Symbol("dingTalk")
    @Extension
    public static final class DescriptorImpl extends BuildStepDescriptor<Publisher> {
        @Override
        public boolean isApplicable(Class<? extends AbstractProject> aClass) {
            return true;
        }
        @Nonnull
        @Override
        public String getDisplayName() {
            return Messages.DingTalkNotifier_DescriptorImpl_DisplayName();
        }
    }
}

用maven打包

maven需要安装java环境，为了方便，我直接run一个maven的docker image，编译完成后把hpi文件send出来
在jenkins的插件管理页面上传hpi文件
在钉钉群中开启自定义机器人
找到accesstoken

在jenkins pipeline中可以使用以下命令发送信息到钉钉群

1	dingTalk accessToken:"2fccafaexxxx",message:"信息",imageUrl:"图片地址",messageUrl:"消息链接"

三、 DevOps解决方案

针对每一个软件项目增加部署目录，目录结构如下：

_deploy
- master
  - deployment.yaml
  - Dockerfile
  - other files
- test
  - deployment.yaml
  - Dockerfile
  - other files

master和test文件夹用于区分测试环境与生产环境的部署配置

Dockerfile和other files用于生成应用或服务的镜像

如前端vue和nodejs项目的Dockerfile：

# 前端项目运行环境的Image，从Harbor获取
FROM xxx/xxx/frontend:1.0.0 
RUN mkdir -p /workspace/build && mkdir -p /workspace/run
COPY . /workspace/build
# 编译，生成执行文件，并删除源文件
RUN cd /workspace/build/frontend && \
    cnpm install && \
    npm run test && \
    cp -r /workspace/build/app/* /workspace/run && \
    rm -rf /workspace/build && \
    cd /workspace/run && \
    cnpm install 
# 运行项目，用npm run test或run prod区分测试和生产环境
CMD cd /workspace/run && npm run test

又如dotnet core项目的Dockerfile：

# dotnet项目编译环境的Image，从Harbor获取
FROM xxx/xxx/aspnetcore-build:2 AS builder
WORKDIR /app
COPY . .
# 编译
RUN cd /app/xxx
RUN pwd && ls -al && dotnet restore
RUN dotnet publish -c Release -o publish
# dotnet项目运行环境的Image，从Harbor获取
FROM xxx/xxx/aspnetcore:2
WORKDIR /publish
COPY --from=builder /app/xxx/publish .
# 重命名配置文件，中缀test、prod用于区分测试环境和生产环境
RUN mv appsettings.test.json appsettings.json
# 运行
ENTRYPOINT ["dotnet", "xxx.dll"]

deployent.yaml用于执行应用或服务在k8s上的部署

由于deployment有很多配置项可以抽离成公共配置，所以deployment的配置有很多占位变量，占位变量用两个#中间加变量名表示，如下所示：

apiVersion: v1  
kind: Namespace  
metadata:  
    name: #namespace#  
    labels:  
      name: #namespace#  
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxxxxxxxxxxxxxxx
kind: Secret
metadata:
  name: regcred
  namespace: #namespace#  
type: kubernetes.io/dockerconfigjson
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: #app#-deploy
  namespace: #namespace# 
  labels:
    app: #app#-deploy
spec:
  replicas: #replicas#
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: #app#
    spec:
      containers:
      - image:  #image#  
        name: #app#
        ports:
        - containerPort: #port#
          name: #app#
        securityContext:
          privileged: #privileged#
        volumeMounts:
        - name: log-volume
          mountPath: #log#
      - image:  #filebeatImage#  
        name: filebeat
        args: [
          "-c", "/etc/filebeat.yml"
        ]
        securityContext:
          runAsUser: 0
        volumeMounts:
        - name: config
          mountPath: /etc/filebeat.yml
          readOnly: true
          subPath: filebeat.yml
        - name: log-volume
          mountPath: /var/log/container/
      volumes:
      - name: config
        configMap:
          defaultMode: 0600
          name: filebeat-config
      - name: log-volume
        emptyDir: {}
      imagePullSecrets:
      - name: regcred
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
  namespace: #namespace#
  labels:
    app: filebeat
data:
  filebeat.yml: |-
    filebeat.inputs:
    - type: log
      enabled: true
      paths:
        - /var/log/container/*.log
    output.elasticsearch:
      hosts: ["#es#"]
    tags: ["#namespace#-#app#"]
---
apiVersion: v1
kind: Service
metadata:
  name: #app#-service
  namespace: #namespace# 
  labels:
    app: #app#-service
spec:
  ports:
    - port: 80
      targetPort: #port#    
  selector:
    app: #app#
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: #app#-ingress
  namespace: #namespace#  
  annotations:
      nginx.ingress.kubernetes.io/proxy-body-size: "0"
      nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: #host#  
    http:
      paths:
      - path: #urlPath#
        backend:
          serviceName: #app#-service
          servicePort: 80

其中几个关键变量的解释如下：

dockerconfigjson：因为所有的镜像需要从Harbor获取，而Harbor的镜像如果设置为私有权限，就需要提供身份验证，这里的dockerconfigjson就是Harbor的身份信息。生成dockerconfigjson的方法如下：
- 进入K8S任何一个节点，删除” ~/.docker/config.json “ 文件
- 使用命令” docker login harbor地址”登录harbor
- 通过命令” cat ~/.docker/config.json “可以看到harbor的身份验证信息
- 使用命令” cat /root/.docker/config.json | base64 -w 0 “对信息编码，将生成后的编码填写到deployment.yaml的dockerconfigjson节点即可
namespace：同一个项目的不同k8s组件应置于同一个namespace，所以namespace可统一配置，在我们的项目实践中，生产环境的namespace为” 项目名 “，测试环境的namespace为” 项目名-test “
app：应用或服务名称
image：应用或服务的镜像地址
replicas：副本数量
port：应用或服务的Pod开放端口
log：应用或服务的日志路径，在本系列的第二篇文章中，提到我们的日志方案是给每个应用或服务配一个filebeat，放在同一Pod中，这里只需告知应用或服务的日志的绝对路径，filebeat就能将日志传递到ES中，日志的tag命名方式为” namespace-app”
host：在本系列的第一篇文章中，讲了使用nginx ingress做服务暴露与负载。这里的host就是给nginx ingress设置的域名，端口默认都是80，如果需要https，则在外层使用阿里云SLB转发
urlPath：很多情况下，如微服务，需要通过相同的域名，不同的一级目录将请求分发到不同的后台，在nginx中，就是location的配置与反向代理，比如host的配置是确定了域名aaa.bbb.com，而urlPath的配置是确定aaa.bbb.com/user/getuser将会被转发到用户服务podIP:podPort/getuser中

以上所有的占位变量都是在Pipeline Script中赋值，关于Jenkins Pipeline的相关内容介绍这里不再多讲，还是去看官方文档靠谱。我们这里将k8s的部署文件deployment.yaml与Jenkinsfile结合，即可做到一个deployment.yaml能适配所有项目，一个Pipeline Script模板能适配所有项目，针对不同的项目，只需在Pipeline Script中给占位变量赋值，大大降低了配置复杂度。下面是一个项目的Jenkins配置示例：

对于一个项目，我们只需配置Trigger和Pipeline，上图“Do not allow concurrent builds ”也是通过Pipeline的配置生成的。Pipeline Script示例如下：

pipeline {
    // 指定项目在label为jnlp-agent的节点上构建，也就是Jenkins Slave in Pod
    agent { label 'jnlp-agent' } 
    // 对应Do not allow concurrent builds 
    options {
        disableConcurrentBuilds()
    }
    environment { 
        // ------ 以下内容，每个项目可能均有不同，按需修改 ------ 
        //author：用于钉钉通知
        author="张三"
        // branch: 分支，一般是test、 master，对应git从哪个分支拉取代码，也对应究竟执行_deploy文件夹下的test配置还是master配置
        branch = "test"
        // namespace: myproject-test, myproject，命名空间一般是项目名称，测试环境加test
        namespace = "myproject-test"
        // hostname：对应deployment中的host
        host = "test.aaa.bbb.com"
        // appname：对应deployment中的app
        app = "myserver"
        // port：对应deployment中的port
        port= "80"
        // replicas：对应deployment中的replicas
        replicas = 2
        //git repo path：git的地址
        git="git@git.aaa.bbb.com/xxx.git"
         //log：对应deployment中的log
        log="/publish/logs/"
        // ------ 以下内容，一般所有的项目都一样，不经常修改 ------
        // harbor inner address
        repoHost = "192.168.0.1:23280"
        // harbor的账号密码信息，在jenkins中配置用户名/密码形式的认证信息，命名成harbor即可
        harborCreds = credentials('harbor')
	    // filebeat的镜像地址
        filebeatImage="${repoHost}/common/filebeat:6.3.1"
        // es的内网访问地址
        es="elasticsearch-logging.kube-system:9200"
    }
    // ------ 以下内容无需修改 ------
    stages {
         // 开始构建前清空工作目录
         stage ("CleanWS"){ 
            steps {
                script {
                    try{
                       deleteDir()
                    }catch(err){
                        echo "${err}"
                        sh 'exit 1'
                    }
                }  
            }  
        }
        // 拉取
        stage ("CheckOut"){ 
            steps {
                script {
                    try{
                      checkout([$class: 'GitSCM', branches: [[name: "*/${branch}"]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'gitlab', url: "${git}"]]])
                    }catch(err){
                        echo "${err}"
                        sh 'exit 1'
                    }
                }  
            }  
        }
       // 构建
        stage ("Build"){ 
            steps {
                script {
                    try{
                        // 登录 harbor 
                        sh "docker login -u ${harborCreds_USR} -p ${harborCreds_PSW} ${repoHost}"
                        sh "date +%Y%m%d%H%m%S > timestamp"
                        // 镜像tag用时间戳代表
                        tag = readFile('timestamp').replace("\n", "").replace("\r", "")
                        repoPath = "${repoHost}/${namespace}/${app}:${tag}"
                        // 根据分支，进入_deploy下对应的不同文件夹，通过dockerfile打包镜像
                        sh "cp _deploy/${branch}/* ./"
                        sh "docker login -u ${harborCreds_USR} -p ${harborCreds_PSW} ${repoHost}"
                        sh "docker build -t ${repoPath}  ."
                    }catch(err){
                        echo "${err}"
                        sh 'exit 1'
                    }
                }  
            }  
        }
        // 镜像推送到harbor
        stage ("Push"){
            steps {
                script {
                    try{
                        sh "docker push ${repoPath}"
                    }catch(err){
                        echo "${err}"
                        sh 'exit 1'
                    }
                }   
            }
        }
        // 使用pipeline script中复制的变量替换deployment.yaml中的占位变量，执行deployment.yaml进行部署
        stage ("Deploy"){
            steps {
                script {
                    try{
                        sh "sed -i 's|#namespace#|${namespace}|g' deployment.yaml"
                        sh "sed -i 's|#app#|${app}|g' deployment.yaml"
                        sh "sed -i 's|#image#|${repoPath}|g' deployment.yaml"
                        sh "sed -i 's|#port#|${port}|g' deployment.yaml"
                        sh "sed -i 's|#host#|${host}|g' deployment.yaml"
                        sh "sed -i 's|#replicas#|${replicas}|g' deployment.yaml"
                        sh "sed -i 's|#log#|${log}|g' deployment.yaml"
                        sh "sed -i 's|#filebeatImage#|${filebeatImage}|g' deployment.yaml"
                        sh "sed -i 's|#es#|${es}|g' deployment.yaml"
                        sh "sed -i 's|#redisImage#|${redisImage}|g' deployment.yaml"
                        sh "cat deployment.yaml"
                        sh "kubectl apply -f deployment.yaml"	
                    }catch(err){
                        echo "${err}"
                        sh 'exit 1'
                    }
                }
            }
        }
    }
    post {
        // 使用钉钉插件进行通知
        always {
            script {   
                def msg = "【${author}】你把服务器搞挂了，老詹喊你回家改BUG！"
                def imageUrl = "https://www.iconsdb.com/icons/preview/red/x-mark-3-xxl.png"
                if (currentBuild.currentResult=="SUCCESS"){
                    imageUrl= "http://icons.iconarchive.com/icons/paomedia/small-n-flat/1024/sign-check-icon.png"
                    msg ="【${author}】发布成功，干得不错！"
                }
                dingTalk accessToken:"xxxx",message:"${msg}",imageUrl:"${imageUrl}",messageUrl:"${BUILD_URL}"
            }
        }
    }
}

发布完成后，可以参考《持续集成CI实施指南三–jenkins集成测试》，做持续测试，测试结果也可通过钉钉通知。最后我们利用自建的运维平台，监控阿里云ECS状态、K8S各组件状态、监控ES中的日志并做异常抓取和报警。形成一整套DevOps模式。

综上，对于每个项目，我们只需维护Dockerfile，并在Jenkins创建持续集成项目时，填写项目所需的参数变量。进阶情况下，也可定制性的修改deployment文件与pipeline script，满足不同的业务需要。至此，完结，撒花！

评论和共享

阿里云Kubernetes实战2--搭建基础服务

8月 06, 2018 发布在 architecture

在系列的第一篇文章中，我已经介绍过如何在阿里云基于kubeasz搭建K8S集群，通过在K8S上部署gitlab并暴露至集群外来演示服务部署与发现的流程。文章写于4月，忙碌了小半年后，我才有时间把后续部分补齐。系列会分为三篇，本篇将继续部署基础设施，如jenkins、harbor、efk等，以便为第三篇项目实战做好准备。

需要说明的是，阿里云迭代的实在是太快了，2018年4月的时候，由于SLB不支持HTTP跳转HTTPS，迫不得已使用了Ingress-Nginx来做跳转控制。但在4月底的时候，SLB已经在部分地区如华北、国外节点支持HTTP跳转HTTPS。到了5月更是全节点支持。这样以来，又简化了Ingress-Nginx的配置。

一、Jenkins

一般情况下，我们搭建一个Jenkins用于持续集成，那么所有的Jobs都会在这一个Jenkins上进行build，如果Jobs数量较多，势必会引起Jenkins资源不足导致各种问题出现。于是，对于项目较多的部门、公司使用Jenkins，需要搭建Jenkins集群，也就是增加Jenkins Slave来协同工作。

但是增加Jenkins Slave又会引出新的问题，资源不能按需调度。Jobs少的时候资源闲置，而Jobs突然增多仍然会资源不足。我们希望能动态分配Jenkins Slave，即用即拿，用完即毁。这恰好符合K8S中Pod的特性。所以这里，我们在K8S中搭建一个Jenkins集群，并且是Jenkins Slave in Pod.

1.1 准备镜像

我们需要准备两个镜像，一个是Jenkins Master，一个是Jenkins Slave：

Jenkins Master

可根据实际需求定制Dockerfile

FROM jenkins/jenkins:latest
USER root
# Set jessie source
RUN cecho '' > /etc/apt/sources.list.d/jessie-backports.list \
  && echo "deb http://mirrors.aliyun.com/debian jessie main contrib non-free" > /etc/apt/sources.list \
  && echo "deb http://mirrors.aliyun.com/debian jessie-updates main contrib non-free" >> /etc/apt/sources.list \
  && echo "deb http://mirrors.aliyun.com/debian-security jessie/updates main contrib non-free" >> /etc/apt/sources.list
# Update
RUN apt-get update && apt-get install -y libltdl7 && apt-get clean
# INSTALL KUBECTL
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl && \
    chmod +x ./kubectl && \
    mv ./kubectl /usr/local/bin/kubectl
# Set time zone
RUN rm -rf /etc/localtime && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
    echo 'Asia/Shanghai' > /etc/timezone
# Skip setup wizard、 TimeZone and CSP
ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false -Duser.timezone=Asia/Shanghai -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';\""

Jenkins Salve

一般来说只需要安装kubelet就可以了

FROM jenkinsci/jnlp-slave
USER root
# INSTALL KUBECTL
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl && \
    chmod +x ./kubectl && \
    mv ./kubectl /usr/local/bin/kubectl

生成镜像后可以push到自己的镜像仓库中备用

1.2 部署Jenkins Master

为了部署Jenkins、Jenkins Slave和后续的Elastic Search，建议ECS的最小内存为8G

在K8S上部署Jenkins的yaml参考如下：

apiVersion: v1
kind: Namespace
metadata:
  name: jenkins-ci
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-ci
  namespace: jenkins-ci
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: jenkins-ci
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: jenkins-ci
  namespace: jenkins-ci
---
# 设置两个pv，一个用于作为workspace，一个用于存储ssh key
apiVersion: v1
kind: PersistentVolume
metadata:
    name: jenkins-home
    labels:
      release: jenkins-home
    namespace: jenkins-ci
spec:
	# workspace 大小为10G
    capacity:
      storage: 10Gi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    # 使用阿里云NAS，需要注意，必须先在NAS创建目录 /jenkins/jenkins-home
    nfs:
      path: /jenkins/jenkins-home
      server: xxxx.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: jenkins-ssh
    labels:
      release: jenkins-ssh
    namespace: jenkins-ci
spec:
	# ssh key 只需要1M空间即可
    capacity:
      storage: 1Mi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    # 不要忘了在NAS创建目录 /jenkins/ssh
    nfs:
      path: /jenkins/ssh
      server: xxxx.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-home-claim
  namespace: jenkins-ci
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 10Gi
  selector:
    matchLabels:
      release: jenkins-home
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jenkins-ssh-claim
  namespace: jenkins-ci
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 1Mi
  selector:
    matchLabels:
      release: jenkins-ssh
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: jenkins
 namespace: jenkins-ci
spec:
 replicas: 1
 template:
  metadata:
   labels:
    name: jenkins
  spec:
   serviceAccount: jenkins-ci
   containers:
   - name: jenkins
     imagePullPolicy: Always
     # 使用1.1小结创建的 Jenkins Master 镜像
     image: xx.xx.xx/jenkins:1.0.0
     # 资源管理，详见第二章
     resources:
      limits:
        cpu: 1
        memory: 2Gi
      requests:
        cpu: 0.5
        memory: 1Gi
     # 开放8080端口用于访问，开放50000端口用于Jenkins Slave和Master的通讯
     ports:
       - containerPort: 8080
       - containerPort: 50000
     readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 40
      periodSeconds: 20
     securityContext:
       privileged: true
     volumeMounts:
     	 # 映射K8S Node的docker，也就是docker outside docker，这样就不需要在Jenkins里面安装docker
       - mountPath: /var/run/docker.sock
         name: docker-sock
       - mountPath: /usr/bin/docker
         name: docker-bin
       - mountPath: /var/jenkins_home
         name: jenkins-home
       - mountPath: /root/.ssh
         name: jenkins-ssh
   volumes:
     - name: docker-sock
       hostPath:
         path: /var/run/docker.sock
     - name: docker-bin
       hostPath:
         path: /opt/kube/bin/docker
     - name: jenkins-home
       persistentVolumeClaim:
          claimName: jenkins-home-claim
     - name: jenkins-ssh
       persistentVolumeClaim:
          claimName: jenkins-ssh-claim
---
kind: Service
apiVersion: v1
metadata:
  name: jenkins-service
  namespace: jenkins-ci
spec:
  type: NodePort
  selector:
    name: jenkins
  # 将Jenkins Master的50000端口作为NodePort映射到K8S的30001端口
  ports:
  - name: jenkins-agent
    port: 50000
    targetPort: 50000
    nodePort: 30001
  - name: jenkins
    port: 8080
    targetPort: 8080
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: jenkins-ingress
 namespace: jenkins-ci
 annotations:
      nginx.ingress.kubernetes.io/proxy-body-size: "0"
spec:
  rules:
  # 设置Ingress-Nginx域名和端口
  - host: xxx.xxx.com
    http:
      paths:
      - path: /
        backend:
          serviceName: jenkins-service
          servicePort: 8080

最后附一下SLB的配置

这样就可以通过域名xxx.xxx.com访问Jenkins，并且可以通过xxx.xxx.com:50000来链接集群外的Slave。当然，集群内的Slave直接通过serviceName-namespace:50000访问就可以了

1.3 配置Jenkins Slave

以管理员进入Jenkins，安装”Kubernetes”插件，然后进入系统设置界面，”Add a new cloud” - “Kubernetes”，配置如下：

Kubernetes URL：https://kubernetes.default.svc.cluster.local
Jenkins URL：http://jenkins-service.jenkins-ci:8080
Test Connection 测试看连接是否成功
Images - Add Pod Template - Kubernetes Pod Template
注意设置Name为”jnlp-agent”，其他按需填写，设置完成后进入Advanced
根据需要设置资源管理，也就是说限制Jenkins Slave in Pod所占用的CPU和内存，详见第二章
设置Volume，同样采用docker outside docker，将K8S Node的docker为Jenkins Slave Pod所用；设置Jenkins Slave的工作目录为NAS
设置最多允许多少个Jenkins Slave Pod 同时运行，然后进入Advanced
填写Service Account，与部署Jenkins Master的yaml文件中的Service Account保持一致；如果你的Jenkins Slave Image是私有镜像，还需要设置ImagePullSecrets
Apply并完成

1.4 测试验证

我们可以写一个FreeStyle Project的测试Job：

测试运行：

可以看到名为”jnlp-agent-xxxxx”的Jenkins Salve被创建，Job build完成后又消失，即为正确完成配置。

二、K8S资源管理

在第一章中，先后提到两次资源管理，一次是Jenkins Master的yaml，一次是Kubernetes Pod Template给Jenkins Slave 配置。Resource的控制是K8S的基础配置之一。但一般来说，用到最多的就是以下四个：

Request CPU：意为某Node剩余CPU大于Request CPU，才会将Pod创建到该Node上
Limit CPU：意为该Pod最多能使用的CPU为Limit CPU
Request Memory：意为某Node剩余内存大于Request Memory，才会将Pod创建到该Node上
Limit Memory：意为该Pod最多能使用的内存为Limit Memory

比如在我这个项目中，Gitlab至少需要配置Request Memory为3G，对于Elastic Search的Request Memory也至少为2.5 G.

其他服务需要根据K8S Dashboard中的监控插件结合长时间运行后给出一个合理的Resource控制范围。

三、Harbor

在K8S中跑CI，大致流程是Jenkins将Gitlab代码打包成Image，Push到Docker Registry中，随后Jenkins通过yaml文件部署应用，Pod的Image从Docker Registry中Pull.也就是说到目前为止，我们还缺一个Docker Registry才能准备好所有CI需要的基础软件。

利用阿里云的镜像仓库或者Docker HUB可以节省硬件成本，但考虑数据安全、传输效率和操作易用性，还是希望自建一个Docker Registry. 可选的方案并不多，官方提供的Docker Registry v2轻量简洁，vmware的Harbor功能更丰富。

Harbor提供了一个界面友好的UI，支持镜像同步，这对于DevOps尤为重要。Harbor官方提供了Helm方式在K8S中部署。但我考虑Harbor占用的资源较多，从节省硬件成本来说，把Harbor放到了K8S Master上（Master节点不会被调度用于部署Pod，所以大部分空间资源没有被利用）。当然这不是一个最好的方案，但它是最适合我们目前业务场景的方案。

在Master节点使用docker compose部署Harbor的步骤如下：

192.168.0.1安装docker-compose
1
pip install docker-compose
192.168.0.1 data目录挂载NAS路径（harbor的volume默认映射到宿主机的/data目录，所以我们把宿主机的/data目录挂载为NAS即可实现用NAS作为harbor的volume）
1
2
mkdir /data
mount -t nfs -o vers=4.0 xxx.xxx.com:/harbor /data

参考https://github.com/vmware/harbor/blob/master/docs/installation_guide.md 安装

根据需要下载指定版本的 Harbor offline installer

解压后配置harbor.cfg

# 域名
hostname = xx.xx.com
# 协议，这里可以使用http可以免去配置ssl_cert，通过SLB暴露至集群外再加上ssh即可
ui_url_protocol = http
# 邮箱配置
email_identity = rfc2595
email_server =  xx
email_server_port = xx
email_username = xx
email_password = xx
email_from = xx
email_ssl = xx
email_insecure = xx
# admin账号默认密码
harbor_admin_password = xx

修改docker-compose.yaml中的端口映射，这里将容器端口映射到宿主机的23280端口

proxy:
    image: vmware/nginx-photon:v1.5.0
    container_name: nginx
    restart: always
    volumes:
      - ./common/config/nginx:/etc/nginx:z
    networks:
      - harbor
    ports:
     - 23280:80
     #- 443:443
     #- 4443:4443
    depends_on:
      - mysql
      - registry
      - ui
      - log
    logging:
      driver: "syslog"
      options:
        syslog-address: "tcp://127.0.0.1:1514"
        tag: "proxy"

运行install.sh

修改 kubeasz的 roles/docker/files/daemon.json加入”insecure-registries”节点，如下所示

{
  "registry-mirrors": ["https://kuamavit.mirror.aliyuncs.com", "https://registry.docker-cn.com", "https://docker.mirrors.ustc.edu.cn"], 
  "insecure-registries": ["192.168.0.1:23280"],
  "max-concurrent-downloads": 10,
  "log-driver": "json-file",
  "log-level": "warn",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

重新安装kubeasz的docker

1	ansible-playbook 03.docker.yml

这样在集群内的任何一个节点就可以通过http协议192.168.0.1:23280 访问harbor

开机启动

vi /etc/rc.local
# 加入如下内容
# mount -t nfs -o vers=4.0 xxxx.com:/harbor /data
# cd /etc/ansible/heygears/harbor
# sudo docker-compose up -d
chmod +x /etc/rc.local

设置Secret（K8S部署应用时使用Secret拉取镜像，详见系列教程第三篇）

在K8S集群任意一台机器使用命令

1	kubectl create secret docker-registry regcred --docker-server=192.168.0.1:23280 --docker-username=xxx --docker-password=xxx --docker-email=xxx

设置SLB（如果仅在内网使用，不设置SLB和DNS也可以）
登陆Harbor管理页面
在集群内通过docker login 192.168.0.1:23280验证Harbor是否创建成功

四、EFK

最后我们来给集群加上日志系统。

项目中常用的日志系统多数是Elastic家族的ELK，外加Redis或者Kafka作为缓冲队列。由于Logstash需要运行在java环境下，且占用空间大，配置相对复杂，随着Elastic家族的产品逐渐丰富，Logstash开始慢慢偏向日志解析、过滤、格式化等方面，所以并不太适合在容器环境下的日志收集。K8S官方给出的方案是EFK，其中F指的是Fluentd，一个用Ruby写的轻量级日志收集工具。对比Logstash来说，支持的插件少一些。

容器日志的收集方式不外乎以下四种：

容器外收集。将宿主机的目录挂载为容器的日志目录，然后在宿主机上收集。
容器内收集。在容器内运行一个后台日志收集服务。
单独运行日志容器。单独运行一个容器提供共享日志卷，在日志容器中收集日志。
网络收集。容器内应用将日志直接发送到日志中心，比如java程序可以使用log4j2转换日志格式并发送到远端。
通过修改docker的–log-driver。可以利用不同的driver把日志输出到不同地方，将log-driver设置为syslog、fluentd、splunk等日志收集服务，然后发送到远端。

docker默认的driver是json-driver，容器输出到控制台的日志，都会以 *-json.log 的命名方式保存在 /var/lib/docker/containers/ 目录下。所以EFK的日志策略就是在每个Node部署一个Fluentd，读取/var/lib/docker/containers/ 目录下的所有日志，传输到ES中。这样做有两个弊端，一方面不是所有的服务都会把log输出到控制台；另一方面不是所有的容器都需要收集日志。我们更想定制化的去实现一个轻量级的日志收集。所以综合各个方案，还是采取了网上推荐的以FileBeat作为日志收集的“EFK”架构方案。

FileBeat用Golang编写，输出为二进制文件，不存在依赖。占用空间极小，吞吐率高。但它的功能相对单一，仅仅用来做日志收集。所以对于有需要的业务场景，可以用FileBeat收集日志，Logstash格式解析，ES存储，Kibana展示。

使用FileBeat收集容器日志的业务逻辑如下：

也就是说我们利用K8S的Pod的临时目录{}来实现Container的数据共享，举个例子：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  replicas: 2
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - image:  #appImage 
        name: app
        volumeMounts:
        - name: log-volume
          mountPath: /var/log/app/  #app log path
      - image:  #filebeatImage
        name: filebeat
        args: [
          "-c", "/etc/filebeat.yml"
        ]
        securityContext:
          runAsUser: 0
        volumeMounts:
        - name: config
          mountPath: /etc/filebeat.yml
          readOnly: true
          subPath: filebeat.yml
        - name: log-volume
          mountPath: /var/log/container/
      volumes:
      - name: config
        configMap:
          defaultMode: 0600
          name: filebeat-config
      - name: log-volume 
        emptyDir: {} #利用{}实现数据交互
      imagePullSecrets:
      - name: regcred
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
  namespace: test
  labels:
    app: filebeat
data:
  filebeat.yml: |-
    filebeat.inputs:
    - type: log
      enabled: true
      paths:
        - /var/log/container/*.log #FileBeat读取log的源
    output.elasticsearch:
      hosts: ["xx.xx.xx:9200"]
    tags: ["test"] #log tag

实现这种FileBeat作为日志收集的“EFK”系统，只需要在K8S集群中搭建好ES和Kibana即可，FileBeat是随着应用一起创建，无需提前部署。搭建ES和Kibana的方式可参考K8S官方文档，我也进行了一个简单整合：

ES:

# RBAC authn and authz
apiVersion: v1
kind: ServiceAccount
metadata:
  name: elasticsearch-logging
  namespace: kube-system
  labels:
    k8s-app: elasticsearch-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: elasticsearch-logging
  labels:
    k8s-app: elasticsearch-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups:
  - ""
  resources:
  - "services"
  - "namespaces"
  - "endpoints"
  verbs:
  - "get"
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kube-system
  name: elasticsearch-logging
  labels:
    k8s-app: elasticsearch-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
subjects:
- kind: ServiceAccount
  name: elasticsearch-logging
  namespace: kube-system
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: elasticsearch-logging
  apiGroup: ""
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: es-pv-0
    labels:
      release: es-pv
    namespace: kube-system
spec:
    capacity:
      storage: 20Gi
    accessModes:
      - ReadWriteMany
    volumeMode: Filesystem
    persistentVolumeReclaimPolicy: Recycle
    storageClassName: "es-storage-class"
    nfs:
      path: /es/0
      server: xxx.nas.aliyuncs.com  # 用NAS来作为ES的数据存储，需要提前在NAS创建目录/es/0
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: es-pv-1
    labels:
      release: es-pv
    namespace: kube-system
spec:
    capacity:
      storage: 20Gi
    accessModes:
      - ReadWriteMany
    volumeMode: Filesystem
    persistentVolumeReclaimPolicy: Recycle
    storageClassName: "es-storage-class"
    nfs:
      path: /es/1
      server: xxx.nas.aliyuncs.com   # 用NAS来作为ES的数据存储，需要提前在NAS创建目录/es/1
---
# Elasticsearch deployment itself
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch-logging
  namespace: kube-system
  labels:
    k8s-app: elasticsearch-logging
    version: v5.6.4
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  serviceName: elasticsearch-logging
  replicas: 2
  selector:
    matchLabels:
      k8s-app: elasticsearch-logging
      version: v5.6.4
  template:
    metadata:
      labels:
        k8s-app: elasticsearch-logging
        version: v5.6.4
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: elasticsearch-logging
      containers:
      - image: registry-vpc.cn-shenzhen.aliyuncs.com/heygears/elasticsearch:5.6.4 # 可替换成私有仓库
        name: elasticsearch-logging
        resources:
          # need more cpu upon initialization, therefore burstable class
          limits:
            cpu: 1
            memory: 2.5Gi
          requests:
            cpu: 0.8
            memory: 2Gi
        ports:
        - containerPort: 9200
          name: db
          protocol: TCP
        - containerPort: 9300
          name: transport
          protocol: TCP
        volumeMounts:
        - name: elasticsearch-logging
          mountPath: /data
        env:
        - name: "NAMESPACE"
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
      # Elasticsearch requires vm.max_map_count to be at least 262144.
      # If your OS already sets up this number to a higher value, feel free
      # to remove this init container.
      initContainers:
      - image: alpine:3.6
        command: ["/sbin/sysctl", "-w", "vm.max_map_count=262144"]
        name: elasticsearch-logging-init
        securityContext:
          privileged: true
  volumeClaimTemplates:
  - metadata:
      name: elasticsearch-logging
    spec:
      accessModes: [ "ReadWriteMany" ]
      storageClassName: "es-storage-class"
      resources:
        requests:
          storage: 20Gi
---
apiVersion: v1
kind: Service
metadata:
  name: elasticsearch-logging
  namespace: kube-system
  labels:
    k8s-app: elasticsearch-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/name: "Elasticsearch"
spec:
  type: NodePort
  ports:
  - port: 9200
    protocol: TCP
    targetPort: db
    nodePort: xxx  # 以NodePort方式暴露端口，供集群外访问ES
  selector:
    k8s-app: elasticsearch-logging

Kibana:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana-logging
  namespace: kube-system
  labels:
    k8s-app: kibana-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: kibana-logging
  template:
    metadata:
      labels:
        k8s-app: kibana-logging
    spec:
      containers:
      - name: kibana-logging
        image: registry-vpc.cn-shenzhen.aliyuncs.com/heygears/kibana:5.6.4 # 也可替换成自己的私有仓库
        resources:
          # need more cpu upon initialization, therefore burstable class
          limits:
            cpu: 1
            memory: 1.5Gi
          requests:
            cpu: 0.8
            memory: 1.5Gi
        env:
          - name: ELASTICSEARCH_URL
            value: http://elasticsearch-logging:9200
          - name: SERVER_BASEPATH
            value: /api/v1/namespaces/kube-system/services/kibana-logging/proxy
          - name: XPACK_MONITORING_ENABLED
            value: "false"
          - name: XPACK_SECURITY_ENABLED
            value: "false"
        ports:
        - containerPort: 5601
          name: ui
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: kibana-logging
  namespace: kube-system
  labels:
    k8s-app: kibana-logging
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/name: "Kibana"
spec:
  ports:
  - port: 5601
    protocol: TCP
    targetPort: ui
  selector:
    k8s-app: kibana-logging

评论和共享

Docker 入门教程

7月 31, 2018 发布在 virtualization

该教程仅对docker常用操作进行了总结归纳

一、什么是Docker

Docker是2013年，dotCloud用Golang开发的基于LXC的高级容器引擎

1.1 什么是LXC

Linux Container的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace

1.2 什么是容器

是一个相对独立的运行环境

1.3 容器和虚拟机的区别

	Docker	虚拟机
启动速度	秒级	分钟级
启动方式	启动应用	启动Guest OS + 启动应用
交付、部署	Docker镜像（Dockerfile）	虚拟机镜像
更新	修改Dockerfile或发布新镜像	向虚拟机推送补丁升级包
操作系统	Linux x64	Linux、Windows、Mac OS等
磁盘占用率	低	高
性能利用率	高	中
成熟度	发展中	高
稳定性	发展中	高
隔离性	中	高
数据保留	删除后销毁	删除后销毁

二、 Docker的3个概念

Docker	Git	OOD
Image	Repository Code	Class
Container	Local Code	Instance
Registry	GitHub/GitLab

2.1 Image

镜像，Docker Image是一系列操作的集合，每一组操作形成一个layer，每个layer有一个id，并说明该layer依赖的前一个layer的id，多个layer堆叠形成Image，注意理解一组操作的意义
Image是静态的，不能直接使用。像面向对象中的类，也像Git中放在仓库中的代码
可以给Image设置Repository，同一个Image ID可以有多个Repository，Repository的命名规范是“Registry Name/Image Name”，若Registry Name为空，则默认Registry为Docker HUB
可以给Image设置Tag，同一个Image ID可以有多个标签Tag，若tag为空，则默认Tag为latest，表示最新的镜像
Image可以在本地通过Container Commit生成，亦可用Dockerfile生成，还可以从Registry Pull下来

2.2 Container

容器，Docker Container 是Image的实例化对象
Container是动态的，可以使用的。像面向对象中的对象，也像Git中被pull到本地的代码，而且代码可以编译和运行
Container经过一系列操作后，并不会影响Image，如果需要生成新的Image，需要做类似git的流程对Container进行Commit操作
Container删除会导致Container中的数据消失，从Image启动新的Container是一个全新的容器，不能发现或共享其他Container中的数据

2.3 Registry

仓库，Docker Registry 是存放Image的地方
Registry像GitHub、Gitlab一样，有官方提供的Docker HUB，也可以自己搭建
Registry里面的项目有公开和私有两种权限，公开项目下的镜像可以被任何人pull，私有项目的镜像只能被Registry分配权限的用户pull

三、 Docker 版本与安装

Docker分为CE和EE版，CE版免费，EE收费、注重安全并能给企业提供技术支持
Docker在各个操作系统上的安装方式见官网 https://www.docker.com
在Windows下亦可使用基于DockerToolBox的项目 https://github.com/sonicrang/Docker_FrontEnd ，控制台输入5直接进入Docker环境

四、 Docker常用指令

4.1 Image 指令

docker images

查询所有镜像
docker tag

“复制”一个Image副本，并重新命名（包括Repository Name、Image Name和Tag）
- docker tag f06 my/redis:4
  
  f06a5773f01e 可以简写开头的几位
- docker tag redis:latest redis:4
- docker tag redis my/redis
  
  表示把redis:latest 复制为 my/redis:latest
docker rmi

删除指定的镜像
- docker rmi redis:4
  
  删除redis:4 这个Image，若该Image ID在本地有其他名称或Tag，则只移除这个Tag
- docker rmi f06
  
  删除Image ID缩写为f06的 Image，该Image ID的所有副本（不同的Repository、Image Name和Tag）都会被删除
- docker rmi -f f06
  
  默认情况下，rmi指令只能删除没有Container的Image；通过-f 参数可以强制删除有Container但Container是停止状态的Image；不能直接删除有运行状态Container的Image，必须先停止、删除Container后再删除Image
docker history

查询指定镜像的操作历史
- docker history f06
  
  查看镜像的所有历史操作，甚至可以通过该指令看出镜像是如何构建出来的，但对于Container的操作在这里无法体现
docker inspect

查询指定镜像的详细信息
- docker inspect f06

4.2 Container 指令

docker run

从Image运行一个新Container
- docker run --name myRedis f06
  
  从Image运行容器并通过–name 命名为myRedis
- docker run -it f06 bash
  
  从Image运行容器，随机名称，-it 是 -i和-t，表示交互并重定向到控制台，bash表示容器入口，不填则进入镜像的默认入口
- docker run -d f06
  
  -d 表示后台执行
docker ps

查看容器列表
- docker ps
  
  查看仅在运行状态的Container
- docker ps -a
  
  查看所有状态的Container
docker inspect

查看指定容器的详细信息
- docker inspect myRedis
docker exec

进入指定的容器
- docker exec -it myRedis bash
  
  以交互模式进入myRedis 容器的bash
- docker exec -u root -it myRedis bash
  
  同上，但以root用户登录
docker stop/start/restart

停止/启动/重启容器
- docker stop myRedis
- docker start myRedis
- docker restart myRedis
docker rm

删除指定的容器
- docker rm myRedis
  
  删除名为myRedis 且状态为退出、停止的容器
- docker rm 3c7
  
  删除ID简写为3c7且状态为退出、停止的容器
- docker rm -f myRedis
  
  强制删除名为myRedis 的容器，不管容器是否正在运行

4.3 Registry 指令

docker login

登录指定的docker registry
- docker login -u test -p xxx hub.docker.com
  
  以用户test，密码为xxx登录Docker HUB
docker pull

从指定的docker registry pull指定的Image，对于私有镜像，必须先用docker login登录registry
- docker pull test/redis:4
  
  从Docker HUB的test用户拉取redis:4 镜像
- docker pull a.b.com/test/redis:4
  
  从a.b.com这个registry的test用户拉取redis:4 镜像
docker push

把指定Image push到docker registry，必须先用docker login登录registry
- docker tag redis:latest a.b.com/test/common/redis:4
- docker push a.b.com/test/common/redis:4
  
  把redis:lastet复制为a.b.com/test/common/redis:4，并push到a.b.com的test用户的common项目下，镜像名为redis，Tag为4

4.4 练习

从Docker HUB pull一个Nginx Image
运行Nginx Container，并访问默认页面
进入容器删除 /usr/share/nginx/html/index.html ，提交容器到新镜像
关闭容器，从旧镜像启动Nginx Container，访问页面并观察
关闭容器，从新镜像启动Nginx Container，访问页面并观察
注册Docker HUB账号，将新镜像提交至自己的Docker HUB

五、 Docker Volume

由于Docker Container释放后不能保存数据，并且Container之间不能共享数据，所以需要“外接一个存储”用于数据的持久化和共享。这就是挂载卷Volume

PS：因为非Linux环境的Docker都是基于Linux虚拟机，所以在非Linux环境下使用Docker Volume需注意以下几点：

如果使用DockerToolBox，需要给虚拟机挂载共享目录，只有这个目录可以作为Volume
如果使用https://github.com/sonicrang/Docker_FrontEnd 我已经在控制台封装好设置虚拟机共享目录的功能，方法为控制台输入1，即可将本机目录例如”e:\test”挂到虚拟机”/develop”下，只有”/develop”目录可以作为Volume

挂载示例：

docker run -v /develop/nginx/log:/var/log/nginx --name myNginx nginx

将宿主机的”/develop/nginx/log” 空目录挂载到容器的”/var/log/nginx”，启动容器后，对于linux系统，可以在宿主机”/develop/nginx/log”看到容器内的日志文件；对于使用DockerToolBox或者Docker_FrontEnd，会在本机的”e:\test”看到容器中的内容。当容器删除后，宿主机目录中的日志文件会被保留下来
docker run -v nginx:/var/log/nginx --name myNginx nginx

将宿主机的空目录”/var/lib/docker/volumn/nginx” 挂载到容器的”/var/log/nginx”，也就是说宿主机的目录可以填写为相对目录，相对于一个docker的默认安装目录
docker run -v /var/log/nginx --name myNginx nginx

将宿主机的空目录”/var/lib/docker/volumn/containerID” 挂载到容器的”/var/log/nginx”，也就是说宿主机的目录可以不填，默认为docker安装目录对应的containerID目录
docker run -v /develop/nginx/html:/usr/share/nginx/html --name myNginx nginx

注意在之前的例子中，我们把空目录挂载到容器的空文件夹中（因为log是运行容器后才产生的）。但在这个例子中，我们把空目录挂载到容器的非空文件夹”/usr/share/nginx/html”，由于挂载源是空文件夹，会覆盖掉挂载目标也就是”/usr/share/nginx/html”的内容，这样就导致nginx的html文件丢失，所以切记不要用一个空目录挂载到容器在运行前的非空目录下，如果我们要在挂载源控制nginx的html文件内容，那就必须要保证挂载源非空且存在html文件

docker run -v /develop/nginx/html/index.html:/usr/share/nginx/html/index.html:ro --name myNginx nginx

将宿主机的”/develop/nginx/html/index.html”文件以只读的形式挂载到容器的”/usr/share/nginx/html/index.html”

六、容器网络

6.1 访问容器

对于linux下的docker，本机IP+端口就可以访问容器，比如127.0.0.1就可以访问nginx容器
对于DockerToolBox和Docker_FrontEnd，要访问虚拟机的IP+端口，默认为192.168.99.100

但是此时输入URL还不可以访问容器，因为端口还没有映射

6.2 端口映射

docker run -p 80:80 --name myNginx nginx

把容器的80端口映射到宿主的80端口，这样就可通过宿主机IP:80访问nginx容器
docker run -p 8080:80 --name myNginx nginx

把容器的80端口映射到宿主的8080端口，这样就可通过宿主机IP:8080访问nginx容器
docker run -p 8080:80 -p 8081:81 --name myNginx nginx

把容器的80端口映射到宿主的8080端口，同时把容器81端口映射到宿主的8081端口
docker run -p 8080-8085:80-85 --name myNginx nginx

把容器的80、81、82、83、84、85端口映射到宿主的8080、8081、8082、8083、8084、8085端口
docker run -P --name myNginx nginx

把容器的所有开放端口随机映射到宿主

6.3 容器间通讯

相同宿主机下有两个容器A、B

容器A内部端口80映射到宿主的8080

容器B访问容器A的方法如下：

宿主IP:8080

如 curl 192.168.99.100:8080
容器A IP:80

如 curl 172.17.0.2

容器A的IP获取需要使用命令docker inspect A

七、 Dockerfile

在2.1小结我们提到Image其实是一系列操作的层堆叠起来。但是传统的commit方式不能很好的呈现Image是如何构建的。试想一个场景，搭建一个软件运行环境的Image，这个Image会随着业务、时间不断更新，如果运维人员想看Image究竟是怎样堆叠起来的，只能用history指令，不利于查看为维护。所以这又引出了2.1小结提到的另一个概念Dockerfile

7.1 Dockerfile编写方式

下面的示例是将一个golang程序打包成Image

# FROM关键字 说明原始镜像
FROM golang:1.9.2-alpine3.6 
# RUN关键字用于执行命令
RUN apk add --no-cache git
RUN go get github.com/golang/dep/cmd/dep
# COPY Dockfile上下文目录的Gopkg.lock Gopkg.toml 到镜像的/go/src/project目录下，注意如果是目录，最后不要忘了/
COPY Gopkg.lock Gopkg.toml /go/src/project/
# WORKDIR 关键字相当于切换目录
WORKDIR /go/src/project/
RUN dep ensure -vendor-only
# COPY Dockfile上下文目录的所有文件到镜像的/go/src/project目录下
COPY . /go/src/project/
RUN go build -o /bin/project
# 暴露端口80，参考6.2小结，如果使用-P映射（大写P），用以告诉docker，容器的80端口是开放的，可以映射出去
EXPOSE 80
# 设置入口，相当于通过镜像启动容器后，进入"/bin/project"，该配置可以被docker run --entrypoint xxx app 强行覆盖
ENTRYPOINT ["/bin/project"]
# 执行命令，该配置可以被docker run app xxx 强行覆盖
CMD ["--help"]

什么是Dockerfile的上下文？需要了解Dockerfile的构建方式

7.2 Dockerfile构建方式

docker build -t myRepo/myAPP:latest .

注意最后的那个点”.”，查找当前目录名为Dockerfile的文件，构建Image并命名为myRepo/myAPP:latest
docker build -f myRepo/myAPP:latest -f myDockerfile

查找当前目录名为myDockerfile的文件，构建Image并命名为myRepo/myAPP:latest

在上面两个例子中，Dockfile的上下文就是指Dockerfile文件所在的目录，先看下图：

左右两幅图目录结构不同，如果Dockerfile具有同样的内容：

1 2	FROM XXX COPY . /target

那么左边的目录结构，最终被放到镜像”/target”目录中的文件应该只有”run.sh”这个文件，而右边的目录结构，最后在”/target”中的是”document”和”source_code”的文件夹及内容。

八、 Docker Compose

试想一个业务场景，我们有一个服务容器A需要连接数据库，把数据库装到A的镜像里不是一个明智的选择，一般情况下我们会再搭建一个容器B作为数据库，那么这时，两个容器如何关联？这里的关联不仅包括如何保证两个容器如何同时管理，还包括两个容器如何通讯。这就引出来容器编排的概念，我们需要对容器进行一系列的调整，以满足我们的业务需要。

Docker Compose 需要额外安装，详情见https://docs.docker.com/compose/install/

Docker Compose是用于管理多容器的Docker应用。看一个示例：

docker-compose.yaml

# 标明用docker compose的哪个版本，不同版本兼容的指令有区别
version: '3'
# 服务编排
services:
  # 服务名称
  nginx:
    # 镜像地址
    image: nginx
    # 容器名称，不填则为“服务名_序号”
    container_name: nginx
    # 设置volume
    volumes:
    - nginx.conf:/etc/nginx/nginx.conf:ro
    # 端口映射
    ports:
    - "8080:80"
  api:
    image: xxx.com/api:latest
    container_name: api

nginx.conf

server{
	listen 80;
	server_name xxx.yyy.com;
	location / {
       	proxy_pass http://api;
  		}
}

上面的服务编排就是对api容器做了一个nginx反向代理，可以看到使用docker-compose可以让容器间的通讯更加简单，直接用Container Name加Container内部端口即可。

使用docker-compose必须将文件命名成”docker-compose.yaml”，使用方法如下：

首先进入”docker-compose.yaml”文件所在目录

docker-compose up -d

根据编排生成所需的容器并启动，-d表示后台执行
docker-compose start

启动编排的容器
docker-compose stop

停止编排的容器
docker-compose restart

重启编排的容器
docker-compose pull

强制拉取编排所需的镜像，因为在上例中，api使用的是latest镜像，当又有新的lastest镜像被push到Registry时，如果本地又存在一个旧的api:latest，那么docker compose 不会自动更新镜像，需要强制用”docker-compose pull”强制拉取，再执行”docker-compose up”
docker-compose build

docker compose的容器镜像还可以直接用Dockerfile
1
2
3
4
5
version: '3'
services:
api:
build: ./
container_name: api
表示编排容器时，需要先在本地用Dockerfile构建一个镜像，如果Dockerfile文件发生改变，而本地又有旧镜像，那么docker compose 同样不会自动更新镜像，需要执行”docker-compose build”强制构建，再执行”docker-compose up”

评论和共享

我的三十岁

7月 11, 2018 发布在 life

孔老夫子说：“吾十有五，而志于学。三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲，不逾矩” 。然而我的而立之年，却是感受了两次“死亡”……

阅读全文

阿里云Kubernetes实战1--集群搭建与服务暴露

4月 27, 2018 发布在 architecture

阿里云K8S集群尚不成熟，使用的版本也相对较老，不能及时更新版本
阿里云K8S集群目前只支持多主多从结构，同时限定Master节点只能是3个，不能增减，这对于小型业务或者巨型业务均不适用
自建原生K8S集群更有利于拓展和理解整体结构

接下来会详细介绍在阿里云搭建原生Kubernetes集群的过程。

一、K8S集群搭建

下面的实战操作基于阿里云的VPC网络，在4台ECS上搭建K8S单主多从集群，部署Gitlab，Gitlab的数据存储在阿里云NAS上，服务通过SLB暴露至外网

阿里云VPC * 1
- EIP * 2
- NAT网关 * 1
- 共享流量包 * 1
阿里云ECS（无外网IP） * 4
阿里云SLB * 4
阿里云NAS * 1

1.1 VPC组网

对于VPC，新建交换机，目标网段用192.168.0.0/24，4台ECS的内网IP分别设置为192.168.0.1 ~ 192.168.0.4

1.2 NAT网关与EIP打通网络

由于VPC网络内，所有的ECS没有配置外网IP，所以这里要配置NAT网关和弹性IP来打通外网和VPC的通讯。

开通一个NAT网关，并加入到VPC内
开通两个EIP，一个用于DNAT(VPC访问外网)，另一个用于SNAT(外网访问EIP)
绑定EIP到NAT网关
配置DNAT(外网访问VPC)
- 我们有4台ECS，每台机器的22端口分别映射到EIP的不同端口上，如23301~23304，该端口用于SSH访问ECS
- 同时映射192.168.0.1的6443端口到EIP上，如映射至23443端口，该端口用于访问K8S集群的API，见第二章内容
配置SNAT(VPC访问外网)

配置完成后，便可以使用绑定DNAT的EIP的映射端口通过SSH访问ECS

1.3 使用Kubeasz部署K8S集群

搭建K8S集群相对比较简单，使用kubeasz的AllinOne部署即可

修改hosts文件，根据实际环境配置master、node、etc的ip
这里将192.168.0.1设置为master，使用单主多从的方式
配置完成后重启所有ECS

二、部署Gitlab实战

2.1 K8S Dashboard

部署好集群后，我们可以使用DNAT的EIP，通过映射端口23443访问K8S API和Dashboard

https://EIP:Port/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy

进入后会要求输入API的账号密码，与1.3章节hosts文件里配置的账号密码一致
通过账号密码验证后可看到K8S Dashboard登录界面
令牌可在Master节点通过以下命令获取

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

2.2 PV与PVC

K8S中的PV和PVC的概念这里不再多提，引用官方的一段解释：

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only).

在Gitlab for Docker中，我们看到Volumes 有三个，如下表所示

Local location	Container location	Usage
`/srv/gitlab/data`	`/var/opt/gitlab`	For storing application data
`/srv/gitlab/logs`	`/var/log/gitlab`	For storing logs
`/srv/gitlab/config`	`/etc/gitlab`	For storing the GitLab configuration files

所以我们也需要给Gitlab for K8S分配3个PV和PVC，这里我们用到了阿里云NAS

给NAS添加挂载点，选择VPC网络和VPC的交换机
查看挂载地址
SSH登录Master节点，挂载NAS，并创建文件夹（注意PV的path必须已存在才可以成功建立，所以需要先在NAS中创建文件夹）
1
2
3
4
5
mkdir /nas
sudo mount -t nfs -o vers=4.0 xxx.xxx.nas.aliyuncs.com:/ /nas
mkdir -p /gitlab/data
mkdir -p /gitlab/logs
mkdir -p /gitlab/config

编写PV和PVC的YAML，根据实际需求替换server节点的NAS挂载地址配置以及storage大小配置

apiVersion: v1  
kind: Namespace  
metadata:  
    name: gitlab  
    labels:  
      name: gitlab
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: gitlab-data
    labels:
      release: gitlab-data
    namespace: gitlab
spec:
    capacity:
      storage: 500Gi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /gitlab/data
      server: xxx.xxx.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: gitlab-config
    labels:
      release: gitlab-config
    namespace: gitlab
spec:
    capacity:
      storage: 1Gi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /gitlab/config
      server: xxx.xxx.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
    name: gitlab-log
    labels:
      release: gitlab-log
    namespace: gitlab
spec:
    capacity:
      storage: 1Gi
    accessModes:
      - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /gitlab/log
      server: xxx.xxx.nas.aliyuncs.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gitlab-data-claim
  namespace: gitlab
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 500Gi
  selector:
    matchLabels:
      release: gitlab-data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gitlab-config-claim
  namespace: gitlab
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 1Gi
  selector:
    matchLabels:
      release: gitlab-config
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gitlab-log-claim
  namespace: gitlab
spec:
  accessModes:
    - ReadWriteMany
  resources:  
    requests:
      storage: 1Gi
  selector:
    matchLabels:
      release: gitlab-log

2.3 K8S部署Gitlab

接下来补全Gitlab的Deployment和Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab
  namespace: gitlab
spec:   
  selector:
    matchLabels:
      app: gitlab
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: gitlab
    spec:
      containers:
      - image: gitlab/gitlab-ce:latest
        name: gitlab
        ports:
        - containerPort: 80
          name: gitlab-http
        - containerPort: 443
          name: gitlab-https
        - containerPort: 22
          name: gitlab-ssh
        volumeMounts:
        - name: gitlab-config
          mountPath: /etc/gitlab
        - name: gitlab-log
          mountPath: /var/log/gitlab
        - name: gitlab-data
          mountPath: /var/opt/gitlab
      volumes:
      - name: gitlab-data
        persistentVolumeClaim:
          claimName: gitlab-data-claim
      - name: gitlab-config
        persistentVolumeClaim:
          claimName: gitlab-config-claim
      - name: gitlab-log
        persistentVolumeClaim:
          claimName: gitlab-log-claim
---
kind: Service
apiVersion: v1
metadata:
  name: gitlab-service
  labels:
    app: gitlab-service
  namespace: gitlab
spec:
  selector:
    app: gitlab
  ports:
  - protocol: TCP
    name: gitlab-https
    port: 443
    targetPort: 443
  - protocol: TCP
    name: gitlab-http
    port: 80
    targetPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: gitlab-ssh-service
  labels:
    app: gitlab-ssh-service
  namespace: gitlab
spec:
  type: NodePort
  selector:
    app: gitlab
  ports:
  - protocol: TCP
    name: gitlab-ssh
    port: 22
    targetPort: 22
    nodePort: 30000

注意在Deployment中，开放了Gitlab Pod的80、443和22端口，用于Gitlab的HTTP、HTTPS和SSH的访问
创建了2个Service，第一个只将80和443端口开放到Cluster IP上，第二个Service通过NodePort将22端口映射到NodeIp的30000端口上
我们将2.2章节PV与PVC中的相关代码和上面的代码合并，并命名成gitlab.yaml，上传到Master节点，执行命令
1
kubectl apply -f gitlab.yaml

接下来进入Gitlab的Pod，修改gitlab的域名，并启用https访问

kubectl get pod --namespace=gitlab
# 获得gitlab pod名称后
kubectl exec -it gitlab-xxxx-xxxx --namespace=gitlab /bin/bash
# 进入pod后
vi /etc/gitlab/gitlab.rb
# 修改external_url 'https://xxx.xxx.com'，保存后退出
gitlab-ctl reconfigure
exit

到这里，配置与部署基本完成了，但我们还不能从外网访问Gitlab，不过至少可以在集群内验证配置是否正确。

在Master节点查看Service
1
kubectl get svc --namespace=gitlab
可以看到443和80端口已经开发给Cluster IP，同时22端口映射到了30000的NodePort上
通过curl命令查看访问结果
1
curl https://10.68.88.97 --insecure
这时返回一串包含redirect的字符，如下

<html><body>You are being <a href="https://10.68.88.97/users/sign_in">redirected</a>.</body></html>

表示服务已部署成功
如果有telnet客户端，还可以验证30000端口，在任何一个节点上执行任意一条命令
1
2
3
4
telnet 192.168.0.1:30000
telnet 192.168.0.2:30000
telnet 192.168.0.3:30000
telnet 192.168.0.4:30000

2.4 使用Ingress-Nginx和阿里云SLB暴露服务

K8S暴露服务的方法有3种：

ClusterIP：集群内可访问，但外部不可访问
NodePort：通过NodeIP:NodePort方式可以在集群内访问，结合EIP或者云服务VPC负载均衡也可在集群外访问，但开放NodePort一方面不安全，另一方面随着应用的增多不方便管理
LoadBalancer：某些云服务提供商会直接提供LoadBalancer模式，将服务对接到负载均衡，其原理是基于kubernetes的controller做二次开发，并集成到K8S集群，使得集群可以与云服务SDK交互

由于我们的集群搭建在阿里云上，所以第一时间想到的是LoadBalancer方案，但很遗憾，没办法使用，原因如下：

阿里云自己提供的Kubernetes集群才可以使用LoadBalancer，但我们是自己在阿里云上搭建的，不具备这个功能
阿里云也有开源的alicloud-controller-manager，但长期没有更新，同时网上现有的资料都过时很久，版本对应不上

回归到NodePort的方式，目前已有的解决方案是基于Ingress的几款工具，如Ingress-Nginx、Traefik-Ingress，他们的对比如下（注意，目前的版本是IngressNginx 0.13.0、Traefik 1.6）：

IngressNginx和Traefik都是通过hostname方式反向代理已解决端口暴露问题
IngressNginx依赖于Nginx，功能更多；Traefik不依赖Nginx，所以更轻量
IngressNginx支持4层和7层LB，但4层也不好用，Traefik只支持7层代理
目前网上关于IngressNginx的文章都是beta 0.9.X版本的信息，而IngressNginx在Github的地址也变化了，直接由Kubernetes维护，所以网上的文章基本没参考性，还需看官方文档，但是官方文档极其混乱和不完善！！！ 后面会有填坑指南。

最终我们还是选择了Ingress-Nginx，结合阿里云SLB，最终的拓扑图如下所示：

其原理是：

通过Service的ClusterIP负载Pod
通过Ingress-Nginx监听Ingress配置，动态生成Nginx，并将Nginx暴露到23456的NodePort
通过阿里云SLB监听所有节点的23456端口

接下来看详细步骤。

2.4.1 部署Ingress-Nginx

主要参考https://kubernetes.github.io/ingress-nginx/deploy/，并做一些小调整

替换gcr.io的镜像为阿里云镜像
暴露服务端口到NodePort 23456
整合成一个ingress-nginx.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app: default-http-backend
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: default-http-backend
  template:
    metadata:
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissible as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: registry.cn-shenzhen.aliyuncs.com/heygears/defaultbackend:1.4
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app: default-http-backend
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: default-http-backend
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
        - events
    verbs:
        - create
        - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ingress-nginx
  template:
    metadata:
      labels:
        app: ingress-nginx
      annotations:
        prometheus.io/port: '10254'
        prometheus.io/scrape: 'true'
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: registry.cn-shenzhen.aliyuncs.com/heygears/nginx-ingress-controller:0.13.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --annotations-prefix=nginx.ingress.kubernetes.io
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
          - name: http
            containerPort: 80
          - name: https
            containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
---
kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx-service
  namespace: ingress-nginx
spec:
  selector:
    app: ingress-nginx
  ports:
    - protocol: TCP
      port: 80
      # 从默认20000~40000之间选一个可用端口，让ingress-controller暴露给外部的访问
      nodePort: 23456
  type: NodePort

上传到Master节点后执行命令：

1	kubectl apply -f ingress-nginx.yaml

2.4.2 给gitlab配置ingress

修改2.3章节的gitlab.yaml，添加

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gitlab-ingress
  namespace: gitlab
  annotations:
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true" # 强制http重定向到https
      nginx.ingress.kubernetes.io/ssl-passthrough: "true" # 将请求时的ssl传递到此，如果后台监听80端口，则无需此配置
      nginx.ingress.kubernetes.io/proxy-body-size: "0" # 设置client_max_body_size为0
spec:
  rules:
  - host: git.xxx.com  # hostname
    http:
      paths:
      - path: /
        backend:
          serviceName: gitlab-service
          servicePort: 443 # 监听443端口

重新执行

1	kubectl apply -f gitlab.yaml

这里就有几个坑了：

网上很多关于Ingress-Nginx的文章比较老旧，与新版annotations的配置不同，还是要以官方文档为准
annotations的配置与nginx实际配置的名称不同，不要错填，还是要以文档为准。比如上面例子中，nginx.ingress.kubernetes.io/proxy-body-size 实际上在nginx里是client_max_body_size，不要错填成nginx.ingress.kubernetes.io/client_max_body_size
官方文档也有不清楚的地方，比如部分配置没有示例说明，还有的示例错误。比如上面例子中，官方给出的例子是

而事实上，value必须用双引号，否则配置将无效

2.4.3 设置阿里云SLB

阿里云SLB的设置比较简单

后台服务器添加所有的K8S节点
配置监听，HTTP：80 -> 23456 ，HTTPS：443 -> 23456 并配置SSL证书， TCP：22 -> 30000，需要注意的是HTTP和HTTPS监听需要勾选SLB监听协议，以配合2.4.2章节中的force-ssl-redirect重定向，HTTPS中的SSL将配合ssl-passthrough传递到后台
把SLB的公网IP添加到域名解析

至此，所有的配置完成。

评论和共享

下一页
第 1 页共 13 页

1. 背景

2. 架构

3. 技术

3.1 阿里云MQ的设计和使用

3.2 rocketmq-client-go踩坑

4. 功能

4.1 注册

4.2 软件更新（非ota）

4.3 远程控制

1. 共享服务体系搭建

2. 服务中心建设

3. 数据拆分

4. 异步化

5. 数字化运营（异常追踪和定位）

6. 平台稳定性

7. 服务化野蛮生长面临的问题

一、跨域

1. 为什么会存在跨域

2. 什么是同源策略

3. 如何定义同源

4. 同源策略存在的意义是什么

5. CSRF跨域请求伪造

6. 跨站Frame DOM查询

7. XSS跨站脚本攻击

8. 如何解决跨域

9. Origin和Referer

二、REST Ful

1. 什么是REST Ful

2. 什么是简单请求

3. 什么是非简单请求

4. 如何实践REST Ful

5. 如何用复杂条件进行查询

6. 手机浏览器HTTPS协议问题

三、分布式服务

1. 什么是分布式服务

2. 如何在分布式服务下使用存储

3. 如何在分布式服务下使用定时消费任务

4. 如何处理分布式事务

1. IP模式

2. Pod与Service的DNS

3. Statefulset 与Headless Service

4. hostname模式

目录

一、一机多Jenkins Slave

二、 二次开发Jenkins 钉钉通知插件

三、 DevOps解决方案

目录

一、Jenkins

1.1 准备镜像

1.2 部署Jenkins Master

1.3 配置Jenkins Slave

1.4 测试验证

二、K8S资源管理

三、Harbor

四、EFK

目录

一、 什么是Docker

1.1 什么是LXC

1.2 什么是容器

1.3 容器和虚拟机的区别

二、 Docker的3个概念

2.1 Image

2.2 Container

2.3 Registry

三、 Docker 版本与安装

四、 Docker常用指令

4.1 Image 指令

4.2 Container 指令

4.3 Registry 指令

4.4 练习

五、 Docker Volume

六、 容器网络

6.1 访问容器

6.2 端口映射

6.3 容器间通讯

七、 Dockerfile

7.1 Dockerfile编写方式

7.2 Dockerfile构建方式

八、 Docker Compose

目录

二、二次开发Jenkins 钉钉通知插件

一、什么是Docker

六、容器网络